Re: Mouse selection
Posted by Sven Gothel on Mar 01, 2012; 4:34pm
URL: https://forum.jogamp.org/Mouse-selection-tp3787468p3790980.html
On 03/01/2012 05:07 PM, elect [via jogamp] wrote:
>
>
> And what about the idea suggest by Demon in the first answer?
>
> http://stackoverflow.com/questions/5543401/opengl-mouse-picking-strategy
>
> Reading depth of 1 pixel (the one corresponding to the mouse position) and
> then use gluUnProject to get all the other coordinates...
>
> It looks easy and simple.. what you think about?This differs w/ the type of detection only, ie. false color vs. view/model
coordinate transformation.
As Julien pointed out, sure, glReadPixel takes a roundtrip (glFinish/sync ..
read .. ). As mentioned, one could use PBO on desktop when rendering is done
in a seperate buffer and if the click result can wait 1 frame let's say.
even though this would not blocking fluent rendering, the click response
would be '1 frame late':
Event based selection async w/ PBO and FBO
frame 1 - render to dedicated FBO for selection
and start glReadPixel w/ PBO (async)
frame 2 - sync data of glReadPixel (probably done by now)
and analyze it via false color per object
-or-
glUnProject of winx/winy and depth (winz).
If glReadPixel becomes an performance issue (1 pixel read),
I would do actual test on those different
refinements of the technique. Guess it's use-case dependent.
Good discussion.
~Sven
URL: https://forum.jogamp.org/Mouse-selection-tp3787468p3790980.html
On 03/01/2012 05:07 PM, elect [via jogamp] wrote:
>
>
> And what about the idea suggest by Demon in the first answer?
>
> http://stackoverflow.com/questions/5543401/opengl-mouse-picking-strategy
>
> Reading depth of 1 pixel (the one corresponding to the mouse position) and
> then use gluUnProject to get all the other coordinates...
>
> It looks easy and simple.. what you think about?
coordinate transformation.
As Julien pointed out, sure, glReadPixel takes a roundtrip (glFinish/sync ..
read .. ). As mentioned, one could use PBO on desktop when rendering is done
in a seperate buffer and if the click result can wait 1 frame let's say.
even though this would not blocking fluent rendering, the click response
would be '1 frame late':
Event based selection async w/ PBO and FBO
frame 1 - render to dedicated FBO for selection
and start glReadPixel w/ PBO (async)
frame 2 - sync data of glReadPixel (probably done by now)
and analyze it via false color per object
-or-
glUnProject of winx/winy and depth (winz).
If glReadPixel becomes an performance issue (1 pixel read),
I would do actual test on those different
refinements of the technique. Guess it's use-case dependent.
Good discussion.
~Sven
signature.asc (910 bytes) | Free forum by Nabble | Edit this page |