Board index FlightGear Development Scenery

Next-generation scenery generating?

Questions and discussion about enhancing and populating the FlightGear world.

Re: Next-generation scenery generating?

Postby Catalanoic » Thu Jun 16, 2016 2:51 pm

Thats great! How long can take the generaton of BTG files?
User avatar
Catalanoic
 
Posts: 1078
Joined: Mon Mar 05, 2012 12:33 am
Location: Barcelona (LEBL)
Callsign: Catalanoic
Version: 2017.3
OS: Lubuntu/Windows 7

Re: Next-generation scenery generating?

Postby bugman » Thu Jun 16, 2016 3:38 pm

That's great news! What about bug #781 though? Is that also a blocker?

Regards,
Edward
bugman
Moderator
 
Posts: 1801
Joined: Thu Mar 19, 2015 9:01 am
Version: next

Re: Next-generation scenery generating?

Postby psadro_gm » Fri Jun 17, 2016 1:19 am

Bug 781 is a confirmed bug, and has not been fixed completely. It happened rarely, and after tweaking some of my cleaning routines, I no longer hit this on that particular tile.
Actual tile generation for the Hawaiian islands is probably 20 minutes. I still have some work to do to get terragear master complete enough to generate btg tiles in general. I was hoping for end of May, but I still find CGAL issues in my large test case - about 30sq degrees of Europe ( Corrine ). Hawaii hopefully won't find any more issues.
8.50 airport parser, textured roads and streams...
psadro_gm
 
Posts: 751
Joined: Thu Aug 25, 2011 2:23 am
Location: Atlanta, GA USA
IRC name: psadro_*
Version: git
OS: Fedora 21

Re: Next-generation scenery generating?

Postby butlert743 » Thu Aug 11, 2016 10:15 pm

This looks like a great project, but for the sake of other's performance on their devices, I think it might be better to make them separate scenery packs. On that note, If someone could create a photoreal scenery pack for the KATL airport, I would love that! I have compared it in Google Earth, and the scenery is actually is INCREDIBLY outdated, being from 2007. Unfortunately, I'm unable to help, as I am already occupied with livery creations. Along with that, my computer is very limited to what I can run.

-FlightGearFlyer on YouTube
butlert743
 
Posts: 42
Joined: Tue Aug 04, 2015 1:20 pm

Re: Next-generation scenery generating?

Postby Thorsten » Fri Aug 12, 2016 6:09 am

I have compared it in Google Earth, and the scenery is actually is INCREDIBLY outdated, being from 2007. Unfortunately, I'm unable to help, as I am already occupied with livery creations. Along with that, my computer is very limited to what I can run.


Better graphics and better performance are usually enemies. If your computer is very limited to what you can run, you'll probably be limited to last generation scenery.
Thorsten
 
Posts: 12017
Joined: Mon Nov 02, 2009 8:33 am

Re: Next-generation scenery generating?

Postby psadro_gm » Sun Aug 28, 2016 3:54 pm

Just a quick update on my progress - I've started scripting up how we would ship such raster images in terrasync.
I believe we'll likely ( as with the mesh ), want to have a couple LOD levels. so 1/8x1/8 degree ( currently smallest tile size ) would encoded at a certain resolution - next LOD up, tile size would be 1/4x1/4 ( or 1/2 x 1/2 ) - but use the same image size.

I've been scripting a few gdal tools to generate the chopped shapefiles ( in 1x1 degree blocks ), then running gdal_rasterize on the chopped shapefile.

On my pc, it takes about 400ms to rasterize 1/8x1/8 degree - BUT, we have to do several passes per landclass.

the attributes ( for smoothness, etc ) have to be rasterized on their own pass. Landclasses are rasterized on their own pass, etc.

so, for each tile, we need something like this:

# generate the geotiff raster - encode landclass into all four bands. ( note that this encodes geometry, so each landclass is done seperately - we just need to generate all four bands once )
gdal_rasterize -init 0 -burn $landclass -burn $landclass -burn $landclass -burn $landclass -ts 4096 4096 -ot Byte -co COMPRESS=DEFLATE --config GDAL_CACHEMAX 600 $chopped_file $raster_file

# encode next landclass
gdal_rasterize -burn $landclass -burn $landclass -burn $landclass -burn $landclass $chopped_file $raster_file

...

then burn smoothness into band 2 ( for each landclass... )
gdal_rasterize -b 2 -a SMOOTHNESS $chopped_file $raster_file

