Changes to match latest JOGL build

[Yuri Vl. Gushchin]

I just committed to CVS some changes that make latest JOGL CVS build working with Xith3D. These updates fix an issue with wrong pixel format choosing.

Additionally, I adjusted implementation of GL_SELECT pick mode to disable extra buffer swap on picking rendering passes (this was producting single-frame flickers). For more details on this search for my older postings about picking in this forum.

Please check if the changes made work for you and let me know if something is broken.

Yuri

[Bombadil]

Please check if the changes made work for you and let me know if something is broken.Yuri

Three small observations with this new version plus new Jogl... :-)

a) I'm not sure when the focus behaviour changed but until a recent Xith+Jogl version I could do the following to set the focus of the starting app to the Xith's Canvas3d:
 xithcanvas3D.get3DPeer().getComponent().requestFocus();
With the new versions this does seem to have no effect. Just when I click with the mouse inside the Canvas3d, then the focus is there... How could I do this programmatically again?

b) GL_SELECT: works fine now I think (the single-frame flicker is gone). However, when I load at least one large 3d model (with many polgons) and set all its nodes to setPickable(true), and then call view.pick(..) it takes ages (3++ seconds) until the call returns. No matter where I click and if there's a hit or no hit result.
How would I do it correctly so that it is fast?

c) OldStyleGLCapabilitiesChooser.java
 private static final boolean DEBUG = true;
The debug=true floods the screen... :-)

[pedro]

b) GL_SELECT: works fine now I think (the single-frame flicker is gone). However, when I load at least one large 3d model (with many polgons) and set all its nodes to setPickable(true), and then call view.pick(..) it takes ages (3++ seconds) until the call returns. No matter where I click and if there's a hit or no hit result.
How would I do it correctly so that it is fast?

I have the same problem. Picking takes ages for me too. I think an altervative to solve this is to implement our own picking, which could be designed in way that is efficient for us.

I use picking to select objects that are on the scenegraph, but since I keep a reference of all those objects anyway. I was thinking that checking which object contains a given point might be faster than using the current picking ray algorithm. I do not really know why it takes so long for jogl to find those objects, and I might not be aware of all the technical problems with the approach I consided above. But it's what I'm considering to do right now.  

(Do you think that if we setPickable to false to some shapes that we know are not in the picking area, that might improve performance? Not sure if just the act to check which shapes are probably in the picking area might take too long anyway.. well.. it's an open problem :))


Yuri, I'll try the new changes from CVS, and see how it goes. Thanks :)

Games published by our own members! Check 'em out!

[gismo]

b) GL_SELECT:
I can confirm this although I definitely use an older Xith3D and JOGL build. Like bombadil said it takes about 3 seconds to pick a Shape with prox. 60000 Polygons.
I thought this might be related to my scenegraph structure: The shape is about 6 nodes under the root, so I had to set each one pickable...
Since then, I haven't done any additional tests.

gismo

[pedro]

I updated my CVS tree to reflect the new changes, and I also got the jogl library and I get the following error trying to run Xith:

1   2   3   4   5   6   7   8   9   10   11   12   13

java.lang.AbstractMethodError: com.xith3d.render.jogl.OldStyleGLCapabilitiesChooser.chooseCapabilities(Lnet/java/games/jogl/GLCapabilities;[Lnet/java/games/jogl/GLCapabilities;)I       at net.java.games.jogl.impl.windows.WindowsGLContext.choosePixelFormatAndCreateContext(WindowsGLContext.java:283)       at net.java.games.jogl.impl.windows.WindowsOnscreenGLContext.create(WindowsOnscreenGLContext.java:204)       at net.java.games.jogl.impl.windows.WindowsGLContext.makeCurrent(WindowsGLContext.java:129)       at net.java.games.jogl.impl.windows.WindowsOnscreenGLContext.makeCurrent(WindowsOnscreenGLContext.java:110)       at net.java.games.jogl.impl.GLContext.invokeGL(GLContext.java:199)       at net.java.games.jogl.GLCanvas.displayImpl(GLCanvas.java:182)       at net.java.games.jogl.GLCanvas.display(GLCanvas.java:82)       at com.xith3d.render.jogl.CanvasPeerImpl.render(CanvasPeerImpl.java:1084)       at com.xith3d.scenegraph.View.renderOnce(View.java:734)       at com.xith3d.scenegraph.View.renderOnce(View.java:667)       at third.Main.run(Main.java:158)       at java.lang.Thread.run(Thread.java:536)

I'm trying to see what's wrong, but if you could spot it easier, let me know



EDIT: use [ code ] tag

[pedro]

Sorry... my bad. My classpath wasn't pointing to new builds  Everything works great!

[Bombadil]

b) GL_SELECT:
I can confirm this although I definitely use an older Xith3D and JOGL build. Like bombadil said it takes about 3 seconds to pick a Shape with prox. 60000 Polygons.

