I was hoping to reuse the same Havok constraint for many instances (not thin instances – regular instances) of something in my scene but I ran across an unexpected thing. When you dispose a constraint that’s used in multiple places, it seems to only truly dispose from the last place you apply it. I’m guessing there’s something internally that makes sharing constraints not a good idea, but I just wanted to ask.
In the havok tutorial pages about constraints there’s a playground showing all the constraint types. I modified that playground to make a 2nd hinge setup below the first. I create one hinge constraint and use it for both hinges. After 2 seconds, I call dispose() on the hinge constraint, but you can see it only detaches from the 2nd hinge joint. I expected it to detach from both hinges. Here is the modified playground: https://playground.babylonjs.com/#7DMWP8#5
Any info/feedback welcome
agg3.body.addConstraint creates a new WASM constraint in the Havok engine and assigns its
id to the constraint passed in, which writes over the
id previously assigned to the constraint in
agg1.body.addConstraint. Since the constraint’s
id only tracks one internal WASM constraint, the call to
dispose only releases the most recent WASM constraint assigned to it.
@Cedric may have more to say on this, but for now I would not share constraints this way. They are only thin wrappers over the internal WASM constraints anyway, so I don’t think sharing them will save you much overhead.
Remove from the physical plug with the value of HingeConstraint._pluginData
In the same sense, disposing the body leads to the same action.
if this is intended.
a joint is a connecting body, so if you use the same joint, multiple _pluginData values must be processed in the same array.
that means each joint must be push to array and used to control.
as docEdub said This is difficult to do as it is handled within the WASM constraints of the Havok engine.
Thanks for the info.
One less thing to worry about!
As @docEdub said, do not share constraint because of Id overwrite. If, in the future, we have a use case where constraints are a memory bottleneck, we will add new API functionality.