Login

1

Lightweight Java Gaming Library / Cant launch JLWGL Examples ?.

« Last post by jackyjoy123 on April 12, 2021, 14:09:41 »

Hello,

aybe im blind .... but i havent found any Example that shows somthing Grafiic related in the jlwgl libs for download. The OpenAL Demos were launched with no prob. If i try to launch the OpenGl related Demos allways a ClassNotFoundExceptions were thrown, but i  have downloaded all possible Files from the website?


thanks
jackyjoy

2

OpenGL / Re: vec3 and floats in UniformBufferObjects using std140 layout

« Last post by KaiHH on April 11, 2021, 15:54:41 »

Am I right in believing that the start offset of any variable has to be a multiple of its alignment?

Correct.

What is the alignment of mat4 and mat3 and what about vec2?

mat4 is treated as four separate vec4's. So, the alignment of a mat4 is like that of a vec4, which is 16 bytes. And the size of a mat4 is 4*sizeof(vec4) = 4*16 bytes.
mat3 is treated as three vec4's. So, alignment is 16 bytes and size is 3*16 bytes. So, you cannot pack a float as the w-component of the last column of a mat3.
vec2 has alignment 8 bytes and size 8 bytes.

See: https://sotrh.github.io/learn-wgpu/showcase/alignment/#alignments

3

OpenGL / Re: vec3 and floats in UniformBufferObjects using std140 layout

« Last post by karlchendeath on April 11, 2021, 15:48:39 »

Okay i think i got it am i right in believing. That the start offset of any variable has to be a multiple of it's alignment.
one question for calarification about alignments
vec3 have a alignment of 16 the same as vec4
what is the alignment of a mat4 or mat3 and what's about vec2 i believe i saw somewhere that it should be vec2 is that correct?

4

OpenGL / Re: vec3 and floats in UniformBufferObjects using std140 layout

« Last post by KaiHH on April 11, 2021, 15:29:12 »

Understanding GLSL layout rules can be a bit tricky at first, yes. Generally, there is a difference between the size of a data type and the alignment requirements of the data type.
For example: The size of a vec3 is three floats, so exactly 12 bytes. But the alignment is 16 bytes.
The alignment dictates, at which multiples of a byte the next value for a given type may begin. The alignment of a vec3 is 16 bytes, so whenever you declare a vec3, it will be padded before the vec3 starts to make sure that the vec3 value begins at a multiple of 16 bytes.

Example:

Code: [Select]

struct {
  float a;
  vec3 b;
}

Here, the float will start at offset 0 bytes, but due to the alignment requirements for a vec3 (which is 16 bytes), there will be a 12 bytes padding after the float and before the vec3.
So, effectively, the float will become a vec4, of which only the first component is actually used for the float. And after the 16 bytes (4 bytes of float and 12 bytes of padding after the float), there will be the vec3 b.

So, in this particular case, it is more space-efficient to redeclare the vec3 b before the float a:

Code: [Select]

struct {
  vec3 b;
  float a;
}
In this case, the alignment requirements for all struct members' data types are naturally fulfilled: The vec3 starts at offset 0 (which is a multiple of 16, namely 0).
And the float b starts at offset 12 bytes, so directly after the vec3's size (which is 12 bytes).
Float itself has an alignment requirement of 4 bytes, so it can start right after the 12 bytes of the vec3.

Another example:

Code: [Select]

struct {
  vec3 a;
  vec3 b;
  float c;
}
Here, the vec3 a starts at byte 0. And, since vec3 has alignment requirement of 16 bytes, the vec3 b will start at byte offset 16. So, the vec3 a will be padded with an additional 4 bytes after it, because the next vec3 b cannot start at byte offset 12, since that would violate its alignment requirements. The float c itself has alignment requirements of 4 bytes, so can start right after the vec3, so at byte offset 16+12 = 28.

So, it's never about the size of a data type, but only about the alignment requirements (where the next instance of a particular member of that data type may start/begin).

