Need help debugging a texture issue

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Need help debugging a texture issue

DamagedTiberius
I'm running into a problem where some of my textures stop drawing, and I simply see the default material color for the associated objects instead. For the moment I'm stuck at JOGL 2.1.5 using GL2 because this all needs to work in NASA World Wind. That being said, I don't think there's a bug in the older JOGL. I just don't see what I've done wrong. I would really appreciate any insight or troubleshooting ideas anyone might have.

The general flow to reach my issue is:
- Load object(s) with texture - 5 or 6 textures are created and look good
- Load different type of object and create a texture by painting into a BufferedImage - one additional texture created

The newly created object looks correct; however, the original objects lose their texture.

The problematic textures are created using AWTTextureIO in a manner akin to:

    public void createTexture(GL2 gl)
    {
        BufferedImage textureImage = getDiffuseTextureImage();
        if (textureImage == null)
        {
            return;
        }
       
        texture = AWTTextureIO.newTexture(gl.getGLProfile(), textureImage, true);
           
        texture.enable(gl);
        texture.bind(gl);
       
        gl.glTexParameteri(GL2.GL_TEXTURE_2D, GL2.GL_TEXTURE_MIN_FILTER, GL2.GL_LINEAR);
        gl.glTexParameteri(GL2.GL_TEXTURE_2D, GL2.GL_TEXTURE_MAG_FILTER, GL2.GL_LINEAR);
    }

A color gradient texture is created by first painting to a BufferedImage then using the same createTexture() method above.

        BufferedImage image = new BufferedImage(256, 2, BufferedImage.TYPE_INT_RGB);
        Graphics2D g = (Graphics2D) image.getGraphics();

        for (int i = 0; i < image.getWidth(); ++i)
        {
            double percentage = ((double) i)/((double) image.getWidth());
            Color color = getColorScale().getAwtColorFromPercentageAlongScale(percentage);
            g.setPaint(color);
            g.fillRect(i, 0, 1, 2);
        }
       
I've checked that:
- gl.glEnable/gl.glDisable(GL.GL_TEXTURE_2D) is called prior to and after drawing the objects
- texture.enable(gl) and texture.bind(gl) are called prior to drawing the objects
- texture.disable(gl) is called after drawing the objects
- The target has not changed from GL2.GL_TEXTURE_2D
- The texture unit has not changed between calls

Here are two images demonstrating what I see. The second image looks weird, but the multi-colored object actually looks the way it is supposed to. That objects uses the color gradient texture.
Render after loading of first set of objects with textures
Render after loading additional object with color gradient texture
Reply | Threaded
Open this post in threaded view
|

Re: Need help debugging a texture issue

DamagedTiberius
I tried loading objects in a different order to see how that affected things. Some additional data points...

  • If I load the color gradient object first then the soldier object, everything draws correctly.
  • If one color gradient object is loaded prior to the soldier, I can destroy the original color gradient object and load new ones with no ill effects
  • I have World Wind running in a separate window/context:
    • If I load the model into World Wind then load the color gradient object into the other window, the model disappears completely in World Wind.
    • If I load the color gradient object in the non-World Wind window then load the soldier into World Wind, everything draws correctly.
    • Loading of the soldier in the non-World Wind window has no impact on the World Wind window
Reply | Threaded
Open this post in threaded view
|

Re: Need help debugging a texture issue

gouessej
Administrator
In reply to this post by DamagedTiberius
Hello

Sorry but we don't have the resource to maintain obsolete versions. Please provide a SSCCE using at least JOGL 2.3.2. The bug could lie in some source code not shown in your post.
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: Need help debugging a texture issue

DamagedTiberius
I didn't suggest that anyone should do anything with an obsolete version. I was simply hoping that someone might be able to help point me towards some debugging steps I might take to track down my problem.
Reply | Threaded
Open this post in threaded view
|

Re: Need help debugging a texture issue

gouessej
Administrator
Ok but it's difficult to make some suggestions with so few elements of information. It could come from a mistake not on the texture unit but on the texture currently bound to the unit in use or on the use of texture coordinates. By the way, JOGL 2.1.5 is obsolete, I advise you to recompile WorldWind with JOGL 2.3.2 (there are some imports to adapt, it's not the end of the world, sorry for the bad play-on-words :p).
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: Need help debugging a texture issue

Sven Gothel
Administrator
On 4/3/20 3:42 PM, gouessej [via jogamp] wrote:
> I advise you to recompile
> WorldWind with JOGL 2.3.2 (there are some imports to adapt, it's not the end
> of the world, sory for the bad play-on-words :p).

WorldWind is using our latest RC, they do maintain a source drop-in AFAIK.
This happened when they restarted their WorldWind efforts.

~Sven
Reply | Threaded
Open this post in threaded view
|

Re: Need help debugging a texture issue

gouessej
Administrator
Sven Gothel wrote
WorldWind is using our latest RC, they do maintain a source drop-in AFAIK.
This happened when they restarted their WorldWind efforts.

~Sven
Thank you for the reminder. Therefore, I advise the original poster to upgrade to the latest version of WorldWind in order to use the latest version of JOGL.
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: Need help debugging a texture issue

DamagedTiberius
I finally figured out my issue.

It was due to the OpenGL context backing the GLJpanel being destroyed and replaced. It makes sense to me now, but I didn't realize I needed to destroy and recreate my textures (along with vertex buffers and any other GPU resources). It hadn't come up in the tutorials I followed, so I hadn't thought to look there.

This was the kind of general advice I was hoping someone might be able to offer. Something along the lines of: If you're seeing issues where something stops drawing correctly after [INSERT LIST OF ACTIONS CAUSING A CONTEXT TO BE REPLACED HERE], double check that you're destroying your OpenGL resources and regenerating them for the next render call.

I suspect that there are probably a handful of JOGL-specific concepts along these lines that someone new to the API needs to be very aware of but may not be clearly addressed in the various tutorials out in the wild. It could be incredibly helpful to have an FAQ/Troubleshooting document somewhere to point people towards.

gouessej wrote
Sven Gothel wrote
WorldWind is using our latest RC, they do maintain a source drop-in AFAIK.
This happened when they restarted their WorldWind efforts.

~Sven
Thank you for the reminder. Therefore, I advise the original poster to upgrade to the latest version of WorldWind in order to use the latest version of JOGL.
My customer prefers staying with the last official release of World Wind for the moment (simply part of the list of things not within my control right now). I'm very much looking forward to the next World Wind release though.
Reply | Threaded
Open this post in threaded view
|

Re: Need help debugging a texture issue

gouessej
Administrator
What do you mean by "the OpenGL context backing the GLJpanel being destroyed and replaced"? I have to repeat quite often that the GL instance mustn't be stored into global variables and fields. Moreover, it's really difficult to follow how the frameworks and engines use JOGL. There's a user's guide, we spent a lot of time in updating it. We're volunteers, we do our best.

It depends on what you mean by "the next render call", systematically destroying an OpenGL resource at the end of the call of GLEventListener.display(GLAutoDrawable) is a bad idea, doing that in GLEventListener.dispose(GLAutoDrawable) is a good idea but when the framework or engine you use doesn't use a GLEventListener, it's up to it to implement its own lifecycle management.
Julien Gouesse | Personal blog | Website