Game Development Community

Vertex and Index buffer Question

by Alex Fritz · in Torque 3D Professional · 06/16/2011 (5:11 pm) · 5 replies

Hello,

I'm currently implementing an interface for T3D to be able to access and use my Planetary terrain Generation library www.youtube.com/user/davlexdesign


This video is quite old, and the newest incarnation of the library produces vastly different results to what you see in here.

As I was poring through the T3D 1.1 Final code, I realized that (especially with your example code) that you have allot of vertex duplication going up to the GPU, for example ....

When you create a cube, which has only 8 vertices, you guys send up 36 individual vertices to the vertex buffer, and 36 indexes to the index buffer, I was wondering ...

(a) Is there any reason why you would do this ?
(b) Am I missing something in my interpretation of what is going on here ?

I always thought the reason for having a Triangle list was to conserve CPU & GPU workload and memory by having the smallest amount of vertices running through matrices, and using the index buffer to repeat use vertices to describe the primitives.

Alex

#1
06/16/2011 (5:24 pm)
You could possibly create a cube using only 8 vertices but you will need 36 indices still.
#2
06/16/2011 (5:34 pm)
Of course, I was just wondering why they are not only using 8 vertices, and duplicating like that, as that increases the workload quite allot to transform a simple cube.

Alex
#3
06/16/2011 (10:13 pm)
Because each face of the cube has a different version of the vertex, as the normal data is different for the hard edges.
#4
06/18/2011 (12:42 am)
You are referring to GFXDrawUtil's code, right? _drawSolidCube in particular?

Actually, this is allocating 36 vertices and no indices at all. It renders the cube as a nonindexed triangle list. Not optimal I guess, but yeah, keep in mind that this is primarily meant for editor and debug rendering (except for the 2D stuff which is used by GUIs) and not really for in-game rendering so none of this is really performance critical.

Actually, this code here will usually only be used to render a couple of cubes for visualizing invisible objects in the editor and for doing some debug visualizations.
#5
06/18/2011 (10:13 pm)
Thanks guys,

OK, I get what's going on there, and I should have picked up on that from the start, but poring through all this stuff (this thing is a monster) I sometimes get pipe lined into trains of thought, and can't see outside the box.

I really need to be careful with the system I'm implementing here, and keeping the cache to its cache friendly ordered minimum is a major priority for this system, as it can request an update at any arbitrary position on the globe at any time. So after the update process if enough of the vertices have been altered in a single page, only then does it get pumped up to the GPU, and that is where the fun starts, as I have to send the data up in a GPU vertex cache friendly manner as well, so I can maximize the GPUs' pre-fetch mechanisms.

It's getting there though.

Alex