Posted by xghost on Jul 15, 2014; 11:45am
URL: https://forum.jogamp.org/Need-Help-Solving-OpenGL-GLSL-4-4-Issues-tp4032557p4032573.html

Sven Gothel wrote

I don't see where you clear the
depth buffer via GL_DEPTH_BUFFER_BIT ..

<https://www.opengl.org/wiki/Depth_Test>

I've enabled GL_DEPTH_TEST in the init(GLAutoDrawable drawable) method:

    gl = (GL4) drawable.getGL();
    gl.glEnable(GL4.GL_DEPTH_TEST);
    gl.glClearColor(0.0f, 0.0f, 1.0f, 1.0f);    // added to replace gl.glClearBufferfv(...) below

I then added the clear in the display(GLAutoDrawable) method, trying a few different things:

    gl = (GL4) drawable.getGL();
    gl.glClear(GL4.GL_DEPTH_BUFFER_BIT | GL4.GL_COLOR_BUFFER_BIT);
    // gl.glClearBufferfv(GL4.GL_COLOR, 0, bufferClearColor);
    gl.glUseProgram(program);

I'm still getting the same result as before --the blue-cleared background w/ no triangle. This is even if I don't use glClearColor() on init and instead keep using glClearBufferfv() that's currently commented out and only clearing the depth buffer bit, not the color buffer bit.

Also, looking at the C++ code from the OpenGL SB 6 (movingtri application), which builds/works fine, the render code is as follows:

    virtual void render(double currentTime)
    {
        static const GLfloat green[] = { 0.0f, 0.25f, 0.0f, 1.0f };
        glClearBufferfv(GL_COLOR, 0, green);
        glUseProgram(program);

        GLfloat attrib[] = { (float)sin(currentTime) * 0.5f,
                             (float)cos(currentTime) * 0.6f,
                             0.0f, 0.0f };

        glVertexAttrib4fv(0, attrib);
        glDrawArrays(GL_TRIANGLES, 0, 3);
    }

This is equivalent to the Java code I included.

Sven Gothel wrote

Note on coordinate system:
====================
You use the device default coordinates,
which are in normalized device coordinates (NDC)
[-1..1] for the x- and y-axis.
The z-buffer semantics depend on the depth range,
which defaults to [0..1]

<https://stackoverflow.com/a/7770714>
<https://www.opengl.org/wiki/GLAPI/glDepthRange>

On the coords topic, perhaps I'm missing something, but the range of the NDC and depth range values seems to be within the valid/accepted range (i.e. within [-1,1] and [0, 1] respectively) in my application.

gouessej wrote

Hi

Please try to use a core profile without backward compatibility and try to use this example too:
https://github.com/sgothel/jogl/blob/master/src/test/com/jogamp/opengl/test/junit/jogl/demos/es2/RedSquareES2.java

I ran into a few problems trying to build/launch it at first... maybe due to a long day/night. If you could please include what you think is the simplest set of steps to get what you need, I'd appreciate it :)


Thanks.