flipping textures with awtTextureIO?

In jogamp 2.5.0 I have a method which creates or update a Texture.

    private static Texture BufferedImageToTexture(Texture texture,BufferedImage image) {
        GL glContext = GLContext.getCurrentGL();
        GLProfile glProfile = glContext.getGLProfile();
        if(glProfile==null) return texture;

        TextureData textureData = AWTTextureIO.newTextureData(glProfile, image, true);

        if(texture==null) {
            texture = AWTTextureIO.newTexture(textureData);
        } else {
            texture.updateImage(glContext,textureData);
        }

        return texture;
    }

The Texture appears in app flipped upside down.  I have tried using

        textureData.setMustFlipVertically(true);

after creating textureData.  I have also tried

        texture.setMustFlipVertically(true);

before returning.  Neither one changes the flip results.  Prior to this I was using `TextureIO.newTexture()` to load textures directly from disk.  What am I missing?

Also congrats to the team that released 2.5.0.  I bet that wasn't easy.  I appreciate all your hard work!

OpenGLTestMinimal.java

OpenGLTestMinimal opens a bare-bones OpenGL window.

CompareLoadMethods.java
viewCube.png

CompareLoadMethods adds a button that invokes a comparison of the results TextureIO.newTexture and BufferedImageToTexture method (see previous post in this thread).  It loads viewCube.png

Opening the temp files created by these methods shows the second image is upside down.  I hope this is enough of a minimal test.

newTexture() does some OpenGL work whereas newTextureData() doesn't.

I have further simplified my test.


        // old method using TextureIO.newTexture
        InputStream streamA = Objects.requireNonNull(CompareLoadMethods.class.getResourceAsStream("viewCube.png"));
        Texture a = TextureIO.newTexture(streamA,false,"png");
        streamA.close();

        // new method using AWTTextureIO.newTextureData
        InputStream streamB = Objects.requireNonNull(CompareLoadMethods.class.getResourceAsStream("viewCube.png"));
        BufferedImage image = ImageIO.read(streamB);
        streamB.close();
        TextureData textureData = AWTTextureIO.newTextureData(GLContext.getCurrentGL().getGLProfile(), image, true);
        Texture b = TextureIO.newTexture(textureData);

Texture 'b' is vertically flipped from Texture 'a'.  What am I doing wrong and how do I fix it?  I hope there's a fix to textureData so that both TextureIO.newTexture calls return the same result.

If nothing is broken, there will be no fix. AWT and NEWT are free to have different expectations on vertical orientations. It's a matter of pixel or image coordinate system.

You can modify your texture coordinates or flip the pixels.

Why doesn't setMustFlipVertically​() work for you? If you use the high level API from the beginning to the end, it will work. If you create a Texture object but manage the binding by yourself, you'll be responsible for the flipping. getImageTexCoords() takes into account the value of getMustFlipVertically().

By the way, I advise you to use try-with-resources statements instead of calling close().

> Why doesn't setMustFlipVertically​() work for you?

There's insufficient documentation about what to expect.  

        TextureData textureData = AWTTextureIO.newTextureData(GLContext.getCurrentGL().getGLProfile(), image, false);
        Texture A = TextureIO.newTexture(textureData);
        textureData.setMustFlipVertically(true);
        Texture B = TextureIO.newTexture(textureData);

I was full of hope that B would be the vertical flip of A.  I find it hard to believe that *mustflipVertically() is just passed down to.. what, the fragment shader?  How does that work if there's also NPOT textures?

Maybe I'm asking the wrong question.  Is there a way that jogamp can flip the a texture for all users to provide a more consistent behavior?  Are all users expected to roll their own texture flip?

As I wrote, if you use the whole high level API, you'll obtain the expected behaviour. Call enable(), bind(), etc. If you mix Texture methods with your own calls, you'll risk to obtain the worst of the both worlds.

Actually, the Texture class has a documentation with a paragraph about NPOT textures:
https://jogamp.org/deployment/jogamp-next/javadoc/jogl/javadoc/com/jogamp/opengl/util/texture/Texture.html

All users aren't expected to roll their own texture flip and I remind you that several frameworks and engines successfully manage such aspects.

B and A have a different value for getMustFlipVertically(), this value is taken into account when using getImageTexCoords(). Modifying the vertical texture coordinates is a lot easier, faster and more scalable than flipping the pixels.

Sorry, I forgot that:
https://jogamp.org/deployment/jogamp-next/javadoc/jogl/javadoc/com/jogamp/opengl/util/awt/ImageUtil.html#flipImageVertically(java.awt.image.BufferedImage)

It flips the image vertically, you don't have to roll your own. Does it help?