> osgPython, osgIntrospection and genwrapper are all open source. If > there are defincies then it is possible to address them. Addressing > these rather than rolling yet another solution will be of alround
Yes, I too enjoy exactly those virtues of the free software community. :) One problem with making the generic code lean towards dynamic languages is that static languages will have a more difficult time using them. There's a great benefit of making a direct API bind generic and then manually "pythonify" them in the high-level Python user API. For instance, we could simply bind osg::Vec3Array to the Python class _Vec3Array, inherit from it to Vec3Array which implements, in Python, operators for emulating a sequence type, etc. I haven't gone through all of the tutorial examples, but so far I've seen great potential to make the Python API for OSG a lot more usable than the original C++ API. At least from a Python users perspective. /Peter _______________________________________________ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
