refresh problem when stereo requested but not available on Linux 64bit

Here is a picture of the problem (attached below):



It shows a problem refreshing, it looks like its a vertical refresh (i.e., vertical sync).

I have simply modified the Gears example with one line, requesting Stereo (i.e., "caps.setStereo(true)").  However, on my Linux 64bit machine (CentOS 5.5), I get this refresh problem.

I am using the most recently downloaded latest versions of gluegen and jogl (from git) and compiled them on this machine.

I do not see this problem on Windows or OSX.

Here is my modified program along with simple scripts to compile and build it:

gears.tar.gz

Thanks in advance,

Blaine

Well, I did not figure out this original problem, it is definitely a bug.  However, going through the recent source code, I am able to figure out whether the default device has stereo capabilities *before* the GLCanvas object is created:

        AbstractGraphicsDevice agd = GLProfile.getDefaultDevice();
        GLDrawableFactory drawableFactory = GLDrawableFactory.getFactory(GLProfile.getDefault());
        List availableCapabilities = drawableFactory.getAvailableCapabilities(agd);
        boolean hasStereo = false;
        for (Iterator it=availableCapabilities.iterator();it.hasNext();){
            Object ob = it.next();
            if (ob instanceof GLCapabilities){
                if (((GLCapabilities)ob).getStereo()){
                    hasStereo = true;
                    break;
                }
            }
        }


Unfortunately, this code (specifically GLDrawableFactory.getAvailableCapabilities()) is not available until 1/31/11, which did not make the 2.0 build.  I am going to download rc2 and see if this works.  I would think that this is something that a lot of people are doing?

I am definitely puzzled by the lack of responses towards my posts on this forum.  It could be that I am missing out on documentation that could help me get up to speed.  Forgive me for my ignorance about JoGL.  Any feedback would be much appreciated.

Thank you,

Blaine

blainebell wrote

I am definitely puzzled by the lack of responses towards my posts on this forum.  It could be that I am missing out on documentation that could help me get up to speed.  Forgive me for my ignorance about JoGL.  Any feedback would be much appreciated.

Hi Blaine,

My guess is that you're one of the few people experimenting with stereo rendering right now, so maybe no one feels qualified to comment  The maintainers are always swamped, so issues like yours that are more esoteric might not get as much attention as an outright crash.

