Maya units meter vs centimeter.


Hi Guys !

When using maxwell it is highly recommended to work with correct units , so you have to keep your scene as physicall as you can, thus in maya a human must be around 175 units (cm).

It would be more convenient to switch pref from cm to m. But i’ve always learn that Maya has to work in cm if you want to “Stay out of trouble”.
This post looks to confirm this.

So here is my question, in 2014 do we still need to keep working in Centimeters if we want to avoid any problem. Or can we now work in Meters.

Thanks for your input




Hi E

I think you can work on miles if you want as long you remember that cm IS the unit Maya uses internally on variety of different things eg. basic rigid body dynamics .

As long as you’re aware of this, you can do whatever you need / want to do ->
meaning when the shit starts to hit the fan, you’re able to debug and pinpoint the problem parts in your scene.

My two centimeters 8)



Thanks for your help Risto !

The fact that maya is working in cm at his core is still an argument to keep cm in the defaults pref. Cause if you work with 10 others guys , with some that has their pref at cm , while other have switch to meter, i’m afraid you will fall on some problem. Like the good old 24fps -> 25fps offset in animation problem.

Thus i guess i will keep my scene in cm in maya …:slight_smile:

I ask this because i’ve met some pb with maya to houdini export.
even if you set your scene in metter in maya when you export throw .abc to houdini you still have to *0.01 to match your maya scale in houdini.

if you work in cm in maya you will find that export will match in houdini. but again maxwell need clean unity to work properly ! so i will go with the

  • 1m = 100 unit in maya
  • 1m = 1 unit in houdini
  • maya object *0.01 = houdini object (for correct scale equivalence)


I’m not very familiar with Maxwell, but in mental ray (for example) it’s kinda weird at first. I model in inches/feet like a good ol’ fashioned elitist jerk still, due to the nature of my construction design, and found it works best to convert the units at 1=1 over in Maya when I import my CAD geometry. So I resize the imported .obj group by .394, and bring it down to centimeter size. It just makes the lights look more natural and predictable, at quadratic falloff.

But mental ray doesn’t care. 1 unit in Maya = 1 cm in mental ray’s lighting calculations, so if for example you had meters set to your units in Maya, MR will treat them as centimeters at rendertime and you’d need to wind down your lighting /10 to make it look proper.

I hope that makes sense, it gets a bit nebulous to describe, but for years I had this exact problem, and my lights looked all blown out as I was trying to correct for scale while maintaining quadratic falloff.


Hi Emmanuel

if you work in cm in maya you will find that export will match in houdini. but again maxwell need clean unity to work properly ! so i will go with the

  • 1m = 100 unit in maya
  • 1m = 1 unit in houdini
  • maya object *0.01 = houdini object (for correct scale equivalence)

This is funky, because when I do a polygon cube ( size 5,5,5 ) in Maya, export it as an abc, import to Houdini, it’ll turn up as 5,5,5 size cube, not .05,.05,.05.

I wonder what is going on here…



Yes Risto, the thing is that when you create a 555 polycube in maya it’s scale is 5cm * 5cm *5cm when you throw it in maxwell.

when you export this cube with .abc inside houdini , in fact it has at first glance the exact same size , 555. But the difference here is that in houdini you have a cube that has a size of 5m * 5m * 5m. Thus in maxwell or any physicall engine i guess, you have a huge scale factor of 0.01.

I could be wrong, but i’m quite sure that if you want to keep coherent units for your rendering engine you have to *0.01.

I’m happy to see that mental ray also respect this , while it’s annoying it force you to keep coherent scale.

the weird thing is that if i’m correct for the nucleus node, 1 maya unit = 1 metter , so if you have a 30 unit objects in maya with default prefs.

  • it is 30cm for all the software
  • it is 30m for the nucleus , and you have to modify nucleus scale to *0.1 to get coherent result
    => That’s quite inelegant but i’m maybe missing something

Thanks for your inputs guys ! :slight_smile:




Hi Emmanuel

so now I’m bit lost here -> what’s you intended workflow ?

Model in Maya, do funky effects in Houdini and then back to Maya for lighting and output ?

Or something else ?



Sorry Risto, if i’m not perfectly clear here ! :slight_smile: ( my english doesn’t help … )

Well the goal is to be able to work in parallel in both software.
The beauty of maxwell is that at the end your lighting / shading rig is compose of

  • light = geometry objects than can be exported
  • shaders = external file with .mxs extension (like .sl)
  • map = .exr/.hdr if you have env maps

So you can export and switch from maya to houdini and get exactly the same result. lighter can work in maya , fx guy can work lookdev in H. The only condition you must respect to switch from Maya to Houdini is to respect scale units. If you respect that you can work in either software you will have exactly the same render in both tools.

Alembic export look to don’t give you the option of entering the scale units of the software you are working with. so if you want to export your .abc from maya to H you have to do this scale by 0.01. Proper workflow would have been to choose the input and output unit (cm to m for ex)

Of course i can be absolutely wrong about all this , i just try to be sure to work in the most correct way ! :slight_smile:

Thanks for your help !


Hi Emmanuel

