So I am posting this here instead of on the lwjgl forums as a similar question was asked but no one answered. In the particle editor I am making I have it so you can export the effect into a sprite sheet using glReadPixels. Everything works fine except that the alpha seems off. When you have grayer images that are not colored it is like everything gets jacked up. I thought it had something to do with how opengl has unsigned and java does not but after printing the results back everything is fine no negatives.

Basically, the preview image on the right is off from what it should look like on the left. Now these are not the same image obviously as the left one is a different animation but if you look the left one has a whole lot more "smoke" in it or looks thicker. But the one on the right which is what it looks like after reading the pixels. I have not tried "not" going through java2d when saving the images but when I drop the alpha I get the right image.

I have tried the nightlies of lwjgl and they only broke the gui. I have tried using the images graphics object and g2d.fillrect with the color set and that gave same results. I think java2d could be screwing with some shit... Could someone else try it and see if they get the same results as me? If it works fine for you then I MUST be doing something wrong.

Looking at a single white block that fades out 8x8 pixels to keep the printouts readable. The color and alpha do not start at 255 but 250 or so but that should not make a huge difference. The alpha drops properly but so do the colors. Is opengl premultiplying everything when before I grab the pixels? When not using an image everything seems to look fine but when I load up an image that is not completely opaque, I start getting issues.

I know what pre-multiplied alpha is and it seems like the pixels returned are pre-multiplied. When I use the BufferedImage TYPE_ARGB_PRE I get the same results.

How would you reverse pre-multiplied alpha? I think I did it right but it did not help. Would rendering everything to an FBO work? I wouldn't think so but it is worth a shot.

I normally do not get pissed easily but this one really pisses me off because I can do almost the exact same thing in Java2D much much easier and it works. Hell I don't mind extra difficulty if the damn thing works.

This is nothing to do with OpenGL; OpenGL doesn't know anything about pre-multiplied alpha. This is solely to do with Java image manipulation.<edit>What are you doing to ensure your BufferedImage is not using pre-multiplied alpha?

What would you like me to post? Name the things you think might be issues and I will post the relevant parts. If you really want I can post the whole damn thing but there are many things not necessary.

Thing is with just passing 0xff as alpha (no alpha) I get the right image. What is on the screen during testing is correct. Opengl is rendering properly. I can post how I setup opengl, render stuff, etc if that will help.

Which would lead to a final color of (1, 1, 1, 0.5), and still allow you to blend multiple particles atop each other.

When you render with this blend func to the default frame buffer, you will probably just see a white box. However, when you use glReadPixels, you will get an image that is not premultiplied, which can then be rendered back with standard GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA blending.

Another solution would be to just tell the user to use pre-multiplied alpha (or have your app pre-process textures when loading a particle image), then you can just use GL_ONE, GL_ONE_MINUS_SRC_ALPHA everywhere.

I made the system before I knew how much better pre-multiplied alpha is which is why I am not using it right now.

I am using the default frame buffer right now. I will be honest and say that I am not very well versed in opengl so I blame my lack of experience and not the bindings them selves.

I will just change everything to pre-multiplied alpha and have an option for the user to say whether the image is pre-multiplied or not and if it is not I will load the file accordingly. I really hope this will fix it. I will post again if this solves it and maybe the LWJGL wiki needs and update.

So I would have to change my whole particle system in order to use premultiplied alpha blending which I am ok with but that would also mean the UI would have to change which I am not ok with...for now. When I rewrite my system it will be not as special and more like libgdx but with more features.

Unfortunately, the issue I have now is when using davedes blending mode I get correct information except that nothing is additively blended.

The 3 step, which I should have read better, I do not do. That is to say, info is wrong coming from the frame buffer and does not get messed up after.

Why would you have to change your UI? Just enable regular blending when rendering UI, and premultiplied when rendering your particles.

If you want additive blending without a "premultiplied" result, use GL_ONE, GL_ONE.

I would advise using a frame buffer to streamline the process. In the following example (using lwjgl-basics), the particles are rendered correctly to the FBO (optionally with additive blending). Then, the FBO contains the correct pixel data (if we want to save to PNG, using glGetTexImage). We can also render the FBO to the screen using our standard GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA blending, so no major changes are needed to your app.

UI is done in swing so that is not what I mean by UI issues. I mean that if I wanted to revamp the particle system then I would have to change UI elements.

I am using swing/awt and lwjgl so I am currently not actually using my own FBO. I render the previews with java2d and other such things as making changes to the animations (making them seamless) is much easier in java2d or at least I know how to do it in java2d.

Thank you for the code. I will change things to use an FBO and see if that will work.

You can layer the particles which means that you could have additive atop non atop add atop non etc. It is not just one time rendering all particles with additive or non.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org