Rotating items

[iiceman]

Well, I at least figured out a way to rotate around the x-axis as well: http://www.babylonjs-playground.com/#Z3UOX#5

 

Playing around with determining the point just by clicking in space i crashed the playground and the scene was gone and I don't feel like doing it again

 

I tried to make a sketch anyways why I think it's not possible to find the correct point without additional information like focusing on a certain plane within the 3D space. You never know what point the user meant because you only get 2 coordinates and not 3. So it could be any point along the ray that is cast from the camera through the screen. I really don't know where I am misunderstanding you guys

 

 

[dbawel]

ou only need two points, as the third point is the object's axis center.  This is how we calibrate optical 3 dimensional systems, as we register the center of a volume or object, and we only need two additional points to set a 3D vector.  Forces such as momentum, acceleration, thrust, etc move the object.  So just remember that the object's center axis is a point in space from which you can aim a vector towards another point in space.  If I have time, i'll build a scene on the playground - just not today.

 

Cheers.

[Wingnut]

http://playground.babylonjs.com/#1WJA7K#1  Just puts a single (html) point in 2d space.    Exciting.

If the camera view vector is running from camera.position... to scene origin (0,0,0)... then... um...

   another vector can run from camera.position to the click point... and then... um... I have no idea. 

I think the second part of dbawel's math... is working in percentages... but I'm scared.

But a ratio can be established here, somewhere.  We can say that the clicked point is SOME percent from canvas center.  Would we then turn the camera the same percent of a 90 degree turn?  (left/right/up/down considered)  hehe.  This is goofy. 

Ice, your new demo is excellent.  Thx!  You still might have a little calibration issue, though.  Click left... and the box is a bit too nose-low.  Click right... too nose-high.  It could be an optical illusion, though.  It's WAY better than I could do, that's for sure.  A few days ago, I tried modifying your demo to do x-rotating.  The box accidentally rotated too fast, and one of its sides detached, and dented the back-side of my monitor screen. 

[iiceman]

I woke up this morning at 5AM an couldn't sleep because my throat hurt and suddenly it hit... out of no where, not even thinking about spaceships an points in 3D space. At least I think I understand now waht you guys mean:

 

It's not really about a certain point in space but the different between two points on the screen. A bit like when you rotate the camera: you start dragging (point 1), you drag, you stop dragging (point 2). The difference between those two points along the y axis of the screen is the pitch, the difference along the x-axis is the yaw. In our case it's not the difference between a starting and an end point but between the clicked 2D point on the screen and the (2D) center of the screen (or that point on the screen where the spaceship is).

 

Did I finally get it right?

 

 

Edit:

Okay, I gave it a try. I imagine you mean something like this: http://www.babylonjs-playground.com/#1WJZF3

 

When you click on the right side the spaceship rotates clockwise around it's y-axis. If you click on the left it rotates counterclockwise. The further away from the center the click is the more it rotates. The same works for rotation around the x-axis: the further up you click the more it rotates. I used an extra plane instead of dome events because... well, it seemed easier on the playground. But I guess using DOM-Events would be more useful (as jerome suggested).

 

Hmm... so that's basically the same idea as Jaskar had in the very first answer to this question? You click a bit left, it rotates a bit to the left... is that really what DigitalHilsone wanted? This kind of controls doesn't seem right to me. Well, I guess It makes more sense if you rotate the camera along with the spaceship like Wingy suggested.

 

So I guess all of you were right and it was really just me who couldn't imagine it Well, I hope I got it now and it dosn't wakre me up at 5AM anymore - but please tell me if I am still wrong about something

 

Edit 2: 

And why do I have only 40 fps on that? Is my implementation really THAT bad?

 

Edit 3:

Never mind the previous edit - seems like I have only 40 fps on all the playgrounds at the moment.