This all sounds somewhat correct to me.
Of course you are able to automate this with a little scripting so when you export abc, you’ll trigger the scaling before that etc etc.
But in the end, this is how I imagine everything should be ok.



My other full 3D app, LightWave, handles units really well, and I had gotten used to just working in metric/meters, but also easily changing the input/display units to feet/inches when modeling from e.g. engineering drawings which use English units.

However, I’ve never really gotten Maya to work perfectly when setting default scene units to anything other than their default cm. Meters makes the most sense to me in terms of it’s easily describing real world objects as tiny as a few millimeters, or environment pieces as large as several city blocks. But you end up having to always fix their incorrect camera settings such as clipping distances and ortho camera width when you create a new scene.

The two issues already mentioned:

  1. of what scale/units assumptions other programs make when importing Maya assets;
  2. the many places for numeric input in Maya where they don’t necessarily specify in the UI but do make implicit assumptions about the input units;

make me conclude it probably makes more pragmatic sense to not fight Maya on this point and just go along with the default.


Maya is such a sorry mess when it comes to units. especially with physical based rendering and dynamics. I would start making some pipeline decisions and stick with them. At my facility Maya units are set to cm. All FX and some rendering is done in Houdini Mantra. Assets coming out from Maya are checked into a database and automatically scaled up on their way to Houdini’s native scale. I would look at what maxwell requires unit wise and make sure all incoming assets are set to that scale. This function should be part of your basic pipeline asset checkin tools.

Alembic export look to don’t give you the option of entering the scale units of the software you are working with. so if you want to export your .abc from maya to H you have to do this scale by 0.01. Proper workflow would have been to choose the input and output unit (cm to m for ex)

You should be stripping all the rubbish out of Maya and optimizing your assets > then setting scale and then exporting as a .abc for Houdini. You should be thinking in terms of assets. The lighting team should be assembling there scenes with “assets” . This work should be all done by your pipeline TD .



Yep, I think that’s what it really boils down to. What will be the least hassle when moving your assets through your production pipeline in which Maya is a major component. Because of Maya’s pervasiveness, the other apps I use already understand this problem and provide the means to deal with the unit/scale conversion… Once those “rules” are set up, it becomes a non-issue.


With Maya as the center of my 3D software universe, I use Maya native cm scale and since I also use MotionBuilder and Mudbox both seam to like that scale as well so that is what I use. Usually I am sizing things up by 100 coming in from other software I use (Blender/LightWave) - or before. And when doing dynamics nucleus is set to .01. Worked out that in the beginning and seems to be the way to go all around. So agree, just stick with something through the pipeline.


To be clear, Maya appears to respect units just fine. You just need do the conversions manually. If I model in centimeters in Rhino, it comes in as centimeters in Maya, since the units are 1:1. But since I live in this ridiculous throwback culture, I model in inches generally.

The conversion is only important when I need to make mental ray behave, and even then only locally. Since I scale down from inches to cm on the group itself, the individual geometries retain their size ratios, so that in MR 1cm becomes 1 inch, for modeling purposes. This also gives an easier lighting math since quadratic falloff becomes predictable.


Thanks for all your input guys ! :slight_smile:

  I think i will stay in CM to avoid swiming against the flow.
  I haven't the same luck as you with mudbox, in facts :
  - i set mudbox units as CM in prefs
  - i set maya units as CM in prefs
  - i have a cube of 100CM (1M ) in Maya that i send to Mudbox  
  - when the cube arrive in Mudbox his size is 1CM so again there is a *0.01 during export.
  How do you manage to get things works correctly beetween Maya and Mudbox 2014 ?
  Bob and Risto i agree the best way is to clean the mess in script before .abc export. 
  Bob in France the idea of having a database to store and check assets is Science Fiction ... :)
  The concept of having a pipeline TD that manage all, to make things runs smoothly is a LUXURY that happen in rare occasion but you can't count on this ... 
  I would be quite interested to know what sort of database you use, is it some sort of classic SQL database, like PostgreSQL for ex ?


Well that’s pretty short sighted. Having a flexible and efficient pipeline saves time which = money.



Having a flexible and efficient pipeline does save money, yes. However, the fact that you need to hire a pipeline TD just so you can overcome your software’s retarded way of handling scale (among other things) is far from efficient. Especially for small studios and freelancers.

But unfortunately, when your talking about maya and having it play well with others, that’s pretty much your only real option if you want things to run smoothly.


Yeah when you have different software that wants things to be a different size - generally - say between Maya and Softimage it is an issue you need to work out and just deal with.

The first thing I always attack on my pipeline is scale. The nice thing about Mobu and Maya is they seem to get along just fine. Muddox seems to like the larger Maya models too. Softimage I think is .1 to Maya, Blender is.01. And if memory serves a unit in Blender is a Meter in LightWave so since I always consider a unit in Blender to be 1M that all works.

Then setting the nucleus node to .01 handles the1M scale there.

So it is really just a matter of working it all out and sticking with it.


Chad I must ask the question then why on earth are you using Maya ? . You should be using a package like Houdini, which requires no plugins and scripts to get basic functionality.
You only have yourself to blame for using Maya. On a side note I will say my facility has all but ditched Maya now for everything but Animation / Rigging.



This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.