Picking causes hiccup?

Engines, Libraries and Tools Xith3D Forums
#1

I’ve implemented picking in my application and with the help of the Tutorial and Xith3d’s test classes it’s pretty OK.

In my scenery there are several 3d objects but just a few of them shall be pickable. So I’ve just set these with setPickable(…) to true (plus the root scene’s branchgroup).
Whilst picking works correcty, I see a hiccup in the animation flow of my scenery if I do

PickRenderResult[] res = myView.pick(canvas3d, posx, posy, 2, 2);

and one of the pickable nodes is visible in the current view. Which means if I move the camera so they aren’t visible anymore the above call doesn’t cause any hiccups.

(The pick() method is being called after the myView.RenderOnce() method call, no multithreading problems. The Xith3d version is the 2003-11-24_cvs community build.)

Does anybody have experienced anything similar? Or is it related to my application only? (Difficult to judge where the problem could be.)

Nota bene: Xith3DPickRenderTest runs smoothly without hiccups on the same machine.

#2

When do you perform picking (for instance after a mouse click, a mouse move, …)?

#3

[quote]When do you perform picking (for instance after a mouse click, a mouse move, …)?
[/quote]
Well, in the main-loop-thread. The other thread, the Swing one, stores all key events/mouseclicks/mouspos. The main-thread does do basically every 1/50 seconds:
° do simulation(),
° do renderOnce()
° if stored mouseklick do picking

If the pickable 3d objects aren’t in the frustum the picking doesn’t cause any hiccups.
If however any pickable object is in the frustum, the same picking call does cause hiccups.

Probably I am doing something silly. Would an jnlp example help? Hardly I guess…

#4

Maybe some code can help.

What you can do is to store the picking results in a class variable to avoid to much garbage collection, but actually this should not matter, if you only pick when you click the mouse. I have an app which performs picking everytime the mouse moves without hiccups.

#5

[quote]Maybe some code can help.
[/quote]
Since it’s not a too small application I don’t know which parts I should quote…

[quote]What you can do is to store the picking results in a class variable to avoid to much garbage collection, but actually this should not matter, if you only pick when you click the mouse.
[/quote]
I avoided the picking result at all by just calling the myView.pick(…) method but with no effect: still hiccup.
Maybe something is strange in my scenegraph (I remember Kev once stored an empty Shape3d or such).
However if I empty it completely there’s nothing to pick. :wink:

[quote]I have an app which performs picking everytime the mouse moves without hiccups.
[/quote]
Does you do something different compared to the Xith3d picking tutorial example?

Would really makes me wonder: if no pickable object is in the frustum the scenery’s animation is smooth as it should… I think this is strange.

#6

Hi,

Sorry for that, but looks like I missed this topic because of my English: I just treated hiccup as something like “lock up” or “hang up”…

OK, now back to the subject.

I guess you are using standard build of JOGL. If so, then you WILL have a flash/flicker/short pause on your animation caused by call to any picking method [the actual sympthoms depend on the graphic card and driver].

The reason for that is following: current official abd CVS versions of JOGL do not expose explicit control over SwapBuffers calls to the applications that use JOGL. For On-screen contexts, especially on Windows, JOGL explicitly calls SwapBuffers or equivalent code just after rendering of next frame finished, i.e. right after returning from GLEventListener.display(…).

Currently Xith3D picking mechanism uses OpenGL to perform picking, i.e. renders one frame in special GL_SELECT rendering mode. In this mode, no pixels are produced, but JOGL does not care about this and calls SwapBuffers anyway.

In typical configuration on Windows you have wait-for-vertical-retrace for SwapBuffers turned ON by default, so you see recognizable delay/pause/flicking (I guess you call this thing as “hiccup”) because of driver is waiting for nearest VSYNC to perform nice buffer swapping.

This problem has been discussed already several times and I think I highlighted it somewhere on earlier threads of this forum. There is also discusson on this in JOGL forum: http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=jogl;action=display;num=1063385846 “Vote time: RFE - Developer controlled swap buffer”.

To eliminate this problem, you need modified version of JOGL (only java-side code have to be modified), a version that lets you disable automatic buffer swapping for pick rendering passes.

CanvasPeerImpl in Xith3D already contains all the neccessary code to add this functionality - there is commented out line in renderStart(…) method:

        // canvas.setNoSwapBuffers(pickMode);

In my local version I have this uncommented, because of I work with modified version of JOGL, which includes this and some other minor patches from JOGL IssueZilla.

Because of this is ready and easy to add, I am just waiting for official JOGL release, which will have the functionality of disabling automatic swap buffers control, to uncomment this code and forget about this issue.

Yuri

#7

No problem. Could well be that “hiccup” is the utterly wrong word for what I tried to say - because I am no English man neither (those have noticed that for long).

[quote]I guess you are using standard build of JOGL.
[/quote]
Yes.

[quote]If so, then you WILL have a flash/flicker/short pause on your animation caused by call to any picking method [the actual sympthoms depend on the graphic card and driver].
[/quote]
I see. With the Detonator driver I am using, the “short pause” in the animation is well visible.

(Thanks for the good technical explanation why this effect is visible)

[quote]This problem has been discussed already several times and I think I highlighted it somewhere on earlier threads of this forum.
[/quote]
This time I checked the FAQ first (who maintains it? smiley), then did a search on this forum with keyword “picking” (unfortunately no regexp allowed in the search, hehe) and no result popped up… Still I could well have missed the important stuff.
The Jogl forum I didn’t read during the last weeks…

[quote]To eliminate this problem, you need modified version of JOGL (only java-side code have to be modified), a version that lets you disable automatic buffer swapping for pick rendering passes.
(…)
In my local version I have this uncommented, because of I work with modified version of JOGL, which includes this and some other minor patches from JOGL IssueZilla.
[/quote]
Oh, I see.

[quote]Because of this is ready and easy to add, I am just waiting for official JOGL release, which will have the functionality of disabling automatic swap buffers control, to uncomment this code and forget about this issue.
[/quote]
Sounds perfect. If we could expect this to happen to Jogl within the next two months I’m well able to wait. Otherweise I’m going to ask (you) for a Jogl-newbie-guide to make the Jogl sources compatible with that uncommented line of code in Xith3d.

Thanks again for your help, Yuri.