It is way faster to use a small amount of objects and a large amount of polygons, it would allso be better if you renderd all polygons with the same material in one go, this is because for some reason it takes a suprisingly large amount of time to bind textures, shaders and other stuff.

It's all about batches, a batch is basicly a change in the renderstate(Could be a new texture, material, alphamode or something like that) followed by a DrawIndexedPrimitive call(witch basicly means render geometry).
Both of these are timeconsuming.
A 1GHz computer can make around 25000 batches per second if you use 100% of the cpu for graphics, at 60fps you get 416 of them per frame, so do you want to waste them on small tiny objects or big ones with lot's of polys.

In the real world though the numbers change a bit
a 2GHz cpu, using 20% for graphics at 30 fps results in 333Batches/frame.

Just thought you should know.

Wow thanks...

I made another test with 6 objects and about 52 000 polygons, it renders almost like the 350 objects with 15 000 polygons, at 140fps to be more precise.


I thought as well that changing states and objects take more time.

#1-But now I`m wondering about how could affect something like a rendition sorting ? Arrange objects in the rendering state complexity :D from just colors to 4 texture units polygons, it might sound interesting ? anyone tested it ? :)

#2-Another thing I`m questioning->Check previous material;if it sounds like the curent one, it keeps the rendering state(and so saving some time right ?) else change the state, in a sorthing algo you`d only check one after another and have full performance. Just had these ideas :D

#1 - Interesting, could work under the right circumstances and if you only have one material per object, but it's fairly useless if you use what i am going to suggest in #2.

#2 - But it's better to keep materials separated from objects, this way you call a material and then render all geometry that has it.
This is because it's better(and faster) to traverse trough huge arrays of objects and polygons multiple times, rejecting those that does not have the correct surface than doing it on a per object basis.
Doing this you could still have 350 objects(if they have the same surfaces) and have it render at the speed and polycount of those 6 objects with 52000 polys

[Edited by - lc_overlord on February 2, 2005 7:20:24 AM]

As I said before, I`ve already written code for the "render all objects under this material";and, still, after this one, you could make that sorting or at least have own code with curent state, and only change it if the state changes, but still why does texture binding takes so much time ?

#3-Another thing I was meditating yesterday. Let`s say I compile in a display list some glBegin()/glEnd() code with only calls to glVertex3f for example. If I set some glTexCoordPointer() and bind a texture, then call display list, should I see something textured ? or it`s already "dead" without any texturing ?