I searched and have not found the answer soooo here it goes. (1st post so I am nervous)
We are currently using 3DS Max and Maya for production into Unity. I initially thought doing a manual export to FBX would be the best route to go, but I am getting issues of consistency when importing.
Would it be better to develop a pipeline around directly importing the .ma or .max files into Unity? Are there any issues with directly importing?
I started exploring this and am reminded of the problem we had before… need software license on Unity machine. Nevermind on the question now I get to figure out FBX exporting.
is there a particular reason to use both 3dsmax and maya?
Because we are awesome!
Varied skill base and varied number of licenses.
We will conform eventually…i hope
Maya is a great platform to build upon, and Max is great for content development, so I certainly understand the desire to use both.
We are just jumping into Unity and are currently using FBX to go from Maya to Unity. Though the export to FBX is scripted per the type of asset. So far this has worked well. What types of inconsistencies do you see?
In my Unity projects I always had some weird importing issues with .fbx’s, but once you get the settings consistent it works great. Are you getting inconsistencies between the 3ds Max .fbx’s and the Maya .fbx’s, or is Unity just not liking the files?
I feel like I’ve had more issues trying to import .ma’s into Maya than .fbx’s though… It’s all about getting it right once and remembering the setting that Unity prefers.
Its hard to know what to suggest without knowing the inconsistencies but have you checked out the free Unity tutorials on 3D Buzz? They cover the .fbx export from Maya(in sometimes too verbose detail).
Keep using direct FBX transfer, exporting ( saving ) .ma or .max files directly to unity, does nothing more than invisible launching the host app (maya or max) and let it do the FBX export, but you loose flexibility ( no options dialog )…
Important thing is finding a working FBX version ( fbx updates tend to break things not so obvious at first glance) and working setting and stick with that as long as you can…
Some inconsistencies will stay, purely because of the fact Max is Z-up and Maya Y-up, and unity is like Maya in that regard, thus Max model/hierarchy imports have some initial rotation on the rootnode and Maya imports will not…
If you have pro licenses for Unity, you can use the AssetPostprocessor methods to automagmically fix up any inconsistencies between Maya and Max fbx files upon import (depending on what sort of inconsistencies you’re experiencing).
Care to elaborate on the inconsistencies?
Also, when you do a direct import of .ma/.max files, all Unity is doing is transparently doing a commandline export to .fbx (this means Maya or Max will need to be installed on any machine doing imports).
[ninja’d on that last point by spacefrog!]
We leverage the AssetPostprocessor to avoid the intermediate FBX files that clog up the pipeline. Not only do we avoid having the extra file around that doesn’t really do anything, we get added benefits of being able to interact with the Maya nodes before it gets exported.
For example, I have it examining the file’s materials and creating new (or updating old) materials right in Unity with proper hookups and attributes. It creates plain diffuse materials for lamberts and specular materials for blinn/phong. It also automates the naming/placing of all the materials at this time as well so that we don’t get multitudes of extra material files in Unity.
Another thing we do with it is import lights and cameras so that we can actually do most of a scene setup in Maya if we need to. There is still the need to tweak this in Unity after the fact, but it gets us 80% of the way there.
You don’t get any of that with the standard FBX export method.
I haven’t tried messing with materials with the postprocessor, but I did something similar with lights and cameras, and also nodes for any scene-specific things (in my case, nodes for interactive objects in a point-n-click adventure) in an FBX file. (Now I decided to go with FBX because I don’t have Max (or Maya) installed on my machine).
I just had a maxscript done up that would go through the scene pre-import and rename any lights and cameras to include FOV, type, color, etc. The FBX file would basically have empties in place of the cameras and lights (and nodes), but with the correct position and rotation. I made use of that on import to create the appropriate lights and cameras in Unity (as well as offsetting the rotation to account for Max’s z-up vs Unity’s y-up). As with Andy, this was mainly so as much scene setup as possible can be done in the DCC app.
[QUOTE=spacefrog;11609]Keep using direct FBX transfer, exporting ( saving ) .ma or .max files directly to unity, does nothing more than invisible launching the host app (maya or max) and let it do the FBX export, but you loose flexibility ( no options dialog )…
[/QUOTE]
The primary thing you gain with direct saving is there is another point to “preprocess” the files in the "C:\Program Files (x86)\Unity\Editor\Data\Tools"
FBXMaxExport.ms
and
FBXMayaExport.mel
Downside being that it just launches max/maya in the background and runs the above script silently, so its not exactly a fast process.
as an addition to the Assetpostprocessor, if you haven’t seen it yet, there’s a good walkthru of some of the possibilities by Adam @ http://adammechtley.com/2011/04/an-automated-pipeline-for-generating-run-time-rigs/
that said, I go FBX myself with heavy assetprotprocessing to setup scenes and components and prefabs on import.