next »

[Marvin Fröhlich]

I ahve introduced a new OpenGLStatesCache for the internal render code. It is used to avoid unnecessary JNI calls. I didn't use it everywhere so far, but just in the geometry render code. But it already boosted the Q3FlightTest by 20% in LWJGL in Windows. For some strange reason it didn't do very much for JOGL in Windows. On Linux both LWJGL and JOGL are boosted.

I will proceed the states caching in the next days. Let's see, how much it brings.

Marvin

[Marvin Fröhlich]

More boost!!!!

I had a day with YourKit. It is really great. It helped me to improve performance by far.

Another boost gave a slight redesign of OpenMaLI's bounds implementation, which needed a little API change. The getCenter() method (with no parameter) doesn't exist anymore. It was slow. I removed it to ensure, that nobody (including me) uses it by accident at critical places. Use the getCenterX(), getCenterY() and getCenterZ() method instead or the getCenter( Tuple3f ) one.

All in all the Q3FlightTest runs over 50% faster now (relative the yesterday). Relative to three days ago it even runs 100% faster. No lie!. Just try it out.

Another tweak, that doesn't do anything for the Q3 test, is the following:
If you have nested groups and one group is totally inside the view frustum, the inner nodes don't need to be further culled, since they are implicitly fully inside the frustum, too. Previously they were culled, which I have fixed now. So, if you have nested groups (like with a pseudo-OcTree/QuadTree implementation) you will notice another performance gain.

Another tweak, that I have enabled manually just for the Q3 test is, that I have disabled the user-defined clipping planes for the main RenderPass. Handling the Clipper or ScissorRects is expensive for the whole RenderPass with the current implementation. So, if you don't need it, disable it through:

Code:

renderPass.setClipperEnabled( false );

Please see my next Thread in the Developer Discussion forum about the Clipper.

Marvin

[Marvin Fröhlich]

I got some more percent of a boost. only 6-10% this time. But hey...

I also found the solution for the DisplayLists problem in JOGL. So DLs are now usable in JOGL again.

On Linux the Q3FlightBenchmark is now equally fast on LWJGL and JOGL. Could please someone test it on Windows?

Marvin

[Marvin Fröhlich]

And yet another 15% speed boost. We are moving forward .

Marvin

[Marvin Fröhlich]

This is a bug one again. About 15-20%.

As you can read here I have tweaked JAGaToo's logging system. This is a log faster especially when the logging is used in critical code sections like the rendering code.

Marvin

[Marvin Fröhlich]

This one is impressive. I have completely rewritten the DisplayLists render code. And while tweaking and trying I found out, that it is much faster to first compile a DisplayList and then call it (instead of doing this in the same OpenGL call). Together with some other good tweaks I got another 54% boost in the Q3 flight bench. Yesterday I got 268 FPS, today it's 413. This is faster than the jMonkeyEngine by +33% !

Check it out.

Next time you will get improved VBOs.

Marvin

[kukanani]

This is faster than the jMonkeyEngine by +33% !

WOW!  Marvin > entire jMe Dev Team

[Pandaemonium]

Marvin scores a critical hit on jMonkeyEngine. This is seriously impressive Marvin!

WOW!  Marvin > entire jMe Dev Team

lol.

[Marvin Fröhlich]

I got another 15% boost by improving texture-unit-state-change-cache .

Marvin

[kukanani]

Wow, The boosts just keep on coming...   Good Job!

[Pandaemonium]

I got another 15% boost by improving texture-unit-state-change-cache .

Marvin

Yet another reason why people should work from SVN instead of the released jar. 

[Marvin Fröhlich]

I have finished the interleaved-VBO patch. VBOs are still by far slower for 100% static geometry, but they are also by far faster than before .

You can switch to interleaved VBOs by using the makeInterleaved() method of GeomComponent (which is the base class for all Geometry classes).

You should use the makeInterleaved() method before you write any geometry data, since otherwise the interleaved nio buffer would be created after all the non-interleaved buffers were created, which means some unnecessary time and GC.

But you should not use interleaved VBOs, if your geometry is not static (if you e.g. want to change the texture coordinates, while the rest of the geometry data remains unchanged).

Marvin

[Marvin Fröhlich]

I found the reason for the strange State-Sorting behavior. It seems, that the order of applying states is important. Currently The Q3FlightTest is running 45% faster than the jMonkeyEngine.

And I found a problem with RenderToTexture. The RenderBuffer was always used and it is not needed at all (currently) It appears to be very expensive to bind a RenderBuffer. Disabling it makes the RenderToTextureTest faster by about 350%. The TerrainTest5 is running twice as fast as before now.

Marvin

[BrazilianBoy]

I found the reason for the strange State-Sorting behavior. It seems, that the order of applying states is important. Currently The Q3FlightTest is running 45% faster than the jMonkeyEngine.

Well, I think it's official: Xith3D is much faster than JME. Actually, is there a scenegraph faster than Xith?


Lucas.

[Marvin Fröhlich]

Well, I think it's official: Xith3D is much faster than JME. Actually, is there a scenegraph faster than Xith?

I don't know many of the available Java scenegraph engines. But AFAIK the only meature engines besides Xith3D/jME/Java3D are Ogre and Irrlicht/BindenLicht. But I don't know, how fast they are.

Marvin