lookAt() when either the source mesh and/or target position are parented

[Convergence]

It looks like mesh.lookAt() doesn 't work correctly if either the mesh and/or it's target are parented; is this intended or not?

https://www.babylonjs-playground.com/#FZEH1H comment line 27 out for correct behavior.

[Wingnut]

Hi C, good to see you again.  umm... I think what you have shown in the playground... is ALMOST intended and ALMOST normal.

The Mesh:  When the lookAt() mesh is parented, the rotation for that mesh... is "bound" to the parent's rotation.  If lookAt() tried to rotate that mesh, it would be ignoring the rotation handed-down from its parent.  Instead, the handed-down parent rotation... WINS.    Rotation, position, and scaling... are "the big 3 hand-me-downs" from a parent mesh.  Note:  When the parent is a light or camera, the "big 3" rule doesn't apply.  For example, cameras and lights have no .scaling to hand-down.

The Target:  When the target is parented, use .getAbsolutePosition() instead of .position... as the first parameter of the lookAt() call.  See line 41...

https://www.babylonjs-playground.com/#FZEH1H#1

The 'ALMOST':  I think that when a lookAt() is done with full parameters, and when the last parameter is NOT BABYLON.Space.LOCAL, then the lookAt() function should automatically convert/change the first parameter. It should automatically modify the pos value... from being box1.position... to being box1.getAbsolutePosition().

Example:  line 37 - box1.lookAt(box2.position, 0, 0, 0, BABYLON.Space.WORLD);

If I'm reading the typescript source correctly, line 1316 should use .getAbsolutePosition() IF the last parameter is NOT BABYLON.Space.LOCAL.  Not sure, though.

When I activate line 37 (and de-activate line 41), the lookAt() should work fine, because I am using WORLD as the last parameter, and NOT LOCAL.

But activating line 37 and de-activating 41... fails.  This MIGHT indicate that the automatic convertor to .getAbsolutePosition() in the framework code... is failing.

Perhaps some TS experts might want to verify this.  I'm certainly no expert in these matters. 

For now, just use .getAbsolutePosition() for looking-at parented targets, such as line 41 does.  Meantime, perhaps you or some other coding Gods... will 'look at' line 1316 and tell us if they think it is doing its job.     Hope this helps.

Other forum helpers... PLEASE correct any wrong things I have said.  Thanks!  I'm always scared of saying wrong things. 

[GameMonetize]

I would expect LOCAL to always use local position (.position) while World should use getAbsolutePosition. This is something I can fix if we agree on it

 

[Convergence]

On 7/30/2017 at 9:49 PM, Wingnut said:

Hi C, good to see you again.  umm... I think what you have shown in the playground... is ALMOST intended and ALMOST normal.

 

Thanks  

https://www.babylonjs-playground.com/#FZEH1H#2 

I changed your playground to parent the lookAt mesh, and it shows what I want to achieve more clearly (and currently not working), if the 'looker' has a parent which is rotated the lookAt function is not working as expected.

15 hours ago, Deltakosh said:

I would expect LOCAL to always use local position (.position) while World should use getAbsolutePosition. This is something I can fix if we agree on it

 

Thank you  yes it seems to be doing that for the target position, but what about if the 'looker' mesh also has a parent, which is rotated? (which may also have another parent which is also rotated), like in the playground above?

[Wingnut]

Could use "the bake" method after every parent rotation.  https://www.babylonjs-playground.com/#FZEH1H#3

Lines 50-53... constantly adjusting box 4 rot, + a baking.  box 4 is box 1's (long looker-box) parent.

But, you know... constant parent baking is... well... kind of weird. 

@Arte has a thread going... that somehow got us onto the subject of "custom parents"... which... instead-of handing-down all rot, pos, and scaling to its children... would allow the programmer to select WHICH values were handed-down to children.  I'm not sure if that would apply, here, but I thought I'd mention it.

[Arte]

3 hours ago, Wingnut said:

Could use "the bake" method after every parent rotation.  https://www.babylonjs-playground.com/#FZEH1H#3

Lines 50-53... constantly adjusting box 4 rot, + a baking.  box 4 is box 1's (long looker-box) parent.

