Hi Robert,
I understand what you're saying, and I agree
with it. I've written my fair share of Python and Ruby scripts and have
been using Perl for more than a decade now (I've looked into but haven't used
Lua), so I'm familiar with the uses and benefits of dynamic scripting.
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.
-Mike
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Robert Osfield
Sent: Tuesday, November 14, 2006
12:33 PM
To: osg users
Subject: Re: [osg-users] OSG and
C#
Hi Mike,
I think if one went the C# -> Lua/Python -> OSG route, one would only do
high level application work in C#, intermediate level app work in Lua, then all
the lower level scene graph work in C++ on the OSG side. In this style of
usage performance should be good as all the performance critical code will be
within C++.
Trying to tie C# to OSG closely via Lua/Python would be not be sensible on
performance perspective, or for the general management perspective. You'd
also loose the power of these dynamic scripting languages.
Finally wrapping a wrapper might not be ideal, but you could potentially use
the wrappers to generate wrappers, i.e. use osgIntrospection to describe all
the OSG classes and methods in a generic way that you parse and generate C#
-> C++ wrappers from.
Personally I'd recommend spending some time with Lua and Python, they are both
great languages.
Robert.
On 11/14/06, Mike
Wittman <
[EMAIL PROTECTED]> wrote:
I'm one of the users who is using C# for my main application, and
performance is a major concern, so the C#-Lua-OSG approach definitely
won't fly for me. Because of that, and because of the difficulties I
experienced manually interoperating between OSG and C#, I'll almost
certainly be tackling the C++/CLI wrappers regardless of any other
efforts that are also occurring.
-Mike
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
On Behalf Of Serge Lages
Sent: Tuesday, November 14, 2006 9:46 AM
To: osg users
Subject: Re: [osg-users] OSG and C#
On 11/14/06, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
>
> Agreed. If I tell my boss I can use Lua as a scene graph driver in a
C#
> application with relatively little effort, he's more likely to go for
> that, than if I tell him we need to start from the ground up and write
a
> .NET wrapper. But this is all my personal feelings; how do others
who've
> expressed an interest feel about this?
>
As I said, I really agree with this solution. It's not the best in
term of performances but I think that the majority of users wanting to
use C# is for tools, and not for their main applications.
--
Serge Lages
http://www.magrathea-engine.org
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
