Cave working, but not synchronizing

[csm5125]

So, thanks to all of the help on the forums, I got JRViewer -vr working on all five walls of our cave. Overall, it's very impressive, but the walls don't always render in synch, particularly when a lot is going on, like the matheon bear with lines and points displaying. It's especially noticeable when the pointer runs between walls, where one wall will have the pointer out-pace the other, which will eventually catch up.


I'm running the master with:
java -cp [LIBRARIES HERE]
-Djava.library.path=jni/win32
-Xms1024M -Xmx1568M
-Dde.jreality.scene.Viewer=de.jreality.portal.PortalServerViewer
-Dde.jreality.viewerapp.env=portal
-Dde.jreality.scene.tool.Config=portal
-Djreality.jogl.quadBufferedStereo=true
-Djreality.config=portal/portal.master
-Dde.jreality.ui.viewerapp.autoRender=true
-Dde.jreality.ui.viewerapp.synchRender=true de.jreality.plugin.JRViewer -vr

and the clients with:
java -Xms256M -Xmx512M
-Djava.library.path=jni/win32
-Djreality.jogl.quadBufferedStereo=true
-Djreality.config=portal/portal.back
-jar lib/smrj-client.jar

Should I be using different flags? This originally was used to open ViewerVR and was primarily copied from the CAVE setup examples.

I'm running this on Windows XP and the setup that I'm working on is able to use NVIDIA hardware synchronization.

[csm5125]

After digging through the code a bit, I realized that ViewerApp is deprecated and not referenced by the PortalServerViewer, which instead references Viewer. This explains the lack of synchRender

To make use of the hardware rendering, I need to make a call to a function that requires the openGL contexts. I'm having trouble finding just where exactly I should modify the code to make use of it. I originally thought that de.jreality.jogl.JOGLRenderer was responsible for this, but now I'm not sure.

Can anyone direct me to the right file?

Also, I'm using the WGL_NV_swap_group functions, which are located in com.sun.opengl.impl.windows.WGLExt

[Andre]

Sorry I forgot to answer.

This is strange, normally this set-up shouldn't run out of sync. Last week I just tried the remote-controlled version. I'll try your set-up tomorrow at our cave and look what happens. I'll write my results tomorrow.

[csm5125]

Thanks for responding.

Just a note: The walls seem to run in sync with light to normal operation (i.e. rotating view, translating object, etc), but during excessive movement, especially with the wand's pointer, the asynchronicity becomes apparent.

[steffen]

Hi, I'll also look into this, but for the next two weeks I am quite busy with other things...

Steffen.

[Andre]

Sorry, but I can't reproduce your problem.

I was running the ViewerVR example with the matheon bear with points and lines displayed. It was really slow, but all our three walls were synchronal. Same with JRViewer -vr and matheon bear.

Also I was running a physics example where I got sync-problems with the remote-set-up, with the normal portal-set-up everything worked fine.Tomorrow I'll try an other example, where I know, that we had sync-problems with the remote-setting too, but we never tried this example with the normal portal-set-up. Its a simulation of a vector field with a lot of particles in the scene.

cheers Andre

[Andre]

The last two days I tried to fix the vector field application without any success, so I couldn't run this final test, sorry. I'm now waiting for the help of the programmer.

[csm5125]

Hello,

Can you tell me what kind of synchronization you're using? My setup uses nvidia ForceWare-compatible graphics cards.

[steffen]

We do not use hardware synchronization at all...

[csm5125]

Just an update:

I have now tried the Matheon bear example with the remote setup as well.

It turns out that whichever screen the bear is on lags by what appears to be one frame (which is very obvious when the simulation starts chugging 2-3 fps). This happens in both the standard setup, and the remote setup.

I would really like to use jReality for our project, but I can't move on until I figure out these problems.

Any suggestions for how I can handle this?

[steffen]

Sounds like we need to make use of the hardware synchronization feature of the graphics cards. Do you know how this works and how other software packages use it?

Steffen.

[csm5125]

Thanks for all of your help so far.

Hardware synchronization is specific to vendor and platform.

My setup uses NVIDIA Quadro FX 5800 cards with Genlock cards and 32bit Windows XP.

I'm using the functions from the WGL_NV_swap_group functions in the WGL extension libraries. The drivers for the functions are available with NVIDIA quadro cards, and WGLExtImpl offers an implementation of them in JOGL. I know that there are also linux drivers available, but I am not aware of the specifics.

Because of all of the specifics, I understand why you didn't originally implement this.

I've actually been searching around in the rendering code so that I could do this myself. The actual code to make use of the hardware sync is simple, but I have been having trouble finding where to insert it.

Basically, I need the GLContext, the GLCapabilities, and the GLCapabilitiesChooser.
These are used to get the WindowsGLContext.

It looks like de.jreality.jogl.Viewer is the correct place to implement this.
(Is this the right file when I'm using PortalServerViewer as my viewer?)

Additionally, I need the hardware device context (hdc), which is probably the same thing as the window handle (which can be grabbed from a GLWindow). Can you direct me to the file/class where I could get the window handle? This would, hopefully, be whatever the viewer is rendered/placed in.

I know that I'm asking a lot of questions, but this is the end of my problems before actual development.

[steffen]

Basically, I need the GLContext, the GLCapabilities, and the GLCapabilitiesChooser.
These are used to get the WindowsGLContext.

It looks like de.jreality.jogl.Viewer is the correct place to implement this.
(Is this the right file when I'm using PortalServerViewer as my viewer?)

Yes, this is the Viewer that is also used with the portal backend. I think the code should go into the JoglRenderer class, but Charles knows the code much better...

Charles, can you give more hints about where to add the method calls?

Steffen.

[csm5125]

Ok, I think I solved my problem.

As far as I can tell, the version of JOGL used by jReality does not support what I need to do.

Basically, I need to call the javax.media.NativeWindow.getSurfaceHandle() method in order to get the HDC. However, this is only supported in newer versions of JOGL, which is not backwards-compatible with old JOGL. My current solution is to go through the jogl code and update it to use the new libraries.

Thanks for your help, and if anyone can find something to let me use the old JOGL library, that would save me a great deal of work.

[gunn]

I've been the primary developer of the JOGL backend. Unfortunately I have no ideas how to implement hardware syncronization using JOGL 1.1.x. Have you looked at the JOGL forum archives? There might be a post there related to this.

It might make sense for jReality itself to move support from JOGL 1.1 to JOGL 2 (I'm assuming that's the newer version of JOGL you're referring to). We haven't really considered the costs of such an upgrade. If you care to share your impressions of what's involved -- at whatever level you've managed to investigate the issue -- I and others involved in jReality development, would be certainly interested to hear about it.