Skip to main content
GameDev.net gamedev.net
🔒 Locked

Rendering meshes efficiently

Started by wasd Sep 26, 2005 at 1:21 PM 4 replies 1.3k views
Original Post
wasd
wasd
I'm about to implement mesh rendering into my engine, to draw players, units etc in the game. I know that the best way is to batch everything into effects (shaders), then textures, then vertex buffers, but my graphics engine currently just calls a draw function for each registered object (such as the heightmap, then each entity). It does support batching by object type, so the render loop looks like this: Loop for each object type (e.g. heightmap, one type of mesh, another type of mesh) --- Call pre-batch drawing function (can be used to set things like shaders and textures for the current mesh) --- Loop for each instance of the object and draw it (e.g. each enemy of a certain type) --- Call post-batch drawing function (can be used to clean up temporary objects etc) Does this sound like a good way of doing things, or maybe anyone could suggest some way to adapt this in order to perform better.
JohnBolton
JohnBolton
Generally, the important thing is to reduce the number of draw calls. If your organization achieves that, then it is fine.
John BoltonLocomotive Games (THQ)Current Project: Destroy All Humans (Wii). IN STORES NOW!
superpig
superpig
Give it a large dataset (maybe 2x your target dataset size) and profile it. That's the best way to find out where your renderer is burning cycles.
Richard "Superpig" Fine - saving pigs from untimely fates - Microsoft DirectX MVP 2006/2007/2008/2009
"Shaders are not meant to do everything. Of course you can try to use it for everything, but it's like playing football using cabbage." - MickeyMouse
Padawan
Padawan
Your scheme will bring you to what you want, i.e. sorting by object/texture/vb.
I would say, this will work okay for __relatively__ small scenes (I don't mean realy small), if your objects will get properly culled.

Unfortunately, it won't satisfy the requirements of big dynamic scenes. Because you need to take care about various cache optimizations, according to both gpu and cpu cache infrastructures.

Second, there can be very small objects in your scenes. Probably you will gain performance if you batch them into buffers, thus achieving lesser draw function calls per frame.

And finaly, if your objects are forwarded to gpu in front-to-back order, you will relax fillrate bounds. But this will be likely increasing DIP calls. I would handle it like doing flexible state sorting, thus finding middle point between state sorting and depth of view sorting.
meeshoo
meeshoo
if you it's about meshes, if you have more meshes of the same type, you can use mesh instancing.
wasd
wasd
It's for an RTS style game, so there will be quite a few different types of model, but lots of instances of them. Also, there shouldn't be too much overdraw (because the view will be looking down on them) so I think depth sorting isn't really required. I'm gonna look into using instancing, which should allow me to draw most quite efficiently.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.