Okey, So i have made a chunk based mesh with diffrent amount of vertices.
All of these meshes are made inside a quadtree,(Maybe octree), which has about 4 levels of depth.
I've managed to set the locations of my ingame objects to switch node automatically and make it be able to collide.
Since the meshes are dynamic, i cant really create a big mesh to handle all the collision and dynamically change it, I wonder if it would be better to integrate BEPU to my own quadtree class and make it the object handler/islandhandler/Collision filterer or what its called.
Or could it be possible to make the giant mesh somehow, Cause i dont know how i can change the mesh at the same time as keeping it into a single one.
If i've seen right, you list all the vertices in some kind of octree system to filter out the right triangles on collision?
And that would be hard to recontruct if i am right.
Could there be an easier way to create a seperate class which could combile octrees within an quadtree, to handle sectionized meshes?
Large recontructable meshes.
Re: Large recontructable meshes.
They are indeed stored within a bounding volume hierarchy and reconstructing it would be expensive.If i've seen right, you list all the vertices in some kind of octree system to filter out the right triangles on collision?
And that would be hard to recontruct if i am right.
I don't feel comfortable suggesting something without understanding the context a bit better. Some of the options here are very work intensive and I wouldn't want you trying one of those approaches when something much simpler would have worked.I wonder if it would be better to integrate BEPU to my own quadtree class and make it the object handler/islandhandler/Collision filterer or what its called.
Or could it be possible to make the giant mesh somehow, Cause i dont know how i can change the mesh at the same time as keeping it into a single one.
...
Could there be an easier way to create a seperate class which could combile octrees within an quadtree, to handle sectionized meshes?
How big is the gamefield in question? What is it composed of? How many triangles or other primitives are going into this? What level of interaction is expected- will there be players all over the place, or will they usually be together? Do players affect things across the whole map, or only tiny localized pieces at a time? What kind of modifications can be made to the mesh? How frequently do these modifications take place, and how responsive do they need to be?
Any other information about what the end goal is would be helpful too. Diagrams are always nice
Re: Large recontructable meshes.
- Jaga.png (26.13 KiB) Viewed 5316 times
I see that there is quite alot there,
I wonder, Could i just do some kind of multilayer terrain based on my terrain data, Like storing some k values in a grid? That would be alot better since it will reduse preformance alot and i dont need to use up alot of ram with Triangles..
Re: Large recontructable meshes.
Sorry, I'm still not clear on what the exact goals are and what the game actually is. Higher level information about the final goals and game would be helpful. Is it a blockworld game with removing/adding voxel-like pieces? Is it only heightmap modification?
With the information I have so far, it sounds like the meshes are already heavily segmented. Reconstructing a small mesh of 1280 triangles won't be too bad. It could be tossed onto another thread to avoid hitching the graphics if it takes too long. Once the modification finishes the mesh gets swapped for the reconstructed version.
If it is a blockworld game, using a kinematic compound body of box shapes can be quite a bit more efficient. It takes 12 triangles to represent a single box in the worst case, so you'll end up with less entries in a bounding volume hierarchy to reconstruct. Putting only the 'exposed' blocks into the compound would help too.
If reconstruction is just too expensive in terms of CPU or garbage, it is possible to create custom Collidable objects and collision handlers. This requires fairly deep familiarity with collision detection and some of the deeper parts of BEPUphysics. This is one of those 'very work intensive' solutions I mentioned earlier, but might be the 'best' solution depending on what your actual goals are.
With the information I have so far, it sounds like the meshes are already heavily segmented. Reconstructing a small mesh of 1280 triangles won't be too bad. It could be tossed onto another thread to avoid hitching the graphics if it takes too long. Once the modification finishes the mesh gets swapped for the reconstructed version.
If it is a blockworld game, using a kinematic compound body of box shapes can be quite a bit more efficient. It takes 12 triangles to represent a single box in the worst case, so you'll end up with less entries in a bounding volume hierarchy to reconstruct. Putting only the 'exposed' blocks into the compound would help too.
If reconstruction is just too expensive in terms of CPU or garbage, it is possible to create custom Collidable objects and collision handlers. This requires fairly deep familiarity with collision detection and some of the deeper parts of BEPUphysics. This is one of those 'very work intensive' solutions I mentioned earlier, but might be the 'best' solution depending on what your actual goals are.
If you have heightmap data, the Terrain is fast and doesn't have to reconstruct any hierarchies since its acceleration structure is implicit (just don't forget to update the BoundingBox if the new height leaves the current bounding box). You can also have multiple Terrains if you wanted. Whether any of this is actually relevant to what you want, I don't knowI wonder, Could i just do some kind of multilayer terrain based on my terrain data, Like storing some k values in a grid? That would be alot better since it will reduse preformance alot and i dont need to use up alot of ram with Triangles..
Re: Large recontructable meshes.
- Tilesystem.gif (35.58 KiB) Viewed 5308 times
The triangles are kind of fixed models that are stretched when created along the height of the pillar.
I really dont know a good algorithm for triangle generation atm, but its most likely to be a "list of vertices" Multiplied by height.
I had another way by creating a triangle per 4 pillars, then kind of do like autobordering, check all air pillars with the surrounding and generate triangles according to a value in a table.
its basically getting 8 corners of a segment and bitshift thier position in the byte as "Air" or "Solid", then getting the right list from the table and multiply height.
Re: Large recontructable meshes.
The kinematic compound entity I mentioned earlier looks like it would do the trick. It be easier to manage and faster than a triangulated representation as far as the physics are concerned.
Advantages of the compound approach over a StaticMesh:
-A single BoxShape can be used to represent an entire column.
-Modifying a BoxShape, as opposed to removing or adding it, only requires a refit instead of a reconstruction. The hierarchy refit operation is much faster than a reconstruction. In fact, a dynamic compound that's moving around calls refit every single frame. You can force the unmoving kinematic to refit and recalculate the bounding box by calling the collidable's UpdateBoundingBox method. Note that you will still need to perform a full reconstruction if a box shape is added or removed entirely. However, it looks like this would be a much rarer occurrence than the simple refits.
Disadvantages of the compound approach compared to a StaticMesh:
-When going over the border between two shapes, particularly with an object which has sharp edges, 'bumps' are possible. If a StaticMesh is built with proper connectivity information- meaning connected surfaces share vertices via the index buffer- these bumps go away. However, creating a proper index buffer that welds vertices together would be tricky to do on the fly. It might be just as possible to weld box shapes together, but of course then you suffer a reconstruction.
However, a completely custom specialized collidable would still win. Because the map is a bunch of tiles, there's an implicit data structure like the Terrain. It wouldn't need to do any reconstruction at all. You wouldn't need explicitly handled BoxShapes, just intervals at each tile. If you needed maximum performance and had as much time as needed, the specialized collidable would be the best option.
Advantages of the compound approach over a StaticMesh:
-A single BoxShape can be used to represent an entire column.
-Modifying a BoxShape, as opposed to removing or adding it, only requires a refit instead of a reconstruction. The hierarchy refit operation is much faster than a reconstruction. In fact, a dynamic compound that's moving around calls refit every single frame. You can force the unmoving kinematic to refit and recalculate the bounding box by calling the collidable's UpdateBoundingBox method. Note that you will still need to perform a full reconstruction if a box shape is added or removed entirely. However, it looks like this would be a much rarer occurrence than the simple refits.
Disadvantages of the compound approach compared to a StaticMesh:
-When going over the border between two shapes, particularly with an object which has sharp edges, 'bumps' are possible. If a StaticMesh is built with proper connectivity information- meaning connected surfaces share vertices via the index buffer- these bumps go away. However, creating a proper index buffer that welds vertices together would be tricky to do on the fly. It might be just as possible to weld box shapes together, but of course then you suffer a reconstruction.
However, a completely custom specialized collidable would still win. Because the map is a bunch of tiles, there's an implicit data structure like the Terrain. It wouldn't need to do any reconstruction at all. You wouldn't need explicitly handled BoxShapes, just intervals at each tile. If you needed maximum performance and had as much time as needed, the specialized collidable would be the best option.
Re: Large recontructable meshes.
i just wonder about some details about the ordinary terrain system, how does it work, does it check both sides of the heightpoint, how does it calculate the collision between the diffrent shapes.
If its the simple collision of just checking the lowest point's height,
Then can just smple calculate values directly.
How many triangles does the terrain go trough use in comvex shapes?
If things go good i will try it out :3
If its the simple collision of just checking the lowest point's height,
Then can just smple calculate values directly.
How many triangles does the terrain go trough use in comvex shapes?
If things go good i will try it out :3
Re: Large recontructable meshes.
Check out the TerrainDemo in the BEPUphysicsDemos project.
It's a standard triangulated heightmap, made out of a bunch of two-triangle quads. The position of vertices are defined by the values in the heights array. The triangles are one-sided; objects approaching from 'below' are allowed through. The terrain can also be given thickness that will pull objects up from below. Thickness does not make a rigid surface on the other side- it just helps prevent objects from falling through due to various corner cases.
If a top and bottom surface was desired, you would need two terrains. Additionally, Terrains must be based on a rectangular array of heights. Holes, gaps, and irregular layouts are not supported by default.
Terrains aren't a very a good option to create tiles. It is impossible to create perfectly vertical walls with a Terrain.
It's a standard triangulated heightmap, made out of a bunch of two-triangle quads. The position of vertices are defined by the values in the heights array. The triangles are one-sided; objects approaching from 'below' are allowed through. The terrain can also be given thickness that will pull objects up from below. Thickness does not make a rigid surface on the other side- it just helps prevent objects from falling through due to various corner cases.
If a top and bottom surface was desired, you would need two terrains. Additionally, Terrains must be based on a rectangular array of heights. Holes, gaps, and irregular layouts are not supported by default.
Terrains aren't a very a good option to create tiles. It is impossible to create perfectly vertical walls with a Terrain.
If you're asking how many triangles does the terrain consider when performing collision detection with a convex object: as many triangles as intersect the other object's bounding box. The terrain's grid nature is used as a fast implicit data structure to find the overlapping triangles.How many triangles does the terrain go trough use in comvex shapes?