Rotating items

[DigitalHilsone]

Hello! For my project I want to re-arrange an interesting feature: the rotation of the object by clicking in the right direction (and of its movement) on the principle of moving the spacecraft to point and rotation to the desired degree. How can I make such a function? Example attached.

[DigitalHilsone]

up

[Jaskar]

Hi,

 

Here is a basic idea : http://www.babylonjs-playground.com/#23HIBC

Place invisible but pickable objects : One left, one right. When hit one, you know in wich direction to rotate your object.

Then, attach these objects to the camera (via .parent), they will follow the camera and you can click it anywhere.

 

I'm not having more times for you now, but if you have questions about this, I'm sure that someone else will respond

[jerome]

You could just use DOM events and get the pointer screen coordinate on click...

if x > half your screen size do that stuff, else do other stuff

[Wingnut]

http://playground.babylonjs.com/#TTLMJ#1  A modification of a PG demo scene... which uses mouseover planes along the edges of the screen... to pan the camera.  (related to Jaskar's solution).  (turn off showBoundingBox to make them invisible).

I need to do some work on it, because the requestor (DigitalHilsone) recently asked (in a different thread) if I could get TWO-pannings at once... when we mouse into the corners.  I need to ponder that.  I might need to change to an 8-plane version.  Be well, guys.

Update:  Wait!  The same guy started THIS thread?  Hi Digi!!!  Ok, well, that makes this all much easier. 

But clicks instead of mouseovers.  ok. 

Jerome, you can get those screen coords from a pickingInfo object, or from a pick event object (which gets sent as an arg to functions that get called via ExecuteCodeAction actions).  That event object has .pointerX and .pointerY properties on it.  And a pickingInfo object has a .pickedPoint which is a Vector3.  Party on!

Update:  I'm doing tests, now.  PickingInfo gives the coords of the picked mesh... not so good for general screen picking.  You might be right, J.  DOM canvas picking points.  hmm.

[Wingnut]

http://playground.babylonjs.com/#Y3YSG#5

Beginnings.    Click in the top, bottom, left, or right 25% of the screen.  The camera should pan.  Nothing fancy... using Jerome's ideas.  Line 17 can be removed... I suspect. 

It's storming like heck, here, so i better shut off the computer for a few minutes.    Party on!

Creds to http://www.html5canvastutorials.com/advanced/html5-canvas-mouse-coordinates for helping us.

Update:  i just found out that the BJS scene object has a pointerX and pointerY property.  DUH, Wingy.  I should take the time to learn this framework someday.  That removes some code from the demo.  (yay)

http://playground.babylonjs.com/#Y3YSG#6

[DigitalHilsone]

Wingnut

 

It has done well, but I do not need the creation of zones around the facility, and that when you click on the area of the screen, the object (model) took the coordinates of the click and the calculation of the angle relative to its position to the point of moving gradually turning this a calculated angle.

[DigitalHilsone]

up

[Wingnut]

Hi DH!  Sorry I've been slow.  Lately I have been working an issue for Auduct... which also involves dragging.

 

http://www.html5gamedevs.com/topic/14481-problem-applying-collider/#entry83022

 

Oh wait, you wanted click-to-turn, not drag-in-sky-to-turn.  Or, darn, I can't remember what kind of steering you wanted, DH.  Sorry.

 

You want NO neutral zone in screen center, correct?  So if user clicks in space (scene background)... a little left-of-center... the ship/camera turns a little toward the left?  Same procedure with up/down?

 

Or maybe... the ship/camera gently (gradually) turns to aim-at the clicked point?  Errr?  Did you ever mention if you want to animate the camera/ship to aim at the new target (gentle)... or SNAP it there instantly. 

 

If you want it done slowly, then we have another issue... the transition "interpolator".  The built-in 'easing' of our followCamera might be helpful there.

 

But WHAT IF... you decided that "mouse-drag in space" is ok for YOUR turning needs?  Think about this, if you please.  What if we generally keep the ArcRotateCamera target... straight ahead of the ship. Then, if a user clicked somewhere on the screen, we gently move the camera .target to the clicked position, BUT keep it the same distance from the nose of the spacecraft?

 

There's options for this.  The camera target COULD be what we move thru space while the ship is moving.  The camera itself and the ship... follow behind it, closely.  Since it is the camera target moving thru space (likely VERY close to the nose of the ship), this allows you to pan the camera around and get different views of the ship as it passes thru space (following a camera .target).  As we pan the camera... the flight direction does no change, because there was no click-in-space to set a new target.

 

