The previous computation was dependent on the vertex order in two ways:
- If the first vertex was on the AABB boundary, the AABB would be
increased by the epsilon due to size clamping
- Every time the AABB would get expanded, we would recompute end from
size and reconstruct size again, which resulted in slow floating point
drift.
In isolation this may not seem like it matters, but it means that the
same mesh with a different vertex order may result in a slightly different
AABB. This can be a significant issue due to shadow meshes and their use in
depth prepass: shadow meshes reorder vertex data as part of the
deduplication process, as they append one unique position at a time and
as such remove the duplicate positions; this can result in a different
AABB which would result in a different reconstructed vertex position
during a depth pre-pass, causing mesh self-occlusion.
Modify BlendKey's sort to use AlphaCompare in order to create a deterministic sort
Co-authored-by: A Thousand Ships <96648715+AThousandShips@users.noreply.github.com>
Normal raycaster makes LOD generation process >2x slower and often
generates normals that look significantly worse compared to what the
simplifier comes up with by default. This was likely different before
last meshoptimizer upgrade, as the attribute metric was not functioning
properly, but now it looks like it's doing more harm than good.
This change makes it disabled by default but keeps an easy option to
re-enable it per mesh using LOD parameters for now until we get more
confidence and can remove the code outright.
Because the long term plan would be to disable this feature entirely,
the scripting API isn't changed, and it's just off-by-default there with
no way to re-enable.
This behaviour was introduced in #90365. This also fixes some inconsistencies in the docs and adds clarification of how the _export_file function works.
As discussed with upstream, the C/C++ standard library is always fully
included when building with MAIN_MODULE=1, so using EMCC_FORCE_STDLIBS
is not necessary in our case.
GPUParticles' Inherit Velocity property used to act strangely
if the physics tick rate was lower than the rendered FPS, as velocity
was tracked in the process and not in the physics process. This
means that on certain rendered frames, the velocity was effectively
0 since there was no movement since the last rendered frame.
Fix Info about Global library on add_animation_library method in doc/classes/AnimationMixer.xml
Fix Info about Global library on add_animation_library method
Co-authored-by: Silc Lizard (Tokage) Renew <tokage.it.lab@gmail.com>
