Hello Guest

Recent Posts

Pages: [1] 2 3 ... 10
OpenGL / Resetting context but keeping the data
« Last post by Aisaaax on Today at 05:32:08 »
Is it possible to re-create context but keep the VAO/VBO's?

In my application, sometimes the window (surface) to which I render gets hidden completely. When it gets shown again - the surface ID changes, and I can't keep rendering to it with the context that I had before.

My solution is to close the context completely as soon as the surface gets hidden, and then create a new one when it gets re-opened.

The problem here is lots of data that I don't necessarily want to re-create. For example I have to triangulate shapes that are calculated in a different part of the program, and that work is quite CPU-intensive. Maybe I could instead just keep the previous VBO and use it? But all attempts have given me no success.

Maybe I'm missing something? Or maybe I can even do away with closing the context (again, I didn't find a solution).

It works as is, but I feel that it's sub-optimal.

Thank you!
Lightweight Java Gaming Library / Re: Loading texture arrays crashes the JVM
« Last post by Zeno on May 30, 2020, 19:57:00 »
You are using width=size[0] and height=size[1] which is probably fine, but then you are telling OpenGL that the depth=index.

Ah so I'm misinterpreting that third size component? The way I understood it, it refers to the index of the given sprite in the texture array. But when I read the documentation again, it seems to refer to the total amount of sprites that you are trying to load, is this correct? So to be fully clear, my line would have to look as follows

Code: [Select]
GL45.glTextureSubImage3D(ID(), lod, 0, 0, index, size[0], size[1], 1, GL11.GL_RGBA, GL11.GL_UNSIGNED_BYTE, data);
As an aside, I'm assuming this also means you can load multiple sprites through one call, and appropriately changing that '1' into however many sprites are stored in your data buffer? How would this data then have to be laid out? I assume the sprites cannot be interleaved, they would have to be stored in the buffer sequentially?
Lightweight Java Gaming Library / Re: Loading texture arrays crashes the JVM
« Last post by KaiHH on May 30, 2020, 18:51:33 »
Code: [Select]
glTextureSubImage3D(ID(), lod, 0, 0, 0, size[0], size[1], index, GL11.GL_RGBA, GL11.GL_UNSIGNED_BYTE, data);
makes no sense. Please look at the definition of this function again: https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glTexSubImage3D.xhtml
You are using width=size[0] and height=size[1] which is probably fine, but then you are telling OpenGL that the depth=index. So, later indexes will upload an always bigger and bigger sub-texture. This is wrong. Your slices all have the same size 128x128x1 (w x h x d). You should use index as the zoffset parameter instead.
Lightweight Java Gaming Library / Loading texture arrays crashes the JVM
« Last post by Zeno on May 30, 2020, 16:47:23 »
Hello everybody!

I've recently decided to switch out my single-texture sprite sheets with the use of texture arrays. I cannot seem to get this to work as the JVM crashes in the middle of loading the images. I have 12 images of size 128x128 that I loop over and load with the glTextureSubImage3D command, the relevant code is given below. My code loops over the load method 12 times, and you can see I print some text to the console. The end result is that the JVM crashes after finishing a handful (between 6 and 8 images) of these methods, and failing to do the next one. Am I actually using the TextureSubImage method right? Is this perhaps not a method you can use repeatedly in quick succession? I've also added a crash log, see here. This was run through LWJGL 3.2.3. Thanks in advance for any help!

Code: [Select]
private void initialize(int lod, int count, int... size)
case 1:
GL45.glTextureStorage2D(ID(), lod, GL11.GL_RGBA8, size[0], count); break;
case 2:
GL45.glTextureStorage3D(ID(), lod, GL11.GL_RGBA8, size[0], size[1], count); break;

public void load(ByteBuffer data, int lod, int index, int... size)
System.out.print("Loading " + lod + ":" + index + ":" + size[0] + ":" + size[1] + ":" + data.remaining() + ":");
case 1:
GL45.glTextureSubImage2D(ID(), lod, 0, 0, size[0], index, GL11.GL_RGBA, GL11.GL_UNSIGNED_BYTE, data); break;
case 2:
GL45.glTextureSubImage3D(ID(), lod, 0, 0, 0, size[0], size[1], index, GL11.GL_RGBA, GL11.GL_UNSIGNED_BYTE, data); break;

