GL_RGBA32F with glTexImage2D

I have some code that uses the GL_RGBA32F internal format for HDR textures (in my case, used for pre-computed atmospheric transmission and scattering).

The following code works in JoGL 2.1.2  but fails in JoGL 2.3.2.

FloatBuffer pixels = (FloatBuffer) GLBuffers.newDirectGLBuffer(GL4.GL_FLOAT, width * height * floatsPerPixel);
 textureData = new TextureData(GLProfile.get(GLProfile.GL4), GL4.GL_RGBA32F, width, height, borderWidth,  GL4.GL_RGBA, GL4.GL_FLOAT, createMipMaps, dataIsCompressed, mustFlipVertically, pixels, flusher);

The GL_RGBA32F is defined in:
https://www.khronos.org/opengles/sdk/docs/man3/html/glTexImage2D.xhtml


Looking at the JoGL source code I can see that formats like GL_RGBA32F do not seem to be supported any more, and JoGL blocks them instead of passing them through to OpenGL.

Is there another way to use HDR textures with JoGL 2.3.2?  or is it just a matter of JoGL dropping support and needing to 'catch up' again to allow all supported formats?

Hi

It seems to be a regression, please fill a bug report, be as accurate as possible.

On 11/12/2015 10:50 AM, gouessej [via jogamp] wrote:
> Hi
>
> It seems to be a regression, please fill a bug report, be as accurate as
> possible.

It has been promoted to superclass, i.e. GL.GL_RGBA32F,
and should not cause a problem.

~Sven

Sorry, I thought that the problem was deeper, maybe in TextureData itself. You're right, GL_RGBA32F is in GL.

Thanks for taking the time to comment, gentlemen.

The problem is not a compile-time problem, but a run-time one.

You didn't have much information to go on, so my apologies for that.  The problem when using GL_RGBA32F at runtime produces the following stack trace on JoGL 2.3.2, but works fine on JoGL 2.1.2

com.jogamp.opengl.GLException: Could not find PixelFormat for format and/or type: PixelAttributes[fmt 0x1908, type 0x1406, null]
        at com.jogamp.opengl.util.GLPixelBuffer$GLPixelAttributes.<init>(GLPixelBuffer.java:498)
        at com.jogamp.opengl.util.GLPixelBuffer$GLPixelAttributes.<init>(GLPixelBuffer.java:464)
        at com.jogamp.opengl.util.texture.TextureData.<init>(TextureData.java:141)

Looking at the class  GLPixelBuffer.GLPixelAttributes it becomes clear that floating-point pixels are no longer supported in JoGL's utilities  (where they were at a point in the past).

I'll try to modify GLPixelBuffer locally to see if I can get around my problem, and if I do this successfully will post a patch here.

Anyway, I thought you gents should know about the regression for HDR textures.  Thanks for all the work you do on this project.

0x1908 matches with GL_RGBA and 0x1406 matches with GL_FLOAT. This is the missing case.

I'd ignored updating JOGL, but decided to take the plunge (I really like the single Fat Jar deployment for Jogamp, thanks for putting that together) and found a work-around for this problem.

Initially I tried fixing up the TextureData and associated classes. This was fairly complicated, and somewhat unnecessary for my purposes.  Instead I found that the JOGL Texture class could be used to wrap an OpenGL texture if you create the texture yourself and provide the OpenGL handle.  It is a good design of JOGL that such 'fallback' methods are available in the public interface. It really 'saved my bacon'.

So, for the RGBA32F image I was using (used to store the Rayleigh and Mie atmospheric scattering integrals for various combinations of altitude and angular distance from the Sun) I changed from using the following:

TextureData textureData = new TextureData(gl.getGLProfile(), internalFormat, width, height, numBorderPixels, pixelFormat, pixelType, mipmap, dataIsCompressed, flipVertically, buffer, null);

to a utility function that creates the texture I want (I've stripped out my custom error handling so show the essentials) and bypasses the use of TextureData which doesn't work for RGBA32F (as in, HDR) images:

  public Texture createRgbaFloatTexture(GL4 gl, FloatBuffer buffer, int width, int height) {
    boolean flipVertically = false;

    int numTextures = 1;
    int[] textureHandles = new int[numTextures];
    gl.glGenTextures(numTextures, textureHandles, 0);

    final int glTextureHandle = textureHandles[0];

    gl.glBindTexture(GL.GL_TEXTURE_2D, glTextureHandle);

    int mipmapLevel = 0;
    int internalFormat = GL4.GL_RGBA32F;
    int numBorderPixels = 0;
    int pixelFormat = GL4.GL_RGBA;
    int pixelType = GL4.GL_FLOAT;
    boolean mipmap = false;
    boolean dataIsCompressed = false;
    gl.glTexImage2D(GL.GL_TEXTURE_2D, mipmapLevel, internalFormat, width, height, numBorderPixels, pixelFormat, pixelType, buffer);

    gl.glTexParameteri(gl.GL_TEXTURE_2D, gl.GL_TEXTURE_MAG_FILTER, gl.GL_LINEAR);
    gl.glTexParameteri(gl.GL_TEXTURE_2D, gl.GL_TEXTURE_MIN_FILTER, gl.GL_LINEAR_MIPMAP_LINEAR);
    gl.glGenerateMipmap(gl.GL_TEXTURE_2D); // Don't really need mipmaps, but we'll create anyway for now.
    Texture texture = new Texture(glTextureHandle, GL4.GL_TEXTURE_2D, width, height, width, height, flipVertically);

    return texture;
  }


I hope this is of some use to other JOGL users, as I've seen a couple of people ask about  using floating-point pixel images.

Thanks so much to the JOGL team and all the contributors.

Here's a screenshot of the real-time atmospheric scattering in action in the background of this image. I'm looking forward to getting PBR going on the aircraft as part of the next step, and I'm about to drop in 30-m global terrain from NASA's SRTM survey. The coloured lines on the aircraft are the forces acting in the flight model (adapted from NASA's high-fidelity F-16 model)

Hi

Thank you for your feedback. Maybe we could fix it in the next maintenance version. Great screen capture :)

For a moment I thought it was my same bug, but it's not.

Could you open a bug, Moa?

If you don't have an account, Gouessej can make you one