C++17 doesn't allow to declare defaulted move ctor with not matching
exception specification to the calculated one:
/Users/eddie/Downloads/BUILD/openmw-master/apps/openmw/mwclass/creature.cpp:63:9: error:
exception specification of explicitly defaulted move constructor does not
match the calculated one
CreatureCustomData(CreatureCustomData&& other) noexcept = default;
^
http://wg21.link/p1286r2 makes this possible in C++20 and newer compilers
already have it working even with -std=c++17 but older onces give an error.
Fixes a regression in which pass lighting was clamped after being passed
to fragment shader. For correct FFP emulation, we need to clamp the result
in vertex shader. When clamping after interpolation, negative lights in
particular have a much more drastic effect.
To avoid triggering NavMesh update when RecastMesh change should not change
NavMesh.
Based on the following assumption:
Given a set of transformations and a bounding shape for all these
tranformations, a new object transformation that does not change this
bounding shape also should not change navmesh if for all of this object
transformations resulting navmesh tiles are equivalent
The idea is to report back to RecastMeshManager all changes of NavMesh if there
are any assiciated with RecastMesh version. So we know the last time when
RecastMesh change resulted into the NavMesh change. When later report shows
that there was no NavMesh change for a new RecastMesh version we can assume
that any object transformation within the same bounding box should not change
NavMesh.
mLastBuildRevision == mRevision with current use cases does not happen. But
even if this will happen when another use case will be added it does not save
much computation. The most expensive operation is not adding objects to the
MeshBuilder but to optimize resulting navmesh that will happen anyway in
MeshBuilder::create call.
nighthawk469
psi29a
AnyOldName3
elsid
jvoisin
glassmancody.info
Simon Meulenbeek
Andrei Kortunov
Hristos N. Triantafillou
AnyOldName3
Lamoot