face rig, curves, cycles :)
Frank Lenhard
i am wondering about how to setup a face rig technically.
wha tiknow is that i want to use curves with contrained nulls
(L(0,100)) to get some nice deformations and skin sliding.
my problem is the control structure which the animator will touch.
i attached a crude sketch to show the problem.
imagine the green boxes are the controls that can be pulled
up/dow/left/right.
these boxes will deform the curves, therefore the nulls and the skin
will be enveloped to the nulls.
so far so good.
what i want is the controls to FOLLOW the curves as well, so when i
push the green control box to the right(X axis), it wont go straight, it will
follow the red curve, so the animator stays within the models shape.
when the animator pulls on z it will go out of the head,
when he pulls on y it will follow the purple curve.
this leads to a cycle obviously, because the control stays on a curve
that gets deformed BY the controls action.
i got that far that i can create path constrain of the control to the
curve, then use a linked with connection to move the control from
0-100% of the path realative to x positions. i get a cycle warning but
it works more or less.
this falls apart when i bring the second curve (purple) in as i can
only constrain to one curve 100 percent.
i feel that i didnt get a grip on the whole thing yet and that it can
be solved in a different manner.
i saw a rig in 3dmax working this way. the rigger used a flaw in the
max system (at least it looks to me like that) to make it work.
any ideas?
ciao
franky
Christian Rittener
Here's a convoluted solution that seems to work:
1. Create your curve.
2. Animate -> Create -> Skeleton -> Create Control Splines. Keep only
the PointType. Set the two other controls to None.
3. Create a tunnel-like lattice with sufficient subdivisions in x.
4. Create a simple geometry (implicits and nulls won't do) small enough
to fit inside the lattice, make it invisible, and place it at the
"entrance" of the lattice tunnel.
5. Deform this geometry by the lattice.
6. Deform the lattice by the curve, X axis. Translate it along the curve
with the PPG slider until it fits OK.
7. Create a null, constrain it to the curve (Param).
8. lock this constraint PPG open, select the geometry created in 4), hit
ctrl-K. Drag'n'drop the geometry's X position green divot from the Local
Transform PPG to the U location green divot on the null's CurveCns PPG.
Apply the expression.
9. Now if you move the green diamonds, you shape your curve, and
everything follows, and if you translate your geometry along local x, it
moves inside the lattice, which has the same shape as the curve. The
null follows along the curve. Use the null as deformer for an envelope.
10. Repeat 4), 5), 7) and 8) with different positions for the geometries
re. the lattice. You can refine the expressions created in 8, such as
(sphere.kine.local.posx / 3).
Bye,
Christian Rittener
---
Unsubscribe? Mail Majo...@Softimage.COM with the following text in body:
unsubscribe xsi
Frank Lenhard
i recreated the rig based on your description. however i think i
didnt explain perfectly. i would like to have ONE control that moves
along the curves in x and y. the red and pruple curves.
and deform these curves on the way. i can constrain different curves
or skin them to these controls to simulate a nice fleshy feel.
the more i think about it, it might not be necessary to MOVE the
control ON the curve, but instead make sure the curve stays on the
other axis curve. means, i move a red curve up, i follows the purple
one, and vice versa.... sigh...
the idea with the lattice is interesting though....
ciao
franky
Wednesday, October 24, 2007, 2:37:05 PM, you wrote:
CR> Here's a convoluted solution that seems to work:
CR> 1. Create your curve.
2. Animate ->> Create -> Skeleton -> Create Control Splines. Keep only
CR> the PointType. Set the two other controls to None.
CR> 3. Create a tunnel-like lattice with sufficient subdivisions in x.
CR> 4. Create a simple geometry (implicits and nulls won't do) small enough
CR> to fit inside the lattice, make it invisible, and place it at the
CR> "entrance" of the lattice tunnel.
CR> 5. Deform this geometry by the lattice.
CR> 6. Deform the lattice by the curve, X axis. Translate it along the curve
CR> with the PPG slider until it fits OK.
CR> 7. Create a null, constrain it to the curve (Param).
CR> 8. lock this constraint PPG open, select the geometry created in 4), hit
CR> ctrl-K. Drag'n'drop the geometry's X position green divot from the Local
CR> Transform PPG to the U location green divot on the null's CurveCns PPG.
CR> Apply the expression.
CR> 9. Now if you move the green diamonds, you shape your curve, and
CR> everything follows, and if you translate your geometry along local x, it
CR> moves inside the lattice, which has the same shape as the curve. The
CR> null follows along the curve. Use the null as deformer for an envelope.
CR> 10. Repeat 4), 5), 7) and 8) with different positions for the geometries
CR> re. the lattice. You can refine the expressions created in 8, such as
CR> (sphere.kine.local.posx / 3).
CR> Bye,
CR> Christian Rittener
CR> ---
CR> Unsubscribe? Mail Majo...@Softimage.COM with the following text in body:
CR> unsubscribe xsi
peter boeykens
[start of rant]
Any have any ideas what the "rate" value in the import options might be for?
For some weird reason I expected it to be related to frame rate, as in:
amount of frames per second. I typed all kinds of values, such as 25, 29.97,
30, 1234,0.0001 to find out that they all have the exact same effect on the
imported data: none at all. A bit frustrated I tried typing fcukall, and to
my amusement the tool didnt blink an eye, and happily digested a string
where a float should apply. No errors whatsoever. Bottom line - the way to
get a correct import is to set sequence frame rate before calling the
import, and to ignore the option otherwise.
Also great idea to import the camera onto the default camera that is
constrained to an interest and set some weird fov value and leave all else
untouched. At least the resulting imported camera is so far of the mark,
that there can be no confusion about the need to go in a verify and rectify
a thing or two.
No worries, giving the camera an obscene name and hiding it in a model
outsmarts the importer, and a new camera is made, that has untouched
positional and rotational data. Now if only it was kind of vaguely directed
at the scene?
luckily, at the end of the day, a bit of swapping axes, adding a couple of
90 degree rotation offsets, some negative signs and all's good?
Well the rotational values still dont match the FBX data - actually there is
a one degree offset on all three axes. (wonder who didnt do his homework...)
But I'm not going to let that hold me back now.
Oh right, camera settings! Luckily in this all-digital age I thought of
scribling down all values on a piece of paper - so I can now type them in -
and after a few attempts even conclude that it is actually as simple as
that? typing the same values in the proper places simply works!!
Repeatedly on over 20 shots now, so I quickly script the thing - takes about
ten minutes of work - make a little plugin out of it - and yes! now I have a
tool that fixes all the errors the importer makes. (at least the ones I
found so far)
the FBX data is consistent between three other 3D applications on import and
export so I assume they're not collectively wrong.
Lets just hope none of this gets fixed in an upcoming release - I would hate
to uninstall my first self-installing plugin.
[end of rant]
Sam Cuttriss
ive flared up on this one occasionally myself, and wholeheartedly agree with you.
i just assumed it had been fixed as their hadnt been much noise about it.
_sam
Sam Cuttriss
Janimation 3D Aficionado
André Adam
unfortunately nothing Softimage can do much about. A while back we
encountered crashes with a whole bunch of fbx files; support was able to
get us the exact line number where the Autodesk dll crashed out, but
obviously couldn't help us any further. It turned out that even Maya
crashed the exact same way on this data, and the fbx files were
generated with a current Motionbuilder release.
Bottom line, it's Autosdesk who can't read their very own file format.
-André
Sam Cuttriss wrote:
> And who says sarcasm doesnt translate well online!!?
>
> ive flared up on this one occasionally myself, and wholeheartedly
> agree with you.
> i just assumed it had been fixed as their hadnt been much noise about it.
>
> _sam
>
>
> *Sam Cuttriss
> * Janimation 3D Aficionado
Morten Bartholdy
peter boeykens
if a software doesnt have good import / export tools, it will hurt it,
especially with new users, migrating from other software, or in pipelines
where it would be added next to other software.
In order to make the import and export really work, one needs to delve into
the software at the other end of the data transfer, and possibly
intermediate software, and get familiar with them. As this is most likely
software from competing vendors, the extent to which this can be done is
limited. One might not have access to source code, detailed specifications
or even said software. Nor a wide variety of example files, preferably
relevant to real production situations, to test and debug on. And there
might be copyright restrictions.
It is understandable that with such factors, I/O tools can not be developed
with the same amount of care as the rest of the software.
But that doesnt benefit the end users of course.
Despite the overtones in my original mail, I do believe Softimage is taking
intitiatives to adress this.
And to be fair, in the shots I was working on I eventually got a perfect
match, based on the imported data, which included complex sets and rigged
characters, so the major part of the import is working. Its the finessing,
such as camera's, that is lacking a bit.
----- Original Message -----
From: "André Adam" <a_a...@49games.de>
To: <X...@Softimage.COM>
Sent: Thursday, October 25, 2007 9:23 AM
Subject: Re: [rant] crosswalk / fbx import
Sam Cuttriss
to me, camera import and export is about as fundamental as it gets.
_sam
Sam Cuttriss
Janimation 3D Aficionado