Yes, it's an old issue, but I thought maybe it's gone with the new Xith version. ;-)
It looks like the more pickable polygons there are in the scene, the slower it is: with several models and up to 100 000 polygons it takes about 7 seconds until the pick click call returns... :-(  So currently I can't use this method  and like Pedro I have to find another way how to achieve fast picking... (No idea how.)

As for point a): Does setting the focus to your Canvas3d's GlCanvas work for you (per code, with requestFocus() method) ?

I found an issue d): With the new version of Xith and Jogl (and my Radeon Ati card) I always get two Java windows when I run one Xith app (for example the test package demos): one real window which shows the 3d stuff, and a ghost window which hasn't got any visible area but it's there on the Window's taskbar... The weird thing now is, in case I right click the taskbar's icon of this "ghost" window and say "maximize" the whole desktop is filled with garbage and "rien ne vas plus" visually: the system doesn't hang but shows a wrong Vram page, so you can't click/do anything.
Anybody could confirm this? Or is it "just" me...

[byteblock]

Anybody could confirm this? Or is it "just" me...

Same here, with gf4 ti4200.

[William Denniss]

I shall wait till these problems are ironed out before updating xith.org with the new versions.

Will.

[Yuri Vl. Gushchin]

Hi,

I confirm that on my system two windows are created, but system does not show invalid behavior for me (NVidia GeForce 440 Go). Most likely this is a JOGL issue, because of window creation code is not changed in Xith3D, but this is for deeper investigation.

As of GL_SELECT, this is definitely a driver issue. If someone can create a test case which also measures picking performance, then we can run it across different systems.

Yuri

Games published by our own members! Check 'em out!

[Bombadil]

I confirm that on my system two windows are created, but system does not show invalid behavior for me (NVidia GeForce 440 Go). Most likely this is a JOGL issue, because of window creation code is not changed in Xith3D, but this is for deeper investigation.

Ok, thanks for the confirmation Yuri and Byteblock.
My mentioned Vram picture (when maximizing the ghost windows) is probably an ATI issue - it tends to be very sensible with OpenGL things.
Since we or rather the JOGL guys have to find a way to make that ghost window dissapear again, I don't think we need to mind the ATI behaviour.

As of GL_SELECT, this is definitely a driver issue. If someone can create a test case which also measures picking performance, then we can run it across different systems.

OK. Since this isn't strictly related to the current Xith version I've started a new thread with a testcase here.


PS: Anybody managed to call a requestFocus() method for his GlCanvas? If so: could you tell me how? Because here it doesn't work anymore with the new Xith+Jogl version. Thanks. :-)

[byteblock]

Actually, Bombadil, I get that funked up screen with my geforce 4 when I maximize the window, as well.

Screenshot:

[Bombadil]

Actually, Bombadil, I get that funked up screen with my geforce 4 when I maximize the window, as well.

Oh well, thanks for your info. Yes, it looks like this...

Remembers me to when a Sinclair ZX Spectrum or Amstrad CPC crashed - visually much more interesting than a dull blue BSOD today. ;-)

[Yuri Vl. Gushchin]

Hi,

Creating this ghost window is currently documented JOGL behavior.

