   When rendering meshes...
  I've taken the course at www.GameInstitute.com  They have awesome material, but I think it is over complicated.  For example:When drawing a mesh and rendering all polygons, they have:Vertex classPolygon classMesh classObject classThey then iterate through all the objects and draw all their meshes, which loops through the mesh's polygons, which loops through vertices.On the other hand, frank luna's book "Introduction to 3D Game programming with DirectX 9", just writes all the vertices to the index/vertex buffer and then calls DrawPrimitive or DrawIndexedPrimitive.Is there an upside to this?  I love Franks' book because it's not complicated like Game Institute, but is he doing the right thing?   
  I think they are the same thing but just presented differentlyVertex Class - Vertex BufferPolygon Class - Face BufferMesh Class -   Wrapper for Vertex Buffer and Face BufferObject Class - Wrapper for Mesh and Object information eg. materials, world matrix transform (rotations, position etc).The reason they are divided like this is because often in games you will want to use the same mesh repeatedly. Think of the mesh class like a template/symbol and the object class is your instances of that template or symbol. The classes are just wrappers but probably do the same or similar to the book internally.Franks book is a good place to start and later you may find that you will build on it towards something like above. I dont use classes but use a similar way of managing all the data. The advantage of putting everything in sections is that it is easier to manage and things are more inter-changable. eg. You could have 3 different meshes of an object in different states (normal, damaged, destroyed etc) and just switch the mesh of the object depending on its state.   ;Quote:Original post by jrmcvI think they are the same thing but just presented differentlyBoy, I hope so, but I suspect not.Quote:Original post by heythereThey then iterate through all the objects and draw all their meshes, which loops through the mesh's polygons, which loops through vertices.Sounds like manual iteration to me, but I hope this is a mistake on my part.In any case, THE way to do it in DirectX, AND openGL, is to use buffers filled with vertexs/indexs that are stored on the hardware, and rendered on the hardware.  Manually iterating over your vertex sets is a sure-fire way to destroy any hope of having high-performance graphics.  You must learn to use the hardware, and in the case of directX, that means using vertex/index buffers and calls to DrawPrimitve and DrawIndexedPrimitive [openGL has the exact same things with different names], or use of something that uses these functions/features.Manually iterating over all your vertex sets is something that is typically taught to introductory graphics students before performance or efficiency is even a concern [the goal of 'just get the picture to the screen', often times with openGL's glVertex functions and the like].  This method just is straight-out unacceptable for games.  The only time it *might* be acceptable to manually iterate over your vertex set is in the case of particle effects, just because they don't always behave well as static geometry.   ;  With the first method it sounds like you're submitting vertices as you iterate over them, like OpenGL's immediate mode, the following gives an overview of what happens with the CPU and the GPU using this technique:    CPU   GPU*Sends vertex  *    Vertex received*Sends vertex  *    Vertex received*Sends vertex  *    Draws triangle*Repeats until done*Non-graphical processes    Sits idle*Repeat allIn this case the CPU and GPU finish all the drawing at the same time, so when then the CPU goes off to do other non-graphical related processing the GPU has to wait until the next frame before doing anything.  With this model the CPU and the GPU rarely/never do any work in parallel at the same time.Using vertex and index buffers you can submit 1 or more large batches of geometry to the GPU in one go, the GPU will then set to work rendering all of these and the CPU can go and do other processing, in this scenario most of the rendering takes place on the GPU concurrently to the CPU doing non-graphical related processing:  CPU    GPU*Sends vertex buffer    *    Vertex buffer received*Sends index buffer*    Index buffer received*Sends draw command*Non-graphical processes    Draws everything*Repeat allNotice how the CPU and GPU do processing at the same time once the geometry has been submitted.  Chances are that the CPU's non-graphical processes will still take longer to perform than the GPU takes to draw everything, in this case the GPU will still have to sit and wait until the next frame.  The advantage of-course is that the amount of time between two frames is vastly decreased so the GPU doesn't really have to wait long at all.   ;Quote:In any case, THE way to do it in DirectX, AND openGL, is to use buffers filled with vertexs/indexs that are stored on the hardware, and rendered on the hardware. Manually iterating over your vertex sets is a sure-fire way to destroy any hope of having high-performance graphics.yeah sorry i should have mentioned that. I assumed no one really sent it per-polygon unless your using BSP tree or something (which is still prob a bad idea). I use ID3DXMesh in Directx, im not sure what openGL equivalent is. What i meant was that they were just different ways of representing the data and that even if you did send draw calls per-polygon, you would still probably need some structures to organize the data unless your only drawing one model where most stuff can just be global variables (although i think thats frowned upon).If you do use DrawIndexedPrimitive and DrawPrimitive, you are still using vertex and index buffers(streams) allocated on the graphics memory though.. or have i misunderstood something.I have Franks book too and would say its a good place to start. It helped me a lot   ;Quote:Original post by jrmcvyeah sorry i should have mentioned that. I assumed no one really sent it per-polygon unless your using BSP tree or something (which is still prob a bad idea).Even using a BSP tree you submit vertices using buffers.  Only beginners send data on a per-polygon basis because it's easier to understand, once they understand the concepts they typically move onto using buffers and other performance gaining devices.Quote:I use ID3DXMesh in Directx, im not sure what openGL equivalent is.There is no equivalent in OpenGL, ID3DXMesh is just a wrapper over some Direct3D functionality; if you wanted a similar construct in OpenGL you'd write it yourself.Quote:If you do use DrawIndexedPrimitive and DrawPrimitive, you are still using vertex and index buffers(streams) allocated on the graphics memory though.. or have i misunderstood something.Pretty much, in Direct3D buffers are managed by the runtime, although they may not always be in video-RAM but you can trust that the drivers knows best.The equivalent in OpenGL would be to use VBOs (Vertex Buffer Objects), although other extensions exist aswell if VBOs were poorly supported for some reason.   ;  Thanks guys.  What he's doing is taking the vertices and adding them to their own polygon objects.  He's then taking those objects and adding them to a mesh, for which I think is more flexibility.He is using index/vertex buffers, but I think he's managing the code better because of all the detail.Later on in the course (realized this after skimming for a bit) he loses the Polygon class alltogether, and just adopts the vertex/mesh structure, in which he stuffs all vertices into the buffer and stores it on the mesh.So thanks for your help.  I love frank's book, and love his code, but if this one gives me more flexibility and is a step up, then I'll continue on with that after finish frank's.Peace out homies   