Hi Preet, On 16 March 2012 19:53, Preet <prismatic.proj...@gmail.com> wrote: > Typically I use osg::ref_ptr<> to let osg handle reference counting. > Right now I'm trying to create a 'rendering engine' for another > library with osg. The idea for the other library is to maintain an API > that allows different rendering engines -- osg, ogre, vtk, etc.
Others have amply answered the ref counting question so I won't add anything further than this. I would like to question the idea of adding an rendering API abstraction layer. VTK is a very different beast to OSG or OGRE, and the later two while have more in common which each other than they do with the approach of VTK are still very different in design and implementation. This will mean the abstraction layer would have to do a lot of work just to try and fit them all into the same box. In doing this fitting you'll almost certainly make it harder to do any advance usage of the underlying API that you are actively using at any time. What you are gunning for is hard to design, hard to implement and hard to maintain. The next question I'd like to pose to what do you gain for this abstraction layer? The Pain is high with the approach you want to take, so the benefit will have to be huge.... Personally I can't think of a good reason to justify all the pain and hampering of final functionality. I would recommend not going to the lengths of trying to abstract away from the API's. Work out what you need to do with your application, work out what you need from your rendering API and match this up against the candidates in front of you. All of the candidates have been around for a good period and are mature SDK's each with their own strengths and weakness, but one thing for sure is that they have lived long enough and have big enough communities to know that they will be around for a good while longer and there all open source, so there isn't any reason to hedge your bets on which one will be around in 5 or 10 years time, there is a good chance they all will be. So work out which one fits best and pick it and discard the rest. This approach will be the most productive in the short term, mid term and long term. Software projects are typically hard enough as it is without putting extra roadblocks of complexity in your way. Robert. _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
