a non-debug precompiled version [withdrawn]

OpenGL Development
#1

In my game-engine, I have lots of nature: bushes, trees, grass, etc. All these are items which get rendered by a couple of VBO calls. The ‘problem’ is that the amount of checks for the VBO-calls is huge, there are even stacks and switch-statements inthere. When rendering thousands of items per frame, this overhead begins to count. My solution is to group geometry of multiple-items into 1. This works, but makes the engine much more complex, because of all the managing.

I heard matzon say in another thread that LWJGL was precompiled by default in debug-mode. I have to admit that I don’t know C/C++, nor do I know how to compile dynamic-libraries, so that pretty much leaves me asking somebody for a favor. It would be nice to have non-debug precompiled libraries on the official LWJGL site, or made available by anybody who would like to share their non-debug version of LWJGL with this community.

Thanks in advance!

#2

this could probably be automated in the build script - I’ll talk to elias about this and see if we can work something out

#3

Hi Riven,

I’ve found that OpenGL pseudo-instancing helps a lot when you’re CPU bound (if you can afford to use vertex shaders). I’ve seen up to 50% speed-ups when rendering thousands of low-poly objects in Marathon. Removing VBO checks from LWJGL might improve things a bit, but I wouldn’t expect anything dramatic.

#4

I know, a few percent speedup would be nice.

Further, my engine has never been CPU-bound :wink:

I’ll investigate “psuedo instancing”, I never heard of it.

I also found that reducing the polycount of a VBO below a certain value (under 75 on my card), won’t increase performance anymore. So in the end I might have to do geom-grouping anyway, whatever overhead LWJGL has. Or do that “pseudo-instancing” or yours, whatever it may be :slight_smile:

#5

I talked to elias about this:
http://echelog.matzon.dk/logs/browse/lwjgl/1135675132
at around 13:00

Would it be possible for you to get some numbers so that we bay actually evaluate the feasability of doing 2 builds

#6

[quote=“Riven,post:4,topic:25660”]
Under 75 polygons, you are CPU bound. Also, no matter the scene you’re rendering, the CPU always affects the frame rate to a certain degree.

Pseudo-instancing is very simple actually. Instead of changing the modelview matrix for every object in the scene, you only load the view matrix at the beginning of the frame and then pass the model matrix individually for every object. The trick is to pass the model matrix as a bunch of “persistent” vertex attributes. Because the modelview matrix is not changing, the driver doesn’t have to “touch” the shader code for every object and that’s where the speed-up comes from.

Go here for details and sample code (search => pseudo).

I’ve also found that this can be applied to other uniform values too. So, for example, instead of defining a model-space light position as a uniform, it’s faster to pass it as a vertex attribute. Btw, because of the above model matrix trick, you end up with a vertex position in world-space inside the shader. This is actually very convenient and saves some instructions when you’ve got to do shadow mapping or calculate an eye vector (for specular, parallax, etc).

#7

Thanks for the above. Let’s get back on topic:

The LWJGL overhead is only noticable when rendering a lot of tiny items. Ofcourse reducing the overhead will increase performance by a few percent, but I think the true optimisations will have such a dramatic increase in performance that it might not be worth it to work on the tiny overhead.

Besides that, there will be a massive increase of posts on this forum, about native crashes, when newbies deploy the ‘release-version’ without thinking of the side-effects.

Considering all that, I withdraw the request.