Re: [Flightgear-devel] Scenery Creation/TerraGear problems
On Sat, 15 Oct 2011 08:53:45 + (UTC) Martin Spott martin.sp...@mgras.net wrote: I think the only solution is to make GPC obsolete - either by replacing GPC by something different but functional equivalent or simply (TM ;-) by avoiding any polygon clipping in 'fgfs-construct' overall. For what it's worth... I am currently trying to generate custom scenery for all of Europe based on Corine + OSM data (similar to what I did for France some time ago: http://wiki.flightgear.org/Custom_France_Scenery), and I am also getting lost in the intricacies of fgfs-construct and crashes in GPC. I managed to make a few changes in the code that improved the situation: - conversely to what is suggested in README.gpc, I did not change the GPC_EPSILON constant (left it defined as DBL_EPSILON) - I completely disabled the removal of so-called bad nodes in poly_support.cxx However I did a lot of preprocessing of the data in Postgis before feeding it to fgfs-construct, hopefully removing the need for the hacks mentioned above. So far this configuration has proved very stable for me, and I was able to generate more than a hundred of 1x1 deg tiles without any crash. So far the only problems that remain seem to be located around the 0deg longitude area - there, I am still running into the problem of the NULL pointer in the GPC merge_right(). What I noticed so far lends me to think that there is a lot of code in terragear that is supposed to deal with imperfect input data - and should maybe be deactivated. Can anyone shed some light on what the bad node detection is supposed to achieve, for instance ? Also, the suggested increase of GPC_EPSILON is bound to introduce inconsistencies in the geometric routines - much better to clean up the input data). Unfortunately, there are many places in terragear where some arbitrary epsilon constants are hiding with unexpected effects - just run grep -r '0\.' terragear-cs and count the matches if you don't believe me. So maybe the problem is not in GPC after all but in what we feed it Maxime -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Alaska 2arc elevation data USGSDEM
Hi Scenery Here I provide converted and clipped Alaska elevation data (2arc seconds) from NED USGS, for testing and developing purposes. The original data is distributed from NED in ArcGIS format, I needed to convert to USGSDEM format to create a new relief for my map. Maybe this will be useful for someone else - and I am still curious if it is possible to get FlightGear scenery with this data. I still have not checked it with our scenery tools, I hope someone else finds the time once. http://maptest.fgx.ch:81/alaska-sources/ned-usgs-2arc-dem-clipped/ Cheers, Yves -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
The 'bad' nodes are points that are co linear with a previous segment on the same contour. When this happens, the even-odd algorithms used for clipping only see one intersection instead of two. So, as a scanline is evaluated, if we were currently outside a poly, we would then determine we were inside, when it should have gone back to outside. In papillon's terragear repo, we have integrated clipper, which is an actively supported clipping routine that has far fewer errors, and is faster as well. I still hit these bad nodes often still, however. I am experimenting with nudging these nodes perpendicular away from the segment they touch instead of removing them completely. Will update when if I get consistent results. On Oct 16, 2011 7:22 AM, Maxime Guillaud m...@mguillaud.net wrote: On Sat, 15 Oct 2011 08:53:45 + (UTC) Martin Spott martin.sp...@mgras.net wrote: I think the only solution is to make GPC obsolete - either by replacing GPC by something different but functional equivalent or simply (TM ;-) by avoiding any polygon clipping in 'fgfs-construct' overall. For what it's worth... I am currently trying to generate custom scenery for all of Europe based on Corine + OSM data (similar to what I did for France some time ago: http://wiki.flightgear.org/Custom_France_Scenery), and I am also getting lost in the intricacies of fgfs-construct and crashes in GPC. I managed to make a few changes in the code that improved the situation: - conversely to what is suggested in README.gpc, I did not change the GPC_EPSILON constant (left it defined as DBL_EPSILON) - I completely disabled the removal of so-called bad nodes in poly_support.cxx However I did a lot of preprocessing of the data in Postgis before feeding it to fgfs-construct, hopefully removing the need for the hacks mentioned above. So far this configuration has proved very stable for me, and I was able to generate more than a hundred of 1x1 deg tiles without any crash. So far the only problems that remain seem to be located around the 0deg longitude area - there, I am still running into the problem of the NULL pointer in the GPC merge_right(). What I noticed so far lends me to think that there is a lot of code in terragear that is supposed to deal with imperfect input data - and should maybe be deactivated. Can anyone shed some light on what the bad node detection is supposed to achieve, for instance ? Also, the suggested increase of GPC_EPSILON is bound to introduce inconsistencies in the geometric routines - much better to clean up the input data). Unfortunately, there are many places in terragear where some arbitrary epsilon constants are hiding with unexpected effects - just run grep -r '0\.' terragear-cs and count the matches if you don't believe me. So maybe the problem is not in GPC after all but in what we feed it Maxime -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Splitting FGdata (again, but now for real)
Hi, I started splitting fgdata this morning. Created a project to store FlightGear aircraft repositories, under https://gitorious.org/flightgear-aircraft More details are available on the wiki: http://wiki.flightgear.org/FlightGear_Git:_splitting_fgdata For some reason, this splitting seems to takes forever on Windows (like 25 minutes for the 744), while Jorg managed to split the F-f16 in 90 seconds on Linux! Jorg will run a script (being Cedric's script, or some homemade combination) to split all the other aircraft. @martin, I also have concerns about the easy-updating that we might loose. However, I found something called git submodules that might do the trick for us. There's a reference in the wiki article. Maybe someone with more git experience can comment on that one? I listed some cons and pros on the wiki, feel free to extend. Anyone's comments are welcome of course :) Cheers, Gijs -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Splitting FGdata (again, but now for real)
On Sun, 16 Oct 2011, Gijs de Rooy wrote: Hi, I started splitting fgdata this morning. Created a project to store FlightGear aircraft repositories, under https://gitorious.org/flightgear-aircraft More details are available on the wiki: http://wiki.flightgear.org/FlightGear_Git:_splitting_fgdata For some reason, this splitting seems to takes forever on Windows (like 25 minutes for the 744), while Jorg managed to split the F-f16 in 90 seconds on Linux! Jorg will run a script (being Cedric's script, or some homemade combination) to split all the other aircraft. @martin, I also have concerns about the easy-updating that we might loose. However, I found something called git submodules that might do the trick for us. There's a reference in the wiki article. Maybe someone with more git experience can comment on that one? I listed some cons and pros on the wiki, feel free to extend. Anyone's comments are welcome of course :) I would agree that it needs to be done, but if you wait around for a global consensus on the how, it's never going to happen. Just do it. g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.diy-cockpits.org/coll - Go Collimated or Go Home. Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! Political correctness is a doctrine, fostered by a delusional, illogical minority, and rabidly promoted by an unscrupulous mainstream media, which holds forth the proposition that it is entirely possible to pick up a turd by the clean end. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Splitting FGdata (again, but now for real)
Am 16.10.2011 16:14, schrieb Gijs de Rooy: For some reason, this splitting seems to takes forever on Windows (like 25 minutes for the 744), while Jorg managed to split the F-f16 in 90 seconds on Linux! Jorg will run a script (being Cedric's script, or some homemade combination) to split all the other aircraft. Time also depends on aircraft size / commit count. Worst and longest operation is eventually filtering the repo to get rid of all the aircraft. With something as large as fgdata, it'll probably take many, many hours :). And it's 384 aircraft repos to be created. Counting 383? Well, don't forget the Antonov AN-2 (https://www.gitorious.org/fg/ac-an2), which was split off months ago - it should also be added to the new project. And I'm curious whether gitorious.org is going to take such a huge number in a single project - I guess no one tried before ;). When you're done, we should rename fgdata and keep it, at least for some time, until we're sure everyting is safe. Also, all branches are lost with the new repos, so it may be good to retain the historic-fgdata, since it has the old release branches and tags. After renaming the old repo, we can create a fresh, new fgdata. cheers, Thorsten -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT
Flightgear already has such a system for scenery. You only download what you want, or need. Very few users need scenery for the whole world. Extending this concept to the bloated aircraft section of fgdata seems quite logical. I don´t think that anyone is talking about splitting apart the core parts of fgdata, just the optional aircraft. Perhaps one day someone will come up with a terrasync-like option to one of the front-ends ( fgrun) which will get chosen aircraft on-the fly when needed. Alan -Original Message- From: Martin Spott Sent: Saturday, October 15, 2011 7:29 PM Newsgroups: list.flightgear-devel To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] GIT Cedric Sodhi wrote: Developers have buoyantly indulged in their lethargy as ever before and passionately ignored the topic wherever it came up. I don't know everybody's favourites but, anyhow, maybe it's also a matter of preferences. Personally I'd hate having to pull dozends of repositories just to retrieve the current state of 'fgdata'. Therefore I'm quite happy with the current state. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] fgdata is frozen!
Jorg and Gijs are working on the new fgdata repo now. Therefore the existing fgdata repo is frozen as of now - even commit privileges are removed - hopefully permanently for the (historic) fgdata repo. They'll start a new (temporary) repository. Once the new repo is all setup and working as expected, we'll switch (shuffle the names) and add committers. cheers, Thorsten -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgdata is frozen!
Hi Thorsten, One question: if we have our own local branches of the fgdata repository for our own experimentation, will it be straightforward to hang these off the new repository? Thanks, Curt. On Sun, Oct 16, 2011 at 2:31 PM, ThorstenB wrote: Jorg and Gijs are working on the new fgdata repo now. Therefore the existing fgdata repo is frozen as of now - even commit privileges are removed - hopefully permanently for the (historic) fgdata repo. They'll start a new (temporary) repository. Once the new repo is all setup and working as expected, we'll switch (shuffle the names) and add committers. cheers, Thorsten -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgdata is frozen!
Am 16.10.2011 23:30, schrieb Curtis Olson: One question: if we have our own local branches of the fgdata repository for our own experimentation, will it be straightforward to hang these off the new repository? Simple answer: no. :-( Since we really want to reduce the repository size - that means reduce the git archive - we need to write a new repository. The change won't just be a normal (= forward) commit which removes aircraft. Instead, it's basically a completely new repository. We'll just give it the same name - but all these magic git commit identifiers (hashes) will have changed - even for the very earliest commits in our history. git will be extremely confused when we switch fgdata and you try to work with your existing repo. You can't just pull the new data into your existing repo, or expect your current local branches to match. Neither can you simply git merge old branches to the new repo, or push old branches to the new repo. You'll probably get funny non-fast forward errors and huge truck loads of merge conflicts. It's probably best to leave existing local fgdata repositories as they are, maybe rename and retain the directories - and start with a completely new repository. And if there's anything in your local repo you want to keep, then create a new branch in the new repo and manually move the stuff and recreate your local branch. At least that's the best that I know of. But maybe some else has a magic solution... But before we switch, we should really test the new repo and verify everything is ok. And we certainly need a short description of how exactly the new repo works - how we update/pull the aircraft etc. I'd expect all this to take a day or two. But let's see how Jorg and Gijs are getting a long - and keep your thumbs pressed. cheers, Thorsten -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
