   multiple glDrawElements calls too slow
  I have an application that divides complex objects in an octree. I've implemented view frustum culling and tested it.I loaded a complex object (around 46 000 polygons). My octree divides it into 8 nodes.If I see a portion of an object which is equivalent to one octree node, I get a significant performance boost. If that portion includes two or more octree nodes my FPS drop lower than expected. It becomes more efficient too render the whole object.Here are some numbers from my testing:Camera is pointed so that I can see only two nodes (two glDrawElements calls), and my application is rendering 17809 polygons out of 46677 - FPS: around 210Same view, but this time rendering all 46677 polygons (one glDrawElements call)- FPS: around 270Different view, only one octree node is rendered (8853 polygons) - FPS: around 380Same view, rendering all polygons - FPS: around 270I've concluded that multiple glDrawElements calls are slowing down my rendering so I implemented glMultiDrawElements instead and got the same result.There must be a solution to this problem. I've registered to this forum because of this. However I've been looking for problem solutions here, and often found an answer...   
  I am not an expert.But what if you made a VBO and attached vertices and indices to this. And updated only the indices when you change what you draw.;Quote:Original post by mrrI am not an expert.But what if you made a VBO and attached vertices and indices to this. And updated only the indices when you change what you draw.I came across that solution, but never worked with VBO. Would that speed things up???   ;  Yes, I think so.   ;  Calling glDrawElements 2 times for rendering 2 nodes vs calling glDrawElements 1 time for rendering 2 nodes?It should not make much of a difference.Perhaps your octree code is costing some CPU time.Get rid of your octree code and compare.   ;  Are you using glDrawElements on vertex arrays? Switch to VBOs. You should see a ridiculously huge improvement.   ;Quote:Original post by V-manCalling glDrawElements 2 times for rendering 2 nodes vs calling glDrawElements 1 time for rendering 2 nodes?It should not make much of a difference.Perhaps your octree code is costing some CPU time.Get rid of your octree code and compare.The problem is not in my octree code, I checked. Really odd thing - when I send 17000 polygons in 22 nodes, I get 310 FPS?!?!I'm trying with VBOs now...   ;Quote:Original post by VVukelicQuote:Original post by V-manCalling glDrawElements 2 times for rendering 2 nodes vs calling glDrawElements 1 time for rendering 2 nodes?It should not make much of a difference.Perhaps your octree code is costing some CPU time.Get rid of your octree code and compare.The problem is not in my octree code, I checked. Really odd thing - when I send 17000 polygons in 22 nodes, I get 310 FPS?!?!I'm trying with VBOs now...Well, this behaviour could be perfectly legal, because there are just too many unknown parameters. Here's a little todo list :-)1. Check if your FPS calculation is correct, use a clock with high resolution !2. Check if your application is NOT pixelshader bound (decreasing screensize improves performance?)3. Check if all drawn triangles are really visible and not culled (camera culling  or backface culling).4. To measure the time correctly you have to flush the command queue. Do something like this:render-pipeline: start_time = Clock::getTimeInMs(); ... render ... // ensure to flush pipeline glFinish(); end_time = Clock::getTimeInMs(); delta_time_in_sec = (end_time - start_time) * 0.001f; fps = 1.0f/delta_time_in_secs;