Level mesh design considerations

[Garold]

Hi, I have a few questions about designing a large FPS level.

The level is approximately 2km square, where 1m is 1 unit. I was planning on breaking this into 100m chunks. Do you recommend keeping it all as a single static mesh or separate meshes?

Also, I have lots of grass, stone, wood and metal. I need to play different audio and particle effects when bullets and feet collide with the mesh. I thought I could separate the static meshes by material in 3DS MAX and export 1 mesh per material type, then during the load set the mesh.tag to the appropriate value: grass, stone, etc. Is that a good method?

So if I did both methods above I could have 20 x 20 x 4 static meshes. Is that ok? Or should I just create 4 meshes, 1 per material? Or is there a way to build 1 large static mesh and somehow identify the material type when a ray collision occurs?

Also a further question! I wanted barriers such as fences dotted around, would it be appropriate to use multiple static or mobile meshes for these as well?

Wow, lots of questions!

Any thoughts at all would be very much appreciated.

Thanks

[Norbo]

Do you recommend keeping it all as a single static mesh or separate meshes? ... So if I did both methods above I could have 20 x 20 x 4 static meshes. Is that ok? Or should I just create 4 meshes, 1 per material? Or is there a way to build 1 large static mesh and somehow identify the material type when a ray collision occurs?

Keeping meshes together is a good idea; it prevents broad phase pollution. 1600 elements floating in the broad phase at once would cause some slowdown. Ideally, it would all be in one mesh; four would still be fine, though.

There are ways of stuffing the material data all into one mesh, but it likely involve more per-vertex storage. It would be less work just to have the multiple meshes for materials unless there were many materials with lots of detailed variation.

Also a further question! I wanted barriers such as fences dotted around, would it be appropriate to use multiple static or mobile meshes for these as well?

In terms of performance, it would still be best to stick those into as few meshes as possible too, but it will probably be fine. If the mesh is static, stick with a StaticMesh.

I would like to add a StaticGroup to make this area a bit easier. If you could stick multiple StaticMeshes, InstancedMeshes, and Terrains all into one big StaticGroup with its own acceleration structure, the broad phase wouldn't get polluted. I'll see if I can get this into v1.2. (Technically, something similar can be done now with CompoundShapes and child MobileMeshShapes, but they have a little overhead that is unneeded for static geometry.)

[Garold]

Thanks for the quick reply.

OK, I will do as you say.

The level is mainly grass, so I can have quite large triangles for that mesh.

The roads, buildings and rocks can go into another mesh, they are impenetrable. They are more detailed but there's not many of them

The wood are trees and fences. The trees are simple twisted cylinders, with no collision on the upper branches. The fences are ranch style. They will allow bullet penetration, but I need an appropriate bullet texture and sound event.

The metal is mainly larges buses, and a few telephone boxes, they will remain static and are also impenetrable.

I will break up my level into 4 and hopefully check the tag in the result set returned from the ray cast.

I will post a video when I get it done, within the next few days. Here's a video of where I am up to with bullet collision if you are interested. http://youtu.be/dmlC08z7-84

As always, Norbo, you are very helpful, thank you!

[Norbo]

I will post a video when I get it done, within the next few days. Here's a video of where I am up to with bullet collision if you are interested. http://youtu.be/dmlC08z7-84

Very nice

[Norbo]

The StaticGroup I referred to earlier is now available in the development version: http://bepuphysics.codeplex.com/SourceC ... evelopment

With a StaticGroup bundling them together, 1600 meshes wouldn't be a problem at all if you wanted to do it that way.

[Garold]

Once again, thank you.

I am really looking forward to trying this out. Specifically for my trees. I will be using gpu instanced models for trees outside the level. Within the level wanted to use L-Tree procedural trees, each one would be individual, it will save me a lot of time messing about, placing trees in 3DS Max. Within 3DS Max I have plugin that can add random noise, scale and rotation, but it's still basically the same tree, I can notice it, maybe a player wouldn't, I don't know.

I was thinking of ways around this like always having the trunk of the tree as a straight collidable cylinder, and the branches above merely L-Tree graphics with no physics. Now I can have the best of both worlds

[Garold]

The static mesh tag is now null

I store 1 in the tag if it's grass and 2 if stone. Then when the player makes a step I cast a ray down to see what type of static mesh he is walking on and play the appropriate sound.

This worked fine before but now the tag is null.

Here's the code where I setup the meshes

Code: Select all

var meshes = new List<Collidable>();

ModelGrass = content.Load<Model>("Models/Stonehenge/StonehengeGrass");
Vector3[] modelGrassVertices;
int[] modelGrassIndices;
TriangleMesh.GetVerticesAndIndicesFromModel(ModelGrass, out modelGrassVertices, out modelGrassIndices);
StaticMesh staticMeshGrass = new StaticMesh(modelGrassVertices, modelGrassIndices);
staticMeshGrass.Sidedness = TriangleSidedness.Counterclockwise;
staticMeshGrass.Tag = 1;
meshes.Add(staticMeshGrass);
//Space.Add(staticMeshGrass);

ModelStone = content.Load<Model>("Models/Stonehenge/StonehengeStone");
Vector3[] modelStoneVertices;
int[] modelStoneIndices;
TriangleMesh.GetVerticesAndIndicesFromModel(ModelStone, out modelStoneVertices, out modelStoneIndices);
StaticMesh staticMeshStone = new StaticMesh(modelStoneVertices, modelStoneIndices);
staticMeshStone.Sidedness = TriangleSidedness.Counterclockwise;
staticMeshStone.Tag = 2;
meshes.Add(staticMeshStone);
//Space.Add(staticMeshStone);

StaticGroup group = new StaticGroup(meshes);
Space.Add(group);

And here's the code where I check the tag

Code: Select all

//footstep on terrain
if ((int)rayCastResults[r].HitObject.Tag == 1) //grass
{
    SM.AudioManager.PlayFootstepGrass(volume, this, false);
    IsOutside = true; // there's only grass outside
}

[Norbo]

The Space.RayCast result always contains the object which was living in the broad phase, not any children of that object. So, because the StaticMesh is in a StaticGroup which is in the BroadPhase, the Space.RayCast sees the StaticGroup instead of the StaticMesh.

The child of the StaticGroup hit by a ray can be found by using the StaticGroup.Shape.RayCast function. It outputs a result object which contains which particular child was hit.

There's two reasonably good options here:
1) If the ray hits a StaticGroup, retest the StaticGroup using the StaticGroup.Shape.RayCast to find which child was hit. This performs a redundant ray cast, but ray casts are pretty cheap.
2) Copy the Space.RayCast method and make some modifications so it dives into StaticGroups when it encounters them, rather than returning only the StaticGroup as the result. This avoids the redundant ray cast.