solved Draggable mesh with constraint

[paleRider]

Hi everybody:

In order to implement with BJS a kind of joystick behavior simulation, that is a cylinder-like object which remains always fixed in one of its endings, and is free (draggable) in the other one, I'm doubting about what could be the best approach:

1. to do all the thing with basic BJS maths;
2. to use a transparent constraint-like sphere, with a radius equal to the length of the stick, so I can detect the picking intersection with the sphere and to orientate the stick accordingly (longitudinal axis) as I dragging it;
3. to use a physics-engine, maybe with a distance Joint (is this an overkill?).

Any help?

[GameMonetize]

Hello!

3 is clearly overkill

1 seems the most reasonable for me (mostly from a performance standpoint)

[paleRider]

Thanks Deltakosh:

I'm going to do as you advice and (surely) I'll come back with new doubts about this implementation.

Best regards.

[paleRider]

Well, only if it could be useful for someone, finally my approach to this problem has been:

• to create an invisible "constraint" sphere;
• to implement a dragging (pointerdown+pointermove+pointerup) solution for such sphere;
• to orientate the stick having as the longitudinal axis the one subracting pickInfo from origin (and two more ortogonal axis).

Best regards.

 

 

[Wingnut]

Hi again, PR.  A forum friend and I... once made a "virtual joystick" to use for controlling a submersible. 

https://www.babylonjs-playground.com/#2JXSKY#5

A WICO "RedBat"    It uses our playground drag'n'drop demo as a starter scene, so... a function called getGroundPosition() is rather important.  The camera angle MUST be kept in such a way... that the "ground" is always behind the red mesh (this allows the "drag" on the red bat to work properly).

In line 43, we set the pivot on the bat... to its bottom.  In the big fat onPointerMove func (lines 105-117 does it all, including bat rotation limiters)... and in onPointerUp, we re-center the joystick in line 85.  This PG also has "coast-to-stop"... a ramping-off of the speed... after joystick is released.

It works pretty well.  Steal code at-will.  The sub is doing a tiny bit of rotation... due to line 134, which can be deleted.  Hope this helps.

[paleRider]

Thank you very much Wingnut:

Very handly example indeed

I'm going to study your code right now.

Best regards.

[paleRider]

Hi again Wingnut:

I've been playing with your joystick-driven-submarine PG and it works great.

Anyway my real problem is a bit different. Let me explain...

I have a shower mono-lever mixer (you know, the ones with a spherical joint)...

...that I want to model in two pieces (base and handle), and a movement with two degrees of freedom (between some limits) as shown:

 

Ok, the mine has the handle upwards, ... but it doesn´t matter!

Please note that, as the shower is going to be shown only in a front-view I prefer don´t mesh with planes and picking rays and remain with clientX and clientY instead.

Lets try the first movement, ...easy as shown in the following PG: +-15º rotation on X using "rotation()"

But when I pass to the second movement I can´t implement it in one: +-55º rotation on Y using "rotation()"

...or the other remaining axis: +-55º rotation on Z using "rotation()"

In these two last PGs, isn´t weird to get a rotation along the same (vertical) axis even though the use of different rotation-axis?

 

Well as I am stuck in this (strange) behavior for a while, I've tried to use other approximation, with the help of addRotation (as advised in the docs), and it works for the first rotation: rotation on X using "addRotation()"

for the second: rotation on Y using "addRotation()"

and, finally, for both: complete rotation using "addRotation()"

The problem now is that I can´t introduce the range of turning-constraints in any way as the different angles are all mixed.

Any help?

 

[Wingnut]

https://www.babylonjs-playground.com/#2JXSKY#39

How's that?  I suppose you'll want to know what I changed, eh? 

Lines 41/42 are interesting.  After rotating the blue base, I baked that orientation change... into the mesh.  (which leaves the mesh as it is, but sets all .rotation and position settings back to 0,0,0).  Then, positioned it to y=7, then later parented handle to it, and positioned IT.  Weird, huh?

Wanna see HOW weird?  https://www.babylonjs-playground.com/#2JXSKY#40

