Re: [Flightgear-devel] alternative terrain engine integration
Hello, Would that be possible? What is the policy for gainining CVS write access to the fgfs repository? Hmm, apparently the thread died an abrupt dead, so I humbly ask again: What can I do to gain CVS access? If you have any reservations or further questions about the project, please let me know. thanks, Manuel ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] alternative terrain engine integration
Hi, I want to start to integrate an alternative terrain engine with flightgear (http://baron.flightgear.org/pipermail/flightgear-devel/2004-September/030853.html) For this, I need to adapt flightgear to use an abstract terrain API, which will encapsulate the current and new terrain engine transparently. As this will involve some (mostly small) changes all over the place, it would be great if I could work on a CVS branch. Would that be possible? What is the policy for gainining CVS write access to the fgfs repository? Of course, I will post planned changes on the mailing lists for discussion, but I want to get the bureaucratic stuff sorted out first :-) cheers, Manuel ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] alternative terrain engine integration
Manuel Massing wrote: Hi, I want to start to integrate an alternative terrain engine with flightgear (http://baron.flightgear.org/pipermail/flightgear-devel/2004-September/030853.html) That's great, I already wondered what happened to that project. This would really be a great addition for FlightGear. For this, I need to adapt flightgear to use an abstract terrain API, which will encapsulate the current and new terrain engine transparently. As I understood you where using your own SceneGraph engine, what would be the best way to handle this; 1. Adding a SceneGraph API 2. You change your code to use plib 3. FlightGear starts to use your SceneGraph library As this will involve some (mostly small) changes all over the place, it would be great if I could work on a CVS branch. Hmm, I've seen work on branches and they have their pro's and con's. I'm not sure I like branches all that much. Would that be possible? What is the policy for gainining CVS write access to the fgfs repository? Curtis? Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] alternative terrain engine integration
Manuel Massing wwrites: Sent: Monday, January 10, 2005 7:33 AM To: flightgear-devel@flightgear.org Subject: [Flightgear-devel] alternative terrain engine integration Hi, I want to start to integrate an alternative terrain engine with flightgear (http://baron.flightgear.org/pipermail/flightgear-devel/2004-September/030853.html) For this, I need to adapt flightgear to use an abstract terrain API, which will encapsulate the current and new terrain engine transparently. As this will involve some (mostly small) changes all over the place, it would be great if I could work on a CVS branch. Would that be possible? What is the policy for gainining CVS write access to the fgfs repository? Of course, I will post planned changes on the mailing lists for discussion, but I want to get the bureaucratic stuff sorted out first :-) cheers, Manuel ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] alternative terrain engine integration
Manuel Massing writes: I want to start to integrate an alternative terrain engine with flightgear (http://baron.flightgear.org/pipermail/flightgear-devel/2004-September/030853.html) For this, I need to adapt flightgear to use an abstract terrain API, which will encapsulate the current and new terrain engine transparently. Apologies for my earlier empty msg I think an abstract Terrain API is a great idea however please keep in mind that FlightGear uses a round earth model and that this should be reflected in any FGFS Terrain API Is this methodology you want to integrate ? http://cg.cs.uni-bonn.de/docs/publications/2004/wahl-2004-scalable.pdf Cheers Norman ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] alternative terrain engine integration
Hello Erik, That's great, I already wondered what happened to that project. This would really be a great addition for FlightGear. Unfortunately I am studying and currently try to compensate for the tremendous lazyness of my past semesters :-) So that project had to wait for the christmas break. As I understood you where using your own SceneGraph engine, what would be the best way to handle this; 1. Adding a SceneGraph API 2. You change your code to use plib 3. FlightGear starts to use your SceneGraph library I am not yet sure what the best solution will be, but I want to either: 1) Wrap it into a plib scenegraph node 2) Abstract out the scenegraph and only offer a render() method, which would just render to the current OpenGL context. I prefer the second method, because of the simplicity of the interface; implementation-wise the difference is small, it's more of a design question at what level the rendering should be encapsulated. IMO the earlier, the better (i.e. simpler). Hmm, I've seen work on branches and they have their pro's and con's. I'm not sure I like branches all that much. I think in this case a branch makes a lot of sense, because otherwise the modifications would greatly disturb the main-branch; or I would be forced to hold back a gigantic monolithic patch until codingtesting has finished, which would leave me without version control (and others wouldn't be able to test or contribute). bye, Manuel ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] alternative terrain engine integration
I think in this case a branch makes a lot of sense, because otherwise the modifications would greatly disturb the main-branch; or I would be forced to hold back a gigantic monolithic patch until codingtesting has finished, which would leave me without version control (and others wouldn't be able to test or contribute). If my memory serves, previous big changes to the codebase have been handled by having a conditional compilation option which switches on the new code (and switches off some old code if needed) and putting all changes in CVS HEAD. This allows people to try it if they want to, and avoids what I understand is the main problem of CVS branches, which is reintegration when it is complete. Richard This e-mail has been scanned for Bede Scientific Instruments for all viruses by Star Internet. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] alternative terrain engine integration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Norman Vine schrieb: Manuel Massing writes: I want to start to integrate an alternative terrain engine with flightgear (http://baron.flightgear.org/pipermail/flightgear-devel/2004-September/030853.html) For this, I need to adapt flightgear to use an abstract terrain API, which will encapsulate the current and new terrain engine transparently. Apologies for my earlier empty msg I think an abstract Terrain API is a great idea however please keep in mind that FlightGear uses a round earth model and that this should be reflected in any FGFS Terrain API Probalby the easiest way would be to create an independant program first, that communicates with FGFS via the network api. This works currently for multi monitor (=machine) setups. And when the new rendering engine is capable enough to work in such a situation we can integrate it. The benefit is a very fast start on the rendering side - w/o much needed internal FGFS knowledge and w/o the need to synchonize development at the beginning. CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB4ppglhWtxOxWNFcRAvA4AJ9TcDWEHcUCHRAvBGrSHQqyz91OsACgr2Vw PwkYmqngc8Qgy/4X9KOF32k= =7SGU -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] alternative terrain engine integration
Manuel Massing writes: I think an abstract Terrain API is a great idea however please keep in mind that FlightGear uses a round earth model and that this should be reflected in any FGFS Terrain API Is this methodology you want to integrate ? http://cg.cs.uni-bonn.de/docs/publications/2004/wahl-2004-scalable.pdf yes, that's it. In the paper this appears to be based on a 'flat Earth' model i.e. lon lat are taken to be simple X, Y or Cos(medianX)*X,Y Perhaps I am missing something or you have extended the engine since this was written ? Are you folks familiar with this work http://globe.sintef.no/documentation/projection.html Cheers Norman ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] alternative terrain engine integration
Norman Vine writes: In the paper this appears to be based on a 'flat Earth' model i.e. lon lat are taken to be simple X, Y or Cos(medianX)*X,Y ooops ... i.e. lon lat are taken to be simple X, Y or Cos(medianY)*X,Y ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] alternative terrain engine integration
Hi, If my memory serves, previous big changes to the codebase have been handled by having a conditional compilation option which switches on the new code (and switches off some old code if needed) and putting all changes in CVS HEAD. This allows people to try it if they want to, and avoids what I understand is the main problem of CVS branches, which is reintegration when it is complete. I don't exactly need to do big changes (as in many LOC), but some intrusive and scattered ones. Conditional compiles would be a _major_ hassle to this end. OTOH, I have never had any notable trouble merging branches... bye, Manuel ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] alternative terrain engine integration
Norman Vine wrote: Manuel Massing writes: Is this methodology you want to integrate ? http://cg.cs.uni-bonn.de/docs/publications/2004/wahl-2004-scalable.pdf yes, that's it. another interesting read from this project :-) http://cg.cs.uni-bonn.de/docs/publications/2004/harabasz-2004-out-of-core.pdf Cheers Norman ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] alternative terrain engine integration
Hi Norman, In the paper this appears to be based on a 'flat Earth' model i.e. lon lat are taken to be simple X, Y or Cos(medianX)*X,Y Perhaps I am missing something or you have extended the engine since this was written ? I don't remember if this was mentioned in the paper, but we use vertex shaders to simulate earth curvature (but could also be done on the CPU). The underlying datasets are projected; for whole earth visualisation, we split the earth into UTM zones (transverse mercator projection). This is important in order to limit map distortions and to retain valid error bounds for our elevation and texture data. I would have to look at the projection you mentioned, but I don't think it would be very well suited for our engine; because of its global nature there will inevitably be areas of high distortion. Additionally, the fact that a single landsat-textured UTM zone is a few 100 MB in size makes a monolithic global dataset unpractical. Are you folks familiar with this work http://globe.sintef.no/documentation/projection.html bye, Manuel ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] alternative terrain engine integration
Hello Christian, Probalby the easiest way would be to create an independant program first, that communicates with FGFS via the network api. The benefit is a very fast start on the rendering side - w/o much needed internal FGFS knowledge and w/o the need to synchonize development at the beginning. Thanks for the suggestion, but as the rendering engine is (mostly) finished, there will be not too much developemnt effort on this side (hopefully! :-)). Given the entangledness of the simulation with terrain handling, I don't think externalizing it via the network would be any easier... you would still have to set the same hooks, regardless if you couple via C++ API or the network. bye, Manuel ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
