PDA

View Full Version : Displacement direction and parenting: issues / World & local displacement probs



jeric_synergy
11-15-2015, 06:20 PM
This was going pretty well until I tried to make it 'portable', i.e. usable with "Load From Scene":

131026

If you load the scene, you'll see that once the MASTER PARENT NULL starts tipping one of two things happens:

Either the displacement gets funky, displacing in World space when it should be Local,

or, if you compensate by setting Displacement Order to "Before Local Displacement", displacement occurs in the correct SHAPE, but the action of displacement gets divorced from the location of the triggering null.

Obviously, this is sub-optimal, especially for portability reasons: I'd prefer the displacement be the correct shape, and that it occur in the correct location.

I can't seem to suss out what combination of world and local switches need to be engaged/disengaged to make this little setup portable. Suggestions?

jeric_synergy
11-16-2015, 12:54 AM
All would be well IF the vector displacement were occurring in PARENT space, but it appears to be happening in WORLD space.

So I guess I need to compensate for the rotation of the child object. (Although it seems it must be possible directly.)
131029

RebelHill
11-16-2015, 05:28 AM
Its a bug in LWs handling of the co-ords. Setting the displacement to After Local (or earlier) fails to get the info on the world spot correctly... setting it to Before World does, but displaces along the world rather than local.

What you want, is to get the distance from the Nulls World Pos, and the items World Spot as the driver for your gradient.

You can get it all right, by taking the Object Spot, piping that through a vector>transform node (object to world setting), and using that as the constructed world spot. Now set displacement order to After Local, and you're good.

jeric_synergy
11-16-2015, 08:33 PM
Reported: (Case LWB-1928) Displacement not correct when LWO rotated / World spot reporting

RebelHill
11-17-2015, 07:42 AM
Its been known to them since a couple years ago now, the last word on which I heard was "not such an easy fix". That said, considering the deformation system is getting a re-jig for 2016, its probably a good time to raise it again.

pinkmouse
11-17-2015, 08:37 AM
I think I may have reported it a while back too.

jeric_synergy
11-17-2015, 10:37 AM
RH, thanks for the tip: I woulda died thinking it was my problem, not a bug.

RebelHill
11-17-2015, 02:44 PM
No worries... as a note though, it always helps to break things down systematically to find out where the problem lies. If for instance you plug in just the morf node, set straight to 100%, then you can easily see the different displacement directions from the different displacement orders. With that you can go back to the distance finder setup to notice that, given the necessary ordering, the world location isnt working, from which you can then either call a bug, or look for alternate routes, in this case, using the object cor-ord, but with the transform node in between to get it as world.

jeric_synergy
11-17-2015, 06:38 PM
What you want, is to get the distance from the Nulls World Pos, and the items World Spot as the driver for your gradient.

You can get it all right, by taking the Object Spot, piping that through a vector>transform node (object to world setting), and using that as the constructed world spot. Now set displacement order to After Local, and you're good.
Right as rain now, your fix worked perfectly. :bowdown: (As far as I can tell-- I twisted the master parent around and the deformation seems to be tracking.)
131062
From my side, it is as if you said, "Add tincture of wolfsbane and walk three times widdershins in the crossroads at the dark of the moon." I also went back and re-watched the "Vector_Ops.mov" section of the nodal series to get more theory.

I'm glad I seem to have used the right approach, although torpedoed by a genuine bug. Hopefully the devs will find it useful to correct this situation-- would anyone be counting on this remaining the same??

Many thanks. Scene attached for everybody's edification.
131063

RebelHill
11-17-2015, 07:47 PM
Just to be clear, you should take object spot, not world spot into the transform node... its only making no difference here on account of the bug.

Further... this has actually cleared up where the bug is (or at least where it strongly appears to be)... its with the spot info node, and how its world/object co-ords mess up depending on the displacement order. Might wanna add that to your report.

jeric_synergy
11-17-2015, 08:59 PM
Just to be clear, you should take object spot, not world spot into the transform node... its only making no difference here on account of the bug.

Further... this has actually cleared up where the bug is (or at least where it strongly appears to be)... its with the spot info node, and how its world/object co-ords mess up depending on the displacement order. Might wanna add that to your report.
Done.

Chris S. (Fez)
11-17-2015, 10:02 PM
Scene attached for everybody's edification.
131063


Thanks!

jeric_synergy
11-18-2015, 08:18 PM
(just kind of muttering to myself here....)
Hmmm, confused myself.... I tried LOAD FROM SCENE-ing the scene into its final LWS, wouldn't work, came back and realized that moving the MASTER PARENT caused the displacement to go away, ie the effect still worked, but only at 0/0/0. Rotation seemed to be ok, but not translation.

Decided to buckle down and really try to grok what was happening: eventually found using the Morf Trigger Position (not World Position) in conjunction with a Displacement Order of AFTER MORPHING, seems to do the trick. Still a bit fuzzy on why.

Not to be a pedant, but: RH, there's no literal "After Local" option in the Nodal Displacement Order options, there's "After Morphing", "Before Bones", "Before Local Displ." and "Before World Displ.". Not nitpicking, I'm just confused enough already that I have to be very specific. I'm grateful for the guidance, believe me.

EDIT: Belay that: tried importing, failed again partially after translation and rotation. Working....
#2- Specifically when I rotated the Master Parent 90, which is enuf to separate it physically from the local location of the Morf Trigger, although since it's a child it goes along with the displacement object.... ::mutter mutter mutter::.....

EDIT3: ok, giving up for the night, here's the latest iteration. In case it's not obvious, what I'm attempting is a repositionable rig that I can place anywhere at ANY rotation and still have the morph A) occur in the correct direction and B) be triggered by the proximity of the trigger null. --It would seem, to me, that simply getting the world positions of the displacing mesh (spot) and the world position of the triggering null should be adequate to make this work. Obviously not. :cry:
131086
131087


(Hour later, LW crash. $3700 isn't looking so bad....)

RebelHill
11-19-2015, 09:46 AM
Hmmm... So there actually seem to be 2 different effects.

If you take the nulls world position into the distance node, then you can rotate the parent and all is good, but translating causes the morf to slide back to 0... if however you take the regular (parent) position of the null... the translation of the parent causes no problem, but rotation does.

Buggy, bug, bug.

jeric_synergy
11-19-2015, 09:52 AM
Aiyeeee!!! ---It'd be nice to at least be compensated for finding and reporting all these bugs.

If I'm going to be cursed with this power, at least I should be able to make some coin. :grumpy:

I don't suppose a 3rd party node could maybe get this right?

:thumbsup: Thanks for the confirmation.