In line 111, change z to y.  Run.  It rotates exactly the same, whether it is set z or y !!!  Ain't that just retarded?    And that's the thing that has been banging on your head with a stick monoMixerHandle.   

I never really understood WHY such things happen... I just fiddle with 'em til they work, and you need bakeCurrentTransformIntoVertices() as one of your fiddling tools. 

[paleRider]

Hi Wingnut, and again thank you very much for your time.

Well I need to spend a little more time with your PGs (this evening, CET Time, I promise) but what you say makes all the sense for me.

Indeed I think it goes in the same direction that I've been thinking about last night and I've just checked a moment ago: if you don´t introduce the first "blue base" rotation the whole thing works (with per-axis rotations) as supposed. In such a case global and local axes are the same.

From that I was thinking that I needed what in Maya, Blender and other 3D Tools is called a "freeze transformations"... and "voila"... maybe is what bakeCurrentTransformIntoVertices() is doing in your code.

As say, let me put in order my mind with all this...and I'll come back to close this thread.

Best regards.

 

[Wingnut]

Hi PR, my pleasure, you're quite welcome. 

Actually, I think you found a framework bug (Wingy pats you on the back).

https://www.babylonjs-playground.com/#2JXSKY#41

A rotate on X... in line 17.  No big deal, in theory.

After that, lines 21 and 22 do the exact same thing, and that is abnormal, I suspect.

I think line 21 is rotating the mesh's WORLD SPACE Y-axis, and line 22 is rotating the LOCAL SPACE Z-axis.

But, I make lots of mistakes.  I'm not a "natural" with geometry.  So, let's ask other forum-folk what they think.

You may have just earned your "I Contributed to BJS Core" shoulder patch and bumper sticker.    Well done!

[paleRider]

Hi again Wingnut:

Well, after reviewing your code and give a new opportunity to the docs, I agree that there is something strange (or maybe out of my reach with my current knowledge of this great engine) with the behavior of the rotation of parented meshes.

Certainly (and fortunately) this is only a model of the final developing, where the single-lever is going to be made, not in parts, but as a unique (complex) mesh.

This way, although there are open questions about the weird "replicating" rotations; applying the "good practices advises" of this forum I think we can mark as "closed" this thread.

Best regards.

 

[Wingnut]

6 hours ago, paleRider said:

the behavior of the rotation of parented meshes.

And behavior of non-parented mesh, as my last PG demo shows. 

I need to read the rotation docs again, I guess.  Sorry I couldn't be of more help, and sorry no other forumers/experts came to verify/validate anything.

I suppose we could report it as a bug, or try to fig why it is acting that way (hack BJS source).  But, I make mistakes, and I dislike submitting bug reports without someone else verifying "yeah, something is broken, there".

Of course you're welcomed to mark this as solved, at anytime you please.  But, I'm going to make one more beg for verification from others.  Here it goes. 

Hey fellow forum users...  in this playground, line 21 and 22 make the mesh rotate in the same direction.  Do you think this is "normal"?  Thx everyone.  And thank you, too, PR.

[Wingnut]

Hmm, no comments from anyone.  Darn.

Ok, let's call-in the "king" of rotation... @JohnK  (or anyone else who wishes to help)

How about a more interesting playground, too?  https://www.babylonjs-playground.com/#2JXSKY#42

THE FIGHT OF THE CENTURY.  Line 18 vs. line 19!

Line 18, using the Y-axis... fighting to make the box rotate clockwise.

Line 19, using the Z-axis... fighting to make the box rotate counter-clockwise.

Rarely do two so-perfectly-matched fighters... meet in a renderLoop... and YOU CAN BE THERE! 

John, (or anyone) umm... help, please?  Perhaps I smoked something I shouldn't have.

I need your opinion... on whether/not... you think these two lines... should BOTH being rotating the box on the (seemingly) same axis.

It just doesn't seem right.  I don't think a rotation on y and a rotation on z... should EVER spin a mesh on the same axis, no matter if the mesh has been pre-rotated (line 14) or not.

It's just not right.  Or is it?  I dunno.  I'm starting to doubt my own horse sense.

[brianzinn]