then burn some other attrib into band 3 - for each landclass...
gdal_rasterize -b 3 -a OTHERATTRIB $chopped_file $raster_file

So we will probably need to rasterize offline - with terragear.

The good news is that terragear becomes a couple of bash scripts :)
And this will allow scenery designers to alter any of the new shader's parameters directly from QGIS.

Here's the result of rasterizing just cs_drycrop into 1/8x1/8 degree tile - with misc attribs...
Image
8.50 airport parser, textured roads and streams...
psadro_gm
 
Posts: 751
Joined: Thu Aug 25, 2011 2:23 am
Location: Atlanta, GA USA
IRC name: psadro_*
Version: git
OS: Fedora 21

Re: Next-generation scenery generating?

Postby pommesschranke » Fri Sep 09, 2016 9:10 am

Hi Pete,

you wrote, that the new terragear does not produce tiles (or btg files) anymore?
so, current or older versions of flightgear can not use the next-gen scenery?

currently the biggest showstopper for updatind airports or adding new airports/runways is to
"cut the hole" into terrain because that requires to have all shapefiles for that area and takes a lot of computing time.
genapts850 is fast & easy to use, X-Plane does that at runtime. But building the tiles around the airport, and the requirement to also have to rebuild neighbour airports, is painful.

How is the workflow with the new version tools ? Is there something that I can try already?
pommesschranke
 
Posts: 1105
Joined: Sat Apr 27, 2013 7:58 pm
Location: EDLM & LJCE
Callsign: d-laser
IRC name: laserman
Version: git
OS: Linux Lubuntu 18.04

Re: Next-generation scenery generating?

Postby psadro_gm » Fri Sep 09, 2016 11:58 am

I don't have anything to try yet, but I can describe how the toolchain would work:

Each 'piece' of the scenery will be independent.

If you need to modify the DEM, you can do so in qgis/grass. by editing the raster for your area. You would then need to update the DEM for each LOD covering this area - There will be a tool for that.
If you modify the landclass shapefiles, you can also do this in qgis/grass. You would then run a tool to rasterize the edited area - along with all of the LOD levels affected.
If you modify an airport, you would run genapt - it will generate the airport in 2D, along with the landclass shapefiles for the airport smoothing and airport boundaries - you would then run the landclass tool to regenerate the LOD levels affected by the airport boundary. - if the airport boundary doesn't change, you would not need to run this step.

If you bring in new OSM data, you would run a tool ( something similar to vector/poly decode ) to regenerate the road network. This is the least thought out part. Something I'm leaving for later. I think runtime-smoothing, and draping roads / stream is the only way to go. But there has been talk of encoding roads into the landclass raster. I don't know how that would work. I plan on having the DEM and landclass rasters - along with airport draping and smoothing done first - then we can decide how to do vector data.

I am also unsure how quickly we can smooth roads. I want to implement something like this instead of the very naive smoothing we currently have in terragear:
http://koenigstuhl.geog.uni-heidelberg. ... -final.pdf



The good news here, is that tgconstruct will go away - the 'combine' all the stuff info a single BTG is really reserved for flightgear.
- it will read the DEM, generate the elevation triangles ( with resolution dependent on distance )
- it will read the landclass texture ( resolution also LOD distance based )
- for airports in very close range, it will smooth the DEM, and drape the airport on top.

There is no forward compatible way to introduce this new terrain - it will rely on an as of yet not included landclass shader. It will also need to be linked against GDAL to read the raster images.
Note that this will be experimental for quite a while ( GDAL linkage will be default OFF, and the new scenery will not be available w/o building simgear/flightgear yourself - much like RTI )
8.50 airport parser, textured roads and streams...
psadro_gm
 
Posts: 751
Joined: Thu Aug 25, 2011 2:23 am
Location: Atlanta, GA USA
IRC name: psadro_*
Version: git
OS: Fedora 21

Re: Next-generation scenery generating?

Postby D-ECHO » Fri Sep 09, 2016 2:07 pm

Though I don't understand much of the things talked about here now, it sounds amazing, looking forward to see it...some day.... ;) :D Thanks
User avatar
D-ECHO
 
Posts: 2219
Joined: Sat May 09, 2015 12:31 pm

Re: Next-generation scenery generating?

Postby Hooray » Fri Sep 09, 2016 6:05 pm

