Jitter / Tremble of Parent Mesh Camera

[Phuein]

Whether Camera is the parent of a Mesh (in example below), or the other way around (in my personal project), when moving "fast" at speed = 1000, eventually there is some (discrepancy) jitter visible on the mesh - although it's probably the camera that isn't set correctly (some matrix?)

http://www.babylonjs-playground.com/#P1YTR#1

Just click, rotate some, then hold Up and Left arrows and wait til the jitters come, at a few seconds in. Just an example of keys used. Even after stopping, if you try to move a bit or look-around, the jitter is already there.

A painful bug for my space sim, where I need to move sonic faaaaast! 

[Guest]

The jitters come from the number precision of Javascript. We are dealing with LARGE numbers in this case and the Float32Array used internally can't handle them precisely.

In this specific case the best option is to keep the camera unchanged and instead move the world (add a root node and move it): this way the local space keeps reasonable values

[Phuein]

I'm not sure I'm following your suggestion. Can you provide a PG example?

My instinct tells me that moving the world makes no sense. For tracking the player. For other players in the scene. For me trying to make sense of interactions.

I saw another post talking about the big numbers, so I'm glad to hear you corroborating it.

 

EDIT: Focusing on the numbers issue, I can see THREE.js solves this by calling on a logdepthbuffer from webgl:

var renderer = new THREE.WebGLRenderer({ antialias: true, logarithmicDepthBuffer: true });

Can BJS do this? I tried searching, but only found references to materials; not the renderer. I get the suspicion that this is doable.

Further clarification, they have a cool example: https://threejs.org/examples/#webgl_camera_logarithmicdepthbuffer

Isn't there some way I could just hrmmm round-up my numbers or something? Assure some kind of precision? I tried messing with Math(), but to no avail.

[Guest]

Yes this is supported: http://doc.babylonjs.com/how_to/using_logarithmic_depth_buffer

You need to turn that feature on per material as they are responsible for the shaders.

Demo: https://www.babylonjs-playground.com/#1180R5#16

But not sure if this is a good idea still. All the space games that I know of are all using the trick I proposed.

[Phuein]

Ah, they're both shaky as heck for me.  (1mb vid attached... should I have linked to an imgur gif instead?)

 

So, let's see if I got this straight. The issue is numbers with too many (over float32) digits ("124512541.2512412"), which is - in this case - an issue with being "very far away" from the mesh's parent position (axis.) So, if I use parents for different "areas", I can keep movement cut into zones, which keep the numbers low? i.e. rookie numbers.

Is that right?

I'm still not sure how I would move my mesh these distances this way. I'd need... err... a matrix of parents, each reducing the distance from axis? So, first set of parents divides by say 10. Then each has 10 parent-children, dividing further by 10. And so on, until my mesh is attached to its parent where the distances are acceptable.

So, for a distance of a trillion units ("meters") it's...

10 ^ 12... Meaning dividing every space section into 10 subspace section, 12 times. Hrm.

 

Goes deeper into the mathematical darkness of Javascript... https://developers.google.com/web/updates/2018/05/bigint

Learning of numeric evils.... http://greweb.me/2013/01/be-careful-with-js-numbers/

 

More specifically, I'm seeing THREE do this:

#define USE_LOGDEPTHBUF

But they do it for the renderer, optionally - set option in Render() object creation. Would that be at all achievable with BJS?

 

[Guest]

the logdepth thingy of three.js is identical to our logarithmic depth buffer

1 hour ago, Phuein said:

So, let's see if I got this straight. The issue is numbers with too many (over float32) digits ("124512541.2512412"), which is - in this case - an issue with being "very far away" from the mesh's parent position (axis.) So, if I use parents for different "areas", I can keep movement cut into zones, which keep the numbers low? i.e. rookie numbers.

This is correct.

I know this is not easy and that's why I keep thinking that moving the world would be an easier one

[Phuein]

What exactly do you mean by moving the world? I thought you meant just a parent.

Has an idea about parenting and unparenting consecutively, to a new empty mesh in location, whenever local distance goes over a certain number; instead of dividing space ahead of time.

[Guest]

I mean having everything but the camera attached to a parent node and move that parent node instead of moving the camera

[Phuein]

That's the most bizarre hack. Literally moving the entire world. No way I'm doing that.

When I implement the parenting system I got in mind, if it works, I'll post it here and mark solved.  So others can replicate the code.

[Guest]

You decide  Keep us posted!

[Guest]

Here is an excellent thread to explain the issue:

And a blog post by the kerbal space team explaining how they solve it (by moving the world and keeping the camera at origin):

http://kerbalspace.tumblr.com/post/16291223741/the-story-of-ksp-ksp-02

 

 

[Phuein]

Wow, that's a cool visualization in that gif! ?