One thing that would definitely get attention would be to write a JUnit test case for stereo rendering and submit it as a pull request (instructions at http://jogamp.org/wiki/index.php/How_to_Contribute). You could adapt your existing code into a JUnit test case pretty easily, and once it's added to the test suite, we could get some idea of how widespread this problem is.

One question I'd have is, does the distortion in your picture show up if you capture the contents of the GL framebuffer, or is it only visible on the screen? As long as it shows up in the framebuffer (you can write it out with com.jogamp.opengl.util.awt.Screenshot), it should be possible to write a unit test that checks the framebuffer for black pixel that shouldn't be there (the test com.jogamp.opengl.test.junit.jogl.demos.gl2.gears.TestGearsGLJPanelAWTBug450 checks pixels in the framebuffer in a way similar to what you'd have to do).

Wade,

Thanks a lot for your response!  OK, it makes me feel better if I am one of a few working with stereo right now.

The picture distortion does not happen when I capture the framebuffer (i.e., taking a screenshot from the OS), and I imagine it wouldn't happen if I took it programatically, either.  It looks like a problem I've had in the past with syncing the vertical refresh, but I have played around with some of the nvidia graphics card configurations with little success.

Thanks for the pointer!  I will be happy to contribute, and will look into your link.  I am a part of an open source project as well, and I am a big fan of contributing to good projects like JoGL.

Thanks again,

Blaine

Hmm, if the distortion doesn't show up in a screenshot, it'd be hard to write a self-checking unit test. It could still be a JOGL bug instead of a driver bug, though. Perhaps the glXGetFBConfig/glXChooseFBConfig is failing to handle GLX_STEREO properly, or an illegal attribute is being passed into XCreateWindow when GLX_STEREO is requested.

At that link I sent, there are detailed instructions on how to build JOGL (including how to turn on debug symbols), so you might want to build it, link your project against your custom build, and do a little stepping in the debugger. The problem could be something obvious that's just never been tested. Just make sure you've got the latest driver before you go looking -- you don't want to waste your time looking for a bug that nvidia may have already fixed

We welcome any contributions -- please let me know if you need help building JOGL or debugging through it

On Thursday, April 07, 2011 04:38:07 am Wade Walker [via jogamp] wrote:
>
> Hmm, if the distortion doesn't show up in a screenshot, it'd be hard to write
> a self-checking unit test. It could still be a JOGL bug instead of a driver
> bug, though. Perhaps the glXGetFBConfig/glXChooseFBConfig is failing to
> handle GLX_STEREO properly, or an illegal attribute is being passed into
> XCreateWindow when GLX_STEREO is requested.
I hope this is not the case .. but surely it could be, since it's not tested
due to the lack of available machines ..

I concur that.

And as Wade stated earlier, yes - I cannot make a statement about stereo rendering
right now, since I don't have a machine supporting it either.

However, if you can help showing us that we do have a bug within the selection
of the native GLX/WGL/.. pixelformat via GLCapabilities .. sure we love to fix it.

As we always stated .. a junit test is always the best start for any communication.
I for one, only use 'laying around' code snippets very rarely.
But if one offers some proper junit test, maybe even via a git patch/repo-pull-req,
I will have a hard time to defend my lazyness :)

~Sven

Well I just wanted to say that you are not alone.  I  too am trying to get stereo to work on a Toshiba A660 with Nividia 3d Vision. Windows 7 64bit

I tried your code to detect if stereo is supported and it returns false.

Has stereo false
INIT GL IS: jogamp.opengl.gl4.GL4bcImpl
Chosen GLCapabilities: GLCaps[2 arb: offscr, rgba 8/8/8/8, opaque, accum-rgba 16/16/16/16, dp/st/ms: 24/0/0, one, mono  , hw, GLProfile[GL2/GL2], pbuffer [r2t 0, r2tr 0, float 1]]
GL_VENDOR: NVIDIA Corporation
GL_RENDERER: GeForce GTS 350M/PCI/SSE2
GL_VERSION: 3.0.0

If I just enable stereo it does get enabled but I get the following and sometimes an out of memory exception.

Caused by: javax.media.opengl.GLException: Unable to set pixel format 106 for device context 0xffffffffef0122df: error code 1
        at jogamp.opengl.windows.wgl.WindowsWGLGraphicsConfigurationFactory.updateGraphicsConfigurationGDI(WindowsWGLGraphicsConfigurationFactory.java:459)
        at jogamp.opengl.windows.wgl.WindowsWGLGraphicsConfigurationFactory.updateGraphicsConfiguration(WindowsWGLGraphicsConfigurationFactory.java:251)
        at jogamp.opengl.windows.wgl.WindowsWGLGraphicsConfigurationFactory.updateGraphicsConfiguration(WindowsWGLGraphicsConfigurationFactory.java:184)
        at jogamp.opengl.windows.wgl.WindowsWGLGraphicsConfiguration.updateGraphicsConfiguration(WindowsWGLGraphicsConfiguration.java:133)
        at jogamp.opengl.windows.wgl.WindowsBitmapWGLDrawable.create(WindowsBitmapWGLDrawable.java:153)
        at jogamp.opengl.windows.wgl.WindowsBitmapWGLDrawable.<init>(WindowsBitmapWGLDrawable.java:61)
        at jogamp.opengl.windows.wgl.WindowsWGLDrawableFactory.createOffscreenDrawableImpl(WindowsWGLDrawableFactory.java:388)
        at jogamp.opengl.GLDrawableFactoryImpl.createGLDrawable(GLDrawableFactoryImpl.java:117)
        at jogamp.opengl.GLDrawableFactoryImpl.createOffscreenDrawable(GLDrawableFactoryImpl.java:202)
        at javax.media.opengl.awt.GLJPanel$SoftwareBackend.initialize(GLJPanel.java:1018)
        at javax.media.opengl.awt.GLJPanel.createAndInitializeBackend(GLJPanel.java:618)
        at javax.media.opengl.awt.GLJPanel.paintComponent(GLJPanel.java:368)
        at demos.jgears.JGears.paintComponent(JGears.java:99)
        at javax.swing.JComponent.paint(JComponent.java:1029)
        at javax.swing.JComponent.paintToOffscreen(JComponent.java:5124)
        at javax.swing.RepaintManager$PaintManager.paintDoubleBuffered(RepaintManager.java:1479)
        at javax.swing.RepaintManager$PaintManager.paint(RepaintManager.java:1410)
        at javax.swing.RepaintManager.paint(RepaintManager.java:1224)
        at javax.swing.JComponent._paintImmediately(JComponent.java:5072)
        at javax.swing.JComponent.paintImmediately(JComponent.java:4882)
        at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:785)
        at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:713)
        at com.jogamp.opengl.util.AWTAnimatorImpl$1.run(AWTAnimatorImpl.java:160)
        at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:199)
        at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:642)
        at java.awt.EventQueue.access$000(EventQueue.java:85)
        at java.awt.EventQueue$1.run(EventQueue.java:603)
        at java.awt.EventQueue$1.run(EventQueue.java:601)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:87)
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:612)
        at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
        at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
        at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)

Anyway I think I had better start a new topic to track this.

Andrew Bailey

Thank you for your responses.

I think it is extremely important that we have communication for this topic.  It is difficult to get access to all hardware that users have and this is the only way we can get our software to work with a wide range of hardware.

So, my function always returns false, or only when it fails?

Its odd that your chosen capabilities is offscreen (i.e., "offscr").   Maybe the auto detection function should rule these out and it isn't.  You might want to print all of the capabilties out (from inside my loop/function) to see if there are other capabilities, and if they are different between the times it works and the times it doesn't.

I am curious to know what you find.

Thanks,

Blaine

Andrew,

Just to let you know, in order to do stereoscopic 3D, you need to have quad-buffer support, such as NVidia Quadro cards.  It looks like you are using a GeForce GTS, which I believe does not have this support.

Blaine

Does it mean that it should work correctly on Windows 7 with an NVIDIA Quadro FX?

yes, you should be able to get 3D stereoscopic rendering using an NVIDIA Quadro FX assuming that you have some sort of hardware or display that can show it (e.g., NVIDIA 3D Vision)

http://www.nvidia.com/object/quadro_pro_graphics_boards.html

But the NVIDIA test programs, and the NVIDIA Stereoscopic 3d Video Player and 3d Vision Photo Viewer, show stereoscopic 3d with the glasses so the hardware and drivers are ok. Theres even code on the NVIDIA web site and references to OpenGL.

I really hope that we can get it to work!

I started another topic to track this as its a separate problem.
http://forum.jogamp.org/Jogl-stereoscopic-support-for-GeForce-GTS-350M-Nvidia-3d-vision-LCD-shutter-glasses-td2845822.html

Thanks

It is strange because some other OpenGL experts confirmed me that the quad buffer used for the glasses is available only on NVIDIA Quadro FX and this problem has nothing to do with Java as they use OpenGL both directly in C/C++ and in Java through JOGL. However, 3D Vision works with Direct3D even with NVIDIA GTS on Windows but it is not exposed in OpenGL.

Maybe Blaine can confirm.

On Thursday, April 21, 2011 11:46:26 am gouessej [via jogamp] wrote:
>
> It is strange because some other OpenGL experts confirmed me that the quad
> buffer used for the glasses is available only on NVIDIA Quadro FX and this
> problem has nothing to do with Java as they use OpenGL both directly in
> C/C++ and in Java through JOGL. However, 3D Vision works with Direct3D even
> with NVIDIA GTS on Windows but it is not exposed in OpenGL.
>

Yup, I have read the same .. :(
They have some D3D hack to support some windows games
with their own method of generating a stereo effect.
However .. this does not support true stereo, ie where you
actually render the scene twice (final fp step).

Too bad, both companies NV/AMD withold stereo from the 'consumers',
only offer it to the pretty expensive pro cards.

~Sven


> Maybe Blaine can confirm.
>
> -----

So does that mean that if I use java3d with d3d then it should work?

On Friday, April 22, 2011 06:51:07 pm apps4u [via jogamp] wrote:
>
> So does that mean that if I use java3d with d3d then it should work?

I don't know.

If it works, probably kind of tweaked, ie the 'engine' does some faked
stereoscopy thing, ie 1 FB from your application to 2 FBs (left/right).
But this is just a guess, since I don't do D3D .. thought they do some
app level tweaking or so .

If somebody finds out more .. pls post those news here.

~Sven