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 0000000: 06 00 47 53 17 fd 05 49 ..GS...I > > NewSyd 0000000: 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 = 300000; // seconds > > > limit.rlim_max = 300000; // 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 [email protected] https://lists.sourceforge.net/lists/listinfo/flightgear-devel
