> I can see two ways to get this into the core: > > a) As a tutorial example. Copy 11picking.cpp and change it to use > the ID buffer > method. That one will just fly into the CVS. ;) > b) As an option for the SSM. That's a little more work, but that's the only > place I can think of that would make sense. Because the method uses extra > Viewports internally, I'd rather not have it do that behind the back of the > app, so it should be inside a wrapper that does these things anyway > (i.e. SSM).
Ok, for the moment, I will make a short tutorial like all others. But I don't think SSM is the right place. Into SSM or in any other place, the constraints (One rendering frame in an extra viewport, with an extra passivewindow, an extra-buffer etc... WITHOUT MOVING ANYTHING) must be explicit => ie: if somebody try do make lot of getObject() during animation or so, this approach loose it's efficiency. So Maybe the IDBuffer Class should be separated from the rest (derivating nothing), so as to efficiently inform the user about semantic and utilisation of such a component. (So the tutorial is a good Idea) >> doesn't window->render() do a swap? How does your render_it() function look? > Depends on the Window. A PassiveWindow will not, all others will. Really thanks => that was the problem !!! (The OSG Wiewport implementation drive me in error.. I was beleiving that only Classes implementing the swap() method could do it ....) Thanks Dirk your help ! Raphaël DUCOM ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
