WS3.0 Subprojects
| World Scenery 3.0 |
|---|
| General |
This page is intended to collect various WS3.0 sub-projects: Smaller self-contained projects that can be worked on independently to improve WS3.0
The aim is to encourage more people to contribute to the WS3.0 effort.
They are split by knowledge required.
C++
Smoother Line Features
Line features (roads, railways, rivers) are generated from OSM data at runtime, with different widths of roads generated for different LOD levels.
Currently the algorithm that generates the roads creates places a quad for each segment such that the width of the road is horizontal, a metre or so higher than the terrain.
There are a couple of improvements that could be made:
- Sharp corners look a bit rubbish because the end of a segment is always a normal to the segment length. This means that on sharp bends the road narrows and looks a bit rubbish. An improvement would be to calculate the width and angle based on both the last segment and the next one.
- At present no bridges are handled. using osm2city code bridges should be implemented.
- The roads currently following the elevation meshes exactly. Real roads have embankments and cuttings to smooth out elevation changes. Cuttings are probably too difficult because they would require modifying the elevation mesh, but embankments would be possible.
- We currently remove some points at the end of the tile where the intersection algorithm can produce many points close together. This currently creates some odd roads at the edges of tiles which could be improved.
Water Bodies
We currently have a good solution for coastlines to remove the blockiness of the raster coastlines by using OSM line data and a separate high resolution raster.
We have a script to collect similar data for water bodies (lakes etc.), A scanline algorithm could be used with this data to fill a polygon in the same raster, creating more detailed water bodies.
Groundcache Lookup
In WS2.0 it is possible to get material information for a point in the scenery. This needs implementing for WS3.0, which will require a lookup into the landclass texture. Ideally this information would also be exposed in fgelev (or as a proxy as for WS20 whether it is a solid material or water).
Update 11/11/2023: This is now implemented and available in next.
Neighbouring Pixel
The higher level fragment shaders can blend the edges of textures. Currently this is done on the shader side. This could instead be done at scenery loading when the texture is generated in VPBTechnique.cxx by using some of the unused channels in the texture. There will be significant performance gains to be had by doing so.
Update 21/03/2023: Stuart prototyped this on his system and found no performance benefit at all.
Terrasync for WS3.0
Currently we do not have the ability to distribute WS3.0 with Terrasync. We need both a distribution mechanism and probably some minor changes to Terrasync/FG to support this.
The base unit for distrbution will be a 1x1 degree tile, tarballed and compressed - e.g. .tgz. This is already used for other data.
Speak to Nia about this, as she has offered to assist with hosting.
Update 11/11/2023: Testing with Nia and some small changes to defaults.xml proved that this Just Works. However the data size remains an issue.
GIS
More Accurate Coastlines
We currently have a good solution for coastlines to remove the blockiness of the raster coastlines by using OSM line data and a separate high resolution raster.
However if the main landclass raster isn't well aligned with this data it can cause graphics artifacts.
I (Stuart) solve this for the Martinique scenery on the final raster by:
- Deleting all the water so that it was NODATA
- Filling the NODATA with surround values
- Using the OSM coastline as a mask on the raster to delete the data that should be water
- filling the NODATA with water.
This works OK, but getting the OSM data as a multipolygon was a manual process. Having a script to do this would be good. Being able to do this all in vector data ahead of rasterization would be even better
Update 11/11/2023: This is now implemented as part of the fgmeta/ws30/genVPB.py script, which accepts a coastline polygon.
Scripted Toolchain
Developing standard scripted toolchain to convert from NLCD and/or CORINE to high quality 10m or 5m raster with the correct landclasses.
Update 11/11/2023: This is now implemented as fgmeta/ws30/genVPB.py but requires a raster file
Python
fgmeta/ws30 contains a number of python scripts for generating scenery that could be improved
Script Efficiency - line features
At present the script to generate line features (genroads.py) simply dumps all the OSM data directly to text file and we generate line features using every point. This has a theoretical resolution of 1cm, which is probably higher than we need.
We could save storage and processing by :
- Rounding the lat/lon pairs to ~10cm resolution. This would save about ~10% disk space for the roads uncompressed.
- Skipping nodes in segments that are too close together.
Textures
WS3.0 Materials
Currently WS3.0 uses the WS2.0 textures. Many of these have line features like roads baked into them. As WS3.0 include OSM roads down to ~ 2m width, the roads on the textures are now redundant. A new set of textures without roads would look a lot better (that is for textures in urban areas and certain agriculture textures).
This should be done at the point that we decide to move to WS3.0, or when we decide the osm2city roads are the WS2.0 solution for small roads.
GUI
Quality Settings
Currently WS3.0 has a lot of configuration properties. These should be consolidated into a dialog that's easier to use. Stuart agreed that the Canvas UI could be a good option to use for this new UI dialog. [1] We also have people volunteering to help with a Canvas based UI dialog. [2]
This new UI dialog could probably be based on the new Canvas tab widget to neatly organize related settings into pages.
We could even use the CompositeViewer support and Compositor integration to provide actual previews for different settings in-sim, as suggested and discussed previously on the devel-list.
There already is an experimental canvas element that uses a compositor instance to render a view to a Canvas, work that Jules and Fernando came up with originally. Fernando in particular mentioned that these Compositor instances could use their own effects/shaders, which would make them ideally-suited for previewing different sorts of rendering settings in-sim.
| References |