5

OpenGL / vec3 and floats in UniformBufferObjects using std140 layout

« Last post by karlchendeath on April 11, 2021, 15:19:44 »

Hi, so i have been playing around with uniform buffer blocks for a while know, but i always avoided vec3 by using vec4 because for them i understood that with vec4 every vector should have 16 bytes. Now iam accually need to work with vec3 and for my understanding in std140 everything is a multiple of 4 of its underlying type so i assumed that a vec3 should therefor have 16 bytes alloceted, but for some reason this doesn't work.

I create my UBO using this Code:

where layout is a String[] with something like this {"mat4 view", "mat4 proj"} for a simple uniformBlock with the view and projection matrix (in order)
and uniformOffsets is a HashMap<String, Integer>

Code: [Select]

        int uboByteSize = 0;
        for (int i = 0; i < layout.length; i++) {
            String[] split = layout[i].split(" ");
            if (split.length != 2) throw new AspectLayoutException("illegal ubo layout");
            final String varType = split[0];
            final String varName = split[1];

            int baseAlignment;
            int count;

            switch (varType) {
                case "mat4":
                    baseAlignment = 16;
                    count = 4;
                    break;
                case "vec4":
                case "vec3":
                    baseAlignment = 16;
                    count = 1;
                    break;
                case "float":
                    baseAlignment = 4;
                    count = 1;
                    break;
                default:
                    throw new AspectLayoutException(varType + " is not defined");
            }

            int aligned_offset = (int) Math.ceil(uboByteSize / baseAlignment) * baseAlignment;
            uboByteSize = aligned_offset + baseAlignment * count;

            uniformOffsets.put(varName, aligned_offset);
        }

        System.out.println(uniformOffsets);

        ID = glGenBuffers();
        glBindBuffer(GL_UNIFORM_BUFFER, ID);
        glBufferData(GL_UNIFORM_BUFFER, uboByteSize, GL_DYNAMIC_DRAW);
        glBindBuffer(GL_UNIFORM_BUFFER, 0);

when updating uniforms i use depending on the type. something like this:

Code: [Select]

        //load a matrix4f (mat4) in the uniform buffer.    mat4 is the Matrix4f to load in the ubo
        Integer offset = uniformOffsets.get(uniformName);
        if (offset == null)
            throw new AspectGraphicsException("can't uniform " + uniformName + " in this uniform block");
        float[] mat4_array = new float[16];
        mat4.get(mat4_array);
        glBindBuffer(GL_UNIFORM_BUFFER, ID);
        glBufferSubData(GL_UNIFORM_BUFFER, offset, mat4_array);
        glBindBuffer(GL_UNIFORM_BUFFER, 0);

So when i use this code with vec3 i get for my understanding the correct result of offets
for a ubo with std140 (16 bytes per vec3):

Code: [Select]

layout(std140, binding=3) uniform mat{
    vec3 albedo;
    float metallic;
    float roughness;
    float ao;
}

i would use the code above with layout = {"vec3 albedo", "float metallic", "float roughness" , float "ao"}
and when i would look at the uniformOffsets map i get this:
{roughness=20, metallic=16, ao=24, albedo=0}.

Maybe it's just my understanding about std140, but in the shader the stuff that load in the ubo is not correct
albedo is obviously right, but there the offeset is obvious. The rest metallic, roughness, ao have some weird values when running the shader.

If you need more information, just ask =^). Thank you

6

OpenGL / Performance issue when swapping buffers

« Last post by vesa1995 on April 10, 2021, 17:12:40 »

At the end of my render code I call glfwSwapBuffers(), it is a GLFW function which swaps back/front frame buffer. I surround that call with my performance measuring code:

performance.start();
GL11.glSwapBuffers();
performance.end();

My update_interval is 0.008333333 sec, which is 1/120 sec (120 FPS). Once per minute, it takes about 10*update_interval to glSwapBuffers() to unblock.
My vsync is off via glfwSwapInterval(0). Follow up question, how to check if my vsync is really off?

