Next-generation scenery generating?

[D-ECHO]

Any progress?
Thank you very very much for what you did!

[psadro_gm]

Yes, I've been working quite a bit on it yesterday.

1) The DEM Reader now supports more than 1 directory ( it uses the existing scenery paths, and priority scheme )
2) I setup a test where I have two DEMS - the normal 3" DEM, and about halfway through Hawaii's big island, I have a 1" DEM. This DEM is first in the scenery list.
( I haven't run tests, yet, however )
This will make custom scenery designers happy - you can easily test, and submit changes to them DEM
3) Code cleanup - SGDem.hxx / SGDem.cxx were growing too large. I'm splitting them up into 1 .hxx/.cxx file per C++ object.
4) I added new options / SGProperties to select the texturing mode of the DEM
bluemarble - use the single 4096x4096 texture
debug - use a solid color per LOD
raster - use a raster per tile ( will be default )

Pete

[D-ECHO]

That's amazing, as americans say
Now the most important to me as a scenery editor, what's about landclasses atm?

[Thorsten]

To be encoded as raster image color, to be decoded by the nextgen terrain shader.

[psadro_gm]

yes, I'll post my test script that generated the raster images on the wiki this week. It's just a test right now. For each landclass, it encodes 3 channels - red, green, and blue, so I can test without a shader, first. landclass will be just solid color.
It can also encode a landclass ID, and smoothing parameter. it's just a script calling GDAL executables.

Once we get some test area complete, I will probably create an executable instead of the script. gdal_rasterize in particular, is not very efficient. it takes for passes per rasterization. I also want to multthread the operation, because as it stands, rasterizing actually takes longer than ogr-decode / tgconstruct from terragear. (Althouh it is MUCH less error prone )

Scenery editing would be reduced to editing shapefiles in QGIS, and setting each shapefile feature to the correct landclass ID, and smoothing, etc. Save in vector format, which could then be merged into the official postGIS database.

Scenery generation would consist of re-rasterizing the affected bounding box.

[psadro_gm]

I've been working a bit more on this, and I now have the ability to use different scenery paths for custom scenery ( or the ability to test small scenery updates without modifying the main terrasync dir ). I will continue this work, but I also think we should discuss osgearth some more as well:

I've updated my osgearth repos with Jeff Bigg's latest, and I think there's a lot to be gained by taking a closer look at what osgearth enables.
They seem to be moving a bit away from pure photscenery, and moving in the same direction we are for next gen scenery. ( although photoscenery is still an option )

Unfortunately, none has been released yet, so I was unable to get the splat global coverage layer working. I wonder if they will add that to the data repo eventually.

Checkout their screenshots of trees / grassy areas around September 2015:

https://twitter.com/pelicanmapping/media

here's the example ( including hardcoded local path )

http://code.metager.de/source/xref/osgearth/tests/splat.earth

Their LOD is very smooth ( some examples look like they don't create big enough skirts, though ). I also really like the layering they do - they are also working on road flattening as we speak...
Jeff has implemented airport flattening already as well.

[vnts]

Is the plan to have metadata stored in raster files as a type of distance fields?

Just a thought (if I've read this thread correctly, and from a conceptual view of what might be of possible assistance):

Found this, when looking at a way to generate distance fields from a black&white street pattern, to better light roads,intersections, and near by city blocks from space .

The concept is inner/outer glow effects create distance fields from any shape segmenting regions (e.g. landclass polygons or street data). AIUI Glow effects use binary morphological operators that should(?) be commonly available image processing effects, even if glow/distance field effects are not. (My only familiarity is with some underlying maths, and what might be conceptually possible)

As far as I see, distance field data might better enable: transition influence (e.g. strips of land type 1 surrounded by type 2 with strong influence from 2), different boundary material (banks&beaches&surf&rejecting large objects crossing boundaries being cut randomly tiled textures based on mask ID& grass growth due to moisture&strips terminating crop fields), ambient night lighting contributions from adjoining urban land types & road lights, lighting on road/runway & adjoining grass by lights with known spacing (at close range eye catches on this), guess at floor+volumetric scattering in shallow waters close to shore.
The extra texture lookup may not be worth it(?), but direct & ambient contributions from runway/apron/road lights on close procedural OSM-objects & trees may be possible (except OSM roads?). OSM-object lights would not contribute to surrounding terrain & trees (except maybe if OSM generation modified or supplied additional channels with object ID/proximity channels). May also need 2d vector (2x 4bits?) to specify direction to an OSM object with lights so trees or terrain can be lit -1 close source, or direction to shore for waves (calculating distance field gradient may also work).

Screenshots indicate some transition mechanism, but not sure if it's a separate transition land type, field with distance to nearest boundary point, or a more weighted distance field.

Kind regards,
vnts

[psadro_gm]

Yes, the raster image would contain only meta data. It looks like the technique is similar, but the blurring would be performed by a shader, not preprocessed.

[Timi]

There is this tool for X-Plane called Ortho4XP which builds the 3D mesh, flattens airports, places orthophotos on top of the mesh and makes the shorelines smooth by using alpha blending. It's implemented using Python. I wonder if it could be somehow adapted to FlightGear? Here's a link to the tool:
https://www.dropbox.com/sh/cjjwu92mauso ... x3cPa?dl=0

The tool looks like this:
https://youtu.be/SWOQ1PiiTNw

The scenery it produces looks like this:
https://youtu.be/D5seXtmdeKo

[Thorsten]

We don't want to create photo-scenery, we want to encode landclass information as a raster image - so the pixel color of the terrain texture is just a code for what properties the terrain underneath the pixel has, you never see the raster image color in-sim.

[pommesschranke]

We don't want to create photo-scenery

I'd like to have the choice to use photo-scenery.
That's why I'm very sad about the fact that the osgEarth patch is not included in mainstream FlightGear.

https://get.google.com/albumarchive/109 ... cIVLG6scOH

http://wiki.flightgear.org/Building_Fli ... ntegration

[Thorsten]

I'd like to have the choice to use photo-scenery.
That's why I'm very sad about the fact that the osgEarth patch is not included in mainstream FlightGear.

So do several others, but unfortunately it seems the people who are doing most coding work for FG are not interested in photoscenery and the people who are interested in photoscenery do no coding work relevant for the issue.

The patch is not included not because the developers would object in principle, but because the comments that came up during review have never been addressed. And, well - patches aren't 'just' merged in for a reason and technical objections can't just be discarded.

For nextgen scenery, I don't think there's any plans to include photo-scenery - certainly not from my side.

[Lydiot]

Thorsten,

Is any of the process of creating scenery heavy on computation and therefore is a bottleneck? I'm just asking because I might upgrade my computer this year and could possibly lend some cycles to FG if needed.

[Thorsten]

I haven't done it myself, but for all I know it's intensely CPU-intensive - I believe running a world scenery update is a month-long affair on a high-performance computer (cluster?).

[Catalanoic]

before need to know to do it in smaller areas, some users have tried it