JOGL + Swing + Multiple viewports

I am currently working on a 3D level editor with swing and java which has the following needs:

- Multiple viewports.
- High performance, smooth rendering.
- Ability to do real time active rendering. (game simulation in editor, physics, particles)

I am having an issue finding and using all the information I need as it is scattered around the internet.
Currently I am using a GLJPanel that handles a GLEventListener and does GLJPanel.display() to repaint if any changes occured to viewport state (camera, etc...).  I want to be able to create active rendered viewports at 60 fps, I just need to be pointed in the right directions.

For example, I created a 3D CSG level editor in C# with Winforms and OpenTK.
It uses one canvas, that is divided into 4 parts with GLViewport. (Do not want this in java)
The viewport is not active rendered, but switches to active rendering when I press in the perspecive viewport that allows me to fly around at 60 fps.



# Multiple viewports, what is the best modern way to do context sharing in Jogl?
I guess the following: https://jogamp.org/deployment/v2.3.2/javadoc/jogl/javadoc/com/jogamp/opengl/GLSharedContextSetter.html

I have also seen this, where a GLPBuffer is used:
http://www.java-gaming.org/index.php/topic,22798.0

# High performance, smooth rendering. NEWT?
I read about using NEWT as it is the prefered way of doing JOGL, because AWT and Swing can lock?
I found out that NEWT could be used with Swing, but how?

Is NEWT preferable in all situations? as in standalone window for a game and GUI(AWT, Swing) applications?
What about context sharing with NEWT?

Guess I need to use this resource: http://jogamp.org/jogl/doc/NEWT-Overview.html

# Ability to do real time active rendering.
I found an article about active rendering dating from 2006, is this still needed or can this be done efficiently with Animator(GJPanel) or NEWT?

Hi

You can use NewtCanvasAWT with Swing. I'm not sure that you need to use offscreen rendering and if you needed to do so, you should use FBOs instead of PBuffers because they're better supported under several operating systems. You can call GLAutoDrawable.display() directly, use a custom animator or use a build-in one but if I were you, I would use active rendering if and only if it improved the performance. It's the same for offscreen rendering, you can render the scene into a FBO and reuse it later but ensure that it's worth the effort. To sum up, keep it simple and avoid early unneeded optimization.

By the way, feel free to share some information about your project with us, I'd like to try your level editor :) Have you implemented any algorithm to compute PVS?

Thanks for your response.

Isn't using an animator the same as active rendering?
And is NewtCanvasAWT a heavyweight or ligweight component as I cant seem to use GLCanvas at the moment (it is not drawing anything). (I am using weblaf and their docking components)

Currently everything is done on the EDT, isn't this going to cause performance issues, I sometimes have that my screen lags a little, I just want consistent framerates. Thats why I thought active rendering would be a solution.

I discontinued my C# editor and put it up on github, https://github.com/MarkWilds/Runegear
I never implemented a BSP and PVS compiler and did not got around to even implement CSG ^^

P.s.

I am also having a problem with enabling GL_CW for backface culling but my screen turns black.
Maybe any knows the cause?

        GL2 gl2 = (GL2) glAutoDrawable.getGL();
        gl2.glClearColor(31.0f / 255.0f, 31.0f / 255.0f, 31.0f / 255.0f, 1.0f);
        gl2.glEnable(GL2.GL_DEPTH_TEST);
        gl2.glEnable(GL2.GL_CULL_FACE);
        gl2.glFrontFace(GL2.GL_CW);

There are several implementations of animator, the most basic one performs active rendering, another one attempts to respect a fixed frame rate (but I advise you to use V-sync instead of this animator).

NewtCanvasAWT is a kind of bridge, it contains a NEWT window but it extends a basic (heavyweight) java.awt.Canvas. It helps to write cross-platform source code as you can use the same listeners with AWT and in AWT-free environments (typically Android).

You must identify the root cause in order to choose the appropriate solution. Multithreading isn't magic but you should do on the EDT only what is necessary.

Where do you call glCullFace(GL2.GL_BACK)?

gouessej wrote

There are several implementations of animator, the most basic one performs active rendering, another one attempts to respect a fixed frame rate (but I advise you to use V-sync instead of this animator).

