Re: [osg-users] Any recent work on CIGI interfaces to OSG?
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 shayne.tuel...@hill.af.mil 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: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] 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 chris.ca...@gmail.com wrote: Hi, I'm new to OSG, coming in from the direction of FlightGear, but I'm here
Re: [osg-users] Any recent work on CIGI interfaces to OSG?
Hi, I work on an image generator based on OpenSceneGraph and driven by CIGI commands. Web site of the company: http://www.oktal-se.fr Section SE-FAST-IG. At first MPV was a source of inspiration. This is no longer the case now. It's been a few years since I look at MPV base code. Lionel On 24/05/2013 23:26, Chris Calef 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 osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Any recent work on CIGI interfaces to OSG?
That's neat...a lot more folks coming out of the closet that are using OSG-based IGs using CIGI...;^). Actually CIGI is quite prolific in the IG industry which is nice for anyone who has a host that has to interface with different IGs or wants to upgrade to a different IG that supports CIGI. You don't have to rewrite the communication protocol to switch IGs... I think VT Mak is another high profile IG vendor that uses OSG technology under the hood that may support CIGI. The last time I glanced at Boeing's MPV code, they had upgraded it to support OSG 2.8.2. They've jettisoned most of the SDL dependencies and are now using the osgViewer paradigm along with other, more modern OSG concepts. The blackboard paradigm still exists with some enhancements. I don't consider myself a prognosticator but I predict that you will see more IGs emerge, based on OSG and other open source tools. They will eventually replace IGs that rely on proprietary scenegraphs and databases because of reduced cost. In the early days, IG vendors relied on proprietary hardware to introduce their discriminators from the competition. With the advent of programmable GPUs found on COTS cards such as NVIDIA and ATI, most of those proprietary hardware discriminators have evaporated and many have had to retreat to proprietary scenegraphs, tools, and databases to maintain their business edge. I think you will see a similar revolution in the software realm as open source tools like OSG make inroads into the current IG market. Proprietary software used by most IG vendors today (such as scenegraphs and databases) could suffer the same fate as proprietary IG hardware did back in the 90's... -Shayne -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Lionel Lagarde Sent: Wednesday, May 29, 2013 8:06 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Any recent work on CIGI interfaces to OSG? Hi, I work on an image generator based on OpenSceneGraph and driven by CIGI commands. Web site of the company: http://www.oktal-se.fr Section SE-FAST-IG. At first MPV was a source of inspiration. This is no longer the case now. It's been a few years since I look at MPV base code. Lionel On 24/05/2013 23:26, Chris Calef 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 osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org smime.p7s Description: S/MIME cryptographic signature ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Any recent work on CIGI interfaces to OSG?
VT-Mak's VR-Vantage product is OpenSceneGraph-based, and it does in fact support CIGI... They told us we'd have better luck using DIS or HLA (their specialties), and weren't in a position to demo CIGI capabilities to us... It's actually a pretty great product, otherwise, and we told them if they'd of showed up with it five years ago we never would have developed our own solution. :) As far as a multitude of IGs supporting CIGI... Well, here's hoping. As I said before, our experience was that the vendors we spoke w/ had CIGI on their buzzword list in the product literature, but when it came down to actually using it they'd get kind of cagey and direct us towards their own protocols... More competition should help that attitude a lot. :) That reminds me, when we wrote the OSG-based our deferred renderer for our Image Generator, we got FAA sign-off for releasing it to the community. If other people are looking to work on IGs, a solution for massive amounts of dynamic lights might be helpful. It's a little outdated, and needs a lot of cleaning up, but it's a starting point... Does anyone think it'd be worth my time to clean up (the curse words in) the code and improve the documentation so it could be released? -Chris B On Wed, May 29, 2013 at 12:18 PM, Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC shayne.tuel...@hill.af.mil wrote: That's neat...a lot more folks coming out of the closet that are using OSG-based IGs using CIGI...;^). Actually CIGI is quite prolific in the IG industry which is nice for anyone who has a host that has to interface with different IGs or wants to upgrade to a different IG that supports CIGI. You don't have to rewrite the communication protocol to switch IGs... I think VT Mak is another high profile IG vendor that uses OSG technology under the hood that may support CIGI. The last time I glanced at Boeing's MPV code, they had upgraded it to support OSG 2.8.2. They've jettisoned most of the SDL dependencies and are now using the osgViewer paradigm along with other, more modern OSG concepts. The blackboard paradigm still exists with some enhancements. I don't consider myself a prognosticator but I predict that you will see more IGs emerge, based on OSG and other open source tools. They will eventually replace IGs that rely on proprietary scenegraphs and databases because of reduced cost. In the early days, IG vendors relied on proprietary hardware to introduce their discriminators from the competition. With the advent of programmable GPUs found on COTS cards such as NVIDIA and ATI, most of those proprietary hardware discriminators have evaporated and many have had to retreat to proprietary scenegraphs, tools, and databases to maintain their business edge. I think you will see a similar revolution in the software realm as open source tools like OSG make inroads into the current IG market. Proprietary software used by most IG vendors today (such as scenegraphs and databases) could suffer the same fate as proprietary IG hardware did back in the 90's... -Shayne -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Lionel Lagarde Sent: Wednesday, May 29, 2013 8:06 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Any recent work on CIGI interfaces to OSG? Hi, I work on an image generator based on OpenSceneGraph and driven by CIGI commands. Web site of the company: http://www.oktal-se.fr Section SE-FAST-IG. At first MPV was a source of inspiration. This is no longer the case now. It's been a few years since I look at MPV base code. Lionel On 24/05/2013 23:26, Chris Calef 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
Re: [osg-users] Any recent work on CIGI interfaces to OSG?
Hi again, and thanks, everyone, for the very useful input! Re: why I am doing this... I am interested in using FlightGear to feed images and data to another application. My use case is not a traditional IG/Host application - for my immediate, personal needs I am actually interested in using FlightGear to serve skybox images and terrain data to a first-person-shooter game environment, built in Unity3D. For details on this project, see the following blog: http://www.garagegames.com/community/blogs/view/22269 I have already written a proof of concept demo application which basically does what I want, setting up a socket connection between my Unity app and FlightGear, passing player position and other information to FG and causing it to save out the necessary skybox images and terrain data for the player's current world location. However, while writing the raw socket code, it seemed to me that someone must have already thought about this and done it better than I... and then I heard about CIGI from one of the FG developers and started researching it. It seemed to be an extremely thorough extrapolation of everything I'd ever thought of and much much more, and being an open source industry standard, it seemed more useful to FlightGear and the general population to make my communication with FG follow this protocol. At the same time, it became evident that there may be a possibility for funding my project through a foundation which supports, I paraphrase, increasing public access to electronic information. My particular angle on this is geographic information, in that the FlightGear world is build from and has tools for import of GIS data, as well as weather modelling, etc. With my project, I hope to bring it closer to feasibility for other various and diverse applications to be able to use FlightGear's capabilities for world visualization, set apart from its abilities as a flight simulator. So, that is my goal, the exact methodology is still a little up in the air. If the decision is between rolling my own CIGI based library, and just rolling my own proprietary library from scratch, it seems like I might as well start with CCL, since it is _some_ sort of standard anyway, and there _are_ people out there using it. The decision to try to move it up the chain to OSG instead of implementing it straight in FG is based on a) hoping that this would be more useful to more people, and that if so, they might take a hand in maintaining my implementation in the future, and b) hoping that by increasing the utility for more people, my project will appear more worthy of support from the foundation. However, I must confess some doubts, as mentioned above, when I notice how many of the CIGI functions relate to higher order logic that I wouldn't necessarily expect many OSG users to share in. In addition, there may be some parts of OSG that could be supported by a CIGI implementation, but are actually not used in FlightGear, in favor of a local system, and these could present complications for me as well. The other elephant in the room for this whole project is HLA/RTI - FlightGear has already made large strides in the direction of HLA support, with the openRTI project and an FGViewer side project which uses OSGViewer and HLA to create external cameras. I am new to all of these protocols and still trying to figure out how they compare/contrast, but it would appear that for purposes of an external app directing a simulator to configure itself and return image data, CIGI might be a functional solution, while for multiple simulators running in parallel, where each may need to broadcast parts of its own local information to the whole group, that HLA would make the most sense. Does anybody here have extensive experience with HLA that they might want to share? In any event, rest assured, I have no intention to exhaustively support every control type defined by the protocol! I'm only applying for six months' FTE here and am focused only on the most basic set of CIGI functions that will accomplish my limited purposes. I do hope to provide a framework for others to expand on, though, if anyone else desires more thorough coverage. So, anyway... in conclusion I don't really know for sure what I should be doing, but I have a possible direction to go and only a couple of days left before submitting the application... further feedback? On Wed, May 29, 2013 at 7:06 AM, Lionel Lagarde lionel.laga...@oktal-se.frwrote: Hi, I work on an image generator based on OpenSceneGraph and driven by CIGI co mmands. Web site of the company: http://www.oktal-se.fr Section SE-FAST-IG. At first MPV was a source of inspiration. This is no longer the case now. It's been a few years since I look at MPV base code. Lionel On 24/05/2013 23:26, Chris Calef 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
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 chris.ca...@gmail.com 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
Re: [osg-users] Any recent work on CIGI interfaces to OSG?
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: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] 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 chris.ca...@gmail.com 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
