Hi, no idea, and where at this time but try by forcing the use of double instead of single 2 000 000 is huge i think the problem is the precisionin the calculs. A round up it's surely the cause..
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Jerome!
Thansk for the response.
Sounds like an idea! But I don't understand how to do that?
Can you explain more?
Yes, 2 000 000 is extreme. But the twitchy camera movement starts alot earlier, just not so noticable.
Thanks!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Here's an example video, using the OctTree demo.
Notice that when I move everything in the scene 2 000 000 in the X direction, the mouse precision gets bad. Add 2 000 000 more, and the precision is non existent. No appearant fps drop.
It must be related to my shaky-camera problem! https://www.youtube.com/watch?v=fWZuRZ4j60Q
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi sorry for later Answer.
I've the same bug with Lazarus.
No idea at this time but i suppect a Matrix funcs in GLVectorgeometry. Or in GLScene.Pas with TGLCamera Object something seems provide from it (Frustrum, rotation computing ?)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It seems like you were correct regarding the precision calculations.
I've solved it by dividing my world into grids, and keeping the world as close to 0,0,0 as possible. But it's not optimal and adds alot of extra (troublesome) calculations to move all objects and effects each time player reaches the grid borders...
You mentioned "forcing the use of doube". How can we do this?
It will only push the problem further out though...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi, Daniel perhaps a clue try to change the MaxDeltaTime and / or MinDeltaTime from your TGLCadencer
MaxDeltaTime :Maximum value for deltaTime in progression events.
If null or negative, no max deltaTime is defined, otherwise, whenever an event whose actual deltaTime would be superior to MaxDeltaTime occurs, deltaTime is clamped to this max, and the extra time is hidden by the cadencer (it isn't visible in CurrentTime either).
This option allows to limit progression rate in simulations where high values would result in errors/random behaviour.
MinDeltaTime : Minimum value for deltaTime in progression events.
If superior to zero, this value specifies the minimum time step between two progression events.
This option allows to limit progression rate in simulations where low values would result in errors/random behaviour.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi!
I discovered a problem that when I move a camera far out in the scene, the movement gets shaky.
And it increase the further from pos 0,0,0 I get.
Take for example the demo /meshes/Ducky
Move both the DummyCube and the actor to position.X := 2000000.
You'll notice how the movement gets shaky.
How can I prevent this?
Kind regards and thanks in advance,
Daniel
Hi, no idea, and where at this time but try by forcing the use of double instead of single 2 000 000 is huge i think the problem is the precisionin the calculs. A round up it's surely the cause..
Hi Jerome!
Thansk for the response.
Sounds like an idea! But I don't understand how to do that?
Can you explain more?
Yes, 2 000 000 is extreme. But the twitchy camera movement starts alot earlier, just not so noticable.
Thanks!
Here's an example video, using the OctTree demo.
Notice that when I move everything in the scene 2 000 000 in the X direction, the mouse precision gets bad. Add 2 000 000 more, and the precision is non existent. No appearant fps drop.
It must be related to my shaky-camera problem!
https://www.youtube.com/watch?v=fWZuRZ4j60Q
Hi sorry for later Answer.
I've the same bug with Lazarus.
No idea at this time but i suppect a Matrix funcs in GLVectorgeometry. Or in GLScene.Pas with TGLCamera Object something seems provide from it (Frustrum, rotation computing ?)
It seems like you were correct regarding the precision calculations.
I've solved it by dividing my world into grids, and keeping the world as close to 0,0,0 as possible. But it's not optimal and adds alot of extra (troublesome) calculations to move all objects and effects each time player reaches the grid borders...
You mentioned "forcing the use of doube". How can we do this?
It will only push the problem further out though...
Hi, Daniel perhaps a clue try to change the MaxDeltaTime and / or MinDeltaTime from your TGLCadencer