Hi Johannes,
Johannes Brunen wrote:
> Could you elaborate a little why it is tricky?
> Below you can find what we are currently doing with our none OpenSG GL
> app.
> I would like to see something along that line for OpenSG. However,
> currently I can't really
> estimate all of the implications in the OpenSG context.
The basic idea should work. You can use a MaterialGroup at the top of the tree
to get rid of all state changes. The main problem I see are the glLoadName()s,
I'm not sure how to get those into OpenSG without writing a new RenderAction.
> Two concerns with that: At first, performance. The pick box we are using
> might
> be quite big.
Ah! I was expecting one, maybe two pixels.
That being said, the performance should only depend on the number of lines to
pick from, not how many you're picking (unless you do some sort of culling,
which might be necessary for large scenes).
Can you give us an idea how many lines you're picking from?
> Secondly, the line ray has infinitesimal small radius but
> a pixel does
> represent an area of the screen. This might result in loosing objects if
> they are
> sufficiently small in size.
I'm not sure I get that. The pixel is only used to create the Frustum to avoid
it having 0 volume. All the math is done on the geometry and thus with float
precision, so that should not lose anything.
Yours
Dirk
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
