Jump to content
  • Advertisement
Sign in to follow this  
justdanyul

Setting Vertex Buffers

This topic is 2689 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

Right, I got a little hobby project going, with the purpose of me learning some more about DirectX. I've successfully created a very simple base framework, and a alias wavefront OBJ parser (and a .MTL parser which basically only grabs a few bits and pieces per material, such as diffuse color and specularity).

Now I'm playing around with rendering the different components which, hopefully, will turn into a board game where the game pieces are continuously moving around the board following a set of rules, and the game purpose will be to apply certain actions to them to beat the board. Very simple stuff. But i'm straying off on a tangent here :D

Back to my questions. Since there are only really a couple of different elements in my game, and they are all visible at any given time, I wont worry too much about trying to determine if they lay within the view frustum.

I have basically 3 types of objects which are rendered to screen.

* the board pieces
* the actual board
* ui elements

I've split this up into three types of a classes:
*a "Element" which basically contains everything i need to render the element (vertex buffer, index buffer, normals, texturecoord, shaders) and position and transformation info.
*a "SimpleElementFactory" which again contains everything i need for rendering (vertex buffer, index buffer, normals, texturecoord, shaders) , but no position or transformation info
* a "SimpleElement" which contains position and transformation info and a pointer to the SimpleElementFactory instance that created it.

The classes all also have a children pointer which contains a array of all children, so i have a graph structure i can iterate through ala:

ROOT
Board | UI
Pieces - Blocks - Portals | Time left - Pieces left
piece 1 .. piece n

The idea with the SimpleElement and SimpleElementFactory is that all the pieces share exactly the same model. So I wanted to be able to just set constant buffers for the position and fire the rendering method in the factory.

Right, finally, this leads me to my question. How heavy is the call to set the index and vertex buffers? The factory idea was basically to keep it to a minimum, and it made sense since all the pieces are the same so there's no idea in having n amount of duplicate data. BUT, this is where i get confused. How far should i take this? theoretically I should be able to calculate only have ONE vertex buffer and ONE index buffer, and then never have to switch it. Basically, combining all the vertex, index data into the root instance (and make that for of a factory, obviously it will need a different logic that what it currently have) and then when the child instances call the render function of the ROOT instance, it tell it what segment of the index buffer it needs to use.

This however, is not as natural as the first "optimization", since i will not get any less vertex data, ill just set the vertex buffer and index buffer less. The question is, is there any point? I seen lots of examples and tuturials on the net which sets the vertex buffers every single time a frame is rendered, and doesn't even care to check if the vertex buffer being set is actually already set. So, im thinking, maybe the overhead in this function call is minimal?

Is there any idea spending time on implementing the proposed "one vertex, one index buffer" scheme?


Additional question. How much overhead does abstract classes add? I currently have a really ugly hack to avoid using abstract classes because i'm uncertain of the overhead involved. Basically all the above mentioned classes have extends BaseNode , which has a NodeType property. So when i iterate though the graph structure, I can cast to BaseNode first get the typeID, and cast to the appropriate type (using a switch statement).

This could be handled a lot more elegant using abstract classes, but at what performance cost?

Share this post


Link to post
Share on other sites
Advertisement

This could be handled a lot more elegant using abstract classes, but at what performance cost?


Probably not enough to matter for a board game.

Share this post


Link to post
Share on other sites

[quote name='justdanyul' timestamp='1304893744' post='4808271']
This could be handled a lot more elegant using abstract classes, but at what performance cost?


Probably not enough to matter for a board game.
[/quote]

Thanks for the reply :) I didn't answer the question in the context of the current project only though. It would be rather pointless of me to put thought into the OO design of the components of this project unless I wanted to re use them for other things in the future. If that makes sense.






Share this post


Link to post
Share on other sites

[quote name='jmastro' timestamp='1304900334' post='4808309']
[quote name='justdanyul' timestamp='1304893744' post='4808271']
This could be handled a lot more elegant using abstract classes, but at what performance cost?


Probably not enough to matter for a board game.
[/quote]

Thanks for the reply :) I didn't answer the question in the context of the current project only though. It would be rather pointless of me to put thought into the OO design of the components of this project unless I wanted to re use them for other things in the future. If that makes sense.







[/quote]

It's not the setting of the vertex and index buffers that is the issue, it is mostly creating them and uploading them to the GPU which causes the biggest delays.

Share this post


Link to post
Share on other sites
The overhead of switching buffers obviously exists, but yes, it is very small. Out of interest - switching vertex formats (declarations) has a higher overhead.

Share this post


Link to post
Share on other sites

The overhead of switching buffers obviously exists, but yes, it is very small. Out of interest - switching vertex formats (declarations) has a higher overhead.


thank you very much for your input, much appreciated :)

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!