Our current project is a 3DSMax to Custom game engine, SO I’m reasonably fluent in MXS, and just learning C#/ .NET
We’ll use Max bones and custom rigs (not Biped / CAT),
and most likely export minimal data via FBX rather than opening native max files in unity.
I have learned that our next Project will be a Unity, which I have used rarely for personal projects,
but never as a TA for a full on production pipeline.
So, I’m wondering if there some important or unusual things to know / beware of about building a pipeline from Max to unity,
as I begin tamping up my learning.
What kind of tools support /scripting does unity have?
C# seems like a useful tool, I suppose I should push forward with my learning there…
What is the best way to get MAX to talk to unity and vice versa?
Can unity materials be displayed / edited in Max?
My goal is always to give the modelers / animators a “one button to engine” solution,
and I am not sure how well I can hook up the Max textures and materials to Unity Shaders in some scripted fashion.
Has anyone encountered an unexpected p[pitfall dealing with unity?
You’ll be using FBX as the primary transport mechanism. Materials will come through as placeholders only (these faces = this name), though you can get it to bring the texture references along if you export the texture files to the same location as the FBX. I would not invest a lot of energy in trying to preserve the Max material settings, the common workflow is to have max and Unity open at the same time, export model changes, and then hop over to unity to see them live. Unity will auto-reimport changed fbxs on the fly so you don’t have to do anything special to see the changes; and that way artists can work on the materials that the game uses not on proxies/approximations in max. If you’re targeting mobile you’ll probably be using pretty low end shaders anyway, so it’s better for your artists to see the real output thing and adjust course accordingly.
For cross communications, Unity includes an AssetPostprocessorclass that can run a function per model - or even per transform inside a model - on import. This is a great way to do things like automatically set import options from Max, or tell Unity to add collision volumes to different parts of a skeleton, or whatnot. You’ll want to make sure to standardize scale, and coordinate system settings and enforce them. Unity looks like the Maya (y-up) coord sys but it is flipped on the X axis so it matches neither Max nor Maya . However it’s usually pretty good about doing those kind of conversions for you if your art is in FBX.
Unity usually works on ‘loose’ C# files - change it and unity recompiles on the fly - but it also supports external assemblies if you load them in to a ‘plugins’ folder in your Unity project. You can share code between Unity and Max by compiling dot net assemblies from c# and accessing them from MaxScript and from Unity. If you were really ambitious you could use a remoting library like WCF or ZeroMQ to do live communications from Max to Unity, but I’m not sure I see a use case.
Unity keeps all of the assets in the game in a single folder hierarchy (the “Assets” folder) . You’ll probably need to create a parallel hierarchy (ours is the “Source” folder) to store original files that you care about but which don’t belong inside the game exe. Our system is to auto export files from source to identically named/located files in assets so there’s little confusion.
Unity’s asset management system is not strong for big teams using traditional source control. You’ll need to bone up on Unity meta files. Metafiles are text based files that describe assets to the system and they need to be lockstepped with the assets they represent - invest some time in perforce triggers or similar that make it hard for people to check in a file without it’s associated .meta or vice versa. One nice thing about metas is that they can include both asset tags and arbitrary user info - I use them to store a bunch of metadata from the exporter - and they are plain text YAML files so you can scan them from outside of Unity – I do this to make an local database inside our user’s Mayas which lets them find all the assets in the game by name or tag w/o using the file system dialog.
Unity has a lot of warts - it’s an unfamiliar way off working and its big enough nowadays that it has weird little quirks you’ll need to discover and work around. However it’s a TA playground - lots of extensibility, easy access to the guts of the editor and the data structures, and very modular architecture that lets you make neat, targeted interventions without having to beg your engine team to tweak some funky C++ metaprogramming template hell for you.
AssetServer != version control. What it does is cache imported versions of assets - that way if user X has imported Y.fbx (which may take several seconds) when user Z opens up Unity he gets the cached version from the asset server instead of re-importing it locally. Since the alternative is having everybody re-import all changed assets after every sync, it’s a big time saver. But it does nothing for version control in the perforce sense of the word.
Unity 4.2 > includes version control support if you have pro, that puts in-UI checkins and checkouts. it’s a good thing to get set up right away because it will minimize problems with assets and metafiles (see above) getting out of sync.
You may want to check these links out as well to further expound upon what Theodox said about AssetPostprocessor.
For our work we setup a maxscript system to add custom definitions to objects such that when those attributes stored in the definitions are read in Unity using the OnPostprocessGameObjectWithUserProperties event, you can do something specific like:
CharacterMaterialNumber1_shader = Transparent/Cutout/Diffuse > sets the shader of the material “CharacterMaterialNumber1” to Transparent/Cutout/Diffuse