So I’m toying with the idea to create a custom referencing/updating tool, so we could be more flexible with changing materials and rigs/objects.
I have attempted a few things in the past, but now I’m looking into it as a pet project (opensource maybe…!?) It would be sort of a Xref replacement that works with animated characters etc. I have read that in the past Bobo and probably others too have made such a pipeline while at Frantic still. I’m looking to get some pointers and ideas. I thought that pipeline serialized every node/controller etc. in the scene so you could rebuild whenever needed. Don’t know if that would be overkill for my purposes though.
My first thoughts are that a model when referenced get assigned a “default state”, then anything that deviates upon refresh/reload is tagged a ‘dirty’ and get’s stored in an structured manner, the model get’s swapped and the deviated data is loaded back on top of the object. This includes controllers, materials, objects, etc. I’d probably need to assign a unique ID to every ‘node’ in the asset so I can track it.
Don’t know if that’s the proper way to go. But if anyone has experience or pointers that would be great!
-Johan
P.s. Looking into CAT .rg3 files now, had anyone ever tried to bend CAT to do the updating, it seems like it will repect animation values and swap materials, from a first look.
When we had to develop a system for our game, I solicited advice at tech-artists.org , where everyone familiar with max strongly recommended against using anything like xref for animation.
The best advice I got was to take complex scenes and export and store as much as possible as external data, to be pulled together with scene merge on the fly.
We have one rig file per character and created custom rigs (no biped or Cat).
We save all animations as .xaf files, which are authoritative. any .max animation file exists only to export the xaf into the game format.
So any texture or rig updates happen in only the rig file.
our animation exporter tool will import xafs to the rig for tweaking and
automatically save the changed animations as xafs during export (to FBX).
our game is admittedly fairly stripped down, it does the trick for us.
we haven’t done anything for specially iterating on textures.
so what you did is only replicating the biped system using xaf as .bip we’re still far away from maya referencing system
Last time that I did it I wrote my own XAF formated file using XML as there were so many issues with the save/load system. I also have my own skin file using XML so that I can store that data and apply it. I flagged all objects with a nodeID in appdata for tracking objects. Appdata was good for this because when you clone an object the appdata is not cloned as well so you don’t have to worry about objects showing up as part of a rig or getting the same nodeID. Referencing the mesh to a rig can be more of a problem if you are doing your own system.
@ Logan
Thanks for that insight, for now I’m trying to leverage CAT’s internal system for updating, but I haven’t tested it enough to say it is bulletproof enough. The advantage of using CAT is I can automatically use animation layers. Which stay in place when you update the asset, everything that isn’t a animation controller is replaced by the changes.
But just spend 2 hours looking at it, so can’t say it’s production worthy. And I’m not sure about the “external file way” for my purposes (non game development here, mainly broadcast). But will think about it if CAT route fails
@Paul
Thanks, I was thinking on similar lines too, though not appdata but CA’s, I’ll keep it in the back of my had. Still I’m looking at CAT, even though the rigs are not great and have gimbal issues, the update/referencing system at least for simple rigs looks like it maybe enough. Not sure about whole character rigs though, still need more time to be sure it can be done. But for simple props you just create a model and a simple cat rig with just a hub. Add the nodes and save the rig. Now you can update the base file and press refresh in the workfile. I’m looking in writing a small wrapper for testing purposes and see it it holds up.
If anyone tried CAT rg3 files and found some glaring issues, I’d love to hear it!
Thanks,
-Johan
re: CAT’s RG3 file. There were glaring issues in previous versions of Max in which updating via the RG3 could completely corrupt a file. I believe those issues have mostly been resolved.
That said, my understanding of the RG3 file format is that it is essentially a max file, and updating a rig using the rg3 file calls a MergeMaxFile function. We had written a script to store note track data and re-apply it after a rig update. That function relied on a merge callback.
The rg3 updater doesn’t respect all animation controllers (hence the Note Track script), so be mindful of that.
You’re right it is a max file and can just be openend. I knew this when I started, but I didn’t make the connection with Mergemaxfile, but it does make sense indeed. hmm… Do you know what the obvious and glaring issues where, as I haven’t progressed much yet, there’s is time to bail out still
I know this, CAT has a “add custom controller” functionality where you can assign CAT layer controllers to arbitrary tracks, I was planning on utilizing them on user chosen tracks. Those controllers don’t get replaced on merge.
Thanks!
-Johan
I believe the glaring file corruption issues have since been corrected. When CAT was first integrated into Max, it was buggy. Then ADSK did a rewrite and broke even more things. It’s still buggy, but at least not as buggy as before.
Hopefully the Add Custom Controller will allow you to cover all of the bases with arbitrary tracks. That’s something I didn’t explore too much. E.g. I remember assigning a noise controller to a CAT bone on an animation layer (not the setup layer). The noise controller updated fine, but the Bezier Float noise strength did not.