Max large scale asset management

hey everyone,
i was curious to know what kinds of methods other people use for managing lots of max files, specifically related to characters and weighting files.

we have a large amount of clothing piece assets which are being dynamically loaded in-game. i would like to keep master files of each piece - uppers, lowers, etc - and use xref to reference other files (similar to how i would do it in maya), but i can’t change visibility of assets within xref’d files to see how my rom animation looks (finding penetration etc). also, script controllers seem to freak out on xref… this is not such a big deal because nothing is being saved on the xref file, but it is an annoyance.

curious to know how others deal with this pipeline…

-jeremy

XRef in Max is barely worth looking at, it’s pitiful in comparison with Maya’s referencing system unfortunately :frowning:
I deal with this pipeline by using Maya… sorry I can’t help more than that :slight_smile:

Are you using scene or object xrefs?

[QUOTE=MoP;1920]XRef in Max is barely worth looking at
:)[/QUOTE]

sorry, this is not totally true, but of course, if you never look at it, it’s not worth using it…

it might be pitifull, but keeping strict naming and layering conventions one is able to do some clean scene setup (using object xrefs for more flexibility).
I never tried xref’ing cloth, so maybe this provides special quirks, but i had good experiences using it with multiple rigged characters, keeping the rig seperated from the geometry (actually rigging/morphing the xref objects)

If you want control over visibility in scene-xrefs on a per object base, use the layer manager. You have to press “Refresh Xrefs” in the Xref window after loading the scene, to get the Layer Manager “filled” with each object, this is such a “quirk”. Here again clever layering and naming conventions are strongly recommended…

Look at the attached max-screen - all characters/ctrl-objects/ and other objects are scene-xrefs, the scene itself only contains the render setup.
The referenced scenes themself contain object xrefs to the rigs, character meshes and morph targets, each part in a seperated max file.

Of course your setups might be far more complex, but than again…why should’nt this method scale enough?
The biggest obstacle is of course that you cannot animate or have access to modifiers from the xref’d scenes objects…

“The biggest obstacle is of course that you cannot animate or have access to modifiers from the xref’d scenes objects…”

and exactly why they are frustrating and not “worth looking at” as people hit this with rigs all the time.
For final render assemblies or having referenced files linked together… I have used them in various ways successfully on a few game projects but not the way I really would like to.
they are usable and can help as you have shown but with out mod. access and also a asscii file format replacement for the .max files they are hard to trust in production compared to maya references. (maya refs. have a huge set of issues and gotchas as well but they are fully functional)

Maybe they all 3 can get to gether, maya.max, xsi and talk about ways to improve their systems.

The pain of not having an XREF in Max is less than the pain of using Max’s XREF for most cases. There are tons of times a xref system would have saved me tons of work, but it just isn’t something I want to deal with in Max. I suppose someone can write a text-based Max format that can support referencing pipelines, but I’m not working on another large product without a referencing pipeline, especially something with tons of content and character customization.

For some reason I feel that the reason Max doesn’t improve its systems is NOT because it doesn’t know something is wrong…

Can we not turn this into an app war and just concentrate on helping Jeremy out? I think it’s a huge disservice to the person asking for help to take his question and use it as a vehicle to slam one 3D app or another. They all have their issues, and basically telling someone that they should switch to another program is hardly ever a valid option.

Jeremy, do you still need help on this? If you tell me whether you’re using scene or object xrefs, I might be able to offer some specific suggestions.

yeah i’m still looking for suitable solutions to this. my intention is/was to use scene xrefs. i’m not very familiar with maxscript yet, and i’m afraid i don’t have time to experiment with custom referencing solutions, so i’m in need of something that is going to be easy to implement. the big things i need to address with this pipeline are:

  • being able to toggle visibility of objects within the xref scene (i might be able to achieve this with layers as spacefrog suggested? i haven’t had time to experiment yet)
  • having animation on the xref’d scene (this part is easy, it is a common rom so as long as the animation is on the asset when xref’d, it should line up)
  • dealing with the errors that pop up on a custom script controller on a biped rig

if using xref isn’t suitable for this, the other alternative i was thinking of is to write a tool that merges in assets from another file, skins, and loads envelopes on the fly, but being able to have multiple assets in one file and toggle visibility would be much more useful, and it would create less clutter because the reference could just be removed, rather than having to delete the proxy meshes i want to use as reference

If you need per object control over the xreffed file, then I would xref the whole scene as objects. Is there a particular reason you don’t want to do that?

And what are the errors you’re seeing on the scripted controllers?

I second the xref object usage. Xref Scenes also bring into your scene any global variables in the xref’d file. If the same vars are being used in your working file, they will be over written every time you enabled the Xref Scene, so you need to be sure that file is clean, or unique named, any global vars and controllers.

I've written a "merger scene" type maxScript setup before.  It works but it's slow to work with.. I used an AppData flag to identify from which files the objects are from.  

The bonuses are you can mod stuff in the render file and save it back to the "x-ref" without issue and also have the file "build itself" after being submitted to the queue ( very small render files ).   

Cons: Trouble shooting network render issues, as you can’t “open” the file that’s giving you an issue. I never wrote it to avoid collisions on the save, so coding it to that scale would be a little more work, but it can be done.


box vaporizer