Hi all,

Is there a way to access the vertex and index buffer data on a Model other than to either use a custom content pipeline processor to extract the data and store it in a Tag object for later access or to copy it out using ModelMesh.Index/VertexBuffer.GetData() ? It seems a waste of space that eg. triangle manipulation (picking, collision) requires all this extra data when it's already present in the Model?

I know, the Model class is just an example of what you can do if you roll your own model class. I get the Model = Hammer analogy. I'm just wondering :-)

foreach (ModelMesh mesh in this.Model.Meshes)
{
       .... = mesh.IndexBuffer;
       .... = mesh.VertexBuffer;    
}    

You can cycle through the meshes in any model, and access them per mesh.

Edit: I guess I should've read your whole post :op. I don't think there is any way other than the buffers or setting up a custom content reader. It is one of the biggest hurdles I've found with XNA.....vertices and physics/collisions.

• The CPU and GPU are not the same thing! To render, the data must live on the GPU, but to test for collisions, it must live on the CPU. This means you fundamentally need two copies, one in video memory accessible to the GPU, and another on the manged heap accessible to your C# CPU code.
• The CPU and GPU do not work well with the same kind of input data. For efficient rendering, the GPU wants an indexed triangle list, sorted for efficient vertex cache reuse. But for efficient collision detection, the CPU certainly doesn't want indexed geometry data! Instead, you will need some kind of hierarchical system like an octree to make your code run efficiently. The only way to make both rendering and collision detection fast is to store two copies of the data, each in a structure that is optimized for a different purpose. Every 3D game does this.
• Most games do not want to render the exact same geometry that they collide against! To make things look good, they often want lots of fine detail triangles that would just cause unwanted bouncing around if they were tested as part of the collision. Also, you may want invisible triangles to close small gaps so the collision detection cannot fall through a space even though visually you may be able to see through it. Finally, most games use lower detail versions of their meshes for collision, because that doesn't need such curvy outlines as you might want for rendering.
  

I didn't realize that the index and vertex buffer data was stored in GPU memory, I sort of thought that XNA made a copy for that internally - cool! It makes sense :-)

I think I should get started on some more content pipeline experimenting and make that custom model class now.

Thanks for the replies!

Now I've (finally) completed a custom model class, using the Custom Model sample to lean on. I have a few observations I'd like to share:

- How über cool! Now I can do anything I want with models, and the code doesn't feel ugly with things stuck in a Tag object.

- Looking back on it, I would recommend anyone with C# skills writing their own custom model class at least once instead of just using Model, because it makes a lot of pieces of the XNA puzzle fall into place - even if Model is the hammer you need.

- The documentation is far from complete on this and related subjects and it would have taken me weeks to figure out all of the logic that goes on behind the scenes using Reflector + trial-and-error, if it hadn't been for the Custom Model sample. Even with that, a lot of questions needed to be answered. For instance, the difference between the data types used in a ContentProcessor and the GPU-ready data types used in a finished model class isn't really something that the documentation explains. Or how the Processor -> ContentWriter -> CustomModel"Content" side of the equation works with the ContentReader -> CustomModel -> Game side.

- I understand why you, Shawn, think that creating a custom model class is easy. It's because you know the intricacies of the XNA framework and have been through it all before :-) But the documentation isn't thorough enough for us outside the XNA team. Maybe it's because the XNA environment is only a year old, but really this was also a problem with the MDX documentation. Example code snippets on "deep subjects" and some more thoroughly explained diagrams would go a long way.

- Maybe someone has asked this before and there is a good explanation to the current situation, but I'll stick my head out anyways: Why not create some sort of wiki on this site, like what's being used with great success on www.ogre3d.org ?

Just my $0.02 :-)

Glad to hear you got this working!

And thanks for the great feedback: I'll make sure this gets to our doc guys.