Hey guys!
Maya’s preferred system units are centimeters and most features/plugins seem to work best with that.
However we’re looking into working with meters, since our engine uses meters and it would make building mocap sets etc. a bit easier.
From my what I found there seems to be no equivalent to 3dsmax’s display units in maya.
Do you know any way of changing the way maya displays units without changing what’s happening internally?
Thanks!
-Sascha
what is “3dsmax’s display unit”
you can change the units in Maya from the UI -> windows -> settings and preferences -> preferences -> catagory: settings, working units
or use the mel command “currentUnit” to set it,
currentUnit -query -linear; // return the current linear unit?
currentUnit -linear “m”; // Change the current linear unit to meters
[mm | millimeter | cm | centimeter | m | meter | km | kilometer | in | inch | ft | foot | yd | yard | mi | mile]
Usually we just leave maya in centimeters, convince ourselves that we are really looking at Meters and perform a scale at export. Switching to Meters can cause some headaches (at least in the past, maybe its better now).
Max can stay in centimeters but the entire UI will display those as feet or meters etc… Maya can’t do this.
Changing display units in Max but not the system units can cause all sorts of confusion (although that’s mostly if you forget to change system units from inches to metric and then change the display units to metric), so I’d generally recommend against it.
In the past at previous jobs we’ve scaled on export (automatically in the exporter to avoid confusing artists) to take us from cms to m. Now we’re working directly in metres and it’s a real pain.
Oh yes, The max system units can cause huge amounts of pain but if you just want to display them or adjust them for visual sanity, it is nice, Maya doesn’t do it.
Scale on export was and is a good solution.
[QUOTE=bclark;16886]Oh yes, The max system units can cause huge amounts of pain but if you just want to display them or adjust them for visual sanity, it is nice, Maya doesn’t do it.
Scale on export was and is a good solution.[/QUOTE]
I don’t agree. The whole point of Display units is to allow the display, widgets, plugins etc to make goods decisions on default values and provide effective user interaction, while allowing exporters and render engines to work at the best level of numeric accuracy.
System units allow you to avoid the export on scale issue. Garbage in\Garbage out. If your pipeline has other geometry transformations or conversions in it, much less if you are editing levels or just working in something other than world-space as local-space on individual meshes, accuracy issues count.
[QUOTE=apocalypse2012;17176]I don’t agree. The whole point of Display units is to allow the display, widgets, plugins etc to make goods decisions on default values and provide effective user interaction, while allowing exporters and render engines to work at the best level of numeric accuracy.
System units allow you to avoid the export on scale issue. Garbage in\Garbage out. If your pipeline has other geometry transformations or conversions in it, much less if you are editing levels or just working in something other than world-space as local-space on individual meshes, accuracy issues count.[/QUOTE]
Good in theory, but in reality setting display units does nothing to the interactivity or defaults of any tools. For example set system units and display units to metres. Make a one metre cube. Convert to editable poly. Select one edge. Open the chamfer options and drag the amount spinner one pixel. It’ll chamfer by something like 0.1 m. Far too big. Change display units to mm and try again. One pixel will be 100mm. Still 0.1 m.
The same is true of weld defaults. It defaults to 0.1 of System units, regardless of the display units. So if I have a 0.1m box and display units is cms, then rather than a default of 0.1 m destroying the box, I get a default of 10cms and the box is still destroyed.
So actually it makes no real difference to the defaults what you set the display units to. It’s still system units that count.
But is does, the examples above all suffer from accuracy issue caused my system units that are too large. Your system units should reflect the accuracy you require in your scene. Your display units reflect the reference scale your are actually working in. Display units should always be larger. Usually by an order of magnitude or more.
If you are working on a box that is .1 meters, then your display units should be CMs and your system units should be MMs at a minimum. Your export behavior will not be directly taken from either. Your target scale for export should be transformed from Display units to Target units to maximize accuracy.
That is all system units are for. Describing the numeric accuracy of system units relative to display units. As a result, System units must be less than Display units, by as wide a margin as is necessary for the smallest geometry details.
We can’t do that. Our game worlds are large. We need metres to get reasonable accuracy across the world. If we were to use cms, we’d lose accuracy at somewhere around the 1km range. Not enough by far. We don’t need less than 0.1mm accuracy. It would be stripped out on export anyway. Although I know max works best at the cm range (due to hard coded defaults across the board) programmers on every game I’ve worked on have specified m as world units. If we set it to mm as system units and m for display units they’d just tell us everything was 1000 times too big. They want a 1m cube to come out as 1 unit, not 1000.
And I don’t see how adjusting the display units makes any difference at all except for convenience. It’s the system units that get exported.
It doesn’t have to be. Of course, you may be limited by tech decisions you have no control over, none the less… Generally I recommend exporting from display units and scaling to target engine units. That way Max’s accuracy is pegged to the asset file and not some fix relationship to game-engine world units.
Second, trying to build a whole world using 3dsmax as your editor is hella problematic. Doable, but a scope and schedule killer. To accomplish it requires Blockouts in game world units and art assets at units appropriate to their scale. Then using xRefs. xRefs can be set up to auto scale to the current scene, but this only matters for getting a view of your placement. You would be exporting the assets from their source files and picking up the transforms only from the World file.
Either way, world building in any 3D DCC app is going to be hard. It gets much much harder if you force all your data to conform to the same coordinate system. The tools are there to avoid that, its just another layer or management work to coordinate, but it is worth it. If you must peg your data to one scale, pin your display units and vary the system units.
More accurately, your export should not be making assumptions about what max units mean. You are given a tool to describe what Max units mean in any given scene. Scaling on export is not bad. Using a fixed scale factor that ignores your system unit settings is bad. You can set your system units to equal 1 mm on prop scene and 3 meters on level scenes and export to 1 meter in your game engine. All you have to do is look at your system unit setting first, then scale the export geo by the ration defined by source system unit settings to target game export units.
The confusion between system/display units makes me think the less ideal but more straightforward ‘single unit’ approach was probably a better decision. I’m very willing to code logic to overcome host program stupidity but it helps when I know what to expect.
That sounds ripe for confusion and heart ache when it came time to merge objects together. That’s where the idea of just sticking with a fixed system unit scale came from in the first place. 
[QUOTE=apocalypse2012;17184]Second, trying to build a whole world using 3dsmax as your editor is hella problematic. Doable, but a scope and schedule killer. To accomplish it requires Blockouts in game world units and art assets at units appropriate to their scale. Then using xRefs. xRefs can be set up to auto scale to the current scene, but this only matters for getting a view of your placement. You would be exporting the assets from their source files and picking up the transforms only from the World file.
Either way, world building in any 3D DCC app is going to be hard. It gets much much harder if you force all your data to conform to the same coordinate system. The tools are there to avoid that, its just another layer or management work to coordinate, but it is worth it. If you must peg your data to one scale, pin your display units and vary the system units.[/QUOTE]
It really isn’t, but that depends a bit on the type of game. Sounds like you’re thinking of something where the world is just a list of instanced props. Like a tileset or to a lesser extent UE. I’ve never worked on a game like that. Sounds like making unique one off variations, or organic landscapes with everything stitched neatly together are a real problem with that method.
Nearly every single game I’ve ever worked on has been built mostly out of unique world geometry in something like Max. It does have problems (the interface making asumptions about scale being a big one) but it gives us huge flexibility in how things are made. If I want an object that’s similar to another one, but a slightly different shape, or has some variation or has to fit on a weirdly shaped hill or angled road, making those changes is dead easy. And it all stitched together perfectly because that’s in the hands of the env artist.
Stick to your world unit scale, all your objects are the same size. Merge things in or work with containers (our current method). Use Xrefs or similar to import instanced props (we have our own alternative as xrefs are rubbish). Works fine really.
I wouldn’t suggest this sort of approach for something made out of snapping tiles together though. There are better tools if all you’re doing is positioning pre-made objects.
I get your point Robin. If its all snow flake then the most direct approach does makes the most sense. In fact, the modular instance approach becomes a huge pain in the junk for no reason. You have already explicitly committed to a single coordinate system.
Rob: You are right from the perspective of Maya. Actually, Plunkett and I were just talking about this. Max differs from Maya in a critical sense that the unit parameters reflect. In Max you are not really building a Node graph. Yes, Max has a node-like structure, but it is much more fixed, not like Maya’s toy-box of general case widgets.
As a result, Max’s objects are more complex, purpose specific, and driven my a much thicker layer of state, context, and UI. This is where it gets tricky. The GUIs don’t just push input to the nodes, they are much more intimately connected. They are part of the scene down to the reference system. That is why Maya has History and Max has an undo system.
Where the Display units come in, its more about presentation verses how numeric accuracy is distributed across the scene. You may need MM accuracy to 5 significant digits, but you don’t want to see that in your UI, when your moving objects around etc. That is why the Display units are made to be change frequently and do not require a scale on the scene. The UI can take advantage of this to present its UI according to the display units. Not only can numeric data be shown in units that are easier to rationalize, but even Viewport interactions can be scaled up to reflect the increments that the user has chosen.
Not sure it is the best method to go with, but that is what they did.