(sorry for that confused and messy post, being awake that early doesn't seem to be good for me. Well I guess I just could have deleted the previous edit comment... anyway )

[dbawel]

Hi Iceman,

 

Wingnit seems to be frightened a bit, but you seem to understand how we must work limited controller values into an object that appears stationary. It's  relationship between a numerical value (a controller such as an x,y position), and a vector. A skeleton joint is probably the best example. I normally use a bone as a parent to drive controller values since a bone has local axis constant numerical values. Just look at the math again, and the important part is the blending math  Otherwise like in your Playground scene the ship's orientation transforms are additive. You have to have limits on this and also blend your controller values. Also, the blending math will return your object to it's original axis unless you structure otherwise. I hope this helps, otherwise I can build a scene that represents this. No need to wake up at 5am, I don't sleep so everyone else can.

[iiceman]

Yeah, I think I get it now. And you are absolutely right that the additive transformations are not really intuitive for a player. I'll give that blending and resetting to original rotation thing a try (maybe tonight) and we will see if I get it to work. Well, It's actually a good feeling even if it took me kinda long. I appreciate the guidence and hints, thanks! I learned something new and building the playgrounds always helps learning new stuff. So it's a good thing I gave it a try

[Wingnut]

Hi Ice, DB, whoever else is hanging around.  Iceman, you asked if this is what DH wants, and I think we left that behind, and we started pursuing providing DH with everything he/she could possibly ever need. 

 

You're not as lost as you might think, Iceman.  It's just that the .subtract might not work for getting a direction.  (I can't remember if you used one, but, the .subtract method... likely needs some "magnitude" on the z axis.

 

So, yes, you are correct about the difference between 0, 0, and the clicked point.  There will be two "offsets" from 0,0 (if user clicked in some place other than 0,0).

 

This is similar to an airplane steering yoke... with a GO button.  You might turn a bit to the right, and pull the steering wheel back (nose-up) a bit... and then CLICK GO.   The airplane then begins moving to that new orientation. 

 

I wish I had DB's experience with RC controllers.  And I hope we stumble across some methods/ideas that DigitalHilsone likes/can use.  But lots of users might learn from this, especially ME.  Using a mouse/touch to steer ships and cams... is a pretty common thing.  I think we are maybe working on an early version of "The Flight Control Library".  Maybe that library will have tools for all this stuff, and it will be all adaptable for keyboards, joysticks, gamepads, touchscreen, deviceOrientation, Oculus head-turns, and maybe even Kinect gestures.  Wow!   Library-o-controller-funcs!  yeah! 

 

DigitalHilsone... I hope we are still somewhat on-topic and still being helpful, or at least semi-interesting. 

[GameMonetize]

Hey guys!! do you mind trying to summarize in a couple of lines what you are trying to achieve here?

[Wingnut]

Hi DK!  Thanks for asking.  I'm not sure any of us know.  DH's posts are #1, #7, #10, and #16.  How do you interpret those, Deltakosh? 

 

Although it appears in the picture that MAYBE DH wants clicks on planets - to target the ship to the planet (easy).  But lately, we have been trying to click on screen (no mesh pick), and then rotate the ship SOME amount... toward the clicked point direction.

 

My thoughts... click-on the right edge of canvas, ship rotates 90 degrees right (with ease in/out), and a followCamera might ride along. 

 

Click HALFWAY toward right edge of canvas, then ship rotates 45 degrees right, with ease-in/out. 

 

Same for left, up, and down.  A click UP and RIGHT, rotates the ship pitch-up, and yaw-right... AT THE SAME TIME (blended).  (and both using ease-in/out).  The rotation animations for X and Y... need to start and end at the same time, even though they are likely different AMOUNTS of degrees/radians of rotation.

 

Iceman and DH have been using Animation/keys to do the rotation.  I prefer a updateRotationProgress() in the animation loop.  Also, we should probably be using quaternion to avoid possible gimbal lock condition... maybe.  Avoid polar clicks... and euler might be fine.

 

That's my opinion of the situation.  Possibly a touch-screen purpose.  Anyone else? 

 

Sorry for the rubber/Jello objective, Deltakosh (it's wobbling-around).  I think dbawel's math is ok for calculating a "percentage of difference from origin".  I think it returns a value between -100 and +100 for both X and Y... which can be thought-of as percent-of-a-90-degree-turn.  ie.  A click could happen 30% up and 70% right, for example.

 

We're having troubles converting those values... to an actual gimbal-lock-free rotation.  

 

That's my take on it.  I have not tested dbawel's math, yet.  I see no ground in the first picture, so I think the solution must be without a ground, too.  Thanks for taking a look, Deltakosh... nice of you.

[dbawel]

Hi Wingnut,

 

You summerized this well in your last post.  So here's a review of the problem and the specifics of the controller math to accomplish the question initially asked in this post - as far as I can tell. 

 

The inital question was how to steer a ship in a specific direction by simply touchin the screen.  One element I mentioned in a seperate post was that I would parent my ship to a bone, and control the axis of the bone with the screen controller.  Bones are ideal since they not only have a root, but a bone and an end effector - so they are far less prone to gimbal lock. Then I use the math below to control the bone to which the ship is parented.

 

Let's say you have a canvas of 1024X1024.  Your pick pint is (x,y).  Using conditional statements:

 

 

if (x > 512) {

    a = ((x - 512) / 5.12));

}  else  {

    a = 0;

}

 

 

if (x < 512) {

    b = -((x - 512) / 5.12));

}  else  {

    b = 0;

}

 

 

if (y > 512) {

    c = ((y - 512) / 5.12));

}  else  {

    c = 0;

}

 

 

