Fix for a regression from software skinning support:
instance_attach_skeleton wasn't called in set_mesh before, and it's
causing issues when the mesh instance is loaded from a thread.
1. Call from a thread queues instance_attach_skeleton with RID() in the
visual server.
2. Call from the main thread when entering tree calls
instance_attach_skeleton immediately with a valid skeleton
3. Queued instance_attach_skeleton resets the attached skeleton
This change prevents that to happen by making sure
instance_attach_skeleton is not called on set_mesh as it was doing
before, but there might be a more general problem to solve in how
visual server commands are executed when resources are loaded from
a different thread.
(cherry picked from commit feee9f9695)
All my earlier test cases for software skinning had the polys parent transform to be identity. This works fine until you had cases where the user had moved the transform of the parent nodes of skinned polys.
This PR fixes this situation by taking into account the final (concatenated) transform of the polys RELATIVE to the skeleton base transform. It does this by applying the inverse skeleton base transform to the poly final transform.
(cherry picked from commit f33e22001f)
It seems 30.0.1 had issues with compatibility with JDK 8 and 11,
which appear to be solved in 30.0.3 as per godotengine/godot-docs#4796.
(cherry picked from commit d88e1f04df)
We still use Emscripten 1.39.9 for official Mono builds so ideally we want to test
against an old Emscripten version to ensure we don't break compatibility.
But then google-closure-compiler-linux broke compatibility for us and is not properly
pinned, so we need to use a more recent version for now to fix CI.
Cf. https://github.com/emscripten-core/emsdk/issues/802
(cherry picked from commit 9571ae3a33)
After further testing it seems to work fine now when building binaries with GCC 5
on Ubuntu 16.04 (previously we were using GCC 9 on Ubuntu 14.04).
Follow-up to #45629.
(cherry picked from commit aa15ad72ee)
The translation to larger vertex formats was assuming that batches were rects, and not accounting that the num_commands had a different meaning for lines and polys, so the calculation for number of vertices to translate was incorrect in these cases.
Also prevents infinite loop if a single polygon has too many vertices to fit in the batch buffer.
(cherry picked from commit d08cf5f434)
The final_modulate was incorrectly being set in the uniform on light passes in GLES3 in situations where color was baked in the vertices. This was already correct in GLES2. This PR makes prevents setting final_modulate in this situation.
(cherry picked from commit 35c5ccce9e)
- Modified classes: RigidBody, PhysicalBone, VehicleBody, RigidBody2D, KinematicBody2D
- The input argument is untrusted even in release mode
(cherry picked from commit e075b6b411)
`tech_debt++`, that's what we get for not taking the time to cleanup all this
and do it right...
Follow-up to #48073 and #48102.
(cherry picked from commit a14b51df92)
We need to propagate the hacky checks from the raycast config to the
lightmapper config, as the failure of a `can_build()` check is not notified to
other modules (which might even be checked further depending on the processing
order in SConstruct).
A more thorough fix would be to change SConstruct to do two loops on modules:
one to check `can_build()` and disable modules which can't build, then another
one to rechecked `can_build()` with the new lineup and do further config.
But there would be more risk for regressions than with this ad hoc hack.
Similar story for the `platform/x11/detect.py` change... oh my eyes :(
(cherry picked from commit a2c68d9da7)
* Better handling of the scene's environment energy in the lightmapper
bakes.
* Fixed a bug where ProceduralSky::get_panorama() returned a reference
instead of a copy.
* Removed includes to Embree's internal header files.
(cherry picked from commit 2db2d1153d)