Quote from JOGL sources:

 // On Windows we want to be able to use some extension routines like
 // wglChoosePixelFormatARB during the creation of the user's first
 // GLContext. However, this and other routines' function pointers
 // aren't loaded by the driver until the first OpenGL context is
 // created. The standard way of working around this chicken-and-egg
 // problem is to create a dummy window, show it, send it a paint
 // message, create an OpenGL context, fetch the needed function
 // pointers, and then destroy the dummy window and context. In JOGL
 // since we closely associate the contexts with components we leave
 // the dummy window around as it should not have a large footprint
 // impact.

...but as you see, impact is relatively high - technically there is nearly no impact, but visually it causes a lot of confusion.

As of VRAM display (wrong content etc). I can easily imagine that resizing 0x0 GL context to a full screen with no clear/paint operations may produce this (and it definitely produces this kind of image).

So, we should file a bug report to JOGL issuezilla and point them to this thread to inform JOGL developers about our opinion on this.

Yuri

[Bombadil]

Hi,

Creating this ghost window is currently documented JOGL behavior.

Quote from JOGL sources:

...but as you see, impact is relatively high - technically there is nearly no impact, but visually it causes a lot of confusion.

I see. Thanks Yuri for that information. I haven't touched the Jogl documentation for ages - since I'm a lucky Xith user. :-)

As of VRAM display (wrong content etc). I can easily imagine that resizing 0x0 GL context to a full screen with no clear/paint operations may produce this (and it definitely produces this kind of image).

Indeed. This dummy "ghost window" causes confusion and even more: as I reported earlier when the dummy window is being maximized (and you never know what your users do) there's no mouse pointer anymore (on my Ati card PC): even hitting Ctrl-Alt-Del doesn't bring the desktop back: you're lost in ghost space.

So, we should file a bug report to JOGL issuezilla and point them to this thread to inform JOGL developers about our opinion on this.

Yes, we definitely have to do this. Two windows for one Xith/Jogl app isn't a solution. As with the Highlander, "there can only be one". :-)
Does somebody already file such a bug report? If so, please tell us, otherwise I'm going to do so tomorrow (~).

[pedro]

There is a new jogl build: http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=jogl;action=display;num=1081799754

I think there will be more work coming to the Xith guys

First thing I realised was that it uses some buffers instead of arrays. I tried used the new build with xith, and it was ok until I tried to pick something. Their new glSelectBuffer takes different parameters.



Technology always moves too fast...

[Bombadil]

Oh well, Yuri is fast... :-)

cvs@xith3d.dev.java.net      
Betreff:       CVS update: /xith3d/src/com/xith3d/render/jogl/
User: yvg    
Date: 04/04/22 00:49:52
Modified:
/xith3d/src/com/xith3d/render/jogl/
 CanvasPeerImpl.java

[pedro]

WOW!

[pedro kindly bows, in awe, to Yuri]

ps: I actually wasted 20mins trying to understand buffers to adapt to the change, but all in vain :p

[William Denniss]

great to see things moving so fast, thanks Yuri

Will.

[Ken Russell]

Please file an issue on the JOGL web page about the dummy window problem. This was added for full-scene antialiasing (FSAA) support on Windows though it's clear from the problems being reported that another solution is going to be needed.

With the change to JOGL to use direct buffers for glSelectBuffer / glFeedbackBuffer, have the selection problems been addressed?

[Bombadil]

Please file an issue on the JOGL web page about the dummy window problem. This was added for full-scene antialiasing (FSAA) support on Windows though it's clear from the problems being reported that another solution is going to be needed.

Thanks Ken for the answer; I've just filed an issue (#75).

With the change to JOGL to use direct buffers for glSelectBuffer / glFeedbackBuffer, have the selection problems been addressed?

Probably a Xith3d developer should answer the question, because I don't know if further adaptions in the Xith sources will have to be done.
With the newst Xith+Jogl version the very long time taken for a pick selection is still there unfortunately. So it's the same some (Xith+Jogl) users reported in the thread GL_SELECT causes long delay.

[Bombadil]

Btw my earlier reported issue a) - the missing focus - has to do with that ghost window, too. It steals the focus...

[Ken Russell]

We just pushed a build (1.1 beta 02) that disposes of the dummy window right after it's created. Could you test with this build and let us know whether it works or if there are more problems?

[Yuri Vl. Gushchin]

Ken,

I confirm that there is no problem with ghost window anymore.

