Hi Christophe,
Thanks for your comments on osgDotNet.
Regarding (A1): you'll need to build the Debug osgDotNet assemblies and use
them with the Debug OSG DLLs. If you do that you should be able to see native
OSG state when you've stepped into the osgDotNet and OSG code. Unfortunately
you can't see the native state when stepping through the managed code. Also,
debugging across the managed/unmanaged boundary only works for 32 bit code, not
64 bit, due to a CLR/Visual Studio limitation.
(B): IMO weaknesses in osgDotNet or osgIntrospection should be addressed in
their respective codebases rather than as patches to the core OSG. Burdening
Robert with unnecessary work due to this project would not be a good way to
ensure his continued support. :)
Just patching your local copy of OSG can be done, but I'd advise against it
because it's fragile and contravenes the project goal of maintaining a similar
API between C# and C++.
For public attributes, support just needs to be added to osgDotNet to handle
these. Some work has been done towards this end, but it's not there yet.
Currently there is a rudimentary mechanism in the code generator to add custom
support code to classes. In the absence of support for operator functions in
osgIntrospection, this could be used to handle the NodeCallback issue,
including virtual calls from C++ to C#.
Mike Wittman
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
___________________________________________________
Seismic Micro-Technology, Inc.
8584 Katy Freeway, Suite 400 / Houston, Texas 77024
Tel. +1 (713) 464-6188
Fax. +1 (713) 464-6440
Web: www.seismicmicro.com <blocked::blocked::http://www.seismicmicro.com>
___________________________________________________
Seismic through Simulation with KINGDOM, (RC)2, and SURE! - CONTACT US TODAY
for more information.
________________________________
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christophe Medard
Sent: Thursday, August 16, 2007 5:46 AM
To: [email protected]
Subject: [osg-users] osgDotNet : Used from C#
The osgIntrospection+osgWrapper and osgDotNet-generator work very well
together. (See
http://www.openscenegraph.org/projects/osgDotNet/wiki/GettingStartedWithTheWrappersGenerator).
Thanks to the osg team for such taht interesting release !
After a bunch of tests, the generated Managed C++ DLLs work perfeclty well
referenced in a C# solution and "porting" a native osg program to osgDotNet in
C# is quick since names of classes, methods and stay the same through the
osgDotNet API.
Yet, two problems remain for the programmer that wants to build an interactive
application in .NET (C# in my case) :
(A) Debugger use. As is, it seems impossible to examine the unmanaged C++
content (native osg) carried by osgDotNet instances, even if the "Enable
unmanaged code debugging" option is set active in the Debug properties of the
projects.
(B) Update vs Draw. Some fundamental methods of classes (ie
Osg.NodeCallback.operator()()) aren't wrapped. Also, some classes interface
become very static in osgDotNet compared to native osg because their
fundamental members were set public and accessed directly in the native API
(limitation of osgIntrospection, as explained among the last points of
http://www.openscenegraph.org/projects/osgDotNet/wiki/DifferencesWithNativeAPI
). An example is OsgSim.LightPoint and _on member.
Regarding (A)...
The Generator builds an osgDotNet solution that only links with the release
versions of the native osg libraries (which stays in phase with the fact that
using osgDotNet dlls, you have to copy aside your osg.NET dlls - on set in the
Windows Path - release versions of the native osg Dlls as explained at
http://www.openscenegraph.org/projects/osgDotNet/wiki/GettingStartedWithTheWrappers).
<Question A1> Is that the main explanation of (A), or is there something else ?
<Question A1bis> Can we modify the osgDotNet solution produced by the generator
to link with debug version of the native osf librairies to solve the (A)
problem ?
Regarding (B)...
Solving the issue with for example the lightpoint is easy : I only have to make
a few accessor add in (native) osgSim as well as in osgWrappers/osgSim and
rebuild OpenSceneGraph. In other words a quickly coded litlle patch on the osg
native release.
<Question B1> There, just one question : is it useful to submit to the OSG
community those patches as we introduce them or will the release to com (2.2.0)
include those or an osgIntrospection improvement that will render this obsolete
?
Concerning the more important NodeCallback issue, it may be embarassing : it is
a callback method called from the native osg internals that have to impact the
overriden method coded in C#.
<Question B2> Will the mere patching of the osg release (as for the LightPoint)
work in that case ? The macros used inside osgWrappers/xxx (osgIntrospection
macros) include virtualstate assesment, but will it work on that case where the
caller is the osg native core, not a .NET call coming from inside the C#
application ?
Thanks for comments or answers.
--
Christophe Médard
Société OKTAL (http://www.oktal.fr)
2 impasse Boudeville
31100 Toulouse (France)
Tél. : (+33) 5 62 11 50 10
Fax : (+33) 5 62 11 50 29
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