public void load(Image image, int lod, int index)
int w = image.Width(); int h = image.Height();
byte[] data = ((DataBufferByte) image.Raster().getDataBuffer()).getData();
ByteBuffer buffer = BufferUtils.createByteBuffer(data.length);
load(buffer.put(data).flip(), lod, index, w, h);
Lightweight Java Gaming Library / Screenshots using GPU.
« Last post by sblantipodi on May 28, 2020, 16:41:14 »
I have created a PC Ambilight project.

This project basically capture the screen image, and sends an encoded version of the "screen colors" to a microcontroller that display that colors to a led strip.

This are the project involved for the purpose

and this the result:

As you can see I use the AWT Robot Java class to capture the screen, it works well and with the right numbers of threads it works even fast.
The problem is that the robot class creates "some stutter" on slow CPUs and it's really CPU intensive if pushed that hard with threads.

Is there a way to get a simple screenshot using LWJGL and the GPU and put that screenshot in a BufferedImage?

JOML / Re: Projection Matrix
« Last post by chris1 on May 27, 2020, 13:15:06 »
I actually sorted it out an hour ago, was going to post here soon.

My model and view matrices were transposed.
I didn't see it until I went through every transformation matrix.

It's properly working now. Thanks to all replies.
JOML / Re: Projection Matrix
« Last post by abcdef on May 27, 2020, 13:10:50 »
Download renderdoc, run your program through it, look at the actual gl_position values your shader gets and see if it's in the NDC

Also print out your MVP matrix and do the calculation by hand to see what should be happening outside the shader.

I am sure it will be obvious what the error is once you see, just debug with the right tools

My first guess is your matrix moves the points outside the frustrum. Kai has kindly shown you that it should work with his example, so you have a bug somewhere.
JOML / Re: Projection Matrix
« Last post by chris1 on May 25, 2020, 20:18:32 »
Still, the GUI presents no shape.
I assumed my projection matrix construction would be clarified in this thread, and it has. Yet the result is still false.
How can make your job easier? Which pieces of code should I post if any?
Should I raise the render issue on a different board?
JOML / Re: Projection Matrix
« Last post by KaiHH on May 25, 2020, 20:04:36 »
What I understood from your initial post:
1. when you render things without a projection matrix, then thinks work
2. when you introduce a projection matrix (with settings that should work), then things don't work anymore

Now my goal here was to identify what you probably might have done wrong between steps 1 and 2, or, though less likely but still possible: what JOML might have done wrongly which need to be fixed (I am the author of JOML by the way.)

When the original problem with the projection matrix has been resolved for you, then I am curious how actually.

About whether to use the fixed-function pipeline or VBOs/VAOs: You should _never_ use the fixed-function pipeline like I did.
The sole reason I was using that is to make the example code simpler without laying the focus on the vertex specification and shader setup but on the actual matrix building code.
There is no advantage to using glVertex and other fixed-function pipeline functions over VAOs and shaders other than simplicity.

The way you described the basic structure of a render call is about right: bind VAO, bind shader, set shader uniforms, issue draw* call, unbind.
JOML / Re: Projection Matrix
« Last post by chris1 on May 25, 2020, 19:52:03 »
Forgive my ignorance, I'm just trying to understand.

Your first reply contains instructions on how to construct the projection matrix, I think the thread's question has been answered; perhaps the next question belongs to another board... but:

Since I am storing model data in a VAO, shouldn't my rendering function include the use of that VAO? Same with the shader associated with the object to render? Typically, I think, most render functions follow the structure I have: enable shader, bind VAO, upload uniform data, draw call, unbind VAO, disable shader. These I have seen in code examples and they seem to be able to render objects properly, except mine which is doing something wrong.
If I was to use your rendering method, how would I go about specifying which attribute each glVertex call refers to (assuming I would later add more attributes to every model)? The same question for other uniform data. If I was going to call glVertex iteratively, would there even still be a point of loading the model into a VAO?

Additionally, is there any reason why using glVertex is advantageous to glUniformMatrix & glDrawElements (besides it working of course)?

In short: I have a system which can contain polygons of any shape, each polygon is assigned a VAO and a shader. In a render call for all shapes in the program, I want each shape to use its own VAO and shader.
Obviously, I'm not expecting an answer containing a thousand lines of code, but the general idea is specified in the render function I gave in the original question.

Pages: [1] 2 3 ... 10