Jason, Architecturally I will usually treat the OSG API as a low-level implementation detail. So rather than a thin layer over OSG, I usually will encapsulate OSG code inside controller interfaces that accompany the OSG .NET Control.
So for example, there will be a single C++/CLI assembly that will expose the .NET control, which handles repainting, mouse/keyboard events, and the rendering loop. That control will then expose various Controller interfaces, like: * ViewController - for setting/getting the camera * ContentController - for adding/removing/toggling models or layers in the scene * AssetController - for managing named dynamic objects/entities * AnnotationController - for managing text labels ...and so on. So this assembly becomes an application-level toolkit that abstracts away not only OSG but the whole concept of the scene graph. Then the C# UI code (in a referencing assembly) will look kind of like: SceneControl scene = new SceneControl(); myForm.Controls.Add( scene ); ... scene.Content.AddLayer( "f:/data/terrain.osga" ); scene.Content.AddLayer( "f:/data/trees.osga" ); ... scene.View.LookAt( x, y ); and so on. Now if you are looking for more re-use, you can break the Controller interfaces our into their own separate assemblies. It just depends on the complexity of your app. -gw -- Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : 703-652-4791 On Feb 17, 2008 10:52 AM, Jason Beverage <[EMAIL PROTECTED]> wrote: > Hi Glenn, > > We're using c# and OSG as well, but we're using hand crafted wrappers that > attempt to expose all of the OSG functionality to C# (like the osgDotNet > wrappers). This works well for the most part, but I often feel that > sometimes it is more complicated than it is worth. I've also written a > simple OSG control that binds an osgViewer to a window in C++/CLI like you > mentioned, and it actually is surprisingly simple. > > When you write your applications that use OSG and C#, how is your > application architecture typically set up? Do you just maintain a thin > layer of C++/CLI code that deals with OSG? Just curious to get your opinion > and learn something from your experience:) > > Thanks! > > Jason > > > On Feb 16, 2008 11:16 PM, Glenn Waldron <[EMAIL PROTECTED]> wrote: > > > Sherman, > > I'll vouch for it ... I've written dozens of apps using C++/CLI and OSG > > and it works great. It is very convenient to be able to mix managed and > > unmanaged code virtually at will (there are a few restrictions) as the > > interop is handled transparently by the CLR. Plus with .NET 2.0, it's > > simple to write an OSG .NET Control in a C++/CLI assembly, and then use it > > in all your C# UI code. > > -gw > > > > -- > > Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : > > 703-652-4791 > > > > > > On Feb 16, 2008 10:10 PM, sherman wilcox <[EMAIL PROTECTED]> > > wrote: > > > > > Ok - so it sounds as if using C# with OSG is bad idea. Sounds possible > > > - just painful. On the plus side I hear (on occasion) good things said > > > about C++/CLI. Can anyone else comment on their experience using OSG > > > and C++/CLI? > > > > > > On Feb 14, 2008 10:48 AM, hesicong2006 <[EMAIL PROTECTED]> wrote: > > > > Hi, > > > > You should try OSG.NET project, but the project does not contains > > > every > > > > feature OSG could provide. A much better solution will be use of > > > > C++/CLI, this language can create mix native C++ and managed code. > > > The > > > > main C# UI design benefit is also contained in C++/CLI. I have use > > > > C++/CLI to integrate OSG and .NET, very well, you should try it. But > > > the > > > > plain will be the much lower compile speed due to lots of inline > > > code of > > > > OSG. > > > > > > > > > > > > sherman wilcox wrote: > > > > > I've read a few posts and I'm a bit fuzzy on the subject. I have > > > an > > > > > OSG app wrapped up in a C++ library. Now I need a UI. I can attach > > > > > this and drive this libarary from a console app, MFC GUI, or even > > > the > > > > > standard Windows API, etc. - All in C++. However, I'm considering > > > > > using C#. I've heard lots of good things about C# from a UI > > > > > development perspective. From an OSG/C# point of view - there > > > seems to > > > > > be lots of pain. > > > > > > > > > > I'm not a C# developer - it's all Greek to me - so what I'm > > > imagining > > > > > may not be practical in reality hence this post. Is it possible to > > > > > link in my OSG app wrapped up in a C++ blanket and use my own API > > > from > > > > > with a C# GUI? Is it painful? What would I lose by going this > > > route? > > > > > Is possible that at some point I won't be able to take advantage > > > of > > > > > some latest OSG feature due to some unforeseen incapability? My > > > > > current UIs (I'm thinking of one MFC UI in particular) don't > > > really > > > > > interact with the OSG - that's all handled by my own C++ API. I'm > > > just > > > > > not sure how well all this would glue together using C#. > > > > > > > > > > Can some of the veterans comment? > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > osg-users mailing list > > > > [email protected] > > > > > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > > > > > _______________________________________________ > > > osg-users mailing list > > > [email protected] > > > > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > > > > > > > > > _______________________________________________ > > osg-users mailing list > > [email protected] > > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > > > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > >
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
