Follow a path with velocity and gravity

[d13]

Hi Everyone,

I'm trying to have a object follow a path, but how it moves along that path should be influenced by gravity and its velocity.

I've found this example, which is a start:

http://jsfiddle.net/7hxQq/1/

However, the motion along the path is tweened, rather than dynamically determined by the object's velocity and gravity.

What I'm trying to build is similar to this, but in 3D:

https://www.myphysicslab.com/roller/roller-single-en.html

I'm not quite sure how to approach this - does anyone have any suggestions?

Thanks!

[adam]

Move the object toward a point on the path.  (get the direction from object to path position, normalize it, scale it by speed, add it to the object position)

When the object is close to the point, get the next point in the path.  (use Vector3.distance or Vector3.DistanceSquared between object position and path position)

Repeat until you have reached the end.

[Wingnut]

Hi guys.  I think flight paths can be done nicely... with the 3rd party physics engines such as Oimo and Cannon.  For smooth flight paths... we want "analog"... linearity... and velocity, momentum, inertia, all that other good stuff.

Recently, I BARELY got Wingnut's Physics-Active Flying Bobsled operational (more info here).   I suggest attempting to ZIP this and take it home, because this PG, currently, cannot be RUNned twice.  It fails after a playground edit... a problem with the physics (see console).  So, ya need to save it after each edit, and do a fresh reload of the new version.  It sucks.  I really want to find out why that is happening. 

Anyway, the flying bobsled started life as this particle-system adorned flying bedframe. 

AND... the physics "thruster controllers" hooked to the master "white box"... are done poorly.  It uses applyImpulse to operate its (fake) 24 thruster ports, but it COULD be done with setLinearVelocity() and setAngularVelocity() funcs.  This would reduce code length and complexity.

The main thing is... the 24-thruster white box in the middle (full 3-axis rotation and translation, like NASA MMU's and Spartan satellites, for example).

You could make a "time-based thruster-event controller".  Just a giant list of thruster commands... to be executed per a timer/scheduler.   Notice... that in these "flyers"... the thrustings are low-powered, but accumulate.  The longer-time you hold the thrust buttons down, the more speed the craft attains.  (I use natural held-keypress-repeat to add thrust or counter-thrust). 

Using this idea, the time-length of any "thruster burn" is pertinent.  So, you might turn-on thruster 7 with an event in the event list, and leave it ON for 8 seconds, WHILE other thrusting events are being processed.  Then, 8 seconds later, you turn-OFF thruster 7 (with a thruster-OFF event).

Each thrust event in the "thruster scheduler" event list... is really an ADDING or SUBTRACTING of linearVelocity or angularVelocity... to/from the white box.  Quite an easy thing to do, programming-wise.  Each flight path (thruster event list) is a type of script... something an actor/director might follow.  It is "played" at a standardized play-speed... and can be stored as separate files. 

We must be careful here.  Changing the mass of the flown object... could make a difficult-to-code event list... not work anymore.  Possibly, this could be corrected by using a .baseRotationNewtons and .baseTranslationNewtons variables... carried with every flight-path script object.  They set the amount of force-per-frame or something like that.

We could all establish MANY flight paths, trade them, share them.  They all "run" on the same "standardized physics flight path player".  Soon we ALL will be flying thruster-controlled mesh via these thruster scripts.  Physics engines are great at "keeping it linear" yet honoring inertia/momentum and overshoot, etc, etc - cool flight things.

But, you know... physics engines can slow-down scenes to a degree.  Yet, nothing is better-at calculating those mass/velocity/inertia values FOR YOU.  I think it is worth some thought, and I would WHOLEHEARTEDLY-support a standardized universal physics-event-list "player".  Of course, programming these thruster event lists (thruster sequences?) could be SLOW SLOW SLOW, but... I think it might be THE BEST JS-based linear flight path system that we have, so far.  Later, we can "feed" the event player with REAL-TIME data, too, honoring proximity sensors on the flown object (AI collision avoidance and path-finding through the asteroid field).  Fancy. 

[Wingnut]

Hi again!  Although d13 probably lost interest weeks ago (I do that to people)... I decided to advance my demented idea, a bit.

https://www.babylonjs-playground.com/#PBVEM#148

Yay, flying bobsled!  He's on auto-pilot for this one (for 15-30 secs, or so).  Thruster script!

My very basic "script" of thrusting commands... starts at line 1469.  Right now, it is just a list of strings, but really, each object in the script... should be a navEventClassObject, eh?    They might be much smarter objects than strings (they might contain a "HOW MANY micro-thrustings?" -value.  Cool.)

Down in line 1659 area... a not-so-simple 1/3-second timer is active, "playing" the script... "marshalling" physics-impulsing on the white box at the center of the bobsled.  The actual "feeder line" is 1667.

As far as flight-path-making systems... not so bad, eh?  Reasonably smooth.  A little jerky here and there, due to the rotate and translate "power settings" in lines 86 and 89.  It took me about a half-hour to make this simple flight path script.

Again, if we "standardize" the script-playing engine, then we can share flight path scripts with each other, adding unnecessary bloat to each others' projects!  Alright! 

(I can hear @Pryme8 thinking... "Why can't they just use interpolators for flying cams/mesh/lights on flight paths, for cryin' out loud?"  heh)  (too hard for the math-less.)  @jerome's rollercoaster is sort of mathy, though.  He "derived" his curves with math, a section here, a section there, then connected them together pretty well.  There's one sort-of sharp turn, though.    

Physics paths are still nicer, and they are the basis of automated cargo ship docking... to spaceports.  The white box could be shooting rays all over the place during the auto-docking, doing thruster decision making... aligning, aligning, aligning... docked.    Failed docked?  Bounce-off, cuz... we got restitution.  AI micro-thrusting... so cooooool.

[Pryme8]

ohh man that 2d example is lots of fun with the graphs and everything wow I like this.

If you scroll down the page it breaks the whole thing down... which if you don't understand any of it don't be ashamed just try to figure it out.  Its a lot simpler then it sounds though once you get into it I was scanning through it and the principle seems like you just calculate the angle of gravity in relation to the curve and apply its force.

If you end up not being able to figure it out, Ill put together a playground (if I have the time) that demonstrates the principle.

[d13]

I did manage to get a working 2d version of what I'm looking for!

https://jsbin.com/fuvomoz/1/edit?js,output

the SVG spec has a nice function for getting the points along a curve: `getPointAtLength`

I guess the first thing I would need to do is come up with a 3D version of that function?

 

[JohnK]

2 hours ago, d13 said:

I guess the first thing I would need to do is come up with a 3D version of that function?

 

These may prove useful

http://doc.babylonjs.com/tutorials/how_to_use_path3d

http://doc.babylonjs.com/tutorials/how_to_use_curve3