Next-generation scenery generating?

[Catalanoic]

Thats great! How long can take the generaton of BTG files?

[bugman]

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

Regards,
Edward

[psadro_gm]

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.

[butlert743]

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

[Thorsten]

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.

[psadro_gm]

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...

[pommesschranke]

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?

[psadro_gm]

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 )

[D-ECHO]

Though I don't understand much of the things talked about here now, it sounds amazing, looking forward to see it...some day.... Thanks

[Hooray]

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)

[psadro_gm]

Yes - a large benefit for using the raw DEM will be for moving maps - the elevation is pretty much displayable as-is.

[statto]

What's the raster resolution?

Rasters typically take up a lot more hard drive space than the triangulation we currently use...

[Hooray]

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.





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.

[psadro_gm]

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:

[D-ECHO]

Hi psadro,
Is there an objective of having this new generation in ws3? (Well, is there any planned release for ws3?)
Regards