Archived

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

Games, Vertex Buffers and Objects

This topic is 5272 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Ok, I''m looking for a little advice. Basically I''ve started recoding my old engine from scratch (as it was pretty clunky and I never got that far anyway) and I would like to ask a few of the pros a bit of advice. Now, having created a MS3D loader and loaded the models and textures, etc into my classes for the engine, I''ve created a vertex buffer and populated it with the model''s info and got it displayed nicely onscreen with all the textures and material properties. So far, so good. Now, the thing I''d like to know is this: Obviously games don''t load a copy of each model that they''d need (eg: with an RTS, you won''t see them loading each unit type a hundred times into memory), no, instead I assume they create a basic unit class and a pointer to the relevant model that was pre-loaded. All games have different rotations and positions of the model, saying to me that they each need their own vertex buffer. Does DX offer a function to take the contents of a basic VB buffer (eg: my preloaded model) and apply a translation matrix that handles the rotation/position change and then push it into a ''new'' VB that is used for this particular instance of the model. And... is this how games work? Do they have a million little vertex buffers flying around, or do they allocate one big huge vertex buffer and push everything into that? (Requiring a fair amount of pre-processing to obtain it''s size, etc) Thanks for any help you may offer Oli

Share this post


Link to post
Share on other sites
Your question is quite simple, and you are on the right track. If you set the stream source, fvf, and indices, you can dran an indexed primitive as many times as you want!


pseudocode


Device->SetStreamSource(ModelBuffer);
Device->SetFVF(ModelFVF);
Device->SetIndices(ModelIndices);

for(int i=0;i < NumMatrices; i++)
{
SetMatrix(ModelMatrix [ i ] );
Device->DrawIndexedPrimitive(TRIANGLELIST);
}


EDIT: Stupid HTML

[edited by - RhoneRanger on July 7, 2003 12:39:55 PM]

Share this post


Link to post
Share on other sites
Thanks...

... so instead of creating a "standard" VB to display all the objects in my world I''d go:

[Pseudocode]

LOAD:
Load object from MS3D model
Create a normal VB for this

DISPLAY:
Number of models = 100
Create an index buffer of 100 * Size of model VB
Populate the index buffer with copies of the model VB (note: all models will be in the same position/rot/etc)
Then do as you say...
For each model that needs to be displayed
...apply relevant matrices
... draw

Share this post


Link to post
Share on other sites
Sort of but not really. You don''t need to create all those VB''s. Just create one, then prior to rendering each unit set the world transform rotation, translation and scale matrix to position the model you want to render. I could be wrong here, but I think that rendering models from VB''s is exactly the same as rendering Meshes in this respect. Feel free to search the forum for help on the matrix set up.

Share this post


Link to post
Share on other sites
In this example take model to be the same as mesh as in my engine a model is a collection of meshes that are all rendered in turn (and each mesh has it's own separate VB).

What I was thinking was:

For each scene, work out how many meshes are on show, allocate a large vertexbuffer to accomodate all the vertices...
... populate this with copies of the mesh VBs, rotating and translating each one in turn until you get to the end...
...Then display.

I guess I could (for optimisation) allocate the vertex buffer and only reallocate it if a mesh is removed/added to the scene.

Oh and I'm fine with world translation/rotation matrices (I think).

is my thinking on track? It seems logical to me



[edited by - downgraded on July 7, 2003 6:26:42 PM]

Share this post


Link to post
Share on other sites