The problem I have is that the embedded scripting model of application architecture doesn't fit the project I'm currently developing. I'm working with a model where an OSG-based module provides graphics functionality within a much larger C# application framework. All interaction with the rest of the world, including the provision of all data to be rendered, occurs through the framework -- there is no independent file or network I/O. In that circumstance, interposing a scripting language doesn't make a lot of sense for performance, as you've said.
That's a good thought on the wrapper generation. It would allow the generation logic to be implemented in a language other than C++, which could really speed up development. I'm not familiar enough with the complexity of osgIntrospection's data model to fully understand the tradeoffs vs. a pure C++ wrapper generator, but it's something to seriously consider.
How is the data passed? Is it individual scene graph objects that your are manipulating, or could you create some specific layer objects that pass data through in an efficient form?
Robert.
_______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