The rotation not happening is puzzling!  I changed beforeRender to registerBeforeRender and that didn't do it.  I changed to rotate and it works, so something about setting the rotate directly does not cause the rotation?
https://www.babylonjs-playground.com/#2JXSKY#43 (this does rotate but using quaternions). Curious why .rotate.x += does not cause rotation.

[JohnK]

Sorry been so long answering been busy with other things.

mesh.rotation.x = -Math.PI/2;

scene.registerBeforeRender(function(){
    mesh.rotation.y += Math.random()/100;
    mesh.rotation.z -= Math.random()/100;
})

Does not mean rotate x by 90 degrees and when it is in that rotation rotate y by a bit and z by a bit.

mesh.rotation is always done in a fixed order which in terms of the world axis , do rotation about  z axis, then about  x axis and then about  y axis ( or if you want to think about local rather than world axes order of rotation is y, x, z ).

Using

mesh.rotate(BABYLON.Axis.Y, Math.random()/100, BABYLON.Space.LOCAL)
mesh.rotate(BABYLON.Axis.Z, Math.random()/100, BABYLON.Space.LOCAL)

accumulates the results in the order the rotations are given.

This PG https://www.babylonjs-playground.com/#1ST43U#45 shows three rows, the top row shows the starter box then an accumulation of z, the middle row is top row plus x rotation, the last row the middle row plus y rotation.

Thinking in terms of world axes notice after z rotation the blue side is parallel to the XoY plane and so giving a rotation to these boxes of  -90 degrees about x brings the blue side to the top parallel to the XoZ plane, effectively the z and x rotation has resulted in a rotation about the y axis. Finally to these is added a further y rotation.

In the PG above the z accumulation is positive and reinforces the final y rotation.

In this PG https://www.babylonjs-playground.com/#1ST43U#46

 the z rotation is negative counteracting the final y rotation.

Since in the animation in this post's PG

17 hours ago, Wingnut said:

How about a more interesting playground, too?  https://www.babylonjs-playground.com/#2JXSKY#42

the accumulation is random with z negative and y positive the actual rotation carried out can be a small positive or small negative number resulting an an oscillation around the y axis.

Besides the method used by  @brianzinn another way to solve this is to  replace

mesh.rotation.y += Math.random()/100

with addRotation

mesh.addRotation(0, Math.random()/100, 0)

as in this PG https://www.babylonjs-playground.com/#2JXSKY#44

[JohnK]

On 8/29/2017 at 3:06 PM, paleRider said:

The problem now is that I can´t introduce the range of turning-constraints in any way as the different angles are all mixed.

Does this solve the constraint problem?

https://www.babylonjs-playground.com/#2JXSKY#45

[Wingnut]

Thanks John... maybe.  I have to read that all about 7 more times. 

Anyway, in the "line 18 vs line 19" prize fight playground,  I add random() just to make it look like a real fight was happening, and then me and my buddies could make bets for shots of whiskey... on the outcomes.

Nah, none of that is true.  But, here's the same thing without the random().  Just two rotaters... going head-to-head... in the renderLoop.  One is += adding onto the Y axis, and the other is -= subtracting on the Z axis.   Result?  No movement!!  Why is that just blowing my mind? 

Oh yeah, apparently JohnK has taught us why.  I'll read it again, and again.

But, now, @JohnK, @brianzinn, @everyone... do you think this is acting "normal" and/or "correctly"?  (Don't worry, you can change your mind later, no problems.) 

[brianzinn]

Don't worry, I've already read it 7 times and don't get it, so you won't be alone!

[Wingnut]

  I'm glad John used different colors on his box sides.  That helps a bunch.  Still, this feels like Algebra 1... which I failed 3 times in high school!  I'm SO proud.

[JohnK]

2 hours ago, Wingnut said:

do you think this is acting "normal" and/or "correctly"?  (Don't worry, you can change your mind later, no problems.

Interestingly the first thing I tried and got totally confused about when I started with BJS were rotations as they didn't do what I expected. Now I accept rotations do what they were designed to do and they do so in a way that makes sense. They set rotation as would a given yaw, pitch and roll. 

So are they behaving normally or correctly yes they are.

Oh no wait a minute I think I'll change my mind...............