Analyze performance for static geometry and material

Anything and everything that's related to OGRE or the wider graphics field that doesn't fit into the other forums.
Post Reply
User avatar
akilar
Greenskin
Posts: 138
Joined: Wed Jun 20, 2007 11:42 am
Location: Taiwan
x 17
Contact:

Analyze performance for static geometry and material

Post by akilar »

Object Count:   50*50
Mode: Release
CPU: Intel(R) Core(TM)i5-2400 CPU @ 3.10GHz 3.10 GHz
RAM: 8.00 GB
VGA: NVIDIA GeForce GTX 560 Ti

1. The same material and convert to a static geometry,FPS:1731
Image
2. Unique material and convert to a static geometry,FPS:28.9482
Image
3. The same material and object mode,FPS:68.5509
Image
4. Unique material and object mode,FPS:26.4973
Image

welcome to my blogger, thanks. :D
http://makedreamvsogre.blogspot.com/
AgentC
Kobold
Posts: 33
Joined: Tue Apr 24, 2012 11:24 am
x 5

Re: Analyze performance for static geometry and material

Post by AgentC »

What kind of object did you use? (how many vertices/triangles) Though I guess it has not much significance, as it's likely the CPU draw call cost which we're largely seeing.

Anyway, just for fun here's similar stats, with 50 * 50 objects, for a well-known indie-friendly commercial engine, as well as another open source engine. In these tests the object was a simple cube, and material was almost as simple as possible (diffuse texture + color modulation.) Conversion to static geometry was not readily available, so only individual object mode was tested. Of course it's rather unscientific as it would be better to measure ms, not FPS, and it's not by a long shot guaranteed that the rendering processes are equivalent, but the assumption is, due to the huge variance in framerate, that again we're mostly seeing CPU overhead. The positive thing to take from this is that it should be entirely possible for Ogre2.0 to reach a quite vast speedup even in individual object rendering. The open source engine in question does not use SIMD or data-oriented optimizations.

CPU: Intel Core i7 @ 2.0 GHz
RAM: 8 GB
GPU: GeForce GT 540 M

Engine #1 (commercial)
1. Not available
2. Not available
3. Same material, individual objects, FPS: 190
4. Unique material, individual objects: FPS: 35

Engine #2 (open source)
1. Not available
2. Not available
3. Same material, individual objects, FPS: 432
4. Unique material, individual objects, FPS: 150
User avatar
akilar
Greenskin
Posts: 138
Joined: Wed Jun 20, 2007 11:42 am
Location: Taiwan
x 17
Contact:

Re: Analyze performance for static geometry and material

Post by akilar »

thanks for you Response.
AgentC wrote:What kind of object did you use? (how many vertices/triangles) Though I guess it has not much significance, as it's likely the CPU draw call cost which we're largely seeing.

Anyway, just for fun here's similar stats, with 50 * 50 objects, for a well-known indie-friendly commercial engine, as well as another open source engine. In these tests the object was a simple cube, and material was almost as simple as possible (diffuse texture + color modulation.) Conversion to static geometry was not readily available, so only individual object mode was tested. Of course it's rather unscientific as it would be better to measure ms, not FPS, and it's not by a long shot guaranteed that the rendering processes are equivalent, but the assumption is, due to the huge variance in framerate, that again we're mostly seeing CPU overhead. The positive thing to take from this is that it should be entirely possible for Ogre2.0 to reach a quite vast speedup even in individual object rendering. The open source engine in question does not use SIMD or data-oriented optimizations.

CPU: Intel Core i7 @ 2.0 GHz
RAM: 8 GB
GPU: GeForce GT 540 M

Engine #1 (commercial)
1. Not available
2. Not available
3. Same material, individual objects, FPS: 190
4. Unique material, individual objects: FPS: 35

Engine #2 (open source)
1. Not available
2. Not available
3. Same material, individual objects, FPS: 432
4. Unique material, individual objects, FPS: 150
Post Reply