[3dsmax] Referencing to replace XRef

Tools 3ds Max
1

Hi all:

So I’ve been looking at getting some sort of character rig referencing going in 3ds max as I’m preparing to start writing rigging tools for a project here that’s heavily based around it, and from looking around the best solution I’ve seen thus far is to have custom metadata on each asset and just create/destroy objects as necessary, rather than rely on XRefs or any of that other buggy nonsense.

I read: Tech Animator Dump: 3dsmax Animation Referencing and Scene Building, but I’m wondering here since I’m relatively new to doing scripting in max: apart from having each object have an Attribute Holder modifier and adding custom metadata to each object that way, is there any other way to have custom metadata on objects? Kind of like the metadata classes in Maya:

http://download.autodesk.com/global/docs/maya2014/en_us/index.html?url=files/GUID-52A836EE-9A09-4B50-8C44-1A6941EAE9D7-1.htm,topicNumber=d30e169599

As I would really rather have these attributes be inaccessible to the end-users in order to prevent artists from accidentally deleting/modifying the metadata stored with each node.

I don’t know a lot about the options available here (Really, storing either user-defined object properties, the Attribute Holder/PEN attribute holder(which I’ve found to be buggy) are the only solutions I’ve managed to find so far), so if anyone would be willing to share what they do for their solution, I’d be glad to take any advice I can get!

EDIT: Managed to stumble across this old thread ([maxScript] custom attributes to aid exporting animtions - 3ds Max - Tech-Artists.Org), creating the attributes without a UI is probably the best thing I’m looking for here (having it be hidden from end-users unless they actually start screwing around with MAXScript), so I’ll go with this for now…seems like the best way to go!

2

As an alternative to keeping your rigs in your max scenes, you could treat the max scenes as “throwaway”, temporary work files, and dump out your animations to another format (xml/json/fbx) in between editing sessions. When the animators go to edit the animation again in max, you force them to load the animation data onto the latest version of the rig, work, then dump out again when finished. Similar to Randall’s Saints Row system you linked, where you use a custom interface to bring the data into your application, but do away with Max scenes as a permanent format.

As for Custom Attributes, they have a lot of potential but like many things in Max, they come with some oddities. I had to build an update system for custom attributes, because if you just re-source the CA definition, it creates a duplicate definition and doesn’t actually update your original CA in your scene. Then you have multiple defs that get saved out in your scene and snowball into accumulated cruft. I’ve also had to build custom attribute cleaner scripts, but sometimes CA’s report that they’re referring to something in your scene when they aren’t, and won’t let you delete them. CA’s can stick around in your max session if you do a File/New or File/Load as opposed to a File/Reset, so I have callbacks to force Max to Reset when animators do a new or load.

Custom Attributes support a ClassID parameter, but the 2010 docs don’t mention it in reference to CA’s, only Scripted Plug-ins. I was lead to believe that using the classID’s would help some of the duplicate CA Definition issues mentioned above, but I think it was too late, and Max gave me weird results using ClassID’s for CA’s that were already established in our max scenes (since they had a different ID than the ones that got assigned a random different ID earlier).

3

[QUOTE=katz;27083]As an alternative to keeping your rigs in your max scenes, you could treat the max scenes as “throwaway”, temporary work files, and dump out your animations to another format (xml/json/fbx) in between editing sessions. When the animators go to edit the animation again in max, you force them to load the animation data onto the latest version of the rig, work, then dump out again when finished. Similar to Randall’s Saints Row system you linked, where you use a custom interface to bring the data into your application, but do away with Max scenes as a permanent format.

As for Custom Attributes, they have a lot of potential but like many things in Max, they come with some oddities. I had to build an update system for custom attributes, because if you just re-source the CA definition, it creates a duplicate definition and doesn’t actually update your original CA in your scene. Then you have multiple defs that get saved out in your scene and snowball into accumulated cruft. I’ve also had to build custom attribute cleaner scripts, but sometimes CA’s report that they’re referring to something in your scene when they aren’t, and won’t let you delete them. CA’s can stick around in your max session if you do a File/New or File/Load as opposed to a File/Reset, so I have callbacks to force Max to Reset when animators do a new or load.

Custom Attributes support a ClassID parameter, but the 2010 docs don’t mention it in reference to CA’s, only Scripted Plug-ins. I was lead to believe that using the classID’s would help some of the duplicate CA Definition issues mentioned above, but I think it was too late, and Max gave me weird results using ClassID’s for CA’s that were already established in our max scenes (since they had a different ID than the ones that got assigned a random different ID earlier).[/QUOTE]

What…I don’t even…why…

I only started playing around with CAs to see if they at least support what I intend to do, but yea, the general idea was to also have a kind of ‘fake’ referencing system going on where end-users just either manually/are forced to always retrieve the latest version of an asset, and the animation serialized beforehand and re-imported after the rig is updated. Thanks very much for that heads-up, though! I’ll try testing this out and see just how messy it gets and if it’s worth pursuing…

One other idea I had was to just have each scene have an accompanying table of contents file that describes every node in the scene and which file it belongs to, that would be auto-generated every time a user chooses to bring in a reference through a UI. It’s not as elegant as having each node in the scene have metadata on them, but the last thing I want to do is deal with an unreliable metadata system…

4

We store our rigs as max files and our animations as .xaf (Max’s xml animation saving format)
When an animator needs to edit an animation, they open the latest rig .max and load the .xaf
We have max tools for quick loading and exporting the xafs
Every time an FBX file is exported to the game via our tools, a corresponding .xaf is also spit out so they stay in sync.
We also have batch versions for when the rig changes and everything needs to be re-exported

We don’t use CAs or object properties, just a strict naming conventions and folder organization.

5

[QUOTE=Mambo4;27103]We store our rigs as max files and our animations as .xaf (Max’s xml animation saving format)
When an animator needs to edit an animation, they open the latest rig .max and load the .xaf
We have max tools for quick loading and exporting the xafs
Every time an FBX file is exported to the game via our tools, a corresponding .xaf is also spit out so they stay in sync.
We also have batch versions for when the rig changes and everything needs to be re-exported

We don’t use CAs or object properties, just a strict naming conventions and folder organization.[/QUOTE]

Ah, that’s a interesting solution…actually had never considered doing that before, might be easier doing that with a UI for artists to handle swapping files instead of writing a whole reference system…

Thanks!