Phuein Posted September 17, 2018 Share Posted September 17, 2018 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! Quote Link to comment Share on other sites More sharing options...
Guest Posted September 17, 2018 Share Posted September 17, 2018 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 Quote Link to comment Share on other sites More sharing options...
Phuein Posted September 18, 2018 Author Share Posted September 18, 2018 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. Quote Link to comment Share on other sites More sharing options...
Guest Posted September 18, 2018 Share Posted September 18, 2018 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. Quote Link to comment Share on other sites More sharing options...
Phuein Posted September 19, 2018 Author Share Posted September 19, 2018 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? 2018-09-19_12-19-09.mp4 Quote Link to comment Share on other sites More sharing options...
Guest Posted September 19, 2018 Share Posted September 19, 2018 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 Quote Link to comment Share on other sites More sharing options...
Phuein Posted September 20, 2018 Author Share Posted September 20, 2018 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. Quote Link to comment Share on other sites More sharing options...
Guest Posted September 20, 2018 Share Posted September 20, 2018 I mean having everything but the camera attached to a parent node and move that parent node instead of moving the camera adam 1 Quote Link to comment Share on other sites More sharing options...
Phuein Posted September 22, 2018 Author Share Posted September 22, 2018 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. Quote Link to comment Share on other sites More sharing options...
Guest Posted September 24, 2018 Share Posted September 24, 2018 You decide Keep us posted! Quote Link to comment Share on other sites More sharing options...
Guest Posted September 26, 2018 Share Posted September 26, 2018 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 1 Quote Link to comment Share on other sites More sharing options...
Phuein Posted September 26, 2018 Author Share Posted September 26, 2018 Wow, that's a cool visualization in that gif! ? Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.