View Full Version : XSI And Team Development
03 March 2008, 10:23 PM
I am very new to XSI, yet I like a lot of the basic features and some of our artist just love XSI's overall toolset and overall good support of high poly models. I would like to start a thread on any tips or tricks for setting up XSI for large teams (such as game development teams).
Basically, any tips for tricks that are specifically helpful for teams using XSI with mutiple people, or things to avoid, limitations etc. Or other resources, such as books or DVD's that cover these topics.
Making generic relative paths for all assets or stripping paths on assets for better portability amongst Multiple users.
How to share multiple models, animations, textures in separate files without creating a scene directory for each asset.
How to safely do Distributed Rendering with multiple artists.
03 March 2008, 11:47 PM
XSI is already good on that out of the box... so start thinking and searching about the following features:
- assets are shared using models, so you must understand models work and work first.
- delta referencing is the best thing to keep a distributed pipeline, so consider to go deep on this.
- workgroups to share your plugins/toolbars/layouts/custom commands/shaders etc...
Theres a lot of information about these things in the XSI help... and also in XSI wiki http://softimage.wiki.avid.com/index.php/Main_Page
I think is good to think on simple tools for versioning control too... so nobody goes crazy on your team :P
04 April 2008, 12:16 AM
few other things:
- referenced animation clips is a good way to split animation from other tasks. Some cases you can go just using external Deltas but if you have many artists working on the same scene, it's better just have the master scene importing a refmodel and loading a referenced animation clip that is being made somewhere else. So you can have someone animation, someonelse refining the model/rig and another one working on lighting/shading/rendering..
- referenced material libraries is not that flexible but it can be the way to split shading development from other tasks..
All this need a crazy amount of organization, if you don't have rules nothing will work from the start.
So you first needto see what you really need to have, and then define how your workflow is going to be. And then how you gonna cover your team so your design will not let you down for the next step.
04 April 2008, 12:16 AM
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.