|
Hi Robert, Currently data is passed as C# objects which
are independent of the scene graph data representation. The graphics module
extracts the relevant data to be rendered, converts to native C++ types, and creates
standard OSG scene graph nodes based off that data. At least this one
conversion is required since "unmanaged" C++ cannot easily operate on
C# types. I believe this is about as efficient as possible. -Mike From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Robert Osfield Hi Mike, On 11/14/06, Mike
Wittman <[EMAIL PROTECTED]>
wrote: 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.
|
_______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
