The resulting objects were inserted into the general broadphase structure along with other objects in the world. Thus, the prototype took each chunk, ran mesher on the chunk to generate a triangle mesh from it, and then created a Bullet collision object using btBvhTriangleMeshShape. Since our voxels are pretty big, we wanted rendering and physics representation to match closely to eliminate visual artifacts, so we decided to use the polygonal representation for collision. While we could try to do collision directly using the underlying voxel representation, the meshing algorithm we use is complex and makes it hard to accurately predict where the surface will be without running the algorithm. We settled on 8^3 chunks (as a reminder, a character is slightly taller than 1 voxel, which should give you a sense of scale) as a balance between these factors. We currently assume that incremental updates are too complex to implement as voxel changes can lead to changes in topology of the resulting mesh) and chunk overhead (if a chunk is 2^3 voxels, then we’d need to spend a lot of time/memory managing chunks).
VOXEL TYCOON INTERSECTION UPDATE
Since terrain can be changed at any time, the chunk size is a balance between update cost (if a chunk is too big, then every time we update a voxel in that chunk we’d have to pay a high cost of updating the entire chunk.
Similarly to voxel storage, we divide the entire world into chunks and represent each chunk as a collision object this division is crucial because each chunk becomes the unit of update of physics data. We care about performance and memory consumption, as the assumption is that some worlds will be heavily relying on terrain and terrain physics.Īlthough our physics engine is custom, we use some components of Bullet Physics for broadphase/narrowphase (specifically for complex convex objects and convex decomposition, relying on Bullet’s GJK implementation and some other algorithms), so it made sense to start by prototyping the solution that would rely heavily on Bullet.
For terrain in particular, having physics support meant implementing collision detection between terrain and all the other shapes we use, as well as supporting raycasts efficiently. Initial prototype Physics support is crucial for terrain since so much of the content on Roblox relies on having robust physics behavior, both in-game and in-editor. While logically speaking it would make sense to look at mesher next (which is how we call the component that is capable of taking a box of voxel data and producing triangle data representing the terrain surface with material attributes), since it is used by both physics and rendering systems, the algorithm is pretty involved and has quite a bit of “magic,” so we will leave that for some other time and instead look at physics today. The implementation for each system (rendering, networking, physics) is completely separate and isn’t dependent on any decisions that storage or other systems are making, so we can study them independently. From there, a lot of other systems read and write data from the storage and interpret it in different ways. In my previous article we discussed the particulars of voxel data definition and storage for voxel terrain on Roblox.
0 kommentar(er)
