Jump to content
  • Advertisement
Sign in to follow this  
Bombshell93

XNA lowering draw calls for low poly models?

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

I'm drawing a world that I suppose is easiest described as minecraft-ish. loads of low poly objects, blocks, slopes, etc. I've got all systems working but the drawing is giving massive frame drop because of the shear amount of draw calls (16,000 objects for 1 floor).
With them all being low poly and the majority taking from the same texture, I assume I could fix this via treating groups of objects as a single mesh part?

I remember reading the draw call itself has enough overhead, so many low poly calls leads the CPU not able to keep up with the GPU, causing my current predicament (thats from memory so its probably incorrect in some way).
So yeah, basicly I want to reduce draw calls by treating groups of objects as mesh-parts when drawing.

Any and all help is appreciated,
Thanks in advanced,
Bombshell

Share this post


Link to post
Share on other sites
Advertisement
The keyword here is batch...batch, batch and batch some more. You're not going to see that many draw calls for an entire scene, let alone a floor. The idea in batching is you group like minded objects together, e.g. you have a cube-world essentially, well all the cubes in that floor should really be in one vertex buffer. When I mean like minded objects, I really mean "have the same material". Especially for simple objects (like cubes), it's a lot better to have them in one vertex buffer, rather than in hundreds (or thousands). You can draw thousands, tens of thousands, hundreds of thousands, etc of triangles in a single draw call, so make full use of it. Drawing a single cube (12 triangles) over and over is not.

Take XNA's SpriteBatch as an example, it's an easy to use tool to draw a lot of sprites (essentially quads) to the screen. If you're creating a 2D game and you have the SpriteBatch sorting by Texture, and submit two characters (each with a different sprite texture), and a 100 bullets flying around on the screen, then the SpriteBatch is smart enough to not do 102 draw calls, but to group the submitted sprites based on their texture - so its reduced to three draw calls.

In a nutshell, a SpriteBatch is a large rotating dynamic vertex buffer. When you submit sprites to be drawn (except in Immediate mode), they're stored in a queue waiting to be processed when you call End(). After that they get sorted, they're added to the vertex buffer. It's a rotating buffer because the SpriteBatch doesn't overwrite what it wrote in it last frame because the last frame could still be drawing.

This can be a useful way to mimic highly volatile geometry where it can change dramatically from one frame to the next, e.g. for my own stuff I have a normals/tangents/bitangents debugger which will create a visualization of those lines on the fly. Or another example with the old D3D9 DrawUserPrimitives (I believe XNA still has this though, so it may be of use to you?).

Of course, this depends on how much your cube world changes. It may not be editable whatsoever, and in that case use static vertex buffers, but heavily batch your objects like I mentioned. You could also employ a combination of the two, so you're only editing a subset of the world (e.g. Minecraft's idea of "chunks"). Another idea for optimization is draw only the cubes/sides of cubes that you can actually see. So it may help to have adjacency information where you can determine if a cube is fully covered, or partially (e.g. if only one side of a cube is visible, you only need to render a quad, rather than a full blown cube).

Share this post


Link to post
Share on other sites
thanks I found this sample about instancing, it seems fairly simple and helpful.
http://create.msdn.com/en-US/education/catalog/sample/mesh_instancing
I think I'll use this for the level editor where the world will constantly be changing but I will look for a better long-term solution E.G. constructing single meshes out of groups of similar objects for use with in game.
As well as this I've been considering an SVO approach, I'm not sure if that would be over-complicating things but it would definitely allow for bigger levels, I capped the levels at 128 x 128 x 128 because I thought that would be a reasonable stretch.

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.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!