Havok Physics engine entity creation and raw pos/rot usage?

Questions
1

Hey all, I’ve been toying around with scene optimizations and trying to use the physics plugin independently from the renderer to tie in some other processing before the final render step, and I am trying to run a renderer and physics engine in separate threads to use asynchronously.

First, I can’t find how to create entities in the physics world that don’t have a render object associated, like just making invisible physics objects straight in Havok. E.g. havok.addSphere({pos,rot, radius}) etc. so I can define the physics world directly.

Secondly, or is there a way to define objects in Babylon that don’t have a render target associated that updates the shader compilation? My current hack is that but with objects set to isVisible:false which still has overhead associated. Then I could just grab the position/rotation buffers for instances after a physics pass independent of the renderer.

I would otherwise like to just access Havok’s world matrix buffers directly but I currently can’t find it without having to destructure objects like {x,y,z} for individual entities which is pointlessly inefficient. This was a main bottleneck in RapierJS too which added several milliseconds per frame for a decent number of objects. Basically I need low level control so I can add some updates inbetween the physics pass (or multiple >_>) and the render pass, and I can break it out asynchronously with web workers and buffer transfers/shared arraybuffers. If that’s possible I can show you some real benchmarks.

1 Like
2

You can feed a TransformNode to a BABYLON.PhysicsBody. And then for a sphere use BABYLON.PhysicsShapeSphere

1 Like
3

I would otherwise like to just access Havok’s world matrix buffers directly but I currently can’t find it without having to destructure objects like {x,y,z} for individual entities which is pointlessly inefficient. This was a main bottleneck in RapierJS too which added several milliseconds per frame for a decent number of objects.

Thanks for sharing this, @Joshua_Brewster. I didn’t know that destructuring could add several ms per frame. Do you know if we can avoid this bottleneck by using object.x instead of const { x } = object?

I’m unsure if this helps, though syncTransform() inside the Babylon.js source code seems like a way to get world transforms from Havok’s memory buffer.

I’ve also been looking into decoupling rendering from physics and have been using the low-level Havok functions directly (using Babylon.js’ havokPlugin.ts as a reference for how to use these functions).