I don’t need it in the literal sense, because I could go back to the old way of doing things, but it’s helpful for how I have things organized which was originally designed to work with refmodels but I had to scale back the plans when Softimage just wouldn’t stop crashing when I tried to set it up this way before. Here’s an example of a set of files and related notes:
· Avatar_Rig_Export : Contains the base skeleton and physics metadata that is used by the game. Usually includes a mesh, also, but it doesn’t have to for cases where models might vary. Rarely changes, but occasionally does when metadata is changed such as locators or physics tweaks. The Export_Rig model is exported for use by other scenes, and it is also exported to the game engine for use as both the bind pose and source of physics rigid bodies and other metadata. · Avatar_Rig_Biped : Contains a Biped Guide generated rig (I call this my control rig), and a nested referenced Avatar_Rig_Export model which is constrained to the control rig. The Biped control rig, and it’s nested referenced Export_Rig are exported as a model. This scene does not get exported to the game engine, it’s used only by the animation authoring scenes (the next two). · Avatar_Anim_Generic : This scene is used to author a variety of animations stored as ActionSources, and has a referenced model of the Biped rig. I just animate on the control rig, plot the changes to the nested export rig, and when ready my custom ‘engine export’ command will export all the action sources created on the Avatar_Rig_Export, which is of course a nested reference model. · Avatar_Anim_Pistol : This scene is an example of animations that may not always be required, but it is set up the same way as Avatar_Anim_Generic. This arrangement lets me correct errors in the Avatar_Rig_Export and have the changes propagate to the dependent scenes by just loading them. It also lets me create new scene files with new animations without worrying about breaking existing animations or getting massive (== unwieldy and potentially fragile) collections of animation data in a single file. The exporter exports animation data from all action sources in the mixer, so it doesn’t matter what’s in the timeline; this lets me test anims in the same scene they are authored. I really like ho the system exports ActionSources instead of the timeline, it’s very handy for keeping related animations organized in a single scene file. This setup also allows me to have different control rigs, which isn’t something I’ve done much but when the need arises I can bind the Rig_Export to any other kind of control rig. I’ve been planning on doing this for things like vehicle specific animations or perhaps multi-character stuff. When I do this, they will all refer to the same referenced Avatar_Rig_Export model. The benefit of course is that the individual animation authoring scenes can choose a control rig that is suited for the animation being made, without the baggage of an overly complicated, potentially fragile, uber-rig designed to solve everything. Until this past week when I switched over to referenced models, I had to manually re-import and in some cases reconfigure the imported models when anything a scene depended on was changed. I’m hoping the refmodels will work well enough for my needs to keep using this setup because it was a hassle when things did have to change. Unless I start having refmodel bugs pop up (and I haven’t yet), it should occasionally save me a fair amount of time being able to rely on them for updating the dependent scenes. I wouldn’t be surprised if there is a much better way to approach all this but it’s working for me so far. I just saw Eric Thivierge’s reply and it sounds like this is a “safe” usage.. hope it’s true :) Eric From: [email protected] [mailto:[email protected]] On Behalf Of Matt Lind Sent: Wednesday, September 18, 2013 8:28 PM To: [email protected] Subject: RE: 2014 Out of curiosity, Why do you need nesting? Matt From: [email protected] [mailto:[email protected]] On Behalf Of Eric Cosky Sent: Wednesday, September 18, 2013 8:26 PM To: [email protected] Subject: RE: 2014 Good to know, thanks for the reminder about those other issues. Perhaps if I use the nesting only as a way to maintain initial setups before making them local I can avoid these problems. It would sure be nice if they hammered out all the ref model bugs and made the system something people could trust, and then proved it with a bunch of sample scenes that verify all these concerns have been resolved. It’s one of the things I was really looking forward to using when I first got into Softimage so long ago now, and I never really got to use it as advertised. From: [email protected] [mailto:[email protected]] On Behalf Of Matt Lind Sent: Wednesday, September 18, 2013 8:14 PM To: [email protected] Subject: RE: 2014 I do not advise using nested models. When you get to the more complicated relationships such as model deltas, group relations, animation mixer propagation, instances, and so on, you’re just asking for trouble. Glad to see improvements, however, as it has far reaching effects beyond nesting. Matt From: [email protected] [mailto:[email protected]] On Behalf Of Nick Angus Sent: Wednesday, September 18, 2013 8:10 PM To: [email protected] Subject: RE: 2014 Thanks Eric, we had huge troubles with nested references in 2013, in fact we gave up on it. So that is definitely a tick in the pro box! Cheers, Nick Sent from my Windows Phone _____ From: Eric Cosky <mailto:[email protected]> Sent: 19/09/2013 9:18 AM To: [email protected] Subject: RE: 2014 I’ve been successfully using referenced models that contain other reference models with SI2014. This used to cause stability problems in earlier versions, but it’s been a while since I checked.. it might have been 2012 or earlier that I last checked. I’m pretty happy to see it working these days, regardless. My usage is generally limited to game export related stuff without referenced material libs, so YMMV. There’s been enough problems with refmodels over the years I’m not about to say it’s problem free but being able to nest referenced models is pretty useful for my workflow and I’m glad it is working for me. From: [email protected] [mailto:[email protected]] On Behalf Of Nick Angus Sent: Tuesday, September 17, 2013 10:12 PM To: <[email protected]> Subject: 2014 About to take the plunge and update from 2013 (not sp1) to 2014 (latest build). Are there any caveats I should be wary of? Appreciate any advice either way! Cheers, Nick
-------------------------- To unsubscribe: mail [email protected] with subject "unsubscribe" and reply to the confirmation email.
