Great to hear someone else is actually using CIGI. Makes me feel a little less crazy. :)
On Tue, May 28, 2013 at 7:18 PM, Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC <[email protected]> wrote: > Our host talks with several different IGs on the backend (OSG, Quantum3D, > Aechelon) . All use the CIGI protocol. If it wasn't for CIGI, our host > would > have to support different ways of communicating with each IG which would be > a pain. > > The OSG-based IG is one that we developed in-house. Like both Chris' , we > also spawned our efforts off of Boeing's MPV with our own modifications. > > Rather than rolling CIGI into OSG, I would suggest using a thread/process > that eats CIGI packets that then interfaces with OSG where applicable. > > A while back, the developer of osgVisual had contemplated writing a CIGI > plugin. I don't know where that effort ended up though... > > -Shayne > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Chris > Best > Sent: Tuesday, May 28, 2013 2:29 PM > To: OpenSceneGraph Users > Subject: Re: [osg-users] Any recent work on CIGI interfaces to OSG? > > Hi Chris, > > > I work on an OpenSceneGraph-based image generator for the Federal Aviation > Administration that is built on the CIGI protocol. Like you, we originally > started from MPV and worked from there. Thankfully we threw all that code > away and started from scratch. > > I don't know how much has changed in MPV in the past five years... Maybe > it's a great, well-engineered piece of software now! But if it's like what > I > remember, I'd only use it as a reference on CIGI concepts, not on how to > integrate OSG into a CIGI application. It wasn't designed for > multithreading, it was originally built for OSG 0.91, and it uses a library > called osgSDL to handle Windowing, "threading", and user input... Which > makes using any modern OSG code/examples (which expect an osgViewer/osgGA > base) problematic to say the least. > > > Also, if you're serious about CIGI support, you may need to roll your own > CIGI library. I haven't looked at the 3.3.3 version of CCL, but when it > finally became apparent that our wrapper code around CCL 3.3.2 was rivaling > the size of CCL itself, we ended up rewriting it from scratch. Again, it's > a > good solution for teaching you the concepts, but I think it's really best > as > a reference implementation and not practical for production use... > > > May I ask why you're working on adding a CIGI interface to FlightGear? I'm > only curious because we keep asking ourselves why we stuck with CIGI all > these years, as no one else actually seems to use it! Any other vendors we > deal with always go "Well, yeah, you CAN use CIGI with our stuff... But > it'd > really be better if you used our API instead!" And then when you look at > their CIGI support, they usually have just wrapped their proprietary > packets > in CIGI custom packets... Bleh. > > > But if this hasn't thoroughly discouraged you yet... Well, I'm not sure I > have any good news for you, really. You're going to find that SO MUCH of > CIGI is either incredibly ambiguous or 'implementation defined', that > you're > going to have trouble writing a general-purpose CIGI wrapper. If you're > willing to get more specific, I think a useful area for you to work on is > handling EntityCtrl packets at the very least, to add/move/delete entities > to a scene graph. That's (to me) the really key/useful feature exposed by > CIGI, and is probably the most well-defined part of the protocol. It'll > also > be your first real taste of how CIGI gets you most of the way, as you'll > have to provide an out-of-band way to map entity types to model files, and > also a way to let a user specify the coordinate system transform from the > WGS84 ellipsoid to their database coordinates. Oh, and CIGI optionally lets > you specify a custom ellipsoid, too. I'd save some sanity and leave that > particular feature in the "not supported" column. :) > > > After that... Extending osgGA::NodeTrackerManipulator to follow the Ownship > entity in your scene graph would be a good step towards having a functional > image generator, if that's what you're aiming for. > > > If you have any specific questions, feel free to ping me and I'll be happy > to share the dubious benefits of five years of working on your problem with > you. > > But if you're looking for general advice on implementing CIGI in OSG... > Well... In one word: Don't. > > > In slightly more words: Think very hard as to why you're doing it, and what > the likelihood is you'll actually ever integrate your solution with a > DIFFERENT system that uses CIGI... And is using a compatible version of > CIGI... And made the same (or similar enough) choices about the ambiguous > or > implementation defined features... > > > Good luck. > > > -Chris B > > > > > On Fri, May 24, 2013 at 5:26 PM, Chris Calef <[email protected]> > wrote: > > > Hi, > > > I'm new to OSG, coming in from the direction of FlightGear, but I'm > here primarily because I am interested in implementing a CIGI interface to > FlightGear, and would like to put as much of this work as possible into an > OSG module in order to make it useful to the larger OSG community and not > only FlightGear developers. > > > I have read the conversations about doing this from several years > ago, but have not found any recent discussion or located any available code > drops. I have downloaded the MPV example from CIGI at sourceforge, which > is > based on OSG, and that is quite helpful, but I wanted to introduce myself > here and see if anyone can catch me up on any other existing work in this > direction, or give me advice about where to start. > > > Much of the CIGI interface is dedicated to higher order simulation > functions (ie celestial bodies, ocean conditions, aircraft controls) which > are probably too specific to implement at the OSG layer, but I'd like to > make at least a virtual wrapper in OSG which could be inherited by > FlightGear and other OSG based projects, each of which could determine on > its own which functions to support, and how to support them. > > > Any pointers would be welcome. I am applying for funding for this > project in one week, so the more information I can gather before then the > better. > > > Thanks for all your efforts! > > Chris Calef, CTO > BrokeAss Games, LLC > > > > _______________________________________________ > 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
