Havok 6DOF Joint: Cannot apply limits to all 3 angular axes

Bugs
, , ,
1

When angular limits are applied to all 3 axes for a Havok 6DOF Joint, and the child body is pushed with an impulse, the simulation seems to blow up and all limits are broken.

Please see the Youtube video below where I show the issue. At first, angular limits are only applied to 2 axes, and the simulation abides by the limit and appears fine. After applying an angular limit to the 3rd axis, the simulation blows up and all limits are broken.

Playground: https://playground.babylonjs.com/#10X8RU#12

Thank you for your help here :slight_smile:

1 Like
2

cc @eoin

1 Like
3

If you wait for long enough with only the 2 axes, the limits are broken as well:

image
image365Ɨ561 2.42 KB

1 Like
4

@riven04 that should be okay and within the limits. I should have drawn the limits for the X-axis too

Playground with updated debug drawing: https://playground.babylonjs.com/#10X8RU#14

However, if you didnā€™t edit the direction of the impulse, itā€™s strange how the green box is rotating around the X-axis in your picture when the impulse was in the X-direction :open_mouth:

5

Thanks for the report. Thatā€™s definitely not behaving the way I expect. Looks like the problem is in our Babylon integration layer, as the same configuration behaves much better in our lower-level SDK. Looks like I have some debugging to do :slight_smile:.

2 Likes
6

Iā€™ve begun referring to the Havok Plugin, by which I mean the HavokPlugin class, and the Havok Engine, by which I mean the wasm and its lower-level typescript classes accessible through havokPlugin._hknp.

By ā€œintegration layer,ā€ are you referring to the Plugin or to the typescript in the Engine?

1 Like
7

This will be fixed in version 1.3.10 of the ā€˜@babylonjs/havokā€™ package.

In this case, the problem turned out to be in the WASM. To complicate naming-matters further, the interface exposed through the WASM is a thin layer which sits on top of the ā€œrealā€ Havok engine :slight_smile:

1 Like
8

Thank you so much, @eoin! I just tested your new version, and it works beautifully :slight_smile:

1 Like
9

Awesome. What you call ā€œintegration,ā€ I think I had included that in ā€œEngineā€. I like your terminology better.

I have been working on a set of Physics Debug visualization classes and it seems beneficial for me to indicate which layer each of those classes digs into.

Does this cover all the layers?

Plugin ā†’ HavokPhysics.d.ts ā†’ HavokPhysics_es.js ā†’ WASM

Iā€™ve been calling these:
Plugin ā†’ Engine (everything not Plugin)

I think you referred to:
Plugin ā†’ Integration ā†’ Engine?

I kind of prefer:
Plugin ā†’ Integration ā†’ Interface ā†’ Engine
What do you think?

The npm package linked below refers to that returned by HavokPhysics the ā€œinterfaceā€. I canā€™t quite tell if this is consistent with my preference.

In my preference above, Plugin and Integration are provided by Babylon while Interface and Engine are provided by Havok. My interest in defining these at all is to provide documentation for my debug visualization.

Short name (type) - access (more info)

  1. Plugin (HavokPlugin) - returned from constructor ā€œnew HavokPlugin(ā€¦)ā€ (doc) (code)
  2. Integration (plugin._hknp) - (code: HavokPhysics.d.ts)
  3. Interface (HavokPhysics) - (doc?) (code: HavokPhysics_es.js HavokPhysics_umd.js)
  4. WASM - I havenā€™t found SDK reference docs, but see below for a few interesting links.

Additional references:

1 Like
10

Well, naming things is hard and I donā€™t have all the answers :slight_smile:

Just a minor correction on your info:

Here, items 2, 3 and 4 are all the same thing - HavokPhysics.d.ts is just type definitions for the WASM - it only provides some niceties in your IDE; not any code. The JS files in item 3 are just some loading code which handles the environment and initialization of the WASM. Item 4 is the actual implementation. The underlying C++ Havok interface isnā€™t exposed - the WASM exposes only a simplified, (much) easier-to-use, thin wrapper around the C++ Havok SDK. While itā€™s intended to be quite generic, the functionality exposed is designed with Babylon in mind. Essentially, this interface is glue code between JavaScript and the C++ Havok SDK. While there isnā€™t really any ā€œuser manualā€ documentation for this layer, the HavokPhysics.d.ts does try to document the functionality.

Item 1, is how Babylon integrates with that Havok interface. It provides the glue code between the Babylon types (PhysicsBody, etc.) and the implementation in items (2,3,4).

11

Thank you for the thorough explanation. Thank you for your time in detailing what is already in the ā€œUsing Havok and the Havok Pluginā€ document.

I had thought that the havok engine itself is C++ compiled into WASM. And your explanation still makes sense. I can understand what you are saying by looking at package.json and rereading ā€œUsing Havok and the Havok Pluginā€

The first is the Havok engine itself, which is a WebAssembly module that is responsible for the actual physics calculations. The second is the Babylon Havok plugin, which is responsible for the integration of the Havok physics engine into Babylon.js.

The ā€œstackā€ is essentially:

  1. HavokPlugin which pulls everything below through constructor parameter hpInjection:HK
  2. TypeScript definitions of exposed narrow interface to HavokPhysics (HavokPhysics.d.ts, ā€œHavokPhysicsWithBindingsā€)
  3. Exposed (narrow) Interface to WASM Havok code (from HavokPhysics_es.js HavokPhysics_umd.js with name HavokPhysics)
  4. WASM Havok code

Further, Iā€™m guessing that 2, 3, and 4 are automatically derived from C++ source wrapped around the Havok SDK to the Havok Engine. And all C++ code (narrow interface, SDK, and the Havok Engine itself) is compiled into WASM.

So the ā€œintegrationā€ code you were referring to was the HavokPlugin (aka ā€œPluginā€), with this source code (dev) and the constraints issue you found was in the WASM Havok code?

1 Like