Meanwhile, that number two option sounds a lot more sane than trying to run through all interfaces for the entire OSG API and SWIG-generate the code like I have been trying to.
This is the jist of my though on option 2, its effectively substituting Swig by osgIntrospection.
Could you get into details on your plan/thoughts regarding what solution you think would be best (1-3) and how you would proceed?
We I think option 1 - the dynamic bindings would first need to be done solidly, as if you have good dynamic python or lua wrappers (even if they arn't really fast) you'd be able to write the lower level wrapping in a language suited for parsing, I would't say C++ fits this bill, so Lua or Python would be better bets. This does stress the initially wrapping capabilities. Getting a good option 1 working would also require more work on genwrapper/osgInterspection side, what parts will be the stress points first I can't say, but one would need to be open to getting ones hands dirty and adding bits that are required as you go along. You suggestion of attempting to rewrite the OSG examples as a means of testing out wrappers is a good one. I have even contemplated the possibility of having the majority of examples in scripted languages rather than C++, as this would help reduce the hassel of build and distributing examples. W.r.t low level work, I can't help too much, I'm not an expert in genwrapper, osgIntroseption or scripting languages. Robert. _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
