Re: [Flightgear-devel] Scenery Creation/TerraGear problems
Hi Jason, Have just completed a new fgfs build, and a TG tool build, and have downloaded your - 34169132 newScenery-YSSY.tar.bz2 149396748 newScenery.tar.bz2 And yes, when I load that scenery in fgfs all I see are spaghetti strips, like in your work/fgfs-screen-001.png image... I unloaded it to a /media/Disk2/TG directory, and moved your 'Scenery' folder out of 'work'... then ran fgfs like - ~/fg/fg16$ ./run_fgfs.sh --timeofday=noon \ --fg-scenery=/media/Disk2/TG/newSydScenery/Scenery \ --airport=YSSY --aircraft=ufo --altitude=1000 run_fgfs.sh: Running: ./fgfs --fg-root=/home/geoff/fg/fg16/fgfs/data \ --timeofday=noon --fg-scenery=/media/Disk2/TG/newSydScenery/Scenery \ --airport=YSSY --aircraft=ufo --altitude=1000 loading scenario 'vinson_demo' getting flightplan: Cruise-1 AIShip: Cruise-1 initializing waypoints AIShip: Cruise-1 done initialising waypoints 0 creating 3D noise texture... DONE ERROR: opening /media/Disk2/TG/newSydScenery/Scenery/Terrain/e150s40/e150s34/YGNB.btg\ or /media/Disk2/TG/newSydScenery/Scenery/Terrain/e150s40/e150s34/YGNB.btg.gz for reading! ERROR: opening /media/Disk2/TG/newSydScenery/Scenery/Terrain/e150s40/e150s34/YSRI.btg\ or /media/Disk2/TG/newSydScenery/Scenery/Terrain/e150s40/e150s34/YSRI.btg.gz for reading! Turning a little to the right I get - http://geoffair.org/tmp/newSyd-YSSY.png It looks like the YSSY area got really messed up ;=)) Your YSSY.btg.gz does not look that different, in size at least S1.0.1 134376 2008-10-27 e150s40/e151s34/YSSY.btg.gz NewSyd 136285 2011-10-22 e150s40/e151s34/YSSY.btg.gz So I copy your YSSY.btg.gz into S1.0.1, and load that and it all looks fine... so it is a problem with the surrounding tiles!!! YSSY is in bucket 5426688, with surrounding buckets 5410315, 5426696, 5426681, 5426689, 5426697, 5426680 5410299 5410307... Now there is a ***BIG*** difference in the main YSSY bucket - S1.0.1 56333 2008-10-27 5426688.btg.gz NewSys 3814419 2011-10-22 5426688.btg.gz That's a WHOPPING 70 times larger, compressed... And replacing your tile with the scenery 1.0.1 tile, and the scene returns to normal - http://geoffair.org/tmp/newSyd-YSSY2.png So it is definitely THAT, and maybe other, tiles, that have been either badly generated OR are badly rendered... Un-gzipping both, and looking at the 'signature', there is no doubt this is a NEW GENERATION tile ;=)) S1.0.1 000: 06 00 47 53 17 fd 05 49 ..GS...I NewSyd 000: 0a 00 47 53 36 5f a2 4e ..GS6_.N with a 'S.G.0.6' versus a 'S.G.0.10' signature... Other scenery parts, like S. Head looks very good - http://geoffair.org/tmp/newSyd-SHead.png with lots of (minor) road detail that add reality... So what can I regenerate using your data and command, modified only for the out path... $ fgfs-construct --work-dir=. --output-dir=../Scene2/Terrain --lon=150 --lat=-30 --xdist=5 --ydist=5 AirportArea AirportObj SRTM2-Australia-3 LandMass Sand Rivers Lakes Freeways Trunk_Freeways Tertiary_Roads Service_Roads Secondary_Roads Primary_Roads Towns Cities Crops Railroads Residential_Roads After reading your 14 hours plus to build, and after an hour of running, that tile is not yet re-produced... maybe if I further limit the lat/lon - maybe with - --lon=151 --lat=-33 --xdist=1 --ydist=1 I will get there quicker... Another hour slipped by, and still no 5426688 tile built... then I remember you can give a single --tile-id=id to fgfs-construct... The idea is I am searching for a very easily repeatable set of data and parameters so that people like James, or others, can very easily build and test... I hope soon we will be rid of the 'swirlies', 'spaghetti', or what ever we want to call the problem... DRAT! Even using ONE --tile-id=5426688 it is still trundling along after two more hours... Am off to dinner, so will leave it running... But meantime hope this helps 'explain' clearly the problem Jason, and now I are still seeing... so maybe the sg_binobj is still not doing its job completely... either as a write, or read... Will report more if I find more... Regards, Geoff. On Mon, 2011-10-24 at 06:56 +1100, Jason Cox wrote: Geoff, the whole scenery build directory is http://dl.dropbox.com/u/3028956/newScenery.tar.bz2 The process that i used for cutting up the 3sec dems was to use your makeYSSY-1.0.4 to produce only the SRTM directory and run terrafit as well as produce the airports. After that everything came from shape files from ga.gov.au. I have found that all data in the VMAP is out of position with airports and coastal data and found that the shape files all align correctly. There were also some changes needed to one of the terragear files to increase the allowed build time for a tile. ~line 1187 in src/BuildTiles/Main/main.cxx limit.rlim_cur = 30;// seconds limit.rlim_max = 30;// seconds The build command fgfs-construct --work-dir=. --output-dir=Scenery/Terrain --lon=150 --lat=-30 --xdist=5
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
Hi Jason, Ok my 5426688.btg.gz took about 5 hours to generate. And most of the near final console output shows - ... center = [ -4.63734e+06, 2.55623e+06, -3.54361e+06 ] radius = 16282.1 dumping normals = 94646 creating 497 fans of type 0 creating 169 fans of type 1 creating 1470 fans of type 2 creating 32220 fans of type 3 creating 1040 fans of type 4 creating 216 fans of type 11 creating 335 fans of type 18 creating 20911 fans of type 19 creating 1428 fans of type 76 Output file = ../Scene2/Terrain/e150s40/e151s34/5426688.btg.gz points size = 0 pt_materials = 0 triangles size = 0 tri_materials = 0 strips size = 0 strip_materials = 0 fans size = 58286 fan_materials = 58286 nodes = 94646 colors = 0 normals = 94646 tex coords = 304869 total top level objects = 14 collecting custom objects from ./AirportArea/e150s40/e151s34/5426688.ind No custom objects ... [snip] ... No custom objects [Finished successfully] I guess it would have been nice if fgfs-construct output what 'version' BTG it was creating... It weights in at about the same size - 3772063 bytes versus your 3814419 bytes... and with 304869 tex coords thus it should be SG 10! And renders as the SAME crazy pattern ;=(( by fgfs... LOVE all the great roads you have added in other many non-broken tile areas ;=)) I think I could even pick out the small road a friend used to live at... And the twin parallel Pacific Highway north, with off ramps, etc... Great stuff... While on that specific VERY BAD tile I still get a reasonable 50-60 fps, and in other areas over 100 (in the ufo)... You can find it here - http://geoffair.org/tmp/5426688.btg.gz So tomorrow to try to discover is the problem in the fgfs-contruct output, the write, or in the fgfs read and rendering... Regards, Geoff. On Tue, 2011-10-25 at 07:22 +1100, Jason Cox wrote: Geoff, thanks for looking at this. I think that the swerllies have actually gone and are now replaced by spaghetti. the old behavior was the terrain being stretched inside a triangle incorrectly followed by tile not being produced at all. in FGFS this would also bottom out the rendering at 1 fps. now it renders all tile FPS never get 15fps, terrain is filling the tri correctly but the underling mesh is not been cleaned up correctly and so you get strips back to a point of origin. Just my take Jason On Mon, 2011-10-24 at 20:19 +0200, Geoff McLane wrote: Hi Jason, Have just completed a new fgfs build, and a TG tool build, and have downloaded your - 34169132 newScenery-YSSY.tar.bz2 149396748 newScenery.tar.bz2 And yes, when I load that scenery in fgfs all I see are spaghetti strips, like in your work/fgfs-screen-001.png image... I unloaded it to a /media/Disk2/TG directory, and moved your 'Scenery' folder out of 'work'... then ran fgfs like - ~/fg/fg16$ ./run_fgfs.sh --timeofday=noon \ --fg-scenery=/media/Disk2/TG/newSydScenery/Scenery \ --airport=YSSY --aircraft=ufo --altitude=1000 run_fgfs.sh: Running: ./fgfs --fg-root=/home/geoff/fg/fg16/fgfs/data \ --timeofday=noon --fg-scenery=/media/Disk2/TG/newSydScenery/Scenery \ --airport=YSSY --aircraft=ufo --altitude=1000 loading scenario 'vinson_demo' getting flightplan: Cruise-1 AIShip: Cruise-1 initializing waypoints AIShip: Cruise-1 done initialising waypoints 0 creating 3D noise texture... DONE ERROR: opening /media/Disk2/TG/newSydScenery/Scenery/Terrain/e150s40/e150s34/YGNB.btg\ or /media/Disk2/TG/newSydScenery/Scenery/Terrain/e150s40/e150s34/YGNB.btg.gz for reading! ERROR: opening /media/Disk2/TG/newSydScenery/Scenery/Terrain/e150s40/e150s34/YSRI.btg\ or /media/Disk2/TG/newSydScenery/Scenery/Terrain/e150s40/e150s34/YSRI.btg.gz for reading! Turning a little to the right I get - http://geoffair.org/tmp/newSyd-YSSY.png It looks like the YSSY area got really messed up ;=)) Your YSSY.btg.gz does not look that different, in size at least S1.0.1 134376 2008-10-27 e150s40/e151s34/YSSY.btg.gz NewSyd 136285 2011-10-22 e150s40/e151s34/YSSY.btg.gz So I copy your YSSY.btg.gz into S1.0.1, and load that and it all looks fine... so it is a problem with the surrounding tiles!!! YSSY is in bucket 5426688, with surrounding buckets 5410315, 5426696, 5426681, 5426689, 5426697, 5426680 5410299 5410307... Now there is a ***BIG*** difference in the main YSSY bucket - S1.0.1 56333 2008-10-27 5426688.btg.gz NewSys 3814419 2011-10-22 5426688.btg.gz That's a WHOPPING 70 times larger, compressed... And replacing your tile with the scenery 1.0.1 tile, and the scene returns to normal - http://geoffair.org/tmp/newSyd-YSSY2.png So it is definitely THAT, and maybe other, tiles, that have been either badly generated OR are badly rendered... Un-gzipping both, and looking at the 'signature', there is no doubt this is a NEW GENERATION tile ;=)) S1.0.1 000: 06 00 47 53 17 fd
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
On 25 Oct 2011, at 03:03, Geoff McLane wrote: You can find it here - http://geoffair.org/tmp/5426688.btg.gz So tomorrow to try to discover is the problem in the fgfs-contruct output, the write, or in the fgfs read and rendering... I'll take a look too :) All the info above looks very sane - nothing anomalous in the vertex/tex-coord counts. James -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
James, here is the scenery that I have generated. Te file 33M and i also have a complwork directory if you would like to look at that but its a +130M bz2 file http://dl.dropbox.com/u/3028956/newScenery-YSSY.tar.bz2 Jason On Sun, 2011-10-23 at 01:46 +0100, James Turner wrote: On 23 Oct 2011, at 00:41, Jason Cox wrote: I can now build more scenery but still hit the spaghetti network around YSSY. Was the change that you made only to a 32bit int? What do i need to do to change to 64bit int? I'd be pretty suspicious of this - much more likely, there's a bug in my code, than you actually need 64-bit indices. I won't say 'impossible', but I don't think GPUs or OSG actually support indices larger than 32-bits anyway, and even if they did, you'd still bring your GPU to its knees before hitting that limit. I have tests for 2^16 vertices / texture coords, which are all working, which suggests there's 'something else' going on. (Or my tests need to be extended) Can you make available, a zip/tarball with your work directories, so I can test locally? Or the produced btg? James -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
Hi Jason, Thanks for sharing your generated BTG files... I will try loading these soon... I am presently in the process of updating SG/FG/TG to the latest respective gits, particularly to get James' latest sg_binobj, and would appreciate having your full - newSydScenery/work perhaps excluding the newSydScenery/work/Scenery/Terrain/* which you have already provided... It would give me some quick data to try this new build of TG tools and then fgfs on... regardless of size... If you do not mind, can you advise, either here or directly, for the Sydney area - What HGT/DEM elevation source did you use? 1 or 3 arcsec, or other? Very important for the N Head Gap, and lots of other shear cliffs around Sydney. Did you push terrafit? If yes, what values? ie min-nodes and max-errors specifically... What source did you use for the landmass (ocean vs land) default? That is, what coastline data? Again important to get detailed harbor, and other coast features. What sources, SHP or other, did you use for the various landuse types? There are lots of 'green' areas in and around the city... Thanks, Geoff. On Sun, 2011-10-23 at 17:24 +1100, Jason Cox wrote: James, here is the scenery that I have generated. Te file 33M and i also have a complwork directory if you would like to look at that but its a +130M bz2 file http://dl.dropbox.com/u/3028956/newScenery-YSSY.tar.bz2 Jason On Sun, 2011-10-23 at 01:46 +0100, James Turner wrote: On 23 Oct 2011, at 00:41, Jason Cox wrote: I can now build more scenery but still hit the spaghetti network around YSSY. Was the change that you made only to a 32bit int? What do i need to do to change to 64bit int? I'd be pretty suspicious of this - much more likely, there's a bug in my code, than you actually need 64-bit indices. I won't say 'impossible', but I don't think GPUs or OSG actually support indices larger than 32-bits anyway, and even if they did, you'd still bring your GPU to its knees before hitting that limit. I have tests for 2^16 vertices / texture coords, which are all working, which suggests there's 'something else' going on. (Or my tests need to be extended) Can you make available, a zip/tarball with your work directories, so I can test locally? Or the produced btg? James -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
Geoff, the whole scenery build directory is http://dl.dropbox.com/u/3028956/newScenery.tar.bz2 The process that i used for cutting up the 3sec dems was to use your makeYSSY-1.0.4 to produce only the SRTM directory and run terrafit as well as produce the airports. After that everything came from shape files from ga.gov.au. I have found that all data in the VMAP is out of position with airports and coastal data and found that the shape files all align correctly. There were also some changes needed to one of the terragear files to increase the allowed build time for a tile. ~line 1187 in src/BuildTiles/Main/main.cxx limit.rlim_cur = 30;// seconds limit.rlim_max = 30;// seconds The build command fgfs-construct --work-dir=. --output-dir=Scenery/Terrain --lon=150 --lat=-30 --xdist=5 --ydist=5 AirportArea AirportObj SRTM2-Australia-3 LandMass Sand Rivers Lakes Freeways Trunk_Freeways Tertiary_Roads Service_Roads Secondary_Roads Primary_Roads Towns Cities Crops Railroads Residential_Roads hope this all helps Jason PS it took 860min to build On Sun, 2011-10-23 at 16:56 +0200, Geoff McLane wrote: Hi Jason, Thanks for sharing your generated BTG files... I will try loading these soon... I am presently in the process of updating SG/FG/TG to the latest respective gits, particularly to get James' latest sg_binobj, and would appreciate having your full - newSydScenery/work perhaps excluding the newSydScenery/work/Scenery/Terrain/* which you have already provided... It would give me some quick data to try this new build of TG tools and then fgfs on... regardless of size... If you do not mind, can you advise, either here or directly, for the Sydney area - What HGT/DEM elevation source did you use? 1 or 3 arcsec, or other? Very important for the N Head Gap, and lots of other shear cliffs around Sydney. Did you push terrafit? If yes, what values? ie min-nodes and max-errors specifically... What source did you use for the landmass (ocean vs land) default? That is, what coastline data? Again important to get detailed harbor, and other coast features. What sources, SHP or other, did you use for the various landuse types? There are lots of 'green' areas in and around the city... Thanks, Geoff. On Sun, 2011-10-23 at 17:24 +1100, Jason Cox wrote: James, here is the scenery that I have generated. Te file 33M and i also have a complwork directory if you would like to look at that but its a +130M bz2 file http://dl.dropbox.com/u/3028956/newScenery-YSSY.tar.bz2 Jason On Sun, 2011-10-23 at 01:46 +0100, James Turner wrote: On 23 Oct 2011, at 00:41, Jason Cox wrote: I can now build more scenery but still hit the spaghetti network around YSSY. Was the change that you made only to a 32bit int? What do i need to do to change to 64bit int? I'd be pretty suspicious of this - much more likely, there's a bug in my code, than you actually need 64-bit indices. I won't say 'impossible', but I don't think GPUs or OSG actually support indices larger than 32-bits anyway, and even if they did, you'd still bring your GPU to its knees before hitting that limit. I have tests for 2^16 vertices / texture coords, which are all working, which suggests there's 'something else' going on. (Or my tests need to be extended) Can you make available, a zip/tarball with your work directories, so I can test locally? Or the produced btg? James -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
James, good work :) I can now build more scenery but still hit the spaghetti network around YSSY. Was the change that you made only to a 32bit int? What do i need to do to change to 64bit int? I can also report that on my box running a GeForce 8400 that the frame rate above 80/sec :) Jason On Thu, 2011-10-20 at 10:04 +0100, James Turner wrote: On 20 Oct 2011, at 09:48, Jason Cox wrote: I am trying to test some builds around YWLM and just need to know if the changes for higher detailed scenery that you spoke of is in the repo? How do I tell the changes that were made to sg_binobj.cxx as I do not understand how to drive GIT to change to a branch? Yep it's all committed, and even tested! However you do need a tearrgear compiled against latest simgear, *not* against simgear-cs. James -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Ciosco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
On 23 Oct 2011, at 00:41, Jason Cox wrote: I can now build more scenery but still hit the spaghetti network around YSSY. Was the change that you made only to a 32bit int? What do i need to do to change to 64bit int? I'd be pretty suspicious of this - much more likely, there's a bug in my code, than you actually need 64-bit indices. I won't say 'impossible', but I don't think GPUs or OSG actually support indices larger than 32-bits anyway, and even if they did, you'd still bring your GPU to its knees before hitting that limit. I have tests for 2^16 vertices / texture coords, which are all working, which suggests there's 'something else' going on. (Or my tests need to be extended) Can you make available, a zip/tarball with your work directories, so I can test locally? Or the produced btg? James -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
James, I am trying to test some builds around YWLM and just need to know if the changes for higher detailed scenery that you spoke of is in the repo? How do I tell the changes that were made to sg_binobj.cxx as I do not understand how to drive GIT to change to a branch? Jason On Sat, 2011-10-15 at 16:20 +0100, James Turner wrote: On 15 Oct 2011, at 15:22, HB-GRAL 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. Martin. Hi Martin Are there any concrete suggestions ? Yes, it's being actively hacked on and tested, I believe, because the clipper is the most numerically sensitive part of the whole process, and performance sensitive too. One candidate is being tested already, and there's other options available, but it's really important not to regress the core functionality, so some caution is required! James -- 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 -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Ciosco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
On 20 Oct 2011, at 09:48, Jason Cox wrote: I am trying to test some builds around YWLM and just need to know if the changes for higher detailed scenery that you spoke of is in the repo? How do I tell the changes that were made to sg_binobj.cxx as I do not understand how to drive GIT to change to a branch? Yep it's all committed, and even tested! However you do need a tearrgear compiled against latest simgear, *not* against simgear-cs. James -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Ciosco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
Thanks will give it a try Jason On Thu, 2011-10-20 at 10:04 +0100, James Turner wrote: On 20 Oct 2011, at 09:48, Jason Cox wrote: I am trying to test some builds around YWLM and just need to know if the changes for higher detailed scenery that you spoke of is in the repo? How do I tell the changes that were made to sg_binobj.cxx as I do not understand how to drive GIT to change to a branch? Yep it's all committed, and even tested! However you do need a tearrgear compiled against latest simgear, *not* against simgear-cs. James -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Ciosco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Ciosco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
Hi. Here is a random thought: what if the polygon data was painted onto a raster texture (of some sufficient resolution) in correct bottom up order, rather than being clipped. Then at the end of the process we figure out how to extract the resulting polygons from the raster image. This would completely eliminate the polygon clipping (although not for the airport generation I guess) but would require solving another difficult problem. I've been thinking that we should use integers (or fixed point) for vertices when processing scenery. With sufficiently long integers (say, 32 or even 64 bits on newer machines?) the precision could be in millimeter level, even on a world scale. At least if I calculated correctly ;) The pro side would be that all calculations on integers are well defined, and degenerate cases would be easier to detect, without using any epsilons. I don't know whether the clippers support that, but at least some do work on integers only. Any comments on this? Lauri, a.k.a Zan -- Lauri Peltonen lauri.pelto...@gmail.com -- 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
HB-GRAL wrote: There is so many software to do exactly this task. I could not imagine that our scenery is THAT important for this developement. At least our Scenery led to significant improvements in the way GRASS7 deals with vector data ;-) 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
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
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
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
Jason Cox wrote: I am hoping to try your changes as I was constantly blowing up the scenery around YWLM by using osm residental data [...] OSM residential is quite ambitious - I'd be a happy man if I succeeded building tertiary without triggering GPC segfaults in 'fgfs-construct' 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. 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
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
Am 15.10.11 10:53, schrieb Martin Spott: 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. Martin. Hi Martin Are there any concrete suggestions ? 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
On 15 Oct 2011, at 15:22, HB-GRAL 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. Martin. Hi Martin Are there any concrete suggestions ? Yes, it's being actively hacked on and tested, I believe, because the clipper is the most numerically sensitive part of the whole process, and performance sensitive too. One candidate is being tested already, and there's other options available, but it's really important not to regress the core functionality, so some caution is required! James -- 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
Hi James Thank you very much (and Martin of course) for diving into. I am just curious how you go to replace GPC. Cheers, Yves Am 15.10.11 17:20, schrieb James Turner: On 15 Oct 2011, at 15:22, HB-GRAL 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. Martin. Hi Martin Are there any concrete suggestions ? Yes, it's being actively hacked on and tested, I believe, because the clipper is the most numerically sensitive part of the whole process, and performance sensitive too. One candidate is being tested already, and there's other options available, but it's really important not to regress the core functionality, so some caution is required! James -- 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
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
HB-GRAL wrote: Am 15.10.11 10:53, schrieb Martin Spott: 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. Are there any concrete suggestions ? As James wrote, one option would be to replace GPC by another clipper (not my expertise). The second option I am investigating is to do all the cleaning and clipping, including cutting holes for line data and airports into the land cover, directly in PostGIS or, preferred, GRASS, thus obsoleting the entire vector preparation in 'fgfs-construct' 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
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
Am 16.10.11 00:30, schrieb Martin Spott: HB-GRAL wrote: Am 15.10.11 10:53, schrieb Martin Spott: 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. Are there any concrete suggestions ? As James wrote, one option would be to replace GPC by another clipper (not my expertise). The second option I am investigating is to do all the cleaning and clipping, including cutting holes for line data and airports into the land cover, directly in PostGIS or, preferred, GRASS, thus obsoleting the entire vector preparation in 'fgfs-construct' Cheers, Martin. There is so many software to do exactly this task. I could not imagine that our scenery is THAT important for this developement. 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
Hi all, Just giving the whole scenery gen ago for the YWLM area and found that the latest git pull appears to broken. the make bailed out with the following Making all in DemRaw2ascii make[3]: Entering directory `/data/terragear/terragear-cs/src/Prep/DemRaw2ascii' make[3]: *** No rule to make target `main.c', needed by `main.o'. Stop. make[3]: Leaving directory `/data/terragear/terragear-cs/src/Prep/DemRaw2ascii' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/data/terragear/terragear-cs/src/Prep' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/data/terragear/terragear-cs/src' I then did a git pull just to make sure that it wasn't a file that i missed but it reports that i am up to date. Jason On Sat, 2011-10-08 at 14:29 +0200, Geoff McLane wrote: On Sat, 2011-10-08 at 11:17 +0100, James Turner wrote: On 7 Oct 2011, at 19:24, Martin Spott wrote: This is what happens when running 'genapts' with a modified 'simgear-cs' on a _really_ simple airport layout (EDKA, consisting of just one runway and two windsocks): [snip] What's the easiest way for me to get enough data to run gen-apts? But maybe it's time for that, anyway :) James Hi James, As a 'quick' sort of setup you might try my TgScenery GUI if you have Qt (SDK and Creator) installed - http://geoffair.org/fg/tg-05.htm just updated today... Just load the TgScenery.pro in Qt Creator, and push F5 to compile and run... Setup your 'favorite' area, and where you want the scenery put, and proceed through the tab pages, action by action... Not particularly 'proud' of it - it was my very first Qt coding attempt - but it does its job... Am slowly working on a TgTake2, with threading, but it is not yet functional, since you will see lots of what seem frozen pauses in TgScenery ;=(( be patient... Or indeed you could try Gijs's TerraGui on which my efforts were originally based - http://wiki.flightgear.org/index.php/TerraGear_GUI Really does the same thing. Has some 'manual' steps, but with a good descriptive wiki... HTH. With a new, working BTG writer/loader everybody can participate in their particular scenery generation ;=)) Yahoo... and thanks... been waiting ages for this... Regards, Geoff. -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ 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
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
On 14 Oct 2011, at 23:42, Jason Cox wrote: I then did a git pull just to make sure that it wasn't a file that i missed but it reports that i am up to date. I've been doing some TerraGear hacking recently, so I'm the most likely person to have caused this, but on both my systems (Linux and Mac) this builds with problem, so I'm not sure what to say! James -- 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
James, I am hoping to try your changes as I was constantly blowing up the scenery around YWLM by using osm residental data and my TOPO's from ga.gov.au I will try a clean terragear pull and see how that goes Jason On Sat, 2011-10-15 at 01:37 +0100, James Turner wrote: On 14 Oct 2011, at 23:42, Jason Cox wrote: I then did a git pull just to make sure that it wasn't a file that i missed but it reports that i am up to date. I've been doing some TerraGear hacking recently, so I'm the most likely person to have caused this, but on both my systems (Linux and Mac) this builds with problem, so I'm not sure what to say! James -- 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
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
On 7 Oct 2011, at 19:24, Martin Spott wrote: This is what happens when running 'genapts' with a modified 'simgear-cs' on a _really_ simple airport layout (EDKA, consisting of just one runway and two windsocks): Starting program: /home/martin/install_headless/bin/genapts --input=/home/martin/landcover/EDKA.dat.gz --work=/home/martin/workdirs --clear-dem-path --dem-path=SRTM2-VFP-3 --dem-path=SRTM2-Africa-3 --dem-path=SRTM2-Australia-3 --dem-path=SRTM2-Eurasia-3 --dem-path=SRTM2-Islands-3 --dem-path=SRTM2-North_America-3 --dem-path=SRTM2-South_America-3 --dem-path=DEM-USGS-3 --dem-path=SRTM-30 --nudge=20 --min-lon=2.8 --min-lat=49.8 --max-lon=8.2 --max-lat=54.2 Ouch, that's bad - I was testing by 'transcoding' existing BTG files (read in, write out, read in again, verify everything looks sane) - since I didn't (yet) attempt to build or run terragear. What's the easiest way for me to get enough data to run gen-apts? Can I rsync / download a small set of data, or do I need to setup a complete terragear environment? But maybe it's time for that, anyway :) James -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
On 4 Oct 2011, at 13:53, James Turner wrote: Of course, I can't confirm or deny that suspicion until I upgrade the writer code path too :) I've committed an updated BTG reader/writer to simgear/next, which supports the current format, and a higher-versioned format with 32-bit indices. Based on some conversions, 32-bit indices (all zeroes so far) compress down with gzip -9 to a tiny size increase over 16-bit indices (less than 4%), but I've also added code on the write path to check the maximum index size, and select the output format - so tiles will be in the current format until they exceed 2^16 vertices. If someone could incorporate the revised sg_binobj.cxx from simgear/next into simgear-cs, and verify the results with terragear, I'd be fascinated to know if the 'swirlies' are gone! (Or, of course, if you encounter any issues - perish the thought) James -- 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-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
On Thu, Oct 6, 2011 at 3:35 PM, James Turner zakal...@mac.com wrote: I've committed an updated BTG reader/writer to simgear/next, which supports the current format, and a higher-versioned format with 32-bit indices. Based on some conversions, 32-bit indices (all zeroes so far) compress down with gzip -9 to a tiny size increase over 16-bit indices (less than 4%), but I've also added code on the write path to check the maximum index size, and select the output format - so tiles will be in the current format until they exceed 2^16 vertices. If someone could incorporate the revised sg_binobj.cxx from simgear/next into simgear-cs, and verify the results with terragear, I'd be fascinated to know if the 'swirlies' are gone! (Or, of course, if you encounter any issues - perish the thought) What could possibly go wrong? :-) Curt. -- 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-d2dcopy1___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
James Turner wrote: If someone could incorporate the revised sg_binobj.cxx from simgear/next into simgear-cs, and verify the results with terragear, I'd be fascinated to know if the 'swirlies' are gone! Will do, thanks a lot so far ! Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
On 2 Oct 2011, at 19:00, J. Holden wrote: Still, as a scenery developer and not a programmer, I'm still wondering what the limit is before the swirlies start floating around. Is it vertices? Fans? Triangles? It's 65536 vertices per BTG, in total. Strictly, this isn't true - the BTG format already supports 2^32 vertices / normals / colors in the file, but any object (tri / strip / fan) can only specify any index from 0..65535, so the higher vertices can't be used in any meaningful way. The good news is, I have the code to read a newer version basically done, which will make all the indices 32-bit, while of course keeping compatibility with existing BTG files of the current versions. Bad news is, we also need to update the writer code, and then measure how much the file size increases, after gzip compression. James -- 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-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
On Tue, Oct 4, 2011 at 3:10 AM, James Turner zakal...@mac.com wrote: On 2 Oct 2011, at 19:00, J. Holden wrote: Still, as a scenery developer and not a programmer, I'm still wondering what the limit is before the swirlies start floating around. Is it vertices? Fans? Triangles? It's 65536 vertices per BTG, in total. Strictly, this isn't true - the BTG format already supports 2^32 vertices / normals / colors in the file, but any object (tri / strip / fan) can only specify any index from 0..65535, so the higher vertices can't be used in any meaningful way. The good news is, I have the code to read a newer version basically done, which will make all the indices 32-bit, while of course keeping compatibility with existing BTG files of the current versions. Bad news is, we also need to update the writer code, and then measure how much the file size increases, after gzip compression. Hi James, Here's a random idea on the writer side: Would it be possible to do something like: if (size of any of my structures are 65535) then write_32bit_index_btg() else write_16bit_index_btg() endif Then we'd be spending are larger index bits on the files that need them, but not paying the penalty across the board on every scenery file. Curt. -- 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-d2dcopy1___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
On 4 Oct 2011, at 13:34, Curtis Olson wrote: Here's a random idea on the writer side: Would it be possible to do something like: if (size of any of my structures are 65535) then write_32bit_index_btg() else write_16bit_index_btg() endif Then we'd be spending are larger index bits on the files that need them, but not paying the penalty across the board on every scenery file. Entirely possible, yes - however I *suspect* it's unnecessary since gzip will compress the larger indices back down to a few % larger than what we currently have. Of course, I can't confirm or deny that suspicion until I upgrade the writer code path too :) James -- 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-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
On Tue, Oct 4, 2011 at 7:53 AM, James Turner zakal...@mac.com wrote: Entirely possible, yes - however I *suspect* it's unnecessary since gzip will compress the larger indices back down to a few % larger than what we currently have. Of course, I can't confirm or deny that suspicion until I upgrade the writer code path too :) Yes, but real world data can really spoil a fun theoretical discussion. :-) Curt. -- 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-d2dcopy1___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
On Tue, 04 Oct 2011 13:53:29 +0100, James wrote in message 04ab1637-d3b3-4396-9a68-4910e1235...@mac.com: On 4 Oct 2011, at 13:34, Curtis Olson wrote: Here's a random idea on the writer side: Would it be possible to do something like: if (size of any of my structures are 65535) then write_32bit_index_btg() else write_16bit_index_btg() endif Then we'd be spending are larger index bits on the files that need them, but not paying the penalty across the board on every scenery file. Entirely possible, yes - however I *suspect* it's unnecessary since gzip will compress the larger indices back down to a few % larger than what we currently have. ..how about write_64bit_index_btg(), could it index all tile files? Of course, I can't confirm or deny that suspicion until I upgrade the writer code path too :) James -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- 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-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
Very good read - thanks. I was worried the limit had been reached and that may have been demoralizing - but I'm going to keep pushing forward now. Still, as a scenery developer and not a programmer, I'm still wondering what the limit is before the swirlies start floating around. Is it vertices? Fans? Triangles? I'm going to try to reduce some of the vertices for Minneapolis-St. Paul and try a rebuild before moving onto my next project... wherever that may be :) Cheers John -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
On 1 Oct 2011, at 03:33, Curtis Olson wrote: That could very well be true ... and I don't think it would be a huge coding change ... but it should be done in a way that bumps up the btg version number and picks a new packet id so as to maintain backwards compatibility with all the existing scenery out there. Just looking at the relevant Simgear code - it already runs through GZip, so I'm not worried about overhead there - and the versioning system looks pretty sane to deal with too. There's already the version check for short-vs-unsigned-short counts, adding a new version increment and making the values longs looks pretty easy. BUT, if I modify the current Simgear code on 'next', is that the only place that needs to be changed, or is there another copy of this code somewhere in the terragear repo? I know terragear depends on simgear, but I've not looked at which code is actually shared. James -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
On Sat, Oct 1, 2011 at 9:29 AM, James Turner wrote: Just looking at the relevant Simgear code - it already runs through GZip, so I'm not worried about overhead there - and the versioning system looks pretty sane to deal with too. There's already the version check for short-vs-unsigned-short counts, adding a new version increment and making the values longs looks pretty easy. BUT, if I modify the current Simgear code on 'next', is that the only place that needs to be changed, or is there another copy of this code somewhere in the terragear repo? I know terragear depends on simgear, but I've not looked at which code is actually shared. Hi James, the answer is yes. :-) We need to modify the loader in simgear as well as the format generation code in terragear. Right now the indices are packed as 2-byte short ints in the binary .btg file so of course making a change only to the simgear side will do nothing to fix the problem. Whatever we do needs to happen in close coordination with the terragear code in order to make sure that the changes match and are sane and reasonable from both perspectives. Regards, Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
On 1 Oct 2011, at 15:37, Curtis Olson wrote: We need to modify the loader in simgear as well as the format generation code in terragear. Right now the indices are packed as 2-byte short ints in the binary .btg file so of course making a change only to the simgear side will do nothing to fix the problem. Whatever we do needs to happen in close coordination with the terragear code in order to make sure that the changes match and are sane and reasonable from both perspectives. Okay, but the relevant source file (sg_binobj) appears to contain both the read *and* write code paths - which is really what I was asking - is the write logic in sg_binobj.cxx the one terragear uses, or 'something else'? James -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
I think the original intention was to keep the read/write together and centralized so it was easier to keep format changes compatible. That said, I haven't been tracking terragear-cs changes so I don't know what version of simgear they are using or if they've made other changes around this area. Curt. On Sat, Oct 1, 2011 at 10:51 AM, James Turner zakal...@mac.com wrote: On 1 Oct 2011, at 15:37, Curtis Olson wrote: We need to modify the loader in simgear as well as the format generation code in terragear. Right now the indices are packed as 2-byte short ints in the binary .btg file so of course making a change only to the simgear side will do nothing to fix the problem. Whatever we do needs to happen in close coordination with the terragear code in order to make sure that the changes match and are sane and reasonable from both perspectives. Okay, but the relevant source file (sg_binobj) appears to contain both the read *and* write code paths - which is really what I was asking - is the write logic in sg_binobj.cxx the one terragear uses, or 'something else'? James -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ 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 of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
James Turner wrote: Okay, but the relevant source file (sg_binobj) appears to contain both the read *and* write code paths - which is really what I was asking - is the write logic in sg_binobj.cxx the one terragear uses, or 'something else'? James Please be aware that TG uses SG-CS currently. I used it with the normal SG for a while but this was no longer possible recently. It exposed weird behaviour and crashes. Chris -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
Christian Schmitt wrote: Please be aware that TG uses SG-CS currently. I used it with the normal SG for a while but this was no longer possible recently. It exposed weird behaviour and crashes. Indeed, we're still maintaining a simgear-cs for terragear-cs to keep a working source tree as a fallback in those situations when essential features are removed from stock simgear (which already had happened). Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
Martin Spott wrote: Indeed, we're still maintaining a simgear-cs for terragear-cs to keep a working source tree as a fallback in those situations when essential features are removed from stock simgear (which already had happened). http://mapserver.flightgear.org/git/gitweb.pl?p=terragear-cs;a=commitdiff;h=4e9a529b1f0da025c61dc73503cef6d55daa51f5;hp=f68f25e0c5c7477905173ed9a94aa53e5c624719 -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
J. Holden wrote: I apologize in advance considering I'm in a very complaining mood at the moment. From my perspective that's ok. We've been doing experiments with detailed land cover data and (OSM-) roads for about five years now - the first sample was built for LinuxTax 2006 - and I know how frustrating this swirlie effect could be. Yet there's no solution I'd be able to provide. Hah, I managed to find the web page I've been searching for weeks, Bruce did a pretty nice writeup of the problem: http://www.cullam.com/flightgear.htm Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
J. Holden wrote: PS - I only get around 3-6 FPS on this brand new laptop(!), and I'm finding with 2.4 simply launching fgfs --airport=KMSP --aircraft=ufo loads up local weather/real-time weather, which is terrible for a simple scenery flyover test on a poorly performing computer Yup, we (Torsten any myself) noticed the same while performing a semi-public demo last weekend. That's quite annoying, indeed. In general, local_weather is supposed to be inactive by default as set in 'preferences.xml': http://mapserver.flightgear.org/git/gitweb.pl?p=fgdata;a=blob;f=preferences.xml#l1249 I have not yet found out why it's still enabled at startup. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
On 30 Sep 2011, at 11:56, Martin Spott wrote: Hah, I managed to find the web page I've been searching for weeks, Bruce did a pretty nice writeup of the problem: http://www.cullam.com/flightgear.htm A very useful description, yes! James -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
All that weird stuff is quite easy to explain. The binary .btg scenery format uses 16 bit integers as indices for the vertex, normal, texture coordinate lists. At one point we were using signed 16 bit integers, but I'm pretty sure we sneakily changed the flightgear btg loader to use unsigned 16 bit ints. So this changed the original limitation of a max of 32,768 vertices/texture coords/normals, etc. up to 65,535. However, I don't know if the terragear-cs tools ever got this fix on the scene generation side. So if your scenery exceeds these limits, this is exactly what you will see. The ultimate solution will be to expand the btg format to 3 or 4 byte integers -- but that will again require changes in the terragear-cs tools as well as changes in the flightgear btg loader. Conveniently we have a versioning system in the btg format so we can extend the format and maintain backwards compatibility if we want. The downside is that this index is used so much in the scenery files that going to a larger int size will have an immediate corresponding proportional impact on the btg sizes of all the files. There may be other ways to tackle this problem too ... maybe the btg format emitter could detect if the size exceeds the threshold of the current format and output just the tiles that require the extended format in the extend format. (Sorry it's late friday, I hope that makes sense.) :-) Curt. On Fri, Sep 30, 2011 at 8:54 AM, James Turner zakal...@mac.com wrote: On 30 Sep 2011, at 11:56, Martin Spott wrote: Hah, I managed to find the web page I've been searching for weeks, Bruce did a pretty nice writeup of the problem: http://www.cullam.com/flightgear.htm A very useful description, yes! James -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ 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 of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
Am Fri, 30 Sep 2011 16:10:39 -0500 schrieb Curtis Olson curtol...@gmail.com: The downside is that this index is used so much in the scenery files that going to a larger int size will have an immediate corresponding proportional impact on the btg sizes of all the files. Ten years ago 16 Bit hurt much more than 32 Bit nowadays... And, wouldn't a compressor (tgz, bz2, ...) solve that issue, at least for distribution (trafficwise)? -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
On Fri, Sep 30, 2011 at 4:22 PM, joac...@gmx.de wrote: Am Fri, 30 Sep 2011 16:10:39 -0500 schrieb Curtis Olson curtol...@gmail.com: The downside is that this index is used so much in the scenery files that going to a larger int size will have an immediate corresponding proportional impact on the btg sizes of all the files. Ten years ago 16 Bit hurt much more than 32 Bit nowadays... And, wouldn't a compressor (tgz, bz2, ...) solve that issue, at least for distribution (trafficwise)? That could very well be true ... and I don't think it would be a huge coding change ... but it should be done in a way that bumps up the btg version number and picks a new packet id so as to maintain backwards compatibility with all the existing scenery out there. Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Scenery Creation/TerraGear problems
I apologize in advance considering I'm in a very complaining mood at the moment. I've just compiled 4 square degrees of scenery around the Minneapolis/St. Paul area in an attempt to figure out whether or not my Alaska scenery creation process worked on places in the lower 48 states. Fortunately, the answer is yes, the process works and the scenery built successfully. Minneapolis is kind of boring minus the lakes, but the scenery also looks like the upper midwest, and there are a lot of interesting rivers to follow. Unfortunately, I've run into problems with what I'll call the swirlies and the staircases. The first is the swirlies - I'm sure people have seen these before, where someone builds a dense road network and all of a sudden all the textures are stretched into oblivion. I'll call them the swirlies because up close the texture pattern looks like a swirl. The second is the staircases. Basically, the fan constructions don't include any sort of centroids, so for large glaciers the elevation literally goes up in steps as the fans walk up. This staircases effect also causes an issue in mountainous valleys. Sometimes the fan will not pick up part of the canyon floor, instead going from peak to peak. This can have a very pronounced effect when you are flying, and there are instances of this in the Alaska scenery as well (and others, but this is the cause). My question is, what can I do from a data point of view to fix these problems? I'm using v.generalize instead of v.clean in my GRASS workflow this time around, which is much faster and gives better results - but it doesn't clean any vertices. As a result, for both Alaska and Minneapolis sceneries, there are a number of strange constructions with the irregular mesh. I know how the irregular mesh is formed. I've designed a couple golf courses for Links 2003 using a similar method and dropping a centroid or a few really can help the wireframe - unfortunately I don't have access to the actual wireframe scenery structure, nor is this a recommended way to edit the files. I could also use v.clean and remove some of the vertices, which in turn would reduce the number of fans. I know there is a limit on fans or vertices? with .btg files, but this scenery is only of a medium-high quality, and compared to other sceneries I've created I'm not sure there's really a need to do this other than for performance. Plus, I'm loathe to run v.clean because pruning became very, very slow sometime in between GRASS 5 and GRASS 6.4, even though v.generalize doesn't remove any vertices, which is a problem. Oh, and Minneapolis/St. Paul scenery is available for anyone who wants it, but please email me personally because it's buggy. (However there is one very nice grass-runway airport which is placed on the cliff of a river - technically a bug but taking off is a fun challenge!) PS - I only get around 3-6 FPS on this brand new laptop(!), and I'm finding with 2.4 simply launching fgfs --airport=KMSP --aircraft=ufo loads up local weather/real-time weather, which is terrible for a simple scenery flyover test on a poorly performing computer - I get 1 FPS because I can't change visibility - is there a way to disable this feature from loading on startup from the command line? Cheers John -- 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-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
