Hi,

I'm currently playing about with DirectX (purely for the fun of it, and to brush up on my C++ skills) , and I got a couple of questions that I hope some of you experienced peeps could give your opinions on. After getting acquainted with the very basics of rendering a triangle and a cube using hard-coded vertices and indices, you know, pre-crawling phase stuff.

Then I wanted to try and create my own little mesh data-structure with a member function to handle rendering. So I've created this little OBJ loader that loads .obj (and a subset of the .mtl files) and feed all this into a mesh instance of another class.

First question:
I'm thinking that the actual data structures should be kept as simple as possible, so, my mesh class is basically just a bunch of pointers to structs. Then I have a member function sending a reference to the pointer (I.e VERTEX3F *&GetVertices() ) into the class that does the object loading class after its done parsing (to make this easier to implement, i used C++ STL datastructures) and it then populates the pointers with C style data-structures. So here's the actual question, is this shooting my self in the foot? Will I be better off using STL data structures in the actual mesh class as well?

Second question:
I'm starting to play around with vertex and pixel shaders now. And I read that the primitive assembly stage is a big bottleneck in the rendering pipeline. So I was thinking I wanted to pass in the vertex colours using constant buffers instead of passing them though the input assembly data-structure. But then I read that constant buffers should only be used when absolutely needed. So I got confused. What's the best way to go about this?

Looking forward to hearing some input

First Question:

My "mesh" classes only consist of buffer data. In other words, my classes are only concerned with holding onto data directly useful for the video hardware. If I need a cache of the raw vertex structure data, I keep that elsewhere. And on the topic, when dealing with raw mesh data, I find it easiest and generally best to use plain old arrays, since your vertex count is generally well known and uniform in size.

Second Question:

If the data varies on a per vertex basis, then it is best to pass this data as part of the vertex buffer data. Constant buffers should hold data concerning the entire geometry to be drawn, and should ideally be a constant size and updated as infrequently as possible.

I hope this helps.

First Question:

If the data varies on a per vertex basis, then it is best to pass this data as part of the vertex buffer data. Constant buffers should hold data concerning the entire geometry to be drawn, and should ideally be a constant size and updated as infrequently as possible.

I hope this helps.

Sorry, I didn't make that very clear in my original post that i meant colour data which was the same for a large group, of vertices

For example, I got a object which only uses 3 different colours, when i do the parsing of the obj+mtl i obviously keep track of which faces uses which materials, and I also keep track of the start and end positions of faces with different materials (i got one big array with all the vertex indices that make up the faces). So i can easily loop though this array and do DrawIndexedPrimitive() for each section.

What I am wondering, is i heard statements like yours about they should be updated as little as possible quite often. I just trying to figure out how much, is too much. In the model im talking about for example, it would seem like it would make better sense to just use a constant buffer instead of sending the same data though with ever n amount of vertices in each triangle group. But, im not sure if thats the case cause of all the warnings not to use them too often

hope that makes sence