Hi all, Hoping to help outline the "not-so-easy-to-cope-with-points-with-OSG"... I'm in the very same case : being used to OpenGL and by-the -way having used a lot OpenGL Performer for example when designing a lot of special effects for real time simulators. The main difference between OpenSceneGraph and OpenGL is that (as Nick said) you don't directly invoke OpenGL calls when implementing your own NodeKits in OSG. Even in the basic bricks are logically the same (TexGen, Lights, Materials, and so on), there is an effort to do to understand how OpenSceneGraph in the background attacks the OGL rendering pipe (contexts push/pop, lists corresponding to OGL rendering orders, etc.).
I think it's the point that Nicks points out. (Talking about that, it would be a good think to explain how stateattributes inheritance between nodes is performed underneath - for me it poses no real problem cos Performer was quite alike). But more, to resume my point of view, there are three points that would be interesting to document in a "programming guide manner" (maybe to add to the Skew Matrix Quick Start Guide ?) : 1) How does OpenSceneGraph deal with performance issues ? --> explain the multithread configurations (how their divide CULL/DRAW), the synchronization issues, in a sythetic and comprehensible way... 2) How are OpenSceneGraph internals designed for the culling issues ? 2') How are OpenSceneGraph internals designed to attack OGL pipeline (draw calls) ? --> like developped above context push/pop/inheritance ; constitution of the rendering list ; orders of drawing for developpers of SFX with transparency (bins, and so on) ; maybe also a word about the default lighting equation using materials when no shader are set for newbies to SFX development (example things like the use of emissive, manners to set blending operation ie TexEnv vs or plus TexEnvCombine, even if the latter is more here an OpenGL problem)... Those 3 points may be a pain even for non-beginner developpers and aren't really clear, looking only at as-is documentation and samples... Let's be serious, the API is really easy-to-use for users just needing a scene format ans and interactive scene graph to design interactive applications, without any own SFX need. But low-level features are to be perfecly known and understood for those developping their own NodeKits and there it needs effort : you just have to spent time looking the code to make your own idea about the whole thing... That's just an opinion. -- Christophe Médard Société OKTAL (http://www.oktal.fr) 2 impasse Boudeville 31100 Toulouse (France) Tél. : (+33) 5 62 11 50 10 Fax : (+33) 5 62 11 50 29 ----- Original Message ----- From: "Robert Osfield" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Wednesday, August 22, 2007 10:38 AM Subject: Re: [osg-users] Tutorials > Hi Nick, > > On 8/22/07, Nick Prudent <[EMAIL PROTECTED]> wrote: >> I too have been programming OpenGL for while (10 years) and I find >> learning >> OSG to be quite humbling: very few of my OpenGL skills are immediatly >> transferable. OSG is very much like what the MFC ins to Win32, however, >> with >> MFC, there's always a way to use Win32 calls directly anywhere in the >> code. >> OSG does not allow this, which is more elegant, but makes it harder to >> "transition" from direct OpenGL. > > I am curious about your experience. The OSG deliberately has quite a > thin OO layer on top of OpenGL, the granularity of state is follows > pretty closely to that of OpenGL, the naming convention of OpenGL has > almost entirely been honoured so glTexGen is osg::TexGen etc. OpenGL > modes are just a pass through and can be set directly on a StateSet. > One of my intentions with this thin mapping was the ability to reuse > OpenGL knowledge and documentation. > > The big difference between using the OSG and OpenGL really comes from > the OSG being OO and having a retained model rather than immediate > model like OpenGL, but its a scene graph so its rather comes with the > territory. I would have thought of all the scene graphs in existence > the OSG is probably the most OpenGL centric in its naming/granularity. > So its it just the OO or scene graph aspect that is the stumbling > point? > > Robert. > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
