Hello bullet community,
I am implementing a voxel based terrain that should be infinite. The graphics library I am using is Ogre3D. I already programmed a tile based terrain that is not infinite and used bullet for the collision handling. My bullet version is 2.76 from the repository but I can (and probably will) update to 2.77.
The terrain itself should be modifiable during runtime, so I divided the whole terrain into chunks. Each chunk stores a btBvhTriangleMeshShape that reuses the mesh data of the chunk. To handle an infinite terrain I separated the space into 3x3x3 "boxes" where the middle box will contain the player. All chunks of the terrain will be added as childs to one of those boxes, so the coordinate system of a chunk is relative to its parent "box". This way I just have to translate 27 objects (the boxes) to keep the terrain around the origin (to avoid the floating point issues at far distances).
These translations however only affect my graphical representations of the terrain. The physical representations (the Collision Shapes) still would need to be translated "manually". So if I have 200 terrain chunks, I would have to translate each chunk. (By the way: Am I even right with this?)
So my question is: Is there a way to also keep objects of bullet around the origin without the need to touch every object itself?
Greetings
BrightBit
How to avoid floating point issues for infinite terrains?
-
- Posts: 6
- Joined: Fri Dec 31, 2010 8:51 pm
-
- Posts: 6
- Joined: Fri Dec 31, 2010 8:51 pm
Re: How to avoid floating point issues for infinite terrains
Hello again,
Just in case that someone is interested in my "solution". Since all rigid bodies store or refer to world space coordinates I actually had to translate each single object. But it turned out to be fast enough. I can't notice performance issues so I will keep this solution.
Greetings
BrightBit
Just in case that someone is interested in my "solution". Since all rigid bodies store or refer to world space coordinates I actually had to translate each single object. But it turned out to be fast enough. I can't notice performance issues so I will keep this solution.
Greetings
BrightBit