HI Art, On Fri, Jan 23, 2009 at 11:46 AM, Art Tevs <[email protected]> wrote: > Ok, I understand what you means. However I do not understand what you means > with high level encapsulation of camera class. There exists an additional > shader class derived from osg::Program, which offers more functionality than > a usual osg::Program. Current osgPPU doesn't force you to use it, user can > still use osg only shader classes. The ShaderAttribute class is just provided > as a wrapper over the osg classes with more 'daily use' methods. As to the > Camera: in osgPPU there is no high level camera classes or so. The only one > class which seems to be same as in osg is the ShaderAttribute, which has not > to be used.
When I talk about high level encapsulation I mean that it wrap existing OSG features that would normally use a combination of Camera's and shaders. While this might use and be compatible with existing core features, conceptually the encapsulation take quite a different take to that of the way one would take using core features. >> After my review I came away with the feeling that osgPPU points some >> deficiences of the core OSG's manage of RTT support in terms of how to >> address certain types of features, and rather than an extra library >> that provides a different way of tackling RTT what we really should >> have is a core support that can better tackle some of the features >> that aren't ideal right now. >> > > Sorry, but I do not get the point what do you mean here. Could you point me > on certain parts of the code, which has to be investigate further to be > included into main core? There are certain parts of the code, it's the concepts about how one should put together this type of functionality, the core OSG has have good continuity of concepts and granularity of class design. If we have too many different approaches mixing in together lots of issues will arise in trying to convey when one should use one approach or another. I feel that the approach you've taken with osgPPU has it's merits, and in fact points to need for the core OSG to handle this type of usage as integral to its class design, something that it doesn't do well right now. This suggests to be that the core OSG code do with a refactor w.r.t RTT and shaders, such a refactor will be required anyway as part of wider changes for support of OpenGL 3.0 etc. As to what these changes need to be I really can't answer without spending several months review the ongoing evolution of hardware, graphics API's, and needs of scene graph users. Right now I'm focused on getting a stable OSG 2.8 out the door, and am very much not in the position to dive in to such speculative work. Robert. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