Can anyone please give me an idea why is this happening, if you need more information I will provide it. Please help, thanks.

7

OpenGL / Re: Share VBOs between contexts

« Last post by filocava99 on April 09, 2021, 16:00:57 »

The solution is to use the sharing parameter of the GLFW's glfwCreateWindow function. You must call such method from the main thread, otherwise glfw will fail to create an opengl context.
I figured it out thanks to a stackoverflow user

8

OpenGL / Share VBOs between contexts

« Last post by filocava99 on April 09, 2021, 14:41:11 »

Hi. I'm trying to buffer data from a context and rendering them from another. The problem is that I get an access violation exception when I try to buffer the data from the second context.
The main context is the one that renders the VAOs, the second one only calls glBufferData to load vertices, normals and uvs and then the main context bind them to a VAO.
I created the second context the same way I created the first one, except that I don't show the window.
Here's my window class that also create the context: https://pastebin.com/yzqtHsRn
I know it's in Kotlin but it is easily understandable.
From  what I've learned only VBOs are shared between context, that's why I'm binding them to the VAO in main context.
The main context can call glBufferData without any exception, so I think the issue is in the second context creation.
What do you think?
Before you ask, I have to use a second context because the glBufferData calls make the game freeze for too many milliseconds (i'm loading tiles of terrain procedurally generated while the player moves)

9

General Java Game Development / Importing and Using LWJGL3 with Ecplise

« Last post by Deanz on April 09, 2021, 11:51:14 »

Hey guys.
Newest as can be, wanna pick up a new hobby, so I wanna tinker a bit with lwjgl.
anyway, sorry in advance for TLDR but:

-> I downloaded all needed jars, sources, docs, natives,
-> I created a new User Library in Ecplise, importing all the necessary jars, and attaching the sources and javadocs as needed.
->  I created a project and added the new User Library to the build path.

So far so good,
Then I tried running the example code from https://www.lwjgl.org/guide,
now I can import lwjgl.* and it even identifies it (I see information tooltip while hovering over the import in eclipse), allowing me to jump to source and whatnot,
but can't use any functionality because everything throws "NoClassDefFoundError",

this is the exact error I get when trying to run (with no errors / warnings prompted by eclipse prior to running):

Code: [Select]

Exception in thread "main" java.lang.NoClassDefFoundError: org/lwjgl/Version
at HelloWorld.run(HelloWorld.java:20)
at HelloWorld.main(HelloWorld.java:112)
Caused by: java.lang.ClassNotFoundException: org.lwjgl.Version
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:606)
at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:168)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
... 2 more

Looking at the project explorer, I can see all the lwjgl within the user library I created, and I can jump to source, but can't seem to run it,
what am I missing? I got all the class files, but eclipse doesn't seem to recognize... or care

Thanks guys!

10

Lightweight Java Gaming Library / Minecraft keeps throwing and error when launching it in my own launcher

« Last post by Luckstern on April 06, 2021, 12:48:50 »

I'm trying to make my own Minecraft launcher, and it works really well with newer versions. The problem is that older versions, like 1.8.9, keep throwing an error.

ERROR:

Code: [Select]

Exception in thread "main" java.lang.UnsatisfiedLinkError: org.lwjgl.DefaultSysImplementation.getPointerSize()I
at org.lwjgl.DefaultSysImplementation.getPointerSize(Native Method)
at org.lwjgl.Sys.<clinit>(Sys.java:118)
at ave.J(SourceFile:2539)
at net.minecraft.client.main.Main.main(SourceFile:41)

Also, I'm making the launcher in Python, though that isn't the problem as the error is with the getPointerSize() method in LWJGL. One thing is, older versions of Minecraft use LWJGL 2 while newer versions use LWJGL 3, but if I use the normal Minecraft launcher, it works perfectly fine.