But, you know... constant parent baking is... well... kind of weird. 

@Arte has a thread going... that somehow got us onto the subject of "custom parents"... which... instead-of handing-down all rot, pos, and scaling to its children... would allow the programmer to select WHICH values were handed-down to children.  I'm not sure if that would apply, here, but I thought I'd mention it.

I'm praying for "custom parents" 

[Wingnut]

Well?  Code one. 

http://doc.babylonjs.com/overviews/observables

See that big list of observables?  Way down there... mesh.onAfterRenderObservable.  Here's a PG SEARCH for that term.  Most of the returned PG's are using scene.onAfterRenderObservable, but a few are using mesh.onAfterRenderObservable.

Just after (or before) your new "super parent" is rendered, what would ya do?

Yep, iterate thru every item in superparent.constrainedChildren array, and ASK each one if it is "ok" to change (hand-down) all axes of rotation, position, and scaling. 

In other words, "Hey child... report to me WHICH of your rot, pos, and scale axes are frozen.  Then I will only adjust the non-frozen properties... per MY settings of those properties."

There ya go.  A parent... that heeds a child's "freeze-preferences".  Cooooooool. 

[Arte]

"Hey child... report to me WHICH of your rot, pos, and scale axes are frozen.  Then I will only adjust the non-frozen properties... per MY settings of those properties."

Easy as 1, 2, 3.

[Wingnut]

  on the child...  child.getTransformationConstraintMask()  (we need to code that)

returns 101000100
                \ \ \ \ \ \ \ \
(pos x y z, rot x y z, scaling x y z)

Position Y frozen, all rotation frozen, scaling Y and Z frozen.

Once the parent gets a return from a successful child.getTransformationConstraintMask(), it decodes the mask and makes the allowed hand-downs... thru shear force.  (we need to code that, too)

The custom parent really isn't a parent anymore.  It's a position, rotation, and scaling commander/manager... in-charge-of the troops.  Sort of like a scoutmaster.    And we're right back to separately positioning, rotating, and scaling each (non-)child mesh, eh?  This is what we were trying to avoid, wasn't it?  Darn. 

(Though, with this "hand-me-down manager", it is somewhat automated.)  Sorry for the thread contamination, Convergy.    We'll get back to lookAt() soon, I promise.  I keep messing up your wish to get words from @Deltakosh about target/looker when-parented issues.

[max123]

19 hours ago, Deltakosh said:

I would expect LOCAL to always use local position (.position) while World should use getAbsolutePosition. This is something I can fix if we agree on it

 

I agree

After all, sticking to real world physics/scenarios will make using a 3d framework far more intuitive:

@Wingnut - when you're on a train, you can still walk and turn around or check out a gorgeous chick picking up the purse she dropped

 

[Pryme8]

50 minutes ago, Arte said:

"Hey child... report to me WHICH of your rot, pos, and scale axes are frozen.  Then I will only adjust the non-frozen properties... per MY settings of those properties."

Easy as 1, 2, 3.

This is a pretty easy concept. If I have some time ill pump this out I keep seeing people ask for it.

 

 

47 minutes ago, Wingnut said:

  on the child...  child.getTransformationConstraintMask()  (we need to code that)

returns 101000100
                \ \ \ \ \ \ \ \
(pos x y z, rot x y z, scaling x y z)

Position Y frozen, all rotation frozen, scaling Y and Z frozen.

I would make them scalers so that way you could have like 0.5 as a value and it would "half" a rotation or a scale change.

[Arte]

And we can name it Group not Parent. I just dreaming 

[Pryme8]

https://www.babylonjs-playground.com/#WYWTUN#3

This is a broken example... It would need to be thought out a little more but this is the idea...  I think it would be smart to do reverse recursion for this or  to split up the parenting before any transforms are done and use a "array map" to rejoin them.

Sorry I only had like 10 mins.

[Wingnut]

P8, I think there would be NO classic parenting done at all.  But then again, having EACH sub-piece ALSO being a sub-piece manager... would be kind of cool. 

We should head back over to @Arte's parametic cabinet thread... for this talk of custom non-parent parenting.    @max123, I have a comment about trains for you, over there.