constraint updating in 4 and 4_2 2005-01-15 - By Brad Friedman
Back
First of all, Hello. This is my first post to the XSI list and I wish
you all well. I'm a fairly recent convert from that other piece of
software from that other company that shares its name with an ABC tv
series, that we wont mention.... EVER AGAIN! Cause it hurts too much.
I moved over last June and have been extremely happy. I'm a graduate
student at NYU in Digital Imaging and Design (which is big fancy
academic wording for 3d animation and other stuff) and am currently
working on my thesis, a two minute animation due for completion in May.
That said, I've run into a bit of a problem over the past week that I
need some insight and help on, and thought this would be the correct
place to try for it. I gave it a shot on XSIBase but the audience there
doesn't seem quite up to this one.
I'm running into problems with Constraints not updating correctly (or so
I think). I've searched the history of this mailing list and found a
lot of talk here and there about various versions of XSI past, having
flakey constraint updating in various ways. Unfortunately, I have not
found anything that seems to directly address the issues I've run into.
Please run the following JScript to build a quick test scene that
illustrates my problem.
[code]
NewScene(null, null);
SetUserPref("SI3D_CONSTRAINT_COMPENSATION_MODE", 0);
CreatePrim("Cube", "MeshSurface", null, null);
Scale(null, 0.199226305609284, 0.199226305609284, 0.199226305609284,
siRelative, siParent, siObj, siXYZ, null, null, null, null, null, null,
null, 0);
Translate(null, -8.46790201304644, 0, 0, siRelative, siLocal, siObj,
siXYZ, null, null, null, null, null, null, null, null, null, 0);
Duplicate(null, null, 2, 1, 1, 0, 0, 1, 0, 1, "1", "1", "1", "0", "0",
"0", "0", "0", "0", "False", 0);
Translate(null, 15.7641426143956, 0, 0, siRelative, siLocal, siObj,
siXYZ, null, null, null, null, null, null, null, null, null, 0);
GetPrim("Null", null, null, null);
Translate(null, 0, -3.55609132719339, 0, siRelative, siLocal, siObj,
siXYZ, null, null, null, null, null, null, null, null, null, 0);
ApplyCns("Orientation", "null", "cube", null);
ApplyCns("Orientation", "null", "cube1", null);
SetValue("null.kine.oricns[1].blendweight", 0.5, null);
SetUserPref("SI3D_CONSTRAINT_COMPENSATION_MODE", 1);
ApplyCns("Position", "null", "cube", true);
ApplyCns("Position", "null", "cube1", true);
SetValue("null.kine.poscns[1].blendweight", 0.5, null);
SetUserPref("SI3D_CONSTRAINT_COMPENSATION_MODE", 0);
ApplyCns("Position", "null", "cube", null);
SetValue("null.kine.poscns[2].blendweight", 0, null);
ApplyCns("Position", "null", "cube1", null);
SetValue("null.kine.poscns[3].blendweight", 0, null);
ActivateObjectSelTool(null);
ActivateObjectSelTool(null);
SelectObj("cube", null, true);
Rotate(null, 0, 0, -7.68170423285901, siRelative, siAdd, siObj, siXYZ,
null, null, null, null, null, null, null, 0);
Undo();
[/code]
I'm using two cubes for constraining objects. And one null in the
middle, slightly lowered, as the constrained object.
there are six constraints in total on the null.
First, a set of two orient constraints to keep the null oriented
relative to the cubes, should they be animated. The first has a blend
value of 1.0, meaning it takes full control. The second constraint has
a blend value of 0.5 to start. Though I want it animate-able to allow
the null to favor one cube or the other at different times.
The next two constraints are position constraints, both with offsets.
I've left "affected by orientation" off for this illustration to
eliminate it as a potential problem. Though in my full implementation
of this mini rig, I turn it on. The purpose of these constraints is to
allow the null to float between the boxes while still maintaining its
"lowered" position relative to them. The first constraint has a blend
value of 1.0, meaning it takes full control. The second constraint has
a blend value of 0.5 to keep the resulting position equally weighted
between them.
So at this point I've eliminated any position or orientation coming from
fcurves, expressions, or the position of the null from the last
evaluation because the first position constraint and first orientation
constraint both have blend values of 1.0.
The last two position constraints are meant to be animated. They pull
the null to the boxes independantly of one another. They are initially
set to a blend value of 0.0. They are off. I intend for the
animator/rigger to either animate them directly, or drive their
animation by something else by turning up the blend weight on these last
two constraints.
Anyhow, thats the intended behavior. And if you select a cube and
transform it around, it all acts as it should.
However, if I select the last position constraint and adjust the blend
weight manually in the property sheet, I get extremely strange
behavior. I'd expect that as I turn up the blend weight, the null would
move from its mostly centered position to a cube. Then, as I turn it
back down, it should retreat back to the centered position. But on my
system thats not what happens. The null shoots over to the cube before
I finish turning up the blend value and it refuses to return not matter
how many times I slide the blend weight slider back and forth.
So firstly, is this the same behavior everyone else gets? I uninstalled
4.2, and my wacom drivers today. I installed 4.0 and 4.2 and tried it
without my wacom drivers installed... just to be sure. And I had the
same problem both in 4.0 and 4.2. I can't try it in 3.51 because I
don't have a license for it. My system is a dual proc system with hyper
threading. Does this same behavior show up on single proc systems
without hyper threading as well?
Second, is there any good reason why this shouldn't work? As I said, I
have been using softimage for less than a year so I could conceivably be
misunderstanding how these constraints should work. That said, I'm not
a 3d newbie. I've been using the "M" 3d program and its predecesor
P**** A******* for years amongts other 3d programs. So I'd say there's
a better than good chance I am getting this right. But I'd appreciate
an idiot check. I know there are other ways to work around this such as
scripted ops. And I probably will. But at this point I'm more
concerned about borken constraint blending in XSI than anything else.
Anyhow, assuming everyone else gets the same weird behavior, and the
test scene "should" work even though it doesn't. I'll move on.
To me, it looks like the constraint stack is not being updated
correctly... namely from bottom to top. I "think" some of the bottom
constraints are being ignored, resulting in the later constraints
operating on the position data from the last update (or last frame or
whatever). This appears to happen when the blend weights of the last
two position constraints are adjusted. Though, the top one is the most
blatant about it. The next constraint down doesn't misbehave as badly,
though it does make errors. Dragging the slider bar quickly up leaves
the constraint short of its target while doing it slowly gets it
closer... a behavior which should not exist with this setup.
Not only does this happen when the blend weight is adjusted
interactively, but also when it is animated.
That said, if one translates either of the cubes at any time, the stack
updates from the bottom to the top and all is well. The null pops to
exactly where it should, based on the blend weights. Adjusting the
blendweights again manually or via animation exhibits unintended
bevahior again. Translating a cube snaps it back.
So, a partial workaround I found, is to put a single keyframe on any
constraining objects that are not animated. This forces the constraint
stack to update correctly on frame changes (and hence allows animating
of the blend weights). However, this does not fix the interactive
update. As I said, its a partial workaround. But it does illustrate
quite clearly exactly what appears to be wrong. If you animate the
blend weight on the top constraint and remove all animation form the
cubes, you'll get unintended behavior. But if you put a single keyframe
on the cubes in place, everything works great.
I have not looked at spdl files before really but I knew enough about
them to look into them and noticed there is no logic line like:
blendweight.Enable( active.Value )
to be found anywhere in the files
C3DCoKineCns.spdl
C3DBaseUpVectorCns.spdl
C3DPositionCns.spdl
C3DPoseCns.spdl
but it is in the file
C3DOrientationCns.spdl
But this may be a red herring. I really don't know enough about spdls
or the inner workings of XSI to know if that has anything to do with it.
Anyhow, if anyone can comment on this mess, I'd appreciate it. I'm
really frightened that constraints may be seriously broken to the point
that I can't count on them for anything involving dynamic blending of
any type. I'm even more frightened that I'm not understanding how they
should be used :)
Thanks for your time.
-brad (XSIBase: Leith)
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.6.12 - Release Date: 1/14/2005
---
Unsubscribe? Mail Majordomo@(protected) with the following text in body:
unsubscribe xsi
|
|
