No fps dependency on polygon count (sphere resolution) on i7, i5

Hey guys,

maybe someone can tell me where this strange behave is coming from?

For bench tests i set a fixed value of spheres (for example 5000 spheres) with different resolution.
Testing:

first: rSampel=zSample=10 >> 160 triangles/sphere
second: rSampel=zSample=20 >> 720 triangles/sphere
third: rSampel=zSample=30 >> 1680 triangles/sphere

So I have 3 test with:

5000x160=80.000 polygons
5000x720=3.600.000 polygons
5000x1680=8.400.000 polygons

I had expected a decrease of FPS with increasing polygon count.
It was indeed this case on my laptop with Win7

CPU: Intel Core Duo CPU L7500, 1,6 Ghz
RAM: 4 GB
GC: Intel GL960/GM965 Chipset
OpenGL: 2.0

But on other hardware with

CPU: i5 or i7 (OpenGL: 4.5 or higher)

the FPS being equal and seem to be dependent only on the number of objects and not by the number of polygons.

Only increase the number of sphere slow down the FPS independently from the sphere resolution.

I’ve tested this on windows and mac os machines.

I suspect a connection with the integrated GPU from CPU but I can not really explain it to me. :neutral_face:
Maybe it’s also an effect of the used openGL version? I really don’t know :confused:

For some help or suggestions I would be very grateful.

Your EsKay. :}

Your GPU can apparently handle all of the polygons you are throwing at it. Note: if the driver is good then often the occluded triangles are completely thrown away. Also note that half the triangles in your spheres are facing away anyway and will also be early-eliminated. So in the 8.4 million case you can feel like you are only rendering 4.2 million even before depth occlusion happens.

More objects = more draw calls = more full round trips to the GPU plus on the CPU side culling, etc… It will have a lot more effect on frame rate many times. This is why batching is such a good optimization strategy.

1 Like

I know that number of draw calls and fillrate are the limiting factor on today’s hardware.
The number of draw calls is 5000 in each test.
The fillrate is the same (almost the same number of pixels on the screen for each).

You should still wait for the more knowing people like pspeed to answer this question.

1 Like

Thanks @pspeed and @Ogli That makes my understanding of this behavior better :3

@psspeed possibly you can me say a few sources where i can read more about this topic? Or which key points i can use for browsing the internet for that topic? :slight_smile:

Batching
means that you have only one draw call instead of many.
Example: All your spheres are static (don’t move) and use the same texture / material. Then you can use GeometryBatchFactory to create one batch from those spheres. See this article: http://wiki.jmonkeyengine.org/doku.php/jme3:intermediate:optimization

Instancing
is another optimization (see e.g. this thread: Best way to display large number of objects). Instances can have moving objects and sometimes different materials (if done cleverly).

Thx for explaning batching for me :slight_smile: In my application objects where set by user action with different unshaded matrials :smile:

The bench testing set alot of spheres for checking how many such object can be set from user until the performance suffers.

I only couldn’t explain why in poorer hardware appeared a dependency on polygon count, but on better hardware this dependency was only on the number of objects ^^

The bottleneck with “call draw” make sense now for me and explain the bench results.

In practice, my application won’t need more than 200 objects :3

Nevertheless i will read your interesting links through! There’s a lot of stuff i still have to learn :3

Also read up texture Atlas and vertex painting.

Both are techniques to combine multiple objects into one (and then have the UV pick another texture or color incase you don’t have textures at all)

Sorry to stealthily abuse your thread to post a question of mine:
Should I expect GeometryBatchFactory.optimize to reduce the amount of objects reported by the statsView?
Looking at statistics, any rendered object augments that number… so I’m wondering why optimize doesn’t seem to influence that number of objects statistics, here. Not saying it’s bugged or anything, just trying to reassure myself ^^.

yes.

Something must be wrong, and you should post your code. But maybe in another thread indeed.

1 Like

Thx for the answer! I guess I’ll have to investigate some more. I’ll make a new thread if something interesting (which I doubt :D) comes up.

edit: ok, I did more testing and it’s working in my code as it should… just very wrong checking on my side… sorry for that.