LWJGL 3.1.5

Engines, Libraries and Tools
#1

LWJGL 3.1.5 has been released!

edit: This post was originally about 3.1.4. The build published to Maven Central was incompatible with Java 8, so it had to be replaced quickly with a new version.

3.1.5 release notes
3.1.4 release notes
Download

You can now contribute to LWJGL by becoming a backer on Open Collective with a monthly/yearly/one-time donation to the project. The plan is to use donated funds:

  • to cover server hosting & bandwidth expenses (currently ~$30 per month)
  • to cover software & hardware expenses
  • to offer bounties for documentation work (priorities: adding EGL & GLES javadoc, updating GL)
  • to offer bounties for new bindings
  • to offer bounties for new platform ports (priorities: ARM, Android)

Finally, don’t forget to check out the lovely path tracing tutorials created by KaiHH!

#2

I open first tutorial

try look on shader but can’t find it :frowning:

org/lwjgl/demo/opengl/raytracing/tutorial1/quad.vs.glsl
org/lwjgl/demo/opengl/raytracing/tutorial1/quad.fs.glsl
org/lwjgl/demo/opengl/raytracing/tutorial1/raytracing.glsl


no folder tutorial1 and no files in folder tutorial

IMO: Oh my…
Why not use Enums (but its ok for RAW example ^^)


eyeUniform = glGetUniformLocation(computeProgram, "eye");
ray00Uniform = glGetUniformLocation(computeProgram, "ray00");
ray10Uniform = glGetUniformLocation(computeProgram, "ray10");
ray01Uniform = glGetUniformLocation(computeProgram, "ray01");
ray11Uniform = glGetUniformLocation(computeProgram, "ray11");
int loc = glGetUniformLocation(computeProgram, "framebufferImage");

up:
Also be nice to


interface GLEnum{
}
class GLShaderVal{
	int gl_Pointer;
	GL_Enum name;//Or String
	/*
	int val_Cur;
	int val_Wait_Set;
	*/
}
GLShaderVal param = glGetUniformLocation(computeProgram, GLEnum_X_Shader.FramebufferImage);
#3

The convention for Maven-style and also Gradle projects is to separate Java source files from non-Java files (resources). And it’s generally a good style to do that. You’ll find the shaders in /res.

#4

…But, But :persecutioncomplex:
its
org/lwjgl/demo/opengl
not
res/org/lwjgl/demo/opengl

OK - its new fancy technologies ::slight_smile:

#5

In case you don’t see the symmetry here:

  • the package for the Java classes is org/lwjgl/demo/opengl INSIDE /src
  • the package for the resources is org/lwjgl/demo/opengl INSIDE /res
#6

I don’t know this Gradle magic)
Not use it
So when I see
org/lwjgl/demo/opengl/raytracing/tutorial1/quad.vs.glsl
First place where I be looking is current
org/lwjgl/demo/opengl/raytracing/

and its
lwjgl3-demos/src/org/lwjgl/demo/opengl/raytracing/

#7

Is there any chance that there will be EUR donations? For a monthly 2$ subscription my bank will charge me another two just for exchanging the money :S

#8

Better one time donation from time to time then

#9

LWJGL 3.1.4 has been replaced by 3.1.5. See the updated release notes in the OP for more information.

LWJGL 3.1.5 includes AMD Tootle bindings. It’s a library that optimizes geometry to better utilize the vertex prefetch cache and post-transform vertex cache in modern GPUs, while also minimizing overdraw (less fragment shading). Here’s a simple demo, everything is done automatically in two simple function calls. Enjoy!

#10

[quote=“NuclearPixels,post:7,topic:59104”]
Open Collective plans to add more payment options in the near future. If it takes too long, we’ll consider other solutions.

#11

I would really be interested in some runtime performance comparisons with/without tootled meshes. Just curious :slight_smile:

#12

[quote=“h.pernpeintner,post:11,topic:59104”]
I have converted the demo to a before-after benchmarking tool. It looks like this:


http://www.java-gaming.org/user-generated-content/members/4730/lwjgl-tootle-demo.jpg

You set up the geometry to test and optimization parameters, then toggle between unoptimized and optimized mesh (with ‘O’) and see the performance difference. The elapsed time on the upper-right is the GPU time for the 3D mesh only (uses GL_TIME_ELAPSED queries), the HUD rendering does not affect it. Some notes:

  1. The meshes 1-8 are procedurally generated using par_shapes. They already have a low ACMR and cannot be optimized significantly, so are not good for testing. The demo supports loading a custom mesh with Assimp (press <CTRL+O>). Artist-created meshes from a DCC app usually suffer from high ACMR.
  2. If you don’t have a good test mesh, press to shuffle the unoptimized mesh. The geometry is exactly the same, but the triangle order is randomized, resulting in a horrible ACMR close to the worst case (3.0). This should give you a good idea of how bad it can get when the vertex caches are not utilized.
  3. When doing ACMR comparisons, it’s best to turn off rasterization (press to toggle). This will isolate measurement to the GPU vertex processing pipeline.
  4. Overdraw optimization is harder to test. It depends on the mesh having clusters covering other clusters and you also need to be doing significant work in the fragment shader. You may want to edit the shader to do something expensive (e.g. a sin/cos loop). There’s also a trade-off involved, optimizing a mesh for less overdraw usually leads to a higher ACMR. This can be tuned with the alpha parameter of TootleFastOptimize. If you want to test for ACMR only, press F1, it usually produces the best ACMR results.

As an example, with the 512 bunnies in the screenshot above and rasterization disabled:

  • Unoptimized mesh with an ACMR of 2.075 -> 12ms
  • Optimized mesh with an ACMR of 0.689 -> 5.7ms

It’s a fairly dramatic difference, but YMMV. It really depends on the mesh used, but it’s always beneficial and, well, it’s free (can be done offline).

Finally, if you’re on Windows, make sure to download the latest 3.1.6 snapshot. It adds support for Direct3D rasterization when doing overdraw optimization/measurement, which makes Tootle at least 100x faster (hundred x, not a typo).

#13

Thank you very much for your effort! Unbelievable that the difference is that dramatic - I just added a point on my to-check-out list :slight_smile:

#14

There is a bit of a problem with the download website,

The LWJGL 3 custom download site refuses to download zip when JOML is selected. I tested

Chrome console outputs the following error:

[quote]Failed to load resource: the server responded with a status of 403 https://build.lwjgl.org/addons/joml/joml-1.9.7.jar()
[/quote]
Deselecting JOML allows the package to download without any problem.

#15

[quote=“kingroka123,post:14,topic:59104”]
Fixed, thanks!