Previously on my system, generating vegetation for a given tile
took 0.15-0.2s (for ~ 56k positions), of ~0.4s. While this is done in a
separate loading thread, the sheer number of tiles being loaded
caused noticeable delays and popping of higher LoD tiles.
As a tile at the highest LoD is typically 6x6km, and vegetation
is generated on a scanline of individual triangles, there is a _lot_
of temporal locality on the landclass of a series of points.
By caching the material information required from the landclass lookup
we can avoid a whole much of material lookups for each successive
vegetation point.
On my system this reduced the time to generate vegetation down to
0.02s per tile, and total tile generation time down to ~0.2s.
Added support for seeking (forwards only) - in ZlibAbstractIStreambuf, added
seekoff().
Also disabled assert that checked that we reach EOF compressed data at same
time as EOF uncompressed data; was breaking things when using embedded
compressed streams within fgtape recording.
Added ZLibCompressionFormat::ZLIB_RAW, uses windowBits=-15, for zlib compressed
streams without header or trailer.
Fixed clang build error with std::min().
- Add an Effect to stars and planets so they don't disappear when not using the fixed-pipeline.
- Allow usage of the shadow mapping related uniforms in 'quad' passes as well.
- Add extra buffer formats (some of them only work under the core profile).
- Better handling of mipmapping in the Compositor.
Attempt to narrow down the source of some fatal exceptions we see
on Senty, which occur during init/startup. All these blocks re-throw
so user behaviour is unchanged, but we’ll log the name of the subsytem.
Previously, by observation comparing actual vegetation density
on Medium, WS30 had many more trees than WS20.
This adjusts the base vegetation density down to match WS20.
Note that at High and Very High densities, there is still a disparity
that needs to be addressed.
Previously, reading LINE_FEATURE_LIST/AREA_FEATURE_LIST/COASTLINE_LIST
files were not read with the .stg file, but deferred into the
DelayLoadReadFileCallback. When the the Callback was executed, the
files were read and appropriate terrain tiles dirtied for regeneration.
However, re-generating dirtied tiles caused significant frame pauses
and was disabled in commit
deb802f74a
This meant that the Line/Area/Coastline features would only be rendered
when the next LoD tile was generated. Which created a race condition
on startup for the tile the user starts on, between the
DelayLoadReadFileCallback and the tile itself.
This commit reads these files at the same time as the initial terrain
so that the VPB has all the data required when the tile is initially
rendered. The downside is that line data is read for every tile,
even if it is far away. As the line data is stored as a series of
lat/lon floats, this is assumed to be OK.
An alternative would be to re-instate the Visitor, and instead
of dirtying existing terrain, generate the roads, and flag them to
the UpdateVisitor to add to the terrain node.