Just thinkin'.  Nothing productive, sorry.

 

Any thoughts?  (thx)

[DigitalHilsone]

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

Here, I was able to make a rotation method of travel. But it uses a mathematical formula for calculating the angle of rotation of the click coordinates (Formula slope - K=(y2-y1)/(x2-x1) ). But the rotation got pretty bad. That is not in the right direction turns, not on the corner. Help with this challenge. I need to get the front of the spacecraft (the model in my project) was moved to this part of the front, not the side or something else.

[DigitalHilsone]

up

[dbawel]

If you create a canvas for recording the x,y screen events, you can cspture this as a variable to determine at what angle the ship should turn.

[Wingnut]

Actually, I think scene.pointerX and scene.pointerY should work fine.  But an extra canvas comes with some advantages... like gui.  A guy could re-program the BABYLON.debugLayer... to be my.gameInfoLayer 

 

DH, your last demo is pretty good.  I like how you used animation.  But yes, the rotation is not acting well. 

 

The actionManager system has some 'actions' that use interpolation to change values, but I don't think our easing system is available for its interpolated actions.  I think all the value changers are linear, for the actionManager.  I think DH's project needs some easing.

 

But there are other issues here.  Let's go back to the picture at the top.  SOMETIMES the ship will have lots of forward speed, and sometimes it will be slow or stopped.  The animation will act differently depending upon the ship's forward speed.

 

Let's ONLY talk of rotation right now.  Let's pretend, a bit.  The user clicks somewhere in space - they want a ship turn.  Let's say we WANT ease-in and ease-out on this rotation animation because that would be normal for a real spacecraft. 

 

The steering thrusters fire, and the ship slowly starts its rotation (ease-in).  The rotation thrusting maybe lasts only a few seconds... to get to the wanted rotation speed (depending upon ship mass).  Then there might be a wait time, no thrusting, waiting for the ship to rotate to the point where the rotation braking thrusters fire.  They might thrust for a few seconds (ease out), and then turn-off exactly when the ship is correctly re-aimed.

 

http://urbanproductions.com/wingy/babylon/thruster/t26/flyer26.htm  (.zip is there too)

 

(pardon the black landing pads if you see such. Something changed in webGL since this was coded)

 

Push (and hold) the Rotation +Y and Rotation -Y buttons a bit.  See how we fire thrust, then wait, then counter-thrust.  The ease-in and ease-out happen automatically due-to the use of the Cannon physics engine.  This ship is turned... with applyImpulse (like a jet thruster), and the ship's mass is very involved.  The ship (the flying 4-poster bed) is heavy, and it's vernier thrusters are not very powerful.  This flying bed was sort-of modeled from a space walker SAFER unit... a cold thrust multi-port backpack unit that can rescue space walkers if they become untethered.  (yawn)

 

DH, can I assume that you want that same ease-in, ease-out "feel" when YOUR ship turns toward its new target?  I bet so.  You are currently using animation... and our easing functions work just fine... with animation/keys.  Fun ahead... but I have zero experience in easing.

 

Now let's pretend that DH's ship is moving forward at quite a high speed, and some crazy ship captain orders a sharp turn to the right.  The ship starts its ease-in to the new direction, and it takes so long to finish the new target aiming, that the ship has flown WAY past the new target (if it was a planet, for instance)... and... well... the ship rotates so slow that it can't keep up with the ship's forward speed.

 

The forward speed of the ship... can "amplify" the amount of easing, in a way, yes?  In certain situations, the ship might have too much forward motion to ever reach a planet... because the rotation takes too long.  The rotation speed... must increase... when ship forward speed increases.  Just thinking. 

 

IF your game takes place in classic "space"... these ships don't NEED to move ONLY forward. In Star Trek/Star Wars stuff... ships were rarely (never?) seen slew-translating or flying backwards.  But your ship could.  Maybe not needed.  You are welcome to use anything you wish... from flyer26.zip.  Its poorly coded... but its controller.js file IS the basis of a physics engine spacecraft, ready for nearly anything.  It can use shifted and control numeric keypad, shifted and control ; (and a circle of keys around it), and it can use the on-screen html buttons.  Controller.js is ready for all, even those who have no numeric keypad.

 

DH, ever thought about using applyImpulse thrusters and one of the physics engines... for YOUR project?  You'll lose some performance if you make the switch to physics and thrusters... but your ship will really start acting like a space craft.  In real space... it takes LOTS of fuel and thrusting to bring a chunk of mass to a stop, or to make it change direction. 

 

