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!

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

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.

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

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

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

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.

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).

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.

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org