Jump to content
  • Advertisement
Sign in to follow this  
VprMatrix89

Skipping the management (vertex buffer)

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

So I have a structure that conforms nicely, and I'm thinking I can just create buffers for each and batch them, effectively skipping buffer memory management. There shouldn't be more than 150. But if I don't use batching, then I'll have to manage memory on one giant buffer, and thats really a pain since structures and going to be deleted and created on the fly. What do you say?

Share this post


Link to post
Share on other sites
Advertisement
I don't quite follow - are you asking if you should use 150 vertex buffers? If so, it depends - how many will you be drawing at any one time? And why are your model structures being created and deleted on the fly? Generally you'll load all the models you need for one level, then be done with it.

Share this post


Link to post
Share on other sites
Erhm.. Clipmap. I actually finished the Quadtree and when I look back at it now I laugh (It was over-complicated representation of a grid). I managed loads of memory, used my own garbage collector and everything.
Trying to make it cleaner now, esp on the buffers themselves. I can optimize later I think.

I would be drawing every single one, the thing is if I dont do it this way, I have to use a garbage collector and the buffer will be all fragmented.


EDIT: I want to ask an unrelated noob question. Ok if I want a couple instances of a model, I don't need vertex information for them all? I guess if you just stored the position of them, you could translate a copy of them each frame?

Share this post


Link to post
Share on other sites
Quote:
Original post by VprMatrix89
Erhm.. Clipmap. I actually finished the Quadtree and when I look back at it now I laugh (It was over-complicated representation of a grid). I managed loads of memory, used my own garbage collector and everything.
Trying to make it cleaner now, esp on the buffers themselves. I can optimize later I think.

I would be drawing every single one, the thing is if I dont do it this way, I have to use a garbage collector and the buffer will be all fragmented.
I'm not really familiar with clip maps, but rendering 150 batches just for this is likely to be a bottleneck. You'd have to give it a go and find out really.

Quote:
Original post by VprMatrix89
EDIT: I want to ask an unrelated noob question. Ok if I want a couple instances of a model, I don't need vertex information for them all? I guess if you just stored the position of them, you could translate a copy of them each frame
You could, yes. At the expense of doubling your number of state changes - it's a memory vs performance trade-off.

Share this post


Link to post
Share on other sites
Model instancing is something I've recently implemented - it gets tricky if you want animations, as you need to clone the animation controller for each one, and some other stuff like the frame heirarchy (as they contain the transform matrices which depend on the exact stage of the animation), but not the actual mesh container (as that contains geometry data which can be shared), and the bone offset matrices for skinning.

But if they are static models then yes just set a new world transform before calling DrawFrame on the root node (or whatever method you are using to draw a model) - easy :)

Do you mean you are using geo-clipmapping for terrain or something? You didn't actually mention terrain but I'm going to assume it is for terrain as you mentioned clipmaps and I don't know what else they are used for. Whatever method you use, try and avoid creating or modifying vertex/index buffers in your render function every frame. A better solution is to create all the vertex/index buffers at initialisation, then each frame you only need to select which buffers to actually render.

If you use true clipmaps this is quite hard - I've not implemented them myself, but it looks like you need to create new buffers every time the person moves, as your window moves along with you. What I prefer is to divide the terrain into large(ish) cells (say 128x128) and pre-compute several levels of detail for each cell, then store each as a seperate buffer. Then at rendering, you need to select one of these LoDs and just call DrawPrim on the precomputed indices/vertices.

If you create new buffers every frame you use a lot of bandwidth and CPU, and if you are using a large terrain set or need resources for other stuff like models/special effects (like SSAO) you just can't do this as its too expensive. Creating them at initialisation also caches them in graphics card memory so they don't even need to be sent to your card every frame, which speeds things up a lot. If you create or modify the buffers every frame, you don't take advantage of cache.

I think you need to go into a bit more detail on exactly what you are trying to accomplish - I assumed it was terrain but you might have meant 'structure' as in a building, I'm not sure :)

Share this post


Link to post
Share on other sites
Hey EvilDonut - I guess we have an evil of every type, EvilSteve, EvilDonut, hehe.

Avoidance of pre-computation is the whole point of clipmaps I think.. But I am using it for terrain. Yes you could allocate everything on start, but I am taking a flexible approach, using all types of parameters, so I can change anything (including the size of terrain), and pretty much use it for any type of terrain.

Yes the instancing is interesting indeed. and tackling the animation frame storage.

May I ask , what type of mesh do you import into your game Donut?

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!