 | | | constraint updating in 4 and 4_2 | constraint updating in 4 and 4_2 2005-01-17 - By Robert Moodie
Back
"I gave it a shot on XSIBase but the audience there doesn't seem quite up to
this one."
Are you smoking crack? Or is this just temporary insanity?
I suggest you go back over to XSI base; read, digest and understand the
explanation Matt Lind gave you. Then apologise to him in both the forums
where you have been critical of his attempts to help you.
p.s. It doesn't matter if you are a newbie or not (and nobody cares) - with
explanations like the one Matt provided you on XSI Base, we all learn
something.
-- -- Original Message -- --
From: "Brad Friedman" <brad@(protected)>
To: <XSI@(protected)>
Sent: Monday, January 17, 2005 9:33 AM
Subject: Re: constraint updating in 4 and 4_2
> kim aldis wrote:
>
> >That's not strictly speaking correct. Most of the discussion has been
about
> >cycle dependancy, a condition that arises when two objects are each
> >dependant upon each other. There's no such thing as a correct result
under
> >these circumstances. Xsi constraints generally behave well but they do
> >sometimes ally you to construct illegal conditions. Use the
cycledependany
> >function to check for this.
> >
> >
> I'm aware of this. I ran cycle checks manuallly a number of times to
> make sure I was not creating them. And regarding the flakey constraints
> thing. I'm just relaying the impression I got from doing a search for
> the terms "constraint" and "update". And more importantly, I'm trying
> to deflect the "do a search of the archives before you ask a stupid
> question like that!" comment. I did not mean to disparage XSI in general.
>
> >Your condition doesn't contain cycle dependancies but it does behave as
> >indicated in the documentation. Simplifying your condition for clarity,
> >create only 2 position constraints on the null, one to each cube. Now,
it's
> >easy to assume that a blend factor of 0.5 on each would result in the
null
> >positioning midway between the two cubes.
> >
>
> I can see how newbies would want it to work that way. And thats how it
> works in Maya as well. However thats not how I have it set up. The
> first position constraint has a blend of 1.0. Full on. The second has
> a blend of 0.5 to put the null in the middle.
>
> The two constraints after that start with blends of 0.0. They don't do
> anything at first. If you turn either of them up to 1.0, the null
> should move to the target fully (overriding the first two constraints
> completely). If you turn it back down to 0.0, control should be turned
> back over to the result from the first two constraints. I understand
> the order of operations and what the blend value should do. I'm using
> it to get the results I want. And it works in almost all cases, except
> for interactive updates of the blend weight value, and animated updates
> of said value, unless I use the partial workaround I described in my
> original message. Please reread my original post for a description of
> my intended behavior vs. what is happening on my machine here. If you
> are getting the intended behavior instead of the errant behavior I
> describe (causing an assumption that I'm just doing it wrong, cause
> everything works as it should) I'd very much like to know because it
> indicates some odd condition over here in my world that I need to seek
out.
>
> Thank you for your time.
>
> -brad
>
>
> --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.300 / Virus Database: 265.6.13 - Release Date: 1/16/2005
>
> ---
> Unsubscribe? Mail Majordomo@(protected) with the following text in body:
> unsubscribe xsi
>
---
Unsubscribe? Mail Majordomo@(protected) with the following text in body:
unsubscribe xsi
|
|
|