   Optimizing the rendering of hundreds of boxes
  I've been programming in directx for about six months, mostly simple demos and the like. Never had any performance issues until recently.Basically I'm making a game with a grid based editor, each grid is a box that gets loaded into the world.Now the problem is when I'm rendering hundreds of boxes the performance starts dying on me. I've heard of a rule that you should never make over 500 draw calls with directx, obviously I'm brekaing that rule by severel thousand boxes :DI've basically been looking around online for a simple way to optimize the way things work, maybe not render boxes I'm not seeing but I'm just not sure which direction I should be heading here.The thing is, I'm not sure just which direction I should be going now, I just want to do something simple. Is there some sort of direction I can take?   
Quote:Original post by chillypacman...maybe not render boxes I'm not seeing but I'm just not sure which direction I should be heading here...Yeah... that's the direction you should be going for starters.  Instead of looping through every "box", just render the ones in the area that is visible on screen.  It might help if you have a camera class that holds a map location and then uses this to determine which part of the grid to render.Cheers;  I'd make one dynamic vertex buffer big enough to contain "a lot" of boxes (Probably a few thousand) in some manager class. Then, instead of creating a box, you can tell the manager class that you want to render a box, and pass in a position and size. The manager class can add that information to an internal vector, and then at the end of the frame, just lock the VB and update it with the data for all boxes in the vector, and then draw them in one call.If you run out of space in the VB, you can just lock and draw multiple times.This is exactly what ID3DXSprite does internally (And my sprite manager in my engine), although it's obviously with quads rather than full models.   ;  Three things:Batching: If the geometry AND transforms are static then at load-time (or even build-time) shove them all in the same vertex/index buffer so that you can blast them at the GPU in a single (or very few) calls.Instancing: If the geometry is the same for each cube/grid but the transforms change then look up "geometry instancing". You can render the same block of geometry 1000's of times, each with a different transform all in a single draw call.Culling: Don't submit draw calls for geometry that you know won't be on the screen. Look up "quad tree" as it'll probably suit you quite nicely. Just bare in mind that there is a sweet spot - highly accurate culling can increase draw calls which introduces more overhead than having 'mostly accurate' culling.Oh, and the other thing - make sure you've got a solid set of analysis results in from PIX or NVPerfHUD (etc..) before you get started. You won't know what is or isn't improving performance if you don't know where you were when you started [wink]hthJack   ;  alrighty guys, thanks for the advice, I'll look into it all :)[Edited by - chillypacman on September 10, 2007 11:10:05 AM];  I'd suggest that you look both at the instancing sample in the SDK and at the instancing demo at humus.ca. The latter will show you how to enable instancing on ATI SM2 cards (i.e., those before the X1xxx series).   