| 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158 |
- <!doctype html public "-//w3c//dtd html 4.0 transitional//en">
- <html>
- <head>
- <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
- <meta name="GENERATOR" content="Mozilla/4.61C-SGI [en] (X11; U; IRIX64 6.5 IP19) [Netscape]">
- </head>
- <body>
-
- <center>
- <p><b><font size=+1>SoftImage Tips and Tricks</font></b>
- <p><font size=-1>[email protected]</font>
- <br><font size=-1>updated 2/26/2002</font></center>
- <p><br>
- <br>
- <br>
- <br>
- <p>The following document contains certain advice for getting models and
- animations through the
- <br>soft2egg converter in one piece. Some of these restraints are
- due to differences between Panda
- <br>and SoftImage and some are workarounds for SoftImage idiosyncrasies.
- The first section is advice
- <br>for set-up, modelling, and animation. The second section describes
- some frequently seen problems
- <br>after conversion attempts. If you have any questions please don't hesitate
- to ask.
- <br>
- <br>
- <p><b><u>Section I - Set-up</u></b>
- <br>
- <p> <u>Hierarchy naming:</u>
- <p> The converter needs to ignore
- most of the constraint hierarchies and they are not always
- <br> flagged invisible so the
- code will ignore any nodes (and anything below them) with the
- <br> following strings in their
- names:
- <p>
- con-
- <br>
- con_
- <br>
- fing-
- <br>
- eyes-
- <br>
- faces-
- <br>
- head-
- <br>
- camRIG
- <br>
- bars
- <p> If you don't do this, the
- converter will make geometry for the sliders and the camera. I freely
- <br> admit there is some kruft
- in this keyword list.
- <br>
- <p> <u>Model naming:</u>
- <p> Try to make the models have
- consistent names through the revision process. SoftImage is
- <br> terrible about appending
- version numbers onto everything in the scene file (null12_1_1, etc.)
- <br> Each time a model name changes
- it's highly likely that a makefile or the show code will break.
- <br> While it is possible to
- "fix" this with wildcards (null12*) it is undesirable as this is no longer
- <br> unique and can cause other
- problems.
- <br>
- <p> <u>NURBS Textures:</u>
- <p> Textures applied to closed
- NURBS surfaces in Soft will have problems in Panda. This is because
- <br> Soft uses phantom vertices
- in their NURBS representation and this seems to affect where they
- <br> start and stop applying
- the texture. This can be fixed by shifting the NURBS parameterization.
- <br> You can do this on the surface
- in question through the Soft GUI, or you can do for all surfaces
- <br> in the scene upon conversion
- with the "-x" option to soft2egg.
- <br>
- <p> <u>Model scale:</u>
- <p> It seems the general convention
- here in the VR Studio has been for the animators to scale the
- <br> character models up by a
- factor of four while animating. I believe this is because Soft has limited
- <br> precision. Thus models should
- be scaled by a factor of one fourth to look right in Panda.
- <br>
- <p> <u>Non-uniform scaling of joints:</u>
- <p> A non-uniform scale is one
- that is not the same in all three axes (ie x=1, y=1, z=0.5). If an
- <br> animation puts a non-uniform
- scale on any joint then you must place the key word "scale-" in
- <br> the name of the joint that
- does that scale.
- <br>
- <p> <u>Face shape trickiness:</u>
- <br>
- <p> Currently SAAPHIRE (the SoftImage
- API) is broken when it comes to reading expressions
- <br> which determine shape weights.
- Because of this you MUST put the expressions in strict order
- <br> of the shape numbers they
- affect (ie the expression for shape 0 must be before 1, etc.)
- <br>
- <p> <u>Animating Nulls:</u>
- <p> When constructing a skeleton
- for the player the converter looks at the skeleton nodes in Soft.
- <br> If you are animating a null
- directly through some relationship you need to make the converter
- <br> aware of that by flagging
- the null with the prefix "joint-" in its name. Alternatively, you
- can
- <br> do a "GroupAsSkeleton" on
- the null in question to make it actually part of the skeleton. It will
- <br> then have a tiny "Skel"
- above the node in the Soft's schematic view.
- <br>
- <p> <u>The Minus One Frame:</u>
- <p> Our animation system works
- by computing offsets from a neutral pose in the -1 frame of the
- <br> scene file. If the character
- is not in the "jesus pose" at frame "-1" all bets are off. Animation
- <br> should not start on anything
- in the scene until frame "1".
- <br>
- <br>
- <p><b><u>Section II - Known Pathologies</u></b>
- <br>
- <p> <u>Part not where it should be:</u>
- <p> Frequently Soft does not
- update the position of parts that are moved and skinned. It will look
- <br> right in Soft until you
- cut it out of the hierarchy. If the geometry stays where it is after cutting
- <br> it is fine. If it
- pops to a different position it will be problematic. We never did find
- a way to make
- <br> Soft update its position
- but we did find a fix: do a "duplicate immediate" on the geometry while
- <br> it is in the correct position;
- cut out the old geometry and delete it; skin up the new copy you just
- <br> made.
- <br>
- <p> <u>Part stretched out while animating:</u>
- <p> If you put a non-uniform
- scale on a joint and don't tag it as described above it will most likely
- <br> be extremely stretched out
- and creepy looking on playback (like Edward Scissorhands). There are
- <br> other things that can cause
- this too (like scaling an egg model and not the egg anim channel and
- <br> vice versa). But when in
- doubt, throw in the "scale-" flag.
- <br>
- </body>
- </html>
|