The random lights placement algorithm was using the incorrect channel
from the object mask image, (red instead of blue as mentioned in
Docs/README.materials). This commit rectifies the mismatch.
Random objects like lights and trees are not placed on airport terrain
anymore. This commit also refactors some of the existing code for clarity.
Discussion can be found here [1] and detailed history here [2].
[1] https://sourceforge.net/p/flightgear/simgear/merge-requests/102/
[2] https://sourceforge.net/u/fahimdalvi/simgear/ci/bugfix/ws30_random_objects_avoid_airports/~/tree/
Squashed commit of the following:
commit 643198f8d52da8d65a674b052c508f03d7f83ac0
Author: Fahim Imaduddin Dalvi <dalvifahim@gmail.com>
Date: Tue Jan 4 09:57:34 2022 +0300
Implemented corrected airport intersection logic
We now convert the point into the correct coordinate system before
checking for intersections with the airport geometry.
commit 7e0819e4f88992658301a2c15d890fc489cfe3b6
Author: Fahim Imaduddin Dalvi <dalvifahim@gmail.com>
Date: Wed Nov 10 19:59:04 2021 +0300
Added airport terrain check code for random objects
This commit does not work as expected. The light-coverage check is disabled
to amplify the bug.
commit eb21e8fd256dcf124857ac51afc0d7c3c90ae1c6
Author: Fahim Imaduddin Dalvi <dalvifahim@gmail.com>
Date: Wed Nov 10 19:53:44 2021 +0300
Refactored elevation constraint checking code
This commit provides a separate elevation constraint function that does not
displace the given point. The current function has been renamed to indicate
the displacement side effect.
The Random objects check now happens in the scanline read in VPBTechnique,
rather in the VBPMaterialHandler objects. These checks are not specific
to any handler, and are thus better suited to be outside of specific
material handling logic.
The texture cache interacts badly with the code creating the WS30
texture atlas, resulting in a bad atlas. This change adds a new
SGReaderWriterOptions::LoadOriginHint::ORIGIN_MATERIAL_ATLAS
which causes the material cache not to cache the texture.
Add defaultValue arg to get*Value() methods that previously took no args. We
do this for getBoolValue(), getIntValue(), getLongValue(), getFloatValue() and
getDoubleValue(). The default value is returned if the node's string is not
convertible to the requested type.
This can enable some calling code to be optimised where it previously checked
for getStringValue() (which is slow now that it returns a std::string)
returning an empty string, before calling getDoubleValue().
This is by Lars Toenning <dev@ltoenning.de>, Roman Ludwicki <romek21@op.pl> and
SDeAstis <salvatore.deastis@gmail.com>, in 2021 Hackathon.
SGPropertyNode::getStringValue() now returns std::string by value instead of
const char* pointer into SGPropertyNode's internal data.
Patched up various call sites to use new API.
Remove SGPropertyNode::getName() and use SGPropertyNode::getNameString()
everywhere.
Uses ffmpeg libraries to provide video encoding of an osg::GraphicsContext
(which could be for Flightgear's main window) to file.
The video codec is specified as a string at runtime. Success depends on what is
supported by the system's ffmpeg installation.
Handling of resize doesn't always work. We finish current stream and create a
new encoder and continue. Works ok with mpeg2, but with more modern codecs vlc
usually fails to handle the change.
We call the encoder on a separate thread to avoid latency.
If SG_FFMPEG is not defined, we don't make calls to ffmpeg libraries and
VideoEncoder class's constructor always throws an exception.
- Prefix all WS30 Uniforms with "fg_"
- fix modelOffset (needs to be passed in as a float)
- Create a true atlas with indexes for relevant material textures
MCST E2K (Elbrus 2000) - this is VLIW/EPIC architecture, like Intel Itanium (IA-64) architecture.
e2k architecture has half native / half software support of most Intel/AMD SIMD
e.g. MMX/SSE/SSE2/SSE3/SSSE3/SSE4.1/SSE4.2/AES/AVX/AVX2 & 3DNow!/SSE4a/XOP/FMA4
Ref: https://en.wikipedia.org/wiki/Elbrus_2000
To simplify various rounding / truncation operations, especially when
dealing with frequency values, give floor() the same precision control
already present in math.round(), and add math.trunc() which always
truncates towards zero.
Earlier calculations assumed degrees instead of radians for the
granularity of random lights, resulting to the wrong density. This
is now fixed. The scanline for random lights is also more efficient
now, taking the lower limit of light-coverage into account.
Previously we were taking the nearest pixel from the nearest
mipmap. Which was braindead. Now just use the OSG defaults,
which are NEAREST_MIPMAP_LINEAR for MIN and LINEAR for MAX.
Thanks to Julian and Henning for helping diagnose this on
the weekly hangout.