if (y < 512) {

    b = -((y - 512) / 5.12));

}  else  {

    b = 0;

}

 

 

If you look at the math for each of these variables a, b, c, d then you have a value of 0 to 100 for each variable.

Then you'll want to average these so that you can direct your ship in a blended direction, and not simply as an additive.

 

This math is:

 

var Blend = (a + b + c + d)

 

if (Blend > 100) {

    BlendDivide = ((a + b + c + d)/100)

}  else  {

    BlendDivide = 1.0   {

}

 

var dir1 = (a / BlendDivide)

var dir2 = (b / BlendDivide)

var dir3 = (c / BlendDivide)

var dir4 = (d / BlendDivide)

 

And you now have a blended direction for each (x,y) vector from a value of 0.0 in the center of your canvas for whatever the pick point is.  This will give you perfect control in whatever direction the user wants to steer.  If you want your (x,y) center to be in a different position on the canvas or more force in any direction, just change the math.

 

1. The first 4 conditions set a value for each direction on the controller to be between 1 and 100.

2. The blend (average) math adds these values together and sets a condition for a percentage of each direction to run from a value of 1 to 100.  

3. Then the values for each direction on the controller are divided by their own average so that you can never exceeed a value of 100 for all directions collectively.

 

This will return the ship to a default vector, however, as sked in the original post - If you want the ship to remain on the vector which is set, add a new condition to not return a value of 1.0 to the average math for each dir variable.

 

I THINK? this answers the question. Thanks for asking DK, as I doubt I'd be able to make sense of this post if I were to review.

 

DB

[Wingnut]

DB, can we see it work?  I can't tell what to do with dir1, dir2, dir3, dir4.  But maybe others can.  I'm still learning, and I don't think we can answer this issue thoroughly until we see it happening.  As far as bones, I have never worked with them at all.  I, and maybe DH, need to see this very clearly, and that's going to require a test scene, I suspect.    Mesh.rotationQuaternion.RotationYawPitchRoll(?, ?, 0)  ?? 

 

I promise, I'm studying as fast as I can, but meantime, DigitalHilsone is probably quite discouraged with my progress.  I jumped into this issue early, and it quickly went over my head... and then DH was dependent upon me for an answer... and I failed him/her.  I asked Deltakosh to help, because I am failing to provide a clear solution for DH, and I SO wanted to be a hero... with this seemingly-common issue.   I didn't do so well.

 

DB, you can call this issue "answered" if you wish, but I'm not yet feeling that way.  I need to see it... and then learn it like the back of my hand.    Then I write a tutorial about it, so I don't forget it.  heh   We need a really nice bridge from complicated-to-simple, here, in my opinion.  Lots of streetlights and smooth pavement. 

[dbawel]

Hey Wingnut,

 

You didn't fail - you provided allot of info here.  I have to finish some work this afternoon, but I'll see if I have time this evening to parent a simple object to a bone in Blender, and drive it with an x,y pointerdown.

 

The variables dir1 through dir4 are the values to provide the bone's x and y deltas.  You'll want to attenuate these with a multiplier if you requie more rotation on any axis, or divide to lessen the influence.

 

Cheers.

[Wingnut]

http://playground.babylonjs.com/#1WJA7K#5  Ok, I turned on DB's math... I THINK I have it coded correctly, but I think DB will need to tweak it.    The numbers don't look so good, yet.  But its a start.  Click on screen, and you get two alerts, one showing a, b, c, and d, and another showing dir1, dir2, dir3, dir4.

lookin' learnin' thinkin', though my pits are stinkin', get them brain cells linkin', rawhide!  yeee haw

[Wingnut]

http://playground.babylonjs.com/#1WJA7K#6  We're in the vicinity.  What a kludge-fest I have going here.    No rotation/easing animation, yet.  That will come later.  The little bit of easing you are seeing... is a built-in feature of the followCamera. 

But by gosh, by golly, the click-to-steer is almost working correctly.  Scary. 

Click near to the "craft" for small changes, farther-away for larger changes.

[iiceman]

That looks pretty good!!! I think it would work more intuitive if it updates while the mouse button is down so that you can drag and don't have to click all the time. But very cool anyways!

[jerome]

maybe may we set an immobile craft and just a long enough textured ground, then offset the texture each frame instead

[Wingnut]

Thanks!  Yeah, those are both possible options, guys.  Feel free to make them.  I am sure DH would appreciate the alternate versions.  Jerome, moving the scenery past a stationary ship is probably plausible when there is only ground.  When you start moving an entire solar system and it's lighting... past a stationary ship... well... I dunno. 

 

Meantime, did you guys see my terrible math mods?  I changed DB's math, to be only A and B...  both are -100 to +100 values for x and y.  No more C and D.  A and B are percentages of screen offset from 0,0... and then I divide them by 1000 in lines 115/116.  So, a 68% turn to the left... becomes a .68 radians turn to the left.  Goofy. 

 

It should probably be 68% of Math.PI/2... i.e.  68% of a 90 degree turn left.  And, it still needs rotation animation with easing.  DH did mention "gradual".  If anyone wants to work-on these issues, that would even be better.  For example, I'd love to see an ease-in/out animation on every rotation, both axes, that start and finish at the same time. 

 

This raises a question.  What happens when a user chooses a NEW direction... when a previous turn's animation is still not complete?

 

I think a rotation animation needs to be cancel-able.  Something like...

 

IF (newDirection && mesh.isAnimating) {

    mesh.animation.stop();

    mesh.animation.keys = newkeys;

    mesh.animation.start();

}

 

(that's for keyframe-type animation)

 

For dynamic animation, such as some kind of auto-easing Math.SIN animation placed in the renderLoop, that can be nulled to zero (upon interrupted rot-anim), and then a new sine (with new start/end points) can be inserted into the animator func.  (omg!). 

 

I'd love some help with THESE things.  (thx, guys)  Then I can close this customer service ticket.  After that, we can REALLY start playing. 

 

(I'm not very tactful or graceful at dumping MY problems/quests... onto others, am I?)  heh

[iiceman]

That's how I imagine the click and drag: http://playground.babylonjs.com/#1WJA7K#7

Just had to add the dbm function to the animation loop and trigger it when mouse is down. Also increased the the values on line 115/116 to smooth the impact a bit to 10000. This way it's automatically "gradual";

The math changes make sense to me. It's a bit easier to imagine with only 2 values, since we only want to control 2 axis.

Can't wait to play a prototype of that space game how long 'till it's done?!?

[DigitalHilsone]

http://playground.babylonjs.com/#NLAUI#2

Guys, there's the option of use. The problem is well known: it is necessary to make the "ship to" move "the nose" (before), but not the center of the figure. This can be done by means of Babylon?

upd: http://playground.babylonjs.com/#NLAUI#3

very informative!

[Wingnut]

Cool, Iceman! I like it.  Too bad I got the goal wrong, eh?  Crap!  No ship pitch up/down, just yaw, I guess.  Sorry for the goose chase.  I had it wrong.

 

Thanks for the clarification, DH, and yes, it can be done with BJS.  It's starting to "look" like a job for mesh.lookAt() with animate-to-new-target.  And no follow cam.  Overhead stationary.  (I'm talking to myself... to firmly weld the objectives into my brain) 

 

DigitalHilsone... do you want a ground plane in the solution, like your demo uses?  Or do you want no ground, like your first picture?

 

I think DH is using a ground in his/her demo... only so that actionManager picking is working.  You prefer no ground, DH?  The latest demos from Iceman and I... are screen-click methods and not actionManager click-on-mesh methods.  ActionManager picks/clicks seem to need a mesh (such as a ground) to pick-on. Conversely, screen-clicking doesn't need a mesh. 

 

Maybe someday, I'll talk Deltakosh into letting us register onMouseDownTriggers on scene.actionManagers.... which would give us click-on-background ops.  But scene.pointerX and scene.pointerY work just fine, too.  Right now, I think onMouseWhateverTriggers... only work on mesh.actionManagers. 

 

There might be issues with a SCENE actionManager and a MESH actionManager... fighting over which one should process a pick/click... if the same trigger is registered on both.  But scene AM's could ignore all clicks that hit a mesh.  AND... mesh AM's could bubble their events to scene AM's, but... hmm... why? 

 

Sorry, I drifted-off for a moment there. 

 

I'm back on it.  Let's see, I figure...

 

1. Set stationary overhead view

2. Get the click

3. Set var targetPoint =  new BABYLON.Vector3(scene.pointerX, ship.position.y, scene.pointerY).  

4. Perform a ship.lookAt(targetPoint, yawCorrection)

5.  Try to get some sucker expert to program mesh.lookAtWithEasing(), so we get our smooth animation.

 

That might work.  I'll do some tests when I get a chance.  Others, please participate at will, thx.

 

Actually, a followCamera does lookAtWithEasing, doesn't it?  Maybe there's some code to steal, there. 

 

The ship never changes altitude (y), huh?  Darn.  How did I misunderstand THAT one?    Maybe I'm more of a geezer than I first thought.  My brain seems to be failing me.

 

UPDATE:  It didn't work.  LookAt() needs world coordinates for its target, NOT scene.pointerX/Y coords.  Duh, Wingnut.  hmm.  Here's my broken test, so far.  Now I know why having the X/Z coords of the ground under the click point... is good to have, but difficult/impossible without a ground... maybe. *scratch scratch*

[Wingnut]

Ok, here's another.  http://playground.babylonjs.com/#1QPL4W

This requires a ground to click-on, and I don't have any animations.  I'm not good at animations.    But, we got click-to-steer... using lookAt() funcs.  So, when some brave warrior programs lookAtWithEasing(), we'll be walking in tall cotton.  (doing good)  (I hope) :/

[dbawel]

I'm sorry that I introduced a new idea and haven't had the time to follow through.  Wingnut and Iceman have put most of the info I didn't translate well in their recent posts.  As I mentioned earlier, the use of a bone will point the ship in the direction the user wants.  There are two methods to do this, with very different results.  First, you must have a bone chain with a root, a joint, and an end effector.  Then parent your ship to the joint (bone) in the chain and either it's local axis is snaped in position to the joint (bone) and this usually works best - or position in any way you like before parenting.  This opens up allot of versatility, including the ability to translate the ship on it's local axis' while rotating from it's bone parent.  The second method is to use the controller math to translate the end effector of the bone chain in x and y.  This will point the ship in any direction you want.

 

I'm now assuming that my lazy way of passing information will be absorbed by whomever is interested and reads this post first.  The only solice I have in providing good info here is that this math is a standard in working with controllers, and I'll expand on this once it is adopted for use.  I have to say that I didn't create this math, but learned it from the dude who created Motionbuilder - Andre Guthier - one of the coolest dudes you'll ever possibly meet.  I'm incredibly fortunate to have such clever friends.

[Wingnut]

It's all cool, DB.  We've seen what the math does, and it's definitely useful.  And, I think the 3-bone chain is useful, too.  I'm going to try it... but not today.    It sounds like a great way to get past my fear of skeletons.  I can understand this.  You get lots of control because of the joints.  Armature management... beginner level puppetry.    I love it!  We can also study beginner level .bvh and other mocappy things.  I can foresee a future Babylon Skeleton Lab.  YAY!  Yep, all this stuff smells good to me.  Bots!   PARTY!

 

How do you translate along ship z?  Elongate the end effector?  Probably not.  That will be small and tight and at ship center... so we can get nice barrel rolls.  I suppose a guy could add a 4th bone... a translation bone.  *shrug*.  I think we'd want to avoid offsetting the ship away from the end effector.  I think the EE needs to stay dead center of the ship... always.  *shrug*

[dbawel]

Hi Wingnut,

 

The ship is simply a child of the bone and can animate (translate if you like) using it's own local axis - or I like to add matrices' for each transform by providing null objects as a hierarchy in between the ship and the bone.  This will maintain complete freedom in all transforms, and avoid any gimble lock.  Bt if you just want to translate on local z, then use the ship's local z axis to do this.

 

In viewing many scenes on this forum, it appears that so many issues could be solved simply with hierarchies (parenting.)  We might want to look at simplifying the code to update hierarchy animations, but let's better understand the communities specifc needs first.

 

Cheers.

[iiceman]

Well, I got this far... pretty much does the same as before, I guess... http://playground.babylonjs.com/#Z3UOX#8

I like the lookAtWithEasing/Animation idea better (would be very usefull I think, but might not be tthhhaat easy to do)... because my solution is not always able to determine the correct direction for a rotation. Sometimes it rotates more than 180 degrees instead of taking the short rotation in the other direction :-/