[Closed] Node Managing

i am using AppData, #filePreSaveProcess, #filePreMerge and #filePostMerge callbacks[b][b]

[/b][/b]using #filePreSaveProcess callback i set save filename to one of channels of AppData for every node

using #filePreMerge and #filePostMerge callbacks i copy save filename to another channel of AppData for all merged nodes.

it gives me the info where every node was saved and where every node was merged from…

genclassid() in the user defined properties seems like the most straightforward approach.

There are still numerous things in 3dsMax that operate based on object names (automatic relinking of merged objects is a big one).

In simple terms I want to get away from the built in max “XRef” (reference manager) and essentially build a custom one that works in a way that allows users to have more control over a scene.

A simple example here:

I have a max file called Donut_model.max
This file only contains a 3ds mesh of a donut.

The second max file only contains a point helper (rig) Donut_rig.max

With a custom reference manager I want to bring in the Donut_model.max file into the Donut_rig.max by merging it in.

The updating part is what makes the unique node managing so important. So if down the road we alter the model of the donut in the donut_model.max file we can easily update the mesh in the Donut_rig.max file. Assuming for this example that the donut is only linked to the point helper.

I know this example is about as plain as you can get, but with a few sprinkles on to, but ultimately I would like this to work on a more complex scene setup as well. Merging in cameras, meshes, lights etc.

I like the donut approach you are using but doesn’t that create circular dependencies?

I have written this sort of thing in the past as well. I wonder if Bobo is around as I know that he developed quite the system at Frantic for doing this as well.

Using appdata is good for this sort of thing as it will automatically remove the data from a node if it is cloned. Using userProps the data in the copy would still be there and could look like it had been merged and you wouldn’t know which is which.

The unique id that a node is given on creation is no good as it is based on scene order, as soon as you merge in a part it is given a new id.

I track parts with names and genClassId. I use the unique ID for a group of objects that are part of a whole so that group has a unique ID. This makes sure that the group can never, just about never end up with the same group name being created else where. There the parts have names, the names don’t mater if they show up time and again in other groups as I look for the group and the named parts.

You can track the referencing that using a scene def for other data that is global to the scene. Knowing what is coming from here like Denis mentions is what you really need. Storing that in each node is a good way to go. It can be a whole lot of work to get it all running smooth.

Speaking of Bobo, there’s an interesting article over at Prime Focus’ site talking about their pipeline for G.I. Joe. I’m always jealous of how much customization they’re able to do at a studio that size.

http://www.primefocusworld.com/work/portfolio/g-i-joe-rise-cobra-paramount

Hey Panayot, How have you been doing?

XRefObjects as well as containers have many limitations to them. Most of those limitations being the main reason why I’ve begun a journey in building a better working XRef managing system.

I’ve got an idea on how I would structure the tool and maybe it is something I’ll build here on the forums to better improve upon existing ideas and get feed.
It seems like the AppData is the best route to go for sure.

I’ll map out some ideas and go over different scenarios and make sure they would flow through it correctly and work.

Now for those of you have already built tools similar to this, are there any specific situations or problems you came across that you found to be worth mentioning, or ones that stuck in your mind as an essential piece to it all working.

Example #2 (a scenarios not possible with any existing reference system in max)
I’ve got the Donut_model.max file merged(referenced) into the Donut_rig.max file.
While the TD’s are rigging it up in the Donut_rig.max I make some shader changes to it in Donut_model.max. So I republish solely the shaders for the donut. So now in the rigging file I would have the TD’s update his reference object’s which would bring in the updated shader.
This I can get working. The twist…
So for a specific reason we make tweaks in the rigging file on the shader and we then want that to be the newly published(master shader) that gets populated to all the other shots that contain a donut in them.

Or in the rig file I’ve made a slight tweak to the donut model and then I publish that model which now becomes the newests donut_model.max file. Doing something to the equivalence of Save Selected on just the things merged in from the previous original donut_model.max.

I too am making a replacement for the xref system, but my system currently relies on very very strict naming conventions, which it’s very hard to get people to stick to. It works amazingly though when people use it.

The advanced version I’m designing at the moment allows easy saving out of different versions of shaders, an automated way of keeping animation rigs seperate with proxy versions of meshes, and then a system to put Point Caches and Baked animation back on to the objects. At any point during any stage if an asset needs updating, you can save it back out from the scene where it is. Works with multiple instances of assets and allows for adding/removing objects from assets without links breaking.

I’d love to package it all up and make it a commercial tool for 3dsmax, when I’ve finished it maybe I’ll talk to my boss about selling it.

Hey Dave,
Good ideas on things.
Now for the animation, does the rig only live in the animation file and then outside of that the meshes are all point cached meshes in the other scenes.