Hello Guest

Recent Posts

Pages: [1] 2 3 ... 10
1
OpenGL / Re: Problem drawing simple quad using orthographic projection matrix
« Last post by Adro on January 19, 2022, 20:19:40 »
Wow I completely get your point. Finally I could draw it! It turns out since my vertex shader is claiming for a vec3, I was missing Z coordinate on the vertex definition, which must be zero. Then I used coordinates in the range of a pixel, scaled the object and positioned it on the origin.
2
OpenGL / Re: Problem drawing simple quad using orthographic projection matrix
« Last post by KaiHH on January 19, 2022, 19:37:17 »
Quote
Because I've seen that usually values are in the interval [0, 1] because the screen takes NDC system.
Effectively, OpenGL only cares about the values that your vertex shader is storing into the pre-defined `gl_Position` variable.
This is in "clip space". Clip space is the same as normalized device coordinates (NDC) space when your vertices' `w` coordinate is 1.0 (which it is for orthographic projections).

HOWEVER you are _not_ providing OpenGL (i.e. its `gl_Position` variable) with 0.0 and 0.5 values, but with hugely scaled-down values more akin to 0.0002604 in the x coordinate (when your screen width is 1920 pixels), because you multiply it with an orthographic projection matrix that has said scaling factor in it, because - as I said before - you _want_ to project all values between [0..windowWidth] and [0..windowHeight] to [-1..1], because this is what you said when you created the orthographic projection matrix.

When you want to see your quad you can simply use an identity matrix as the projection matrix, or come to grips with what you actually _want_ (how your orthographic projection should look like).
3
OpenGL / Re: Problem drawing simple quad using orthographic projection matrix
« Last post by Adro on January 19, 2022, 18:19:55 »
Thanks for your answer, Kaihh!

So if for instance I put vertices in [0, 1.5] will generate fragments? Because I've seen that usually values are in the interval [0, 1] because the screen takes NDC system.
4
OpenGL / Re: Problem drawing simple quad using orthographic projection matrix
« Last post by KaiHH on January 19, 2022, 17:39:28 »
With the effective values:
Code: [Select]
orthoProjectionMatrix.setOrtho2D(0, window.getWidth(), window.getHeight(), 0);
you are saying that all coordinates between [0, window.getWidth()) and [0, window.getHeight()) get mapped to your viewport.
Therefore, when you render a model with model-space coordinates in [0, 0.5] that becomes smaller than one pixel and likely don't generate any fragments when rasterized.
You either need to modify the extents of the orthographic projection or increase the spacing of your model-space vertices.
5
OpenGL / Problem drawing simple quad using orthographic projection matrix
« Last post by Adro on January 19, 2022, 17:31:44 »
Hi!

I'm trying to draw a simple quad into the screen with no perspective, only for setting an image on it, but it doesn't show up. It's not an issue about color or texture, because the quad is drawn with perspective if I use perspective matrix instead. In fact, the renderer says it's drawing the mesh... My code is very simple. Here I define the vertex positions, indices and texture coordinates:

posText = new float[]{
            0.0f, 0.0f,
            0.0f, 0.5f,
            0.5f, 0.5f,
            0.5f, 0.0f
        };
       
indicesText = new int[]{
            0, 1, 3, 1, 2, 3
        };

textCoords = new float[]{
            0.0f, 0.0f,
            0.0f, 1.0f,
            1.0f, 1.0f,
            1.0f, 0.0f,

        };

And when rendering it, the orthographic matrix is called and built as:

Matrix4f orthoProjMatrix = orthoProjectionMatrix(0, window.getWidth(), window.getHeight(), 0);
public Matrix4f orthoProjectionMatrix(float left, float right, float bottom, float top){
        orthoProjectionMatrix.identity();
        orthoProjectionMatrix.setOrtho2D(left, right, bottom, top);
        return orthoProjectionMatrix;
    }

The vertex shader is simple:

#version 330

layout (location=0) in vec3 position;
layout (location=1) in vec2 texCoord;


out vec2 outTexCoord;

uniform mat4 projectionMatrix;
uniform mat4 worldMatrix;

void main()
{
    gl_Position = projectionMatrix * worldMatrix * vec4(position.xy, 0.0, 1.0);
    outTexCoord = texCoord;
}


Where projectionMatrix takes the value of the othographic matrix. What am I doing wrong?
6
OpenGL / Re: I am confused with OpenGL versions and signatures
« Last post by Steyrix on January 15, 2022, 13:24:58 »
Thank you, KAIHH :)
7
OpenGL / Re: I am confused with OpenGL versions and signatures
« Last post by KaiHH on January 13, 2022, 19:05:59 »
LWJGL has a class for every OpenGL version, including only the methods that got introduced in that version of OpenGL.
And every newer OpenGL class inherits from the previous version, such that when you use e.g. GL46C you can still use OpenGL functions through that class that were introduced in previous OpenGL core versions.