If there is no aero-properties in space... then why the heck do Star Trek vessels BANK when they turn?  Goofy. 

 

It really depends upon what kind of game you are making.  Space-based shoot 'em-up... no need for a bunch of space physics or performance-slowing crap.  But if you are trying to simulate real space... there's nothing like a physics engine (in my opinion). 

 

Here's Wingy... with another post... with NO answers for DH.  Sorry, bud!  I'm still thinking about it all.  Have you tried more experiments?  Do tell, thx. 

[iiceman]

maybe like that: http://www.babylonjs-playground.com/#Z3UOX (not sure if I understood the question right but I tried anyway )

 

edit: I had fun playing around so here is the fancy version: http://www.babylonjs-playground.com/#Z3UOX#2 with god rays, textrues, particles and trans warp space travel

[Wingnut]

Fancy fancy fancy, iceman!  Nice work.  You certainly have grabbed BJS by the balls and ran with it.  Smokin'!

 

I think the original objective... is to be able to click anywhere on screen, and the ship (and camera) turn that direction.  But the scene could use a separate followCamera as needed, when needed.  Since the click point could be anywhere, I don't think we can use an actionManager for picking (actionManagers seem to pick mesh, not backgroundLayer or arbitrary screen coords), and the ship targeting must be able to rotate around X, as well (it should be able to target high/low things, too).  *shrug*

 

Don't mark my words, but this is how I interpret the objective.  I could be wrong. 

 

I suppose a person could put a tiny temporary/invisible quad (plane)... exactly where the screen click happened, and then use some actionManager operations, but I don't know if that would be "the long way" or not.

 

Thanks for helping with this, I-man!  You certainly know how to do it with style.  That's a fast flight to those planets!  vrroooooooom... fwoooosh!    Fun!

[DigitalHilsone]

Thank you to everyone who responded to the rescue! Thank you for your work! As I understand it, to organize proper management - you need to draw a flight path of the ship and doing certain conditions? Otherwise, such as make a loop? The ship also will rotate around itself for a given program. There has probably not save any algorithms, right?

[Wingnut]

Check this out, DH.

 

http://www.babylonjs-playground.com/#2FIXEM#1     (keys W A S D Q E)

 

It is a fat playground, sorry.  But, look at line 425... the animate func.  Animate runs once per frame.  Line 427 is an elapsed time thing... as you can tell.  Now look at lines 412 and 415.  That is your "throttle setting" on your spacecraft.  Now look at lines 469 and 470.  WOW!  There it is... the main thrusters and the turn thrusters.  Wow! 

 

In Iceman's demo, it is 'direction' that does it all.  No need to 'draw' a flight path, he calculates a 'direction' vector to the clicked mesh. But the way HE is doing it... the user MUST click on a mesh to do steering.  I think you want to click ANYWHERE in space to turn the ship that direction.  His current technique... only turns toward mesh, and won't do mesh that are higher or lower.... yet.  He'll probably fix that for us. 

 

direction, that's the secret.  Iceman does some 'subtracts' of some mesh.positions and camera.positions, and derives a direction.  Then he uses the animator to FWOOSH along the direction.  You might not want to fly your ship quite that fast.

 

And so... using elapsed time... ie. engine.getDeltaTime()... your ship can just fly along slow, or just idle in space... or go real fast... always traveling along the direction.  The ship's captain is the person who turns the ship, in real (game/delta) time.  No need to draw paths... he just calls for turns and throttle settings. 

 

Ship inertia/coasting will be your next challenge, if you wish.  A .mass could be involved.    But that's all later.

[iiceman]

Adding the rotation around the x axis shouldn't be a problem, that should work the very same way as for the y axis.

 

About the "clicking anywhere in space" thing: I don't think it works like that. A click on the screen could describe alot of points in space (it's actually a ray, isn't it?). You never know what point the user meant. Do you guys know waht I mean? I think you need something like a plane in that space. When the user clicks you use the raycasting the determine where the click hits this plane and then u can use this point as your target coordinates... I might do a little example of what I mean, but I don't have time at the moment..maybe tomorrow

[Wingnut]

Hi Iceman!  Umm... if the user clicks on screen, we do know the x and y of their click.  So, derive the direction from camera position... to picked point, and now "pretend" the z of the click is 10000 units of magnitude (distance) along that direction vector.  Pretend the click happened 10000 units away-from the camera.

Now just animate the camera and ship direction... to ROTATE toward that point. (in theory)  We don't really need z at all.