As of GL_SELECT mode, I think it worked and should work stable in both cases (arrays and buffers) because of picking code in Xith3D implemented such a way to keep hard reference to allocated buffer until core is 100% sure that no selection will happen against it (in short words, we ensure that buffer will not be garbage collected until we finish selection procedures).

I personally never had problems with crashes caused by selection (except of early development stages), not remember reports about such crashes from Xith3D users (I mean those who access selection via Xith3D).

As of slow picking, I think the reason is that in drivers selection seems to be performed in software, and it looks non-hardware-accelerated, so number of triangles is really an issue, but this is more OpenGL question than JOGL or Xith3D. I plan to perform more tests on this subject using plain C implementation of the test.

Yuri

[Bombadil]

Formerly the ghost window used to steal the focus of the main Xith/Jogl GlCanvas window. Since the ghost window isn't visible anymore since the newest Jogl beta release, the focus works again as expected. :-)

[William Denniss]

The new JOGL/Xith3D work great on my dev box (with nVidia card) - but now fails on my laptop (with a low spec SiS650 card).

The previous version of JOGL and Xith3D did work.

This is my error message, can anyone explain to me what's going wrong here?

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19   20   21   22   23   24   25   26   27   28   29   30   31   32   33   34   35   36   37   38   39   40   41   42   43   44   45   46   47   48   49   50   51   52   53   54   55   56   57   58   59   60   61   62   63   64   65   66   67   68   69   70   71   72   73   74   75

net.java.games.jogl.GLException: Error re-describing the chosen pixel format       at net.java.games.jogl.impl.windows.WindowsGLContext.choosePixelFormatAndCreateContext(WindowsGLContext.java:456)       at net.java.games.jogl.impl.windows.WindowsOnscreenGLContext.create(WindowsOnscreenGLContext.java:204)       at net.java.games.jogl.impl.windows.WindowsGLContext.makeCurrent(WindowsGLContext.java:133)       at net.java.games.jogl.impl.windows.WindowsOnscreenGLContext.makeCurrent(WindowsOnscreenGLContext.java:110)       at net.java.games.jogl.impl.GLContext.invokeGL(GLContext.java:203)       at net.java.games.jogl.GLCanvas.reshape(GLCanvas.java:97)       at java.awt.Component.setBounds(Unknown Source)       at java.awt.BorderLayout.layoutContainer(Unknown Source)       at java.awt.Container.layout(Unknown Source)       at java.awt.Container.doLayout(Unknown Source)       at java.awt.Container.validateTree(Unknown Source)       at java.awt.Container.validate(Unknown Source)       at java.awt.Window.show(Unknown Source)       at net.java.games.jogl.impl.windows.WindowsGLContextFactory.getDummyGLContext(WindowsGLContextFactory.java:124)       at net.java.games.jogl.impl.windows.WindowsGLContext.choosePixelFormatAndCreateContext(WindowsGLContext.java:264)       at net.java.games.jogl.impl.windows.WindowsOnscreenGLContext.create(WindowsOnscreenGLContext.java:204)       at net.java.games.jogl.impl.windows.WindowsGLContext.makeCurrent(WindowsGLContext.java:133)       at net.java.games.jogl.impl.windows.WindowsOnscreenGLContext.makeCurrent(WindowsOnscreenGLContext.java:110)       at net.java.games.jogl.impl.GLContext.invokeGL(GLContext.java:203)       at net.java.games.jogl.GLCanvas.displayImpl(GLCanvas.java:186)       at net.java.games.jogl.GLCanvas.display(GLCanvas.java:74)       at com.xith3d.render.jogl.CanvasPeerImpl.render(CanvasPeerImpl.java:1100)       at com.xith3d.scenegraph.View.renderOnce(View.java:731)       at com.xith3d.scenegraph.View.renderOnce(View.java:664)       at com.xith3d.test.CubeTest.<init>(CubeTest.java:181)       at com.xith3d.test.CubeTest.main(CubeTest.java:201)       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)       at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)       at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)       at java.lang.reflect.Method.invoke(Unknown Source)       at com.sun.javaws.Launcher.executeApplication(Unknown Source)       at com.sun.javaws.Launcher.executeMainClass(Unknown Source)       at com.sun.javaws.Launcher.continueLaunch(Unknown Source)       at com.sun.javaws.Launcher.handleApplicationDesc(Unknown Source)       at com.sun.javaws.Launcher.handleLaunchFile(Unknown Source)       at com.sun.javaws.Launcher.run(Unknown Source)       at java.lang.Thread.run(Unknown Source)