Usually, when you write an OpenGL application, you define beforehand which minimum OpenGL version you want to target/support, i.e. what the client running your application must support at minimum. Let that be OpenGL 3.3 core, for example, which nowadays is a very save bet.

Then, if you only had one code path in your application that will use OpenGL 3.3 core features only, then you can simply do
Code: [Select]
import static org.lwjgl.opengl.GL33C.*;
at the beginning of every compilation unit that contains OpenGL calls.

Having explicit classes for specific OpenGL versions also prevents you from walking all over the place and scattering your code with GL 3.3, 4.1, 4.3 and possibly 4.6 function calls, making your application potentially unusable for clients that do not support certain higher OpenGL versions and the functions therein (like all macOS machines, which only support up to OpenGL 4.1 core, but not higher).
So, explicit version classes allow you to make an informed and compile-time-enforcable decision about which OpenGL functions (from which version) you can and want to use, without acidentally making use of a higher-versioned and potentially unsupported (depending on the minimum context version you request via GLFW) OpenGL version.
If you begin to type the name of an OpenGL function and your IDE cannot auto-complete/find it, then it is not supported in the OpenGL version your are currently targeting/importing, and you need to reconsider your approach.

As for glGenBuffers (or other methods taking a NIO Buffer as parameter): When the C API takes in a pointer and a length/count parameter, that is indicative of the number of read or written elements from the pointer, then that is automatically inferred by LWJGL which will use the NIO Buffer's `remaining()` to provide the argument value for the count/length parameter to the native C call.
If you'd rather call the _direct_ native function, you can also do that with the methods having an `n` as prefix, like `nglGenBuffers()`. But that is more cumbersome, since you will be operating with native pointer address as `long` values.
You pretty quickly get used to the "auto-sized NIO Buffers and count/length-parameter-inferring" when working with LWJGL.
It's just a style of binding that LWJGL adheres to.
8
OpenGL / I am confused with OpenGL versions and signatures
« Last post by Steyrix on January 13, 2022, 18:43:24 »
Hello there, please excuse me in advance, since I am really new to this forum and english is not my native.

I have recently discovered LWJGL and I was using JOGL before. Now I am trying to put my JOGL-based engine on LWJGL OpenGL rails and I get really confused.
First of all, I can't really figure out which version of GL class should I use. Since most of my functionality was written for GL3-4 API, I guess I will be OK with using org.lwjgl.opengl.GL46?
Moreover, some GL methods' signatures seem unfamiliar to me, despite I have used them before. For example, glGenBuffers() does not have size parameter. Does this mean that
size is calculated automatically, out of box?

Will be thankful for any help or clarification
9
Lightweight Java Gaming Library / Re: Stack allocation converting to Buffer
« Last post by szg on January 09, 2022, 15:07:38 »
Thank you Spasi,
for your explanation and code. I try to learn the memory model and to understand better how lwjgl and vulkan works.

Your code nailed what I tried to achieve, and answers my current questions regarding this topic.

From my point we can close this thread
10
Lightweight Java Gaming Library / Re: Stack allocation converting to Buffer
« Last post by spasi on January 09, 2022, 13:31:43 »
It fails because the MemoryStack in LWJGL grows "downwards", i.e. if you stack allocate A then B of the same type, they will be contiguous in memory but B will have a lower memory address than A. This is unspecified, just like you can't assume anything about two local variables in C declared next to each other. You can probably get away with using the fragment shader address instead, it should work, but there are no guarantees it won't break in the future (if the MemoryStack implementation changes for whatever reason).

Not sure what your goal is, but if you're trying to minimize local variables, the struct DSL allows it, like this:

Code: [Select]
VkPipelineShaderStageCreateInfo.calloc(2, stack)
    .apply(0, vsh -> vsh
        .sType$Default()
        .stage(VK_SHADER_STAGE_VERTEX_BIT)
        .module(createShaderModule(vshCode))
        .pName(stack.UTF8("main")))
    .apply(1, fsh -> fsh
        .sType$Default()
        .stage(VK_SHADER_STAGE_FRAGMENT_BIT)
        .module(createShaderModule(fshCode))
        .pName(stack.UTF8("main")));

and you pass that directly to VkGraphicsPipelineCreateInfo::pStages().
Pages: [1] 2 3 ... 10