everything is playing nice, physics, particles, models. it worked well enough since there is a separate ecs tracking all objects and i was already transposing the entity position to the babylon nodes. now its just an extra step to subtract the floating origin. particles have a custom update loop, same deal, subtract the origin.
anyway…
trails segments get their position from the generator transform but the transform is in the modified subtracted position. so while trails float around the camera you can never get closer to them
I’m not sure where to insert myself to be able to run a floating origin calculation on the trail segments. Does anyone have any ideas??
Something that can work is only move everything back to the origin when going far away enough instead of everyframe (like when the camera is 1km away from the origin)
When that happens you call the TrailMesh.reset() function to avoid translation artefact.
I don’t know a solution for true floating origin where everything is translated every frame. I am curious how you handle physics in such context because Havok caused much havoc on my side when I tried that
I do the fully-relative motion in Unity, built-in rendering pipeline, which probably still uses PhysX. The world moves under and around the player and I let Unity physics to its own thing and it works. I’d like to learn about what issues you had with havoc and why it fails.
One of the issues is Wasm specific: translating everything every frame requires sending a lot of data across the JS/Wasm boundary (disablePreStep=false), and it is not fast to say the least.
Here is a discussion about that from a while ago:
You can also have issues when not using a fixed physics framerate, creating jittering.
Translating everything back to the origin for rendering only is not easy to accomplish as discussed here:
None of this is unfixable, but I didn’t take yet the time to make all of that in a single demo haha
