Performance problems

Hey guys.
Here's the situation :
I'm on a Core 2Duo E7500@2,93GHz, 4Gb RAM, Quadro4000, Windows 7 64.
I'm creating a scene with 4 cameras and 10000 boxes (simple cubes) stored 100x100 on 2 levels loaded from a cached geometry, with a color and no texture.
It takes 15-20 seconds to have the first rendering of each camera, and seconds to refresh when a box moves.
I'm using jreality, and I'm wondering if with raw jogl the same scene would work faster, or if I'm hoping for too much with such requirements.
Thanks for the help guys.

Hi Tiofred,

I've run tests on my Core2 Quad @2.4GHz, 8GB RAM, GeForce 8800 GTX, Windows 7 64, and I get about 15 million colored, non-textured triangles per second when I use vertex buffers as described at http://wadeawalker.wordpress.com/2010/10/17/tutorial-faster-rendering-with-vertex-buffer-objects/. This is re-copying the whole vertex buffer to the card every frame, so if the geometry wasn't changing, it would be much faster.

For your scene on my machine, 10,000 boxes means 6 * 2 * 10,000 = 120,000 triangles, so with one camera I'd expect 15M/120K = 125 frames/second. With four cameras, 125/4 = 31.25 FPS.

The fact that you're getting many-second delays from a scene with only 120K triangles in it seems to imply some algorithm or data structure problem, rather than an OpenGL API or hardware problem  Have you tried profiling your application to see where the time is being spent?

Hi!

I agree with Wade, I think that there is a real lack of optimization in JReality even though it is a powerful scientifical viewer.

Hi guys, thanks for the answers.
I've made a new test where I do :
ap.setAttribute(CommonAttributes.EDGE_DRAW, false);
ap.setAttribute(CommonAttributes.VERTEX_DRAW, false);
on each cube. I guess that simplify rendering.
And the speed is much better, I create the scene, then add the cameras and they display in 5, 8, 11 and 15 seconds.
When I animate, fluidity is better still not perfect yet.

When I do the scene creation, I don't use much memory or CPU, but when I create the cameras, it begins to suck CPU and memory up.

I can provide a working sample of my code if needed.

I'll have it working the speed of light some day...

Wade : thanks a lot
Julien : merci cher compatriote

Actually, when those attributes are set to true, jReality uses GL_LINES and GL_POINTS, drawing these primitives can be very slow and is badly handled with shaders. On some graphics cards it is even not accelerated.

jReality uses a lot of display lists. Nowadays, they are badly implemented, the most accelerated paths use VBOs.

As the problem is related on jReality, maybe its users might help you better than us.


De rien cher compatriote.

Thanks Julien.
This problem has been posted in the jreality forum, gunn helped me a lot already.
Btw, I'm using latest version of jogl (2.0 rc2), is that fine?
Thanks guys.

> jReality uses a lot of display lists. Nowadays, they are badly implemented, the most accelerated paths use VBOs.

Contrary to popular belief VBO's aren't the fastest way to submit static geometry to the GPU. Display list are just fine or even better "the fastest way to send geometry" to the GPU (at least on NVidia GPU's). Take a look here for further details: http://www.gputechconf.com/page/gtc-on-demand.html#session2127 (slide 101).

So "jreality using display lists" isn't the bottleneck here. Maybe stg else is wrong with jreality or the code ...

Actually, the main problem is that the performances of the display lists compared to VBO are very different on all hardwares supporting both, it is not a popular belief. On ATI Radeon 9250 Pro, it depends on the size of the data set, when it becomes "big", compiled vertex arrays and static VBOs are faster, otherwise display lists are faster. On some other more recent graphics cards, I observed different results. VBOs were a kind of revamping of the whole API, display lists have been worsely implemented as time goes by except on some consumer and professionnal graphics cards whereas there is no such problem with vertex arrays and VBOs except on a very few OpenGL 1.5 compatible Intel chips.

Your slide only concerns NVIDIA.