Vertices, meshes and FPS

Hope someone can help with what might be a dumb newbie question: I have a scene containing about 70 models (ships); each ship is a SharedNode, and I have used DLOD to make three levels of model detail, ranging from about 2000 vertices each to about 500; each model contains the same number of parts (hull, masts, sails), but the parts are less detailed for the distant models.



Now when I have a small number of high detailed models in my scene, I get stats something like:

FPS: 70 Meshes: 1000 Vertices: 40000



But when I look at a large number of low detailed models, the stats are something like like:

FPS: 6 Meshes: 4000 Vertices: 38000



In other words, increasing the number of meshes by four completely hammers the FPS, making it unplayable, even though the number of vertices is about the same or even lower (and I can get decent framerates with 100,000+ vertices, so long as the number of meshes is not too high). My models are all SharedNodes, which I believe means they are also SharedMeshes - is that right? Does anyone know why a larger number of meshes seems to have such a dramatic effect on FPS? Or is it the textures? Each model has the same textures, but the textures are part of the model (3ds) and I haven't been able to figure out how to access the texture from inside the app anyway. Is there some trick I can use to get decent FPS with a large number of models?



Any advice gratefully received.

vertices and triangles are really not the limiting factor (usually) on cards these days.  You are probably running into issues with the update process.  Do you really need to update every model on every frame?

I'd assume it had something to do with the fact it's generally better to send many vertices in one large batch for processing instead of fewer in several smaller batches.



I'm sure someone will come along with a more technical (correct) reply soon  :slight_smile:

OK interesting; yes I do update every frame, but the slowdown only occurs when the distant models are on screen - if I look the other way (at empty sea), FPS goes up to 200+. So does this mean that updates only take effect if an object is on screen (surely not)? Or that if a model doesn't change it doesn't have to be re-rendered? I suppose I imagined that that the screen gets completely redrawn every frame even if nothing has changed, so if models are off screen the amount of computation (in update) would be the same, and it was only drawing it that would take extra time - is this not correct?

Thanks Hal, me too am struggling adding many small items to view at once.



How can items be added to batch please. Or should I just join them up in a node and lock the node.

Well I have done some more tests, and it certainly seems to be the case that vertices/triangles don't matter very much, but number of meshes matters a lot:



FPS: 40    Meshes: 1  Vertices: 249500  Triangles: 498000

FPS: 16    Meshes: 100    Vertices: 990000    Triangles: 1960000

FPS: 21    Meshes: 4000    Vertices: 96000    Triangles: 48000



These tests are all with simple shapes (boxes and spheres), running SimpleGame, and do nothing more than put the items on screen every cycle (nothing happens in update). FPS of 21 doesn't seem very fast - is there a way around this? I had thought that SharedNode was the way to go, but these tests are all using SharedNode (and am I right in thinking that SharedNode also uses SharedMesh?). What is the best way to handle lots of small objects - or is this just something that can't be done?

Obviously making lots of draw calls would slowdown rendering, this is a very known issue with hardware 3D rendering. I suggest that you find some way to significantly lower your meshes/frame ratio, there's really no other way to do this. Try using VBO if you haven't tried it yet. Also try to combining all your ship parts into one mesh and use a texture atlas to access the needed texture for each part. Another thing you can do is reduce the view distance so that models far away are not drawn at all.

Any suggestions here ???



Can anything be skipped in an update ( maybe the whole update) for static things once in a while.




theprism said:

Any suggestions here ???

Can anything be skipped in an update ( maybe the whole update) for static things once in a while.


You certainly don't need to update the visual state of objects not visible, I'd also suggest some kind of "AI LOD" where enemies further away get simpler logic applied (i.e. In a race game just generating a random number to decide if off screen racers crash).