Hello Guest

Recent Posts

Pages: [1] 2 3 ... 10
1
OpenGL / Re: Java FloatBuffer in C++ (i know that is a dumb question)
« Last post by KaiHH on April 16, 2021, 11:58:00 »
If you knew C++, then you'd also know that there is no such thing as a FloatBuffer.
And you'd also know the C signature of e.g. glBufferData:
Code: [Select]
void glBufferData( GLenum target,
  GLsizeiptr size,
  const void * data,
  GLenum usage);
and know that you are supposed to pass your data directly as the (const void*) argument.
2
OpenGL / Re: Java FloatBuffer in C++ (i know that is a dumb question)
« Last post by Electronics Boy on April 16, 2021, 11:52:47 »
Oh ok, thx, i actually know C++, but, i did not know that you can use a float[] isted of a FloatBuffer, thx btw  :)
3
OpenGL / Re: Java FloatBuffer in C++ (i know that is a dumb question)
« Last post by KaiHH on April 16, 2021, 11:49:19 »
The C++ equivalent of:
Code: [Select]
float[] data = {1.0f, 2.0f, 3.0f};
FloatBuffer buffer = BufferUtils.createFloatBuffer(data.length);
buffer.put(data);
buffer.flip();

is (drumm-roll):
Code: [Select]
float data[] = {1.0f, 2.0f, 3.0f};

You are basically asking "Please, teach me C++".
You should look elsewhere.

If you use OpenGL and search for a good OpenGL tutorial using C++ and GLFW, then: https://learnopengl.com/
The "Hello Triangle" section also has the code for uploading a float array into an OpenGL buffer object: https://learnopengl.com/Getting-started/Hello-Triangle
4
OpenGL / Re: Java FloatBuffer in C++ (i know that is a dumb question)
« Last post by Electronics Boy on April 16, 2021, 09:59:10 »
Can someone replay?
5
OpenGL / Java FloatBuffer in C++ (i know that is a dumb question)
« Last post by Electronics Boy on April 16, 2021, 05:10:43 »
ok, so i used LWJGL3 in Java, but now, i want want to code in C++ using GLFW, and for rendering, i want to use VAOs and VBOs as it is the new rendering way, but, i dony know how to do it, can home one help me? plz?


Code (Java(i Need it in C++)):
private FloatBuffer storeDataInFloatBuffer(float[] data) {
   FloatBuffer buffer = BufferUtils.createFloatBuffer(data.length);
   buffer.put(data);
   buffer.flip();
   return buffer;
}
6
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
7
OpenGL / Re: vec3 and floats in UniformBufferObjects using std140 layout
« Last post by KaiHH on April 11, 2021, 15:54:41 »
Quote
Am I right in believing that the start offset of any variable has to be a multiple of its alignment?
Correct.

Quote
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
8
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?
9
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).
10
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
Pages: [1] 2 3 ... 10