I am working on an LOD terrain with collisions using the new Havok engine.
The LOD is performed using quadtrees so the terrain is just a bunch of meshes attached to a common transformNode by parenting.
To make the collisions work, I see two path that I could take:
This one is nice because I can create a container shape on the parent transformNode, and then I add the shapes of the terrain chunks to the container. It was all nice and good until I had to remove some chunks (when zooming on a chunk, it is removed and replaced by 4 smaller ones to give finer details).
The documentation mentions the removeChild method, but it takes an index. The issue I see is that when I remove the shape of index 2, then the shape of index 3 will have its index changed to 2 to align the array in wasm memory (i don’t if that makes sense). Therefore I can’t easily keep track of each shape’s index in the array. It would require a complicated system to update the indices everytime a chunk is deleted.
2 - Use one physics aggregate for each chunk
If I can’t use the container, maybe I can create a physics aggregate for each chunk, as I can delete them easily. But then I wouldn’t really know how to replicate the parenting that the container enforced out of the box.
I probably missed something about the way physics body work in Havok, but I haven’t made any progress so far :') Is there a way to use the container in an easier way, or must I use different aggregates?
But then I wouldn’t really know how to replicate the parenting that the container enforced out of the box.
Just so I can understand the situation better, what do you mean by the container enforcing the parenting? Is it just the fact that the body has a parent node?
My understanding is that container aggregates will behave like the parenting system of BabylonJS, whereas the separate aggregates will ignore any parenting that I set in babylonjs because havok will treat them as separated. So by enforcing parenting, I should rather say “respect parenting”.
Basically the right sphere has the left sphere for parent. The left sphere is applied an impulsion and yet the right sphere is not influenced by it, hence not respecting babylonjs’s parenting.
Ah, I see what you mean That is correct, if you have two assets that are parents only on the Babylon hierarchy, but not in Havok, they won’t have forces applied to them both when it’s applied to one. But if it’s just this effect you want, you could also achieve it with constraints, would that work? Aggregate parenting | Babylon.js Playground (babylonjs.com)
It comes with a strange side effect: the balls seem to be clumped together at startup and then they take their expected locked positions afterward. I think the issue is that I don’t understand the arguments of the constructor of the FixedConstraint though, why do we need 4 Vector3s? Wouldn’t a relative translation be enough?
Oh, these are default parameters for constraints, they represent the pivot and axis of each body in the constraint. You can read about them here: Constraints | Babylon.js Documentation (babylonjs.com), but trying to explain here, the pivot is the position of the constraint on each body’s local space, while the axis is, well, the main axis of rotation of the constraint, also in local space. The rotation doesn’t make much difference in the locked/fixed constraint, but we do need the positions to know where to place the constraints relative to the bodies.
Thank you for the explanation! I was able to correct the playground to make the fixed constraint work (https://playground.babylonjs.com/#Z8HTUN#770). Still, I am curious to see how well this method will scale on large terrains!
That is correct, if you have two assets that are parents only on the Babylon hierarchy, but not in Havok, they won’t have forces applied to them both when it’s applied to one. But if it’s just this effect you want, you could also achieve it with constraints, would that work?