Archived

This topic is now archived and is closed to further replies.

mux

Vertex Buffers Management, lots of questions

Recommended Posts

Some questions on Vertex Buffers and Object Loading. If you have a level format consisting of several static object how will you load and manage the vertex and index buffers? If a level format consists of hierarchical, empty ''groups'' (ie. car) which are formed by objects (ie. tires) will you just load vertices, indexed primitives, normals into one big vertex & index buffer in order to apply spatial divisioning (octree, abtree, whatever)? Or do you create the octree while loading the level, storing the data in its leaves and only use the buffers on those small piece of geometry data? Please bare with me, now how do you actually ''synchronize'' the raw geometric data which is stored in an octree/vertex buffer/whatever with the ''game data'' (ie a door and its behavior, triggers for quests). I mean if you subdivide the whole scene into boxes with a treshold you could end up with only part of the actual geometry data forming the ''game object''. Do you have to propagate a separate, linked ''game object'' tree? Ok this doesn''t make any sense at all, but this is my current state of confusion

Share this post


Link to post
Share on other sites
In order to create a canonical space subdivision octreetree, the whole level has to be loaded into memory, then you apply the vector math, slice it, propagate the tree, till you end up with the geometry data in the leaves. In order to achieve this you at least once have to load the whole lvl into a vertex buffer and index buffer (where, not like a vertex buffer, only one is permitted to be in use I thought?). So you basically end up with vertice data propagated into the trees, and one global index buffer?

correct?

[edited by - mux on May 26, 2004 9:34:22 AM]

Share this post


Link to post
Share on other sites
You can only use 1 index buffer per call to DrawIndexedPrimitive(), but you''re only limited in the number of buffers that you have by available memory.

All that aside, you probably shouldn''t actually be creating the buffers until you''ve sorted the geometry in the first place.

Personally, I use an adaptive algorithm for subdivision (determines how many levels to use, as well as whether a quadtree or an octree would be more effecient for the data provided), and store raw vertices & faces in the level data.

I create the maximum nodes first, then send the triangles through the heirarchy until they find a home. Once there, they''re appended to the existing geometry.

I do the apending ala most string implementations; that is, I allocate a few hundred / thousand faces / vertices (depending on the complexity of the level) at a time. Once I finish loading and sorting all geometry, I delete any extra geometry that has been allocated (but isn''t actually used).

Each node in my trees contain a linked list of game objects that exist within the node (static objects are stored in the map file, and dynamic objects are placed at run time). That allows me to quickly move objects from one node to the next, as well as reduce the physics and rendering workload.

Share this post


Link to post
Share on other sites