By the way, I have updated JOGL in the CVS, and the official xith.org JWS demos.

Thanks,

Will.

[Yuri Vl. Gushchin]

The reason for this is that since 1.1 JOGL has completely different mechanism of choosing pixel format. I tried to preserve the old one by providing OldStyleGLCapabilitiesChooser in jogl renderer package, but it seems to fail in some cases.

Can you please try out some of pure JOGL demos on the same PC and let me know if they work or not?

Yuri

[William Denniss]

thanks for the reply Yuri, I should have done that anyway.

No - the latest JOGL demos do not work, although past versions did.  I posted a thread in the JOGL forum: http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=jogl;action=display;num=1082976294;start=0

Cheers,

Will.

[SpuTTer]

Im getting similar / possible same error now that Ive upgraded to the new Xith and JOGL.

I tried todays nightly build that Ken posted in your other post there, but it still fails...

Here is what I'm getting:

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19   20   21   22   23   24   25

Exception in thread "main" java.lang.UnsatisfiedLinkError: dispatch_wglGetExtensionsStringARB         at net.java.games.jogl.impl.windows.WindowsGLImpl.dispatch_wglGetExtensionsStringARB(Native Method)         at net.java.games.jogl.impl.windows.WindowsGLImpl.wglGetExtensionsStringARB(WindowsGLImpl.java:33296)         at net.java.games.jogl.impl.windows.WindowsGLContext.choosePixelFormatAndCreateContext(WindowsGLContext.java:277)         at net.java.games.jogl.impl.windows.WindowsOnscreenGLContext.create(WindowsOnscreenGLContext.java:204)         at net.java.games.jogl.impl.windows.WindowsGLContext.makeCurrent(WindowsGLContext.java:133)         at net.java.games.jogl.impl.windows.WindowsOnscreenGLContext.makeCurrent(WindowsOnscreenGLContext.java:110)         at net.java.games.jogl.impl.GLContext.invokeGL(GLContext.java:203)         at net.java.games.jogl.GLCanvas.reshape(GLCanvas.java:97)         at java.awt.Component.setBounds(Component.java:1664)         at java.awt.BorderLayout.layoutContainer(BorderLayout.java:691)         at java.awt.Container.layout(Container.java:1020)         at java.awt.Container.doLayout(Container.java:1010)         at java.awt.Container.validateTree(Container.java:1092)         at java.awt.Container.validate(Container.java:1067)         at java.awt.Window.show(Window.java:461)         at net.java.games.jogl.impl.windows.WindowsGLContextFactory.getDummyGLContext(WindowsGLContextFactory.java:124)         at net.java.games.jogl.impl.windows.WindowsGLContext.choosePixelFormatAndCreateContext(WindowsGLContext.java:264)         at net.java.games.jogl.impl.windows.WindowsOnscreenGLContext.create(WindowsOnscreenGLContext.java:204)         at net.java.games.jogl.impl.windows.WindowsGLContext.makeCurrent(WindowsGLContext.java:133)         at net.java.games.jogl.impl.windows.WindowsOnscreenGLContext.makeCurrent(WindowsOnscreenGLContext.java:110)         at net.java.games.jogl.impl.GLContext.invokeGL(GLContext.java:203)         at net.java.games.jogl.GLCanvas.displayImpl(GLCanvas.java:186)         at net.java.games.jogl.GLCanvas.display(GLCanvas.java:74)         at com.xith3d.render.jogl.CanvasPeerImpl.render(CanvasPeerImpl.java:1100

Same thing?

I have a Geforce 3 ti200. Athlon 1800+. 1.4.2_04, Windows XP

[William Denniss]

AFAIK the nightly build has not yet been built yet

I'm waiting for the build on the morning of 27th.

It makes it hard when they don't post what timezone the builds are done it but one assumes it's somewhere in America.

Will.