NewtCanvasAWT is a kind of bridge, it contains a NEWT window but it extends a basic (heavyweight) java.awt.Canvas. It helps to write cross-platform source code as you can use the same listeners with AWT and in AWT-free environments (typically Android).

You must identify the root cause in order to choose the appropriate solution. Multithreading isn't magic but you should do on the EDT only what is necessary.

Where do you call glCullFace(GL2.GL_BACK)?

Thank you again for your explanation, it helps alot.
I guess I can't use newt as heavyweight components do not work with the components I am using.

About `GL_BACK`I have it commented out below the code I posted. It has the same effect(Black screen) and should be default with OpenGL? (Guess it depends on driver impl)

    @Override
    public void init(GLAutoDrawable glAutoDrawable) {
        GL2 gl2 = (GL2) glAutoDrawable.getGL();
        gl2.glClearColor(31.0f / 255.0f, 31.0f / 255.0f, 31.0f / 255.0f, 1.0f);
        gl2.glEnable(GL2.GL_DEPTH_TEST);
        gl2.glEnable(GL2.GL_CULL_FACE);
        gl2.glFrontFace(GL2.GL_CW);
        gl2.glCullFace(GL2.GL_BACK);

        LOGGER.info("OpenGL Canvas initialized = " + Thread.currentThread().getName());
    }

Yes GL_BACK is the default when you enable the face culling. Your source code seems to be correct, the problem is elsewhere.

Edit.: Maybe the winding of your vertices isn't the one you expect.

gouessej wrote

Yes GL_BACK is the default when you enable the face culling. Your source code seems to be correct, the problem is elsewhere.

Edit.: Maybe the winding of your vertices isn't the one you expect.

I checked my winding, but that wouldn't cause my screen to go black in a fixed function pipeline I guess.

When I set setSkipGLOrientationVerticalFlip(true); the screens does not turn black :S

Thank you for the feedback. It's a side effect of this feature, it's mentioned in the documentation:
http://jogamp.org/deployment/jogamp-next/javadoc/jogl/javadoc/com/jogamp/opengl/awt/GLJPanel.html#bug842

P.S: I use jogl.gljpanel.noglsl in JogAmp's Ardor3D Continuation, that's why I don't reproduce this problem but the vertical flipping has a lower memory footprint when it's performed by the build-in GLSL shader.

Is there a way to see which states are adjusted by the bug? (where in the code do I need to look)
And is it best to just disable vertical flip? Are there any more things I should know?

At the moment I am still using GL2, but I am currently starting my migration to GL3.3+
Its a bit annoying that I have to keep tweaking my code to be able to use my setup conventions.

Currently using LeftHanded, so i am telling my math library to create LH projection matrices for me.
And am ofcourse using Clockwise winding that's why I had the issue.

I now seem to have an annoying depth bug where polygons that are behind other polygons are shown...
And what is the difference in setting a shared autodrawable or a shared glcontext? The docs state using the shared autodrawable in their example for context sharing.

Here some code and a picture of my problem (two cubes next to each other):


This code is copied and pasted into an image and should be read as pseudo code.
Depth test with LESS and CW backface culling are enabled.

This is test code and I know that creating new instances of my vector is not the way to do it and does not belong in this class. (will become a mesh class in the future)

The problem is that my east side polygon for a cube is drawn over the top and front polygons! I tried different depth test settings but to no avail. (this does not happen with the cube on the west, -x axis)

The answer should be here but it's not crystal clear to me:
https://github.com/sgothel/jogl/blob/master/src/jogl/classes/com/jogamp/opengl/awt/GLJPanel.java#L1877

the problem seemed to be that I am using the default capabilities.
My depth buffer did not have the needed precision, it was 16 now it is 24.
I am using a large scale  32 opengl units is equevelant to 1 world unit for my editor. (will probably change this in the future).

Don't use a 32-bit depth buffer as it might force JOGL to pick Microsoft GDI under Windows :s

Yeah I know, going to stick with 24, should always be enough.
And 32 bit is rather "recent" which might mean my editor will not run on gpu's not supporting 32 bit depth buffers.