Hi Dirk, Dirk Reiners wrote: > Johannes Brunen wrote: >> 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. Couldn't this be a general mechanism. Selection is one of the basic GL operations? Maybe modifying the current RenderAction suffice? Probably not... >> 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. No, our application allows the dynamic creation of a selection box (by cursor dragging). A list of all geometry inside of the frustum defined by this box must be found. Additionally, we perform dynamic highlighting. I.e. the user moves a pick-box over the scene and the internal geometry nearest to the box's center of the solid body below the cursor is highlighted dynamically. The internal geometry is calculated on the fly from the topological model of the body. The user is then allowed to pick from the internal geometry. > 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? Oh maybe a lot, don't know. Perhaps I should explain that we are working in the CAD business (http://www.datasolid.com/html/professional.html) We are currently evaluating scenegraphs as replacement of our own aged graphics implementation. After comparsion of OSG, OpenSG, VRS and OGRE only OpenSG did meet our expectations. However, we have some very fundamental requirements defined by the business we are engaged in (picking, dynamic highlighting, low memory consumption,....). So I hope that we can solve all of these initial problems and contribute a little back to the OpenSG community. >> 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. Hi, this was actually nonsense since I didn't clearly understand what you did mean. Yours Johannes ------------------------------------------------------------------------- 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