re: the GDAL linkage, that should be a nobrainer for the osgEarth build, which already links in osgEarth anyway (IIRC), I was once using this to teach Canvas::Image to read GeoTIFF images for a moving map, so it would be good to provide a corresponding SimGear option (and maybe a few helper APIs), because other code/subsystems may benefit from GDAL/OGR related functionality (e.g. Canvas in this case)
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12186
Joined: Tue Mar 25, 2008 8:40 am

Re: Next-generation scenery generating?

Postby psadro_gm » Sat Sep 10, 2016 3:24 pm

Yes - a large benefit for using the raw DEM will be for moving maps - the elevation is pretty much displayable as-is.
8.50 airport parser, textured roads and streams...
psadro_gm
 
Posts: 751
Joined: Thu Aug 25, 2011 2:23 am
Location: Atlanta, GA USA
IRC name: psadro_*
Version: git
OS: Fedora 21

Re: Next-generation scenery generating?

Postby statto » Sat Sep 10, 2016 9:39 pm

What's the raster resolution?

Rasters typically take up a lot more hard drive space than the triangulation we currently use...
Custom Scenery available from http://www.stattosoftware.com/flightgear
statto
 
Posts: 2106
Joined: Fri Jan 25, 2008 9:57 pm

Re: Next-generation scenery generating?

Postby Hooray » Sat Sep 10, 2016 9:45 pm

psadro_gm wrote in Sat Sep 10, 2016 3:24 pm:Yes - a large benefit for using the raw DEM will be for moving maps - the elevation is pretty much displayable as-is.


There already is a Canvas::Image class handling raster images, and that could be easily subclassed/extended to support other DEM formats, which should also come in handy for in-sim debugging/troubleshooting, or even just tinkering with alternate scenery/terrain and LOD schemes.

The boilerplate code/stubs for registering new elements is pretty compact and straightforward: http://wiki.flightgear.org/Canvas_Sandbox

I once used this to add a dedicated Canvas::PDF handler that would render PDF files to an osg::Image.


Image


The same mechanism should work for DEM data, including hopefully ESRI shapefiles - which would help greatly boost moving map development in FlightGear, and which is something that James mentioned on various ocassions in the context of his hard-coded Map/NavDisplay components, as well as the G1000.

It's simply not a good idea to implement such features using ShivaVG/OpenVG paths - and we're also hitting limits regarding osgText based labels: viewtopic.php?f=71&t=17647

Thus, the corresponding GDAL/OGR dependencies would definitely have other valid use-cases in FlightGear, while also paving the way for anything related osgEarth based functionality.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12186
Joined: Tue Mar 25, 2008 8:40 am

Re: Next-generation scenery generating?

Postby psadro_gm » Sun Sep 11, 2016 12:24 am

statto: here's the 2x2 degree tiles I generated - The 1x1 are pure .hgt from vewfinderpanorama.org. I am compressing when I generate the next LOD. I will probably run the VFP 1x1 degree DEMs through gdalwarp to get compressed GTiff files as well:

max: -rw-rw-r--. 1 peter peter 2884802 Jun 8 2012 N00E006.hgt
min: -rw-rw-r--. 1 peter peter 15231 Sep 10 11:26 S16W178.hgt

Note that this is just elevation data. it is MUCH smaller than a .btg ( 64 of which make up a single 1x1 degree tile )

BUT: the landclass raster will be for 1/8x1/8 tile, and will probably be fairly large.. I will compress, though, and the compression should be pretty good, as it will contain large areas of data that is the same.

This hasn't reached the experimental stage yet. Let's see what it can do. I think if it works, you will really like it, as you will be able to modify your shapefiles in QGis, and see the results in fg without a complete scenery regen :)

edit: hmm -odd timestamp, and extension on these files. I'll need to run again to see what's up.

Here's a screenshot will the lowest res dem loaded into QGIS : I am unsure how much memory QGIS uses without loading the files, but it's looking pretty good to me:

Image
8.50 airport parser, textured roads and streams...
psadro_gm
 
Posts: 751
Joined: Thu Aug 25, 2011 2:23 am
Location: Atlanta, GA USA
IRC name: psadro_*
Version: git
OS: Fedora 21

Re: Next-generation scenery generating?

Postby D-ECHO » Sat Sep 17, 2016 4:36 am

Hi psadro,
Is there an objective of having this new generation in ws3? (Well, is there any planned release for ws3?)
Regards
User avatar
D-ECHO
 
Posts: 2219
Joined: Sat May 09, 2015 12:31 pm

PreviousNext

Return to Scenery

Who is online

Users browsing this forum: No registered users and 2 guests