Then let the user or programmer handle the throttle settings (translation along direction vector per elapsed time).

Actually, I think the Babylon ActionManager should have an onPickBackgroundTrigger... but I don't know if it is possible, wise, or at all necessary.

Look at http://playground.babylonjs.com/?18 if you please.  Not one mention of an actionManager.  A drag'n'drop demo... with no actionManager?  That doesn't make sense.  I think I heard that our drag'n'drop demo was made BEFORE the actionManager was invented.

All that aside...  http://playground.babylonjs.com/#QUYA1  It's a slightly modified drag'n'drop demo that reports scene.pointerX and scene.pointerY if a ground or sky click is seen.  Otherwise, it works normally. 

Iceman, keep in mind that "fly the ship to the planet" was an idea that YOU added.    I believe DH only wanted a gradual turn of the ship (and camera?) toward the clicked direction, but I could be incorrect on that.

I wonder if a followCamera that is tracking the ship...will turn automatically when the ship is anim-rotated.  (I should study followCams someday) 

If not, the followCamera will need updating as the ship's rotation-animation runs (or it might need its own animation).  Fun experiments.  Someday I'll collect all these interesting click/pick operations and ... well ... I'll do SOMETHING with them all.  ...

[iiceman]

Hmm, I see. Well, that doesn't sound to hard to achieve. You could just have a sky box (you need one anyway for the space environment, right?) and then catch the clicks and calculate the point... but I am not really sure if this kind of controls works well and is precise enough.

 

I gave the rotation on the other axis a try because I thought it would be easy... but... well, not as easy as I thought. I'll have to try again, but I don't have enough time at the moment. Maybe anybody else has a good idea how to solve the problem in a better way

[dbawel]

If you register the pick point on the canvas, the math is easy.  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.

 

You can also use a Triginometry function, but this math is much simpler and easy to add more controls to the blend.

 

DB

[iiceman]

Hmm, interesting... the blending part is like the scaling that you could do with vectors, right?

 

Well, I think I get the idea. But I am still not convinced it really works like that (would have to see it in action - sorry, I am a doubter ) With the click on the screen you could make the spaceship move up/down and left/right but always parallel to the the current screen plane. That means you will never go along the z axis to travel to something in the background.... or am I misinterpreting something here? Maybe I really just can't imagine it. I would love to try it out but still no time.

 

(Whenever I start with a "simple" playground I end up taking hours playing around with it - can't do that today )

[dbawel]

That's why you never see me on the playground, unless I'm looking at another's code.  Trust me, I have used this math for years on games, as well as theme park rides.  I even used it on the animatronics system I built for the Hobbit films.  Just put the #s into the formula - it works for a 4 axis controller and even a 10 axis controller (or greater).  As for translation on the camera z axis or any local axis other than pitch, roll, and yaw, that is a different function all together and very simple.

 

Cheers.

[Wingnut]

hehe.  I know what you are feeling, Iceman.  It "feels" like the z of the clicked point... HAS TO BE really really really far away, or else the ship and camera aiming will not be very accurate at all.  And I think you are correct, or not.  You use a .subtract to determine a direction?  Maybe that's not the only way. *shrug*

 

Pretend that the camera is directly behind the ship (looking +z), and the ship is sitting at 0,0,0 (origin).  So, the mouse targeting cross-hairs (reticule), is sitting directly over the ship's primary thruster port (in the rear, of course).

 

Now mouse into an area of space, and click.  Then programmatically turn the ship and cam until that clicked point is straight ahead of the ship/cam.

 

Did we do the correct turn?  Yep.  Did we need a huge simulated "z" factor (or ANY z-factor)?  Nope.  We just need to do an... umm... un-projection?  *scratch scratch* 

 

DB, you just keep getting cooler by the day.  Theme park rides?  Actuators? (powerful stepper motors)  (drooool).  Done some embedded controller stuff?  I imagine those theme park rides have some computer control + possible safety monitoring.  Robots!   I like the car-crushing smoke-spewing fire-belching banshee-screaming -type of robots... the kind that require 3 semi-trucks to take to the next show. 

[dbawel]

Thanks for chiming in Mr. Wingnut.  I wish I had built fire spewing rides, however, it's all simulation rides for theme parks such as Universal Studios in Singapore, and a new Batman ride coming from Warner Bros. soon (secret, as far as you know.)  I hope you got the math I was promoting - however, I could push out some Trig for those who want the less flexible math.  Not for me.