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
[quote]Please check if the changes made work for you and let me know if something is broken.Yuri
[/quote]
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…
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
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
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:
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
Sorry… my bad. My classpath wasn’t pointing to new builds :-[ Everything works great!
[quote]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.
[/quote]
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…
Same here, with gf4 ti4200.
I shall wait till these problems are ironed out before updating xith.org with the new versions.
Will.
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
[quote]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.
[/quote]
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.
[quote]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.
[/quote]
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.
Actually, Bombadil, I get that funked up screen with my geforce 4 when I maximize the window, as well.
Screenshot:
[quote]Actually, Bombadil, I get that funked up screen with my geforce 4 when I maximize the window, as well.
[/quote]
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.
Hi,
Creating this ghost window is currently documented JOGL behavior.
Quote from JOGL sources:
[quote] // 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.
[/quote]
…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
[quote]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.
[/quote]
I see. Thanks Yuri for that information. I haven’t touched the Jogl documentation for ages - since I’m a lucky Xith user.
[quote]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).
[/quote]
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.
[quote]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.
[/quote]
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 (~).
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…
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
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 
great to see things moving so fast, thanks Yuri
Will.
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?