Jump to content

Jitter / Tremble of Parent Mesh Camera


Recommended Posts

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! :P

Link to post
Share on other sites

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

Link to post
Share on other sites

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. :P

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.

Link to post
Share on other sites

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.

Link to post
Share on other sites

Ah, they're both shaky as heck for me. :D (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?

 

Link to post
Share on other sites

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

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...