   Batching is confusing
  Ok batching is just to reduce the number of render state changes, texture changes, and render calls. Here''s where Im confused if this should even be batched. I have a group of primitives that all have a unique transformation that needs to be applied. They all use the same render state and same texture so I tried to batch them. But I have to make 25 calls still because I have to reset the transformation for each set in the batch. That''s not batching is it? 
  If you are sorting things by state, and making as few calls AS POSSIBLE, then yes, I would say that is batching. Just because you don''t have 1000 polygons in one DIP call, that doesn''t mean you are doing something wrong. It may very well be a necessity to make that many calls in order to set each objects transform before calling DIP. There''s nothing wrong with that. ;  If the number of vertices in each transformation is small (for example, a single quad), it might be faster to do the transformations on the CPU. ;  Really? That''s good to know since I am working on rendering 2d quads efficiently and I wanted to manually transform them so I still make one render call.Right now I''ve implemented wrapped up index/vertex buffers as a helper class. After locking the internal vertex buffer I start adding batches of quads that are already batched (by the user), I also send a struct describing the states,textures,and matrices to be used with that batch. Once the buffer fills up it renders all the batches.Problems so far I have to work out:1.) The user has to batch the quads beforehand and I want to eliminate that to make it easier to use. I''m thinking of creating a simple scene graph (seems like overkill for 2D but I wanna keep it simple).2.) The matrix problem, with individual quads needing unique transformations yet still belonging to a batch. Still brainstorming that one. ;  Yes... if you want to render bazillions of quads (billboards/particles for example) you will need to "transform" them on the CPU and send them as one big batch.  This is really the only way to get any good performance.Sending a matrix per quad will really hurt the speed.  Luckily, transforming 2D things like billboards can be done without full vector vs. matrix multiplies.Also, be sure to use either A) multiple vertex buffers that you ping-pong between frames, or B) a big vertex buffer that you access cyclically, with the correct usage flags so you don''t lock down the entire buffer while the board may be rendering from it. ;  Don't worry, I am using a cyclic vertex buffer and fills, flushes, and refills as vertex data fills the buffer. The only problem that has risen so far is sorting quads to get effective batches. Does this seem viable?Quick pseudo algorithm that I've been working out on paper:if current texture not a node in render treeadd nodeelse if current render state not a child node of texture nodeadd state child to texture nodeelseadd poly child to state node sorted by Z depthso it might look like:alphatesting - 50 polyroot -> texture 0 < |   alphablending - 20 poly |   alphatesting - 30 poly |   -> texture 1 <alphablending - 5 poly  Is this the best way to sort? I read on nvidia and ati's dev sites that texture switches were actually more costly then render changes. Also I'm a little confused since sorting this way now breaks the "draw front to back" sceme to prevent overdraw, since not every available polygon in the front is drawn first. Thoughts?By the way, thanks for the replies so far  [edited by - Zorbfish on July 30, 2003 5:13:46 PM];  I''m just guessing you''re doing particle system or the like.In any case, you need to take the batching advice much farther if you want to really draw a lot of quads.If, as in your example, you''re talking about 10 or 20 quads per DrawPrimitive() call, you are at least one order of magnitude below the point where you will be able to get any kind of performance.I''d aim for THOUSANDS of quads per DrawPrimitive call if at all possible.Try combining multiple small textures into several larger ones to improve the chance for batching.;  Actually no, I''m not doing a particle system (at the moment at least) I''m just trying to make an efficient wrapper for rendering textured quads for doing 2D graphics (i.e. no DP/DIP for one quad, no DPUP/DIUP calls, etc). Doing a 2d game wouldn''t have that thousands of quads at once, unless I was implementing particle effects and such.I''ll try that adding functionality to my texture manager to combine small textures together. ;  I would go with a scene graph and reorder the objects in a render method. This way the user of the system does not have to care.By not using the 3d coordinate system you can actually skip all transformations - just set the screen cordinates, and render. ;quote:Original post by thona  I would go with a scene graph and reorder the objects in a render method. This way the user of the system does not have to care.By not using the 3d coordinate system you can actually skip all transformations - just set the screen cordinates, and render.   What do you mean when you say reorder the objects in a render method? I though a scene graph takes care of that as objects are added.If I didn''t use the 3rd coordinate I may as well be using ddraw!  I''d like to be able to do implement some the features availiable in 3d to a 2d game.