PDA

View Full Version : model in model - bad?


kidult one
09-19-2006, 08:34 AM
Is placing models inside models bad? I have a character mesh under a model and made a rig using the biped guide - so its a rig under its own model. I then put that rig-model inside the character one. Now I see in some training vids that its not always good because u have 2 mixers now? My character is rigged, enveloped and has deform keys set. I have just made a static pose clip for the rig itself. Would this cause troubles? The animation is just goin to be a short scene with no tranferring of animation to other rigs / characters but with blending of clips in the mixer?

Am I setting myself up for trouble? Can I remove the rig from the its own model to the character? The static pose for the rig can be set again - it was just to make a reset button in my synoptic view. (will moving the rig in the heirachy cause the scripts to be wrong? just thought about it now- aaargh!)
Man being a noobie can be frustrating!

ThE_JacO
09-19-2006, 04:11 PM
nested models are a paranoia that some people spread more then it warranted to be spread.
nested models quickly turn into a nightmare if you use referencing, especially so if the referencing is happening at intervals, but static nested models in scenes (and even exported/imported) are perfectly safe since v4.
The last four movies I worked on used structures that involved nested static (at least in XSI's scope) models in different configurations, and there's never been a problem that ended up being tracked to that.

it's basically one those things that got demonized with surprising zeal, like materials on clusters, when it's actually perfectly safe in most conditions.

kidult one
09-19-2006, 07:21 PM
Well that rules out on thing that might be causing the problems! And now no going back and re-doing, well at least for most things, wish i had read the part about making a tail in the model and not the scene root!

dwigfor
09-19-2006, 07:36 PM
I've got a question, kinda related to this... I thought I read that you can't put RBD elements under a model node. Is that true? I've got 3 setups that I want to include in my model, so I can export it as a model for use in other scenes. I've got the Rig, The Mesh, and the RBD ragdoll "rig". Is that gonna give me problems putting the RBD under the model node?

ThE_JacO
09-20-2006, 12:16 AM
the issue with RBDs currently is that they ignore kinetic inheritance in hierarchies, but I haven't had problems putting them under a single model for the sake of ordering the scene's representation.
just try your simulation under the root, put it under a model that is untransformed, and then see what happens, chances are you won't see any changes or issues, just don't expect it to react to eventual animation on the model, and keep an eye on caching to mixer maybe, but even then I haven't had problems with that, the clips seemed to be fine working with an arbitrary mixer in my experience.

kimaldis
09-20-2006, 06:40 AM
One issue that you'll find with models under models is that if you select the parent model an store actions, no actions will be stored for the child models. We've been having a few other issues as well, nothing really serious but we tend to stay away from nested models now. They can kick up problems when you least need them.

With the current release there's still a problem with RBDs in any kind of hierarchy. The offcicial line was that this was to do with transformations on the parents but I did manage to show that you can still get problems with rigid bodies in hierarchies even if there were no transforms on the parents. It's a big headache.

Watch out also for rigid body caches, especially if you cache to a mixer and intend to export in models.

kidult one
09-20-2006, 07:06 AM
Now Im confused... Which is better? It makes sense that Actions would only be stored for one mixer and not its children. They are seperate mixers - my rig model is under the model for the character mesh - so i have shape and deform keys on the top model mixer and then my rig is an entire model - one mixer for it - surely this should not cause trouble (apart from having to store shape keys in a differant mixer i.e hit the action button twice?)

otherwise how do I remove the rig from the model? would the mixer clips go with? or once in a model its too late?

ThE_JacO
09-20-2006, 07:15 AM
One issue that you'll find with models under models is that if you select the parent model an store actions, no actions will be stored for the child models. We've been having a few other issues as well, nothing really serious but we tend to stay away from nested models now. They can kick up problems when you least need them.
I would personally consider the isolation of animation a feature, and we sure exploited it a number of times in different occasions.
if all you need is a buffer in the hierarchy then there is no point in nesting models to start with. If you are nesting models I expect you would want the ordering in that hierarchy to correctly represent your finite elements to mix/operate for, a different behaviour would require traversing large trees and deciding at which point one mixer should override another, and no algorithmical calls would ever be correct in all situations.
It's definitely not a problem in my opinion, it simply requires you to make a design effort in deciding how and why you isolate.

There was a time when everybody used models in hierarchies the wrong way because new model would encapsulate your selection under what looked like a null, but that was a mistake on the user's side in first place, and it's been made redundant by the addition of the transform groups in 5 anyway, so if you're nesting models you should know what you're after, the excuse of the command's conveniency isn't there anymore.

With the current release there's still a problem with RBDs in any kind of hierarchy. The offcicial line was that this was to do with transformations on the parents but I did manage to show that you can still get problems with rigid bodies in hierarchies even if there were no transforms on the parents. It's a big headache.
I remember reading your mails on some list in those regards, I still can't say I've had unexpected behaviour though if you only have a model/null leading the cascading and that bit's transformation is defaulted to an ID matrix (once you know the annoying default one being not propagating kinetic states that is)

Watch out also for rigid body caches, especially if you cache to a mixer and intend to export in models.
that still holds true and is worth iterating over.
caching and handling mixers with RBDS clips can be a minefield if you start nesting or inserting too many intervals, or putting more then one mixer in the picture.

jason-slab
09-20-2006, 08:09 AM
i've used models in models lots without any problems, well until this last job where i was referencing, updating the ref model resulted in loosing a couple of hours of animation:( ooops, guess sometimes we have to learn the hard way!!

jason

kimaldis
09-20-2006, 10:47 AM
I would personally consider the isolation of animation a feature, and we If you've selected a model and that selection includes sub-models, which it does, intuitively it's confusing if those operations don't include the full selection, which they don't.

[quote] but that was a mistake on the user's side in first place,
Hmm .... If it consistently leads to confusion because it's counter to intuition, which it does, I'd say the design is at fault. Generally speaking, blaming a user when his world view doesn't fit the underlying technical model leads down a rocky road.


I remember reading your mails on some list in those regards, I still can't say I've had unexpected behaviour

it was a pretty basic test; parented, broken, remove from parent, not broken. There was no translation on the hierarchy and on at least 2 scenes, removing the rigid bodies from a parent consistently fixed a whole bunch of problems.

ThE_JacO
09-20-2006, 04:10 PM
Hmm .... If it consistently leads to confusion because it's counter to intuition, which it does, I'd say the design is at fault. Generally speaking, blaming a user when his world view doesn't fit the underlying technical model leads down a rocky road.
the alternative, of automatically linking or encapsulating the animation, is an impossibility of conflicts that can't be resolved by any reasonable heuristic model.
unintuitive or not (and I don't find it unintuitive, it's the way I expected things to work the first time I used mixers and models, and so did the original poster going by what he wrote above) it's pretty much the only stable situation you can easily aim for without getting into all the issues of prioritizing and overriding.
the alternative would basically be having the animation equivalent of the current potential conflicts between differently scoped properties, which are largely agreed to be a pain in the butt :)

that's basically the simple reason why I see the point as moot.

it was a pretty basic test; parented, broken, remove from parent, not broken. There was no translation on the hierarchy and on at least 2 scenes, removing the rigid bodies from a parent consistently fixed a whole bunch of problems.
I'm sure it happened mate, I was just saying I couldn't repro it then and I never had the problem.
The thread got me a bit paranoid at the times (also because I happened to be working with RBDS), but after failing at failing I had to shelf it as situational, which basically means I tend to neither encourage nor demonize the practice. That's why I was saying to setup at root level first and then move it under something to see if something would change, if it doesn't it means you're lucky enough to not be in the episodical percentile :) if it does... cluttering the root level it is.

Strang
09-21-2006, 05:39 AM
one thing you need to watch out for is namespace with the models under models. when you are scripting the objects behave quite normally. like if you logmessage() an object that is under 2 models will have "immedateModelName.objectName" for its .FullName property. but the model itself doesn't have a namespace, you dont get "modelName.modelName" for a model thats nested. instead you just get the modelName

the isn't a show stopper but rather something to consider when your accessing information about your scene, or storing information about your scene. like in custom file formats for extracting information then rebuilding it later. this can still work you just have to be aware of the limitations. then you can implement functionality that supports nested models

i have been using nested models on a current project with out much fuss.

kidult one
09-21-2006, 06:14 AM
Thanx again for all the replies - don't really understand the rgb stuff as i have not used it yet but my nested model setup is working great - no problems with actions or clips and the models I exported (in emdl format) keeps its mixers and clips intact.
Will keep an eye out for the referance models story - but I did read about that one in the manuel - one of the reasons I thought it might be bad.

Then for the scripting story - Strang - does this mean when setting scripts for the model mixers too? My scripting is in the noobie zone too but Im always up for learning more. The only scripts I have running is for my synoptic view which just selects various parts and a reset that uses a static pose. I made these by just copy and pasting from the script ed. and then made the adjustments needed - all seems to work great - must be beginners luck!

dwigfor
09-21-2006, 09:35 PM
Sorry to hijack your thread, kidult one. Thanks for all the replies to my questions guys. Hope you don't mind that I posted the replies on my original thread on xsibase.

For an addition to your synoptic view, you might want to take a look at this tutorial - http://www.joncrow.com/tutorials/xsi_tuts/XSI_KEYING/Automated%20Keying.htm

That shows how you can create scripts to key your entire character with 1 click. Or you can customize it really easy to key just the hands, just the legs, etc. Thought it'd help you out, expanding from just selecting and resetting.

CGTalk Moderation
09-21-2006, 09:36 PM
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.