I’m working on collision detection for a game written using the Microsoft XNA framework version 4.0. When trying to access the model itself once it’s been loaded by the content framework, I can access a list of “ModelMesh”es, and for each one a list of MeshParts, but the parts only seem to have diagnostic data like the number of vertices. I’m completely stumped as to what’s happened to the actual face data for the model.
I’m trying to implement sphere-sweep/plane collision– that is, I have a ball moving and I’d like to test collision with a polygon as the ball moves. I need a way to define all the polygons to test with, and it just makes sense to me to define a collision map as a simplified mesh that I design in parallel with my actual graphics object to use for the colliding, but I’m completely baffled as to how I’m supposed to access that info once XNA’s content pipeline has loaded it.
Some insight here perhaps? I’ve been combing Google all day and I’m unable to locate anything that might help, although it’s possible that I’m using the wrong search terms…
The built-in XNA FBX/model content importer and processor handle “faces” the same way that just about every modeling program out there does – as lists of vertices and indices. (As a side note, your GPU also natively supports this scheme, and modern games rely upon it for performance reasons.)
For instance, consider a simple, two-triangle quad. The vertices might be:
or,
To represent this in “face” form, you’d need a list of data equivalent to
triangle 1 (upper-left): (0,0,0),(1,0,0),(0,1,0) = (v0,v1,v3)
triangle 2 (lower-right): (1,0,0),(1,1,0),(0,1,0) = (v1,v2,v3)
which requires six vertex records.
Using XNA-native structures, a Vector3 has three elements, each of which are single-precision floats (4 bytes), so that’s 3*4=12 bytes each, and you need six of them, so that 72 bytes.
Or, you can use indexing. In addition to the four vertices, you store a list of indices:
Indices can be stored using shorts (16-bit integers). So, let’s examine the difference:
No indices: two faces * 3 vertices*3 components (xyz) * 4 bytes each = 2*3*3*4=72 bytes.
Indexed:
vertices: 4 vertices * 3 components each * 4 bytes per component = 48 bytes,
indices (3 shorts per triangle): 6 indices * 2 bytes each = 12 bytes.
48 + 12 = 60, which is slightly less than 72 bytes for the non-indexed model.
That 12 bytes might not seem like a lot until you consider an entire level with 100,000+ triangles. At that point, you’re looking at a 1.2MB difference. Although your graphics card may about 2+GB of memory, moving that data back and forth between host RAM and GPU RAM is expensive.
So, how do you get that data?
Look at
Model.Meshes[].MeshParts[].VertexBuffer.GetData()andModel.Meshes[].MeshParts[].IndexBuffer.GetData(). You can use those methods to extract the vertices and indexes, then cross-reference the two to get the triangle list.You can’t just directly access the elements of
VertexBufferandIndexBufferbecause they are stored in the GPU’s RAM – allowing random element access would drag performance to near-negative velocity.Also, have a look at the
GraphicsDevice.DrawIndexedPrimitives()method.I can post some example code later if necessary.