I think they are the same thing but just presented differently

Vertex Class - Vertex Buffer
Polygon Class - Face Buffer
Mesh Class - Wrapper for Vertex Buffer and Face Buffer
Object 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.

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 all

In 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 all

Notice 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 jrmcv
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).

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.