Terrain or StaticMesh?

[chebob69]

I've been using a terrain object for the physics in my game but I'm struggling with the limitations of using a terrain for the visuals.
I'm thinking of switching to using a regular Model (XNA) for the visuals so I'm wondering the best way to make the physics match?
I've read in other posts that the terrain object is slightly more efficient. What would you recommend as the best approach? Do I use a staticmesh
that matches my visuals exactly? Do I use a terrain physics object that is a best approximation of the visual model?
Thanks in advance

[Norbo]

Unfortunately, I can't give you much more information than you already have.

-Terrains have constant-time access to the triangles that need to be tested while a StaticMesh would have logarithmic time. So, if Terrains match what you need sufficiently, it's marginally better to use them. To see how significant the difference is for your simulation, I can only suggest testing it.

-If the difference in shape is too large ('too large' being defined entirely by your judgment), then you'll need to use a StaticMesh.

[chebob69]

Thanks Norbo.

If it's only gonna be a marginal difference, I might just go with the StaticMesh and look for cost cutting ideas elsewhere. I can foresee fiddling about with
a heightmap to try and match the intricacies of a model being an arduous process.

[chebob69]

I'd actually like to follow this up by asking how the more intricate parts of the terrain would affect the performance. One of the main reasons I'm switching to a model for the visuals is so I can have features on my terrain of different amounts of detail (as a heightmap forces you to keep it constant). So if you have just a flat beach, obviously you can have neighbouring vertices a fair way apart. However, I have some areas (like stone ledges, a rock arch and a hollowed out volcano) that need more vertices to help define them. How does BEPU cope with this sort of thing on a StaticMesh? Do areas with smaller polygons affect the whole model or does it just test the local proximity. So for example, would it be better to just have a very basic model for the main terrain and then add separate staticmeshes for the more intricate areas? (That way they're only being tested for collisions occasionally)

Thanks

[Norbo]

How does BEPU cope with this sort of thing on a StaticMesh? Do areas with smaller polygons affect the whole model or does it just test the local proximity.

First, an important note: only the triangles which have bounding boxes overlapping the query bounding box will actually be tested. This is true of both Terrains and StaticMeshes. So, the difference between Terrains and StaticMesh is only in how those triangles are found.

The terrain's grid layout can tell the query exactly which triangles exist near a given bounding box trivially; it's like accessing an array index.

The StaticMesh, in contrast, has a bounding volume hierarchy. The root node bounding box contains all objects, its children bounding boxes contain roughly half of the objects each, and so on. If the query box intersects a node, its children are investigated. For a reasonable sized query, it will only visit a logarithmic number of nodes. So, the query is on the beach and there's an extremely complex piece of geometry somewhere else, you do technically pay a little bit of computational cost- but for reference:
log2(1000) = 10
log2(100000) = 16
log2(10000000) = 23

Ten million triangles will take a little more than twice as long to query as one thousand triangles. All of that cost will still likely be less than the contact generation cost that comes later, when it's actually processing the located triangles.

So for example, would it be better to just have a very basic model for the main terrain and then add separate staticmeshes for the more intricate areas? (That way they're only being tested for collisions occasionally)

This could conceivably be better, given a particular implementation of the broad phase. However, as it is, the default broadphase is the DynamicHierarchy, which- as the name might imply- is another hierarchy. So, splitting meshes apart doesn't meaningfully change the algorithmic time. There would be a little more overhead from having more stuff in the DynamicHierarchy, though: it's a slightly lower quality tree than the StaticMesh's tree.

[chebob69]

Thanks for the detail Norbo.

By the looks of things, I think I'll be ok to go ahead with the method that gives the best visuals. The physics concerns don't seem to be
hugely different and I'll be able to keep the poly count down if I go for StaticMesh.

Thanks