Glenn, That seems like a great design choice, thanks for your insight. It's always nice to get another perspective.
Thanks! Jason On Feb 17, 2008 1:09 PM, Glenn Waldron <[EMAIL PROTECTED]> wrote: > 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 > >
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
