Hoping to Use Babylon.js instead of Three.js because of joints. Couple of questions

[Adam_Marciniak]

I’ve got a model of a car and its suspension linkages. I want to animate all of the linkages in realtime. Before, I was using three.js as shown on my website:
http://adam.teaches.engineering
If you press play you can see the front suspension move.
This isn’t too difficult for the front suspension as it’s just a four bar linkage. My problem is the rear suspension. It’s more complicated.

So I’m hoping I can use Babylon and it’s joints feature to simulate linkage positions and rotations for me.

The way I’ll be inputting angle data is I’d like to specify the angle of a certain linkage and have the linkages connected to that one through joints update their positions appropriately. Is that possible? Or does this only work if I provide an impulse? Can I directly provide a position for a linkage without caring about mass or any dynamic simulation features? I just want to have babylon figure out the positions and rotations of the other linkages based on an input rotation.

[Wingnut]

(duck and cover! Long post ahead!)

Hi Adam, welcome to the BJS forum… good to have you with us. What an amazing pile of questions you have presented us. We have had discussions here before… you know… "WHEN should something we brute-math-animated, and WHEN is it better to let a third-party physics engine do the animation based-upon real-life environment forces.

End objective is everything. Want to drive your car across a heightMap of hills, and have it act real-life correctly? Then physics engine all the way.

OR, do you want to keep the car on-the-blocks and just wiggle the suspension linkage using some simple math? Can do, and it will look fine, but it will never cross the heightMap looking “real”.

A quick note. BabylonJS has no fancier “joints” than any other webGL framework. For physics engines, we have joints, and springs, and motors. For pure home-grown math and boundingBoxes… we have parenting, centers, dimensions, pivotPoints… and manually-commanded springs and motors… much less automated than a physics engine would provide.

It sounds/looks to me like you will be making lots of minor edits/tweaks to your suspensions. You haven’t really mentioned springs and shocks (dampers)… but I think you will be wanting those, eventually, too.

Here’s what others MIGHT do…for a suspension edit/mod. Remove all physics impostors (mesh ghosts), motors, springs, dampers… ALL the physics stuff that WAS on there, then re-“grow” the linkages and adjust pivotPoints and parentings. Some of the models could be up-scaled or down-scaled, but mainly, re-“derive” the config of the NEW suspension… ALL based-upon the change that was made.

AFTER it has been re-assembled with the new “span” somewhere, re-physics it again… adding all the impostors, frictions, masses, joints, springs, dampers, everything… so not only does it LOOK correct… it also acts correctly when on the track or in the hills.

As you may notice, I didn’t say ANY of this is “automated”. You will be perfoming many sequences of actions during an edit. You must follow a procedure… and a rather lengthy one… during that de-install of all physics, rebuild mesh per modification, and re-install all physics. Not automated at all… until you code-up the functions that do the automation.

By using this method… the car is always ready for the blocks or for the track. You can impulse if you like… watch the suspension bounce and flex… PER ACTUAL algorithms derived from REAL metal springs. Your shocks/dampers/brakes will be fluid, and take-into-complete-consideration… momentum/inertia, traction, center of gravity, mass… ALL of which you would have to do MANUALLY… by writing formulas… if it weren’t for the help of the physics engine.

So, do you want to stay on-the-blocks and off the track… animating linkages that move other linkages and pivots because of parenting (kind of yawn-ful). Or do you want to keep your car… ready for the test track and hill-climbs (exciting and nice realistic accidents/failures)?

Avoid the physics engine, and you remove substantial realism levels… but get back SOME ease of suspension edits (still plenty challenging with boundingbox measurings and moving pivotPoints and rotations). When you “accept” using the physics engine (we honor some Oimo, Cannon, and Ammo partially at easy-level, FULLY at native level), you get BIG returns and quite a few more headaches at the same time.

Sorry if this is bad news. I don’t think BabylonJS has any “joints” that threeJS doesn’t have. They use the same physics engines as we do, I suspect. I think both systems will have the same general procedure… place all the linkages/items in proper worldSpace… and then loosely assemble using set pivots and parenting, OR… populate the mesh with meshImpostors, joints, and springs… each which already know how to BE rigidBodies, joints, and springs (they have the formulas for those things… built-into them, by others).

@Adam_Marciniak

it’s joints feature to simulate linkage positions and rotations for me.

Again, our joints feature comes from 3rd party physics engines (except for parenting/setPivotPoint and similar)… which threeJS allows. And it is likely that ThreeJS does ITS joints… just like BabylonJS does them. Without using a physics engine add-on (easily included in a BabyonJS scene, but not authored by BJS folk), there will be very little done “for me”. A physics engine is designed to do LOTS of “for me” IF you connect its pieces together properly, and give it some needed values… like friction, mass, spring-stiffness/damping, parts-lengths, bounce-amount, etc.

Have I been any help? Sorry if this is bad news. The reason car/plane accident re-construction simulators are SO expensive? THIS stuff.

Let’s hope others reply, too, because… I’m not sure I did a very good job.

[Deltakosh]

pinging @Cedric

[Adam_Marciniak]

Hi Wingnut!

Wow thank you for the lengthy response! There’s a lot of info here for me to digest.
I agree it would be WAY more awesome to actually model the springs, dampers, and masses of all the parts and have the car be able to drive over fake mesh terrain and see how it responds. That is okay though because this 3d car model isn’t going to be moving in some boring calculated way. I’ve got sensors on the actual real life car that will be measuring suspension position in realtime and sending that data over to all the clients of the website. So the 3d model will actually react like the real car does live on the track. Also, I am just a newbie in JS and having to deal with the added complexity of masses, springs and dampers may curb my learning from “learning how to use JS properly” to “learning vehicle dynamics” which I admit is a super cool topic.

I’ve done some searching and yeah it looks like three.js can use physics libraries as well. Although I’m still not clear on how I’d implement my idea?

Let’s say I want to have a four bar linkage. I want to import the models from solidworks and then in the model environment (babylon or three) I’d define how each link is connected to each other one and which axis they can rotate about. Then I’d like to programatically set the angle of one linkage directly and the rest of the linkages should move accordingly without me having to think of the equations because they all know which degrees of freedom they have and which link they are connected to. Is that possible?

[Cedric]

Hi @Adam_Marciniak

If you want to run a physics simulation, you can create 2 physics Hinge joints (between cast body A and wheel body B)

This will compute the position of the wheel. But you’ll have to orient the linkage yourself (I mean computing the orientation between A and B and set the mesh orientation according)

Or with 2 more joints you won’t have to compute the arms orientations yourself. But you might get more difficulties tweaking the joints.

And, of course, you will have more physics bodies to create (2 arms, chassis and wheel)

Also, you’ll may have to create a vertical spring for the wheel, connected to the chassis because I’m not sure you can have spring forces with juste hinge joints.

[Cedric]

I think it’s possible to set a physics model, push the wheel with impulse and have all the linkage to move properly.

If you want to use that model on a terrain with springs, then it will become more complex but that’s possible too.

[Adam_Marciniak]

Is it possible to not have to use an impulse? I’d like to just set the position of the linkage and have the other links follow?

[Cedric]

I don’t think it’s possible as physics bodies use forces.
But maybe you don’t need physics at all. It seems like you only need to compute arms orientation from the chassis and the wheel position. If that’s all you need it can be done quite easily but you’ll have to compute the constraints yourself and you won’t be able to use a physics solver.

I can find time tomorrow to do a quick prototype without a physics solver if you want.

[Adam_Marciniak]

Yeah SolidWorks does something like that with its motion analysis package. It’s got options to not analyze mass or springs or inertia and just have direct position to position solving.

[Adam_Marciniak]

Found a great looking inverse kinematics library that I believe will do the trick:

https://lo-th.github.io/fullik/#3D_demo_13

[Adam_Marciniak]

hey Cedric! Any chance you got close to a solution to this?

[Cedric]

Sorry, I totally forgot
But, I promise you to do the PG next monday!

[Adam_Marciniak]

So just to me clear of what I’m trying to accomplish:
I’ve made this physics simulation with the linkages I’ll be using here:
Babylon-Test

You can press the up and down buttons at the bottom to apply an impulse to the large link. The problem is, is that I don’t want to be inputing an impulse and seeing it move because I’ll be getting data for the direct angle of the short arms from a real live rig. So I need a solution where I can get this thing to move like it does but using an input angle of the short links and not an impulse.

This seems like a problem that doesn’t need to worry about forces and masses at all but just positions, velocities and accelerations based on constraints. So far, I’ve found some inverse kinematics libraries but usually they show links being attached in a sort of chain one after the other rather than the layout I have here where a link has more than one joint. Does that make sense?

[Adam_Marciniak]

So I’ve found a JS library called Fullik which does inverse kinematics. It seems like what I’m looking for although the documentation is barren.

This is sort of what I’d lay it out like. Where bones 1,2,3 are all locked to eachother at a specific angle. Bone 4 would rotate up and down to move the whole assembly.

This is of course in 3d space laid out like the example I posted above.

[Cedric]

Hi @Adam_Marciniak

Here is my attempt:

https://www.babylonjs-playground.com/#487FSE#1

so, you have 2 arms, linked with a 3rd one that you can move. This is forward kinematic, not inverse.
And there is only one iteration!
In this case for example :

The middle arm should be pushed in the direction of the arrow. Then the lower one should be reoriented, middle arm repositioned and so on.
Wih multiple small iterations, the system should converge to a valid solution.

[Adam_Marciniak]

Woah this is awesome Cedric!
As I understand it the heart of this is the lookAt method which causes each link to orient itself towards another one that is moving?

[Cedric]

yes, identify moving and fixed part. then orient arms from fixed to moving end. and iterate until you have a solution that converged.

[Adam_Marciniak]

So when does the iteration happen? Right now it seems like it’s just doing lookAt when the part is dragged but it’s only doing it once. Why do there need to be multiple iterations if lookAt just puts orients the arm in the right place?

[Cedric]

Just like with IK, when you have more than 2 segments where you can find a analytic solution, you need iterations to approximate the result.
So, for example, in my sample image, you see the red arrow. once you moved the ‘box02’ you have to orient one arm, but then, you have to move again box02 because the length doesn’t match. and because you moved box01, you have to move the first arm. back to square one. and by doing multiple iteration, you’ll see the solution gets closer to the end result.

[Adam_Marciniak]

So where would you do these multiple iterations? In scene.registerAfterRender ?

Also, for an example such as this the math seems pretty straight forward when rotating box2 as it’s just using asin which is easy to figure out.

But for my example above with the three linkages and rotation in multiple planes, how do I figure those out? I was hoping I could find a solution which lets me attach joints together and have it just solve for the angles and positions without having to write the math for that one particular problem.