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
