Havok: motorized constraints

Hi all,

I am very excited at the idea of using the Havok engine in my video game where my performance bottleneck is precisely related to Ammo.

I did not find any information on the motorization of physical constraints. I would need to induce velocity on a hinge-like and slider-like constraint as is possible in Ammo and Canon.

Is it possible? Is there an example or related documentation?

Thanks in advance.

Probably that PhysicsConstraint.setAxisMotorTarget() does the job. I will test this asap and keep you updated.

1 Like

Motorized constraint is not well documented. If you can provide a good sample playground, I’d be happy to add it to the documentation.

First of all, it seems that the API is only open for 6DOF constraints, which makes using motors difficult from the very beginning. Indeed, I would have expected to be able to simply do a setTargetVelocity() , setTargetPosition() or setForce() on simpler constraints such as a HingeJoint or a PrismaticJoint.

  • Is there a way to call native Havok functions to try this?
  • Is there an online API for Havok?

I’ve done a few tries starting with the main Havok example and the constraints example, but I can’t get the second solid to move using the motor related functions.

Here is my result on a 6DOF joint which looks like a distance constraint:

I wonder if anyone has a starting point that would allow me to start with this topic?

Indeed, I can’t get it to work with 6DOF or other constraints when using directly the plugin. Is there something we are missing here @eoin?

1 Like

We’ve got a bug in HavokPlugin.setAxisMotorType() - we’re passing the motor type straight into the WASM; it needs to be converted to the “native” type, like we do for the axis ID.

I was able to workaround it in the playground by passing in the native type directly. Here’s a playground that I based on the above which shows how. I also modified the joint and shapes to make it a bit easier to see the effect of the motor. I’d definitely like to add some more interfaces to the simple joint types. As it is, they use the 6DOF interface under the hood, but in a limited way, to make them easier to setup.


Thank you very much for taking my issue into consideration.
I can now progress a lot with your workaround.

I worked several years in robotic simulations and I recommend you to open APIs to control prismatic and hinge constraints, in force, velocity and position modes. This covers 95% of the robotic cases. PID control would also be sugar.

If at some point I have a good sample to share, I will post it there.

I’ve open an issue to keep track [Physics] setAxisMotor native parameters · Issue #13801 · BabylonJS/Babylon.js · GitHub

1 Like

Fwiw i saw ms iot os using babylon in the vscode plugin and also made a collada loader. Not associated with it in any way, just saw it on github. GitHub - ms-iot/vscode-ros: Visual Studio Code extension for Robot Operating System (ROS) development

.babylon_ros/Joint.ts at main · polyhobbyist/babylon_ros · GitHub

Hopefully a good reference for cedric and havok friends

I progress a lot with linear and angular constraints in my project, and it’s working like a charm (even if 6DOF anchors and axes are a nightmare to setup).
Linear and rotational control in velocity and position seems to work well too.

I have now another issue: is there a way to retrieve the actual angle or position of a constraint? I need this feeedback to implement PID control.

Physics6DoFConstraint.getAxisMotorTarget() allow to get the last command, but not the actual position or angle feedback.

@eoin I probably have to call some Havok API directly?

Thank you in advance.

If you keep track of bodies using that constraint I guess you can get the angle using a simple dot product of one of their axis?

Yes, this is what I’m doing now, so I’m not blocked with this.

But I expect that the physics engine has this data internally. So recomputing it is not efficient, and not so obvious. For example, a motor controlled in position can do several turns and can have values above 2*Pi. There are also issues with signs, etc. This is not simply a crossproduct.

Every physics engine I worked with have an access to this value, for example AMMO:

We don’t actually store those values in the engine (except in some special cases), so calculating it is definitely the way to go. I agree we should put in methods in the joints to calculate these so you don’t have to write that code.

As an aside, Ammo seems to sometimes calculate it, and sometimes use a stored value:

I don’t know anything about the Ammo implementation, but my gut feeling is that using a stored value is likely to give slightly incorrect results. I guess that slider’s stored value is set inside the solver; in a PGS solver, other constraints are able to modify the bodies after that value would have been computed, so it can be slightly wrong. It also probably doesn’t account for modifications to the body transforms after the solving has completed. Could be wrong on either of these, obviously, but just looked like something I’d be concerned about.

Also I see you said the 6DoF constraint was difficult to use. I spotted a bug last week where the ‘perpAxis’ parameter was ignored, which might have been the cause of that? (Fix bug where constraint perp axes were ignored by eoineoineoin · Pull Request #13859 · BabylonJS/Babylon.js · GitHub) If so, I’m real, real, REAL sorry. Very embarassing bug :pensive:. If you had any ideas for how we could improve the documentation here, I’d love to incorporate them. All those constraint setup parameters feel quite natural to me, but I’ve been doing this fo a long time :wink:

Thank you very much for your answer.
I have to digest it, and I will come back later with this.
The bug you solved with the perpAxis may explain lot of my issues. Currently, I think there are bugs with 6DOFConstraints, when there are more than 4 DOF that are locked. I bet that it’s precisely linked with perpAxis…

OMG, I confirm that the perpAxis bug was causing lot of issues in my project. Upgrading @babylonjs/core and using perpAxis properly allow me to do what I want with 6DOF constraints.