This wasn't an issue in the real buildbot environment since the
precompiled libraries are compiled with same ABI as the compiler
used for Blender build. But it was causing issues when building
Blender using buildbot scripts (for troubleshooting purposes)
on a machine with different default compiler ABI.
Usually ABI detection is happening in platform_unix.cmake when
detecting whether there are any precompiled libraries folder
available. This detection is not happening when library folder
is provided explicitly, expecting ABI to be setup explicitly
as well.
In 2011 special handling was introduced, apparently for no other
reason than to address a complaint in T25707 that World and Local
space are equivalent for objects without parent. This causes issues
and confusion, as mentioned in rB599c8a2c8e4.
This special meaning of Local Space is not documented in the manual,
and is not known to experienced riggers, so removing it should not
be a problem.
Differential Revision: https://developer.blender.org/D6095
This commit implements the change in behaviour described in T71246.
In short:
For export, per mesh:
- Custom loop normals are defined → loop normals are exported.
- One or more polys are marked flat → loop normals are exported.
- Otherwise, no normals are exported.
For import, when the Alembic mesh contains:
- loop normals (kFacevaryingScope) → use as custom loop normals, and
enble Auto Smooth to have Blender actually use them.
- vertex normals (kVertexScope or kVaryingScope) → convert to loop
normals, and handle as above.
- no normals → mark mesh as smooth.
- unsupported normal types (kConstantScope, kUniformScope,
kUnknownScope) → handle as 'no normals'.
This also fixes T71130: Alembic split normal export issue
Previously the mesh flag `ME_AUTOSMOOTH` was used in conjunction with
the poly flag `ME_SMOOTH` to determine whether loop normals or vertex
normals were exported. This behaviour was hard to predict for artists,
and hard to describe in the manual. Instead, Blender now only exports
loop normals, computing them if necessary. This way, the mesh in Alembic
should always have the same loop normals as in Blender.
Maniphest Tasks: T71130
Differential Revision: https://developer.blender.org/D6197
This computation is complex and useful enough to expose the existing
C math utility used by BVH nearest to Python. Otherwise this requires
the use of intersect_point_tri and multiple intersect_point_line calls
with some added vector math.
Differential Revision: https://developer.blender.org/D6200
Check was losing precision -- adjust by translating points
before calculating circumcircle.
Also, needed to check for flippability of edges before flipping.
Check was losing precision -- adjust by translating points
before calculating circumcircle.
Also, needed to check for flippability of edges before flipping.
When importing subdivision surfaces a 'Topology Changed' error was shown
even though the topology didn't change at all. The code was comparing to
`totpoly` where `totloop` should have been used.
The multi device code did not correctly handle cases where some GPUs store a
resource in device memory and others store it in host mapped memory.
Differential Revision: https://developer.blender.org/D6126
Data was not quantified properly. It also lets the library choose the suitable
encoding method rather than forcing it to use the edgebreaker method.
Differential Revision: https://developer.blender.org/D6183
Was happening when object transform is animated.
Caused by overly aggressive dependency construction introduced a
while back in 9d4129eee6: we shouldn't add dependencies unless
we really need them.
This change removes unneeded transform dependency for cap objects
(since only their geometry is used), and also removes own transform
dependency if there is no offset object (which is the only case when
own transform is needed).
Differential Revision: https://developer.blender.org/D6184
'rna_CollisionSettings_update' has a history of tagging ob for update:
rB79312c1912b4 ID_RECALC_TRANSFORM |ID_RECALC_GEOMETRY |
ID_RECALC_ANIMATION
rBf90a2123eedc OB_RECALC_OB | OB_RECALC_DATA | OB_RECALC_TIME
rBfaf1c9a4bb27 OB_RECALC_ALL
rB7df35db1b136 OB_RECALC
Since the meaning of OB_RECALC_TIME/ID_RECALC_ANIMATION changed a bit
historically (from "please update my animation if the animation
datablock is tagged for update" to "update animation of this datablock")
this was now always overwriting user edit with animated values, making
it impossible to change those values once animated.
Thx @sergey for guidance!
Maniphest Tasks: T68396
Differential Revision: https://developer.blender.org/D6113
When continuous grab, cursor motion was mapped to the min/max.
This caused problems when int/float max values were used.
Now the range is clamped by a value derived from the click-step
so dragging numbers never increases it to an impractically large value.
To recreate the main issue:
* Set render and file browser to show in full-screen in the preferences
* Default scene, press F12 in 3D View
* Press Alt+S to save the image
* Escape the file browser
* Escape the image editor
The former 3D View would now show the image editor. This is a common
use-case that should work.
Full-screen code is a hassle to get to work as expected. There are
reports from 2.5, I did lots of work years ago to get these kind of
use-cases to work fine. But apparently I broke this one with a fix for
another common use-case in March (0a28bb1422).
This now stores hints in the space, rather than the area, which should
make things much more controlable and hopefully help us fix issues like
this.
Here are a few references describing further common issues (all should
work fine now): 0a28bb1422, e61588c5a5, T19296
Checked over this with Bastien, we agreed that at some point we should
do a big rewrite of all of this, for now this is acceptable.
Cycles did not update the "is_enabled" flag on lights when they were synchronized again, which caused all lights disabled by "LightManager::disable_ineffective_light" to be disabled indefinitely. As a result the OptiX kernels were not reloaded with correct features when a change to a light was made. This fixes that by updating the "is_enabled" flag during synchronization.
Differential Revision: https://developer.blender.org/D6141
The cryptomatte sockets were incorrectly numbered using a step size of two. While the increment by two is necessary to get the correct number of render passes, they should be numbered consecutively matching the socket names of the cryptomatte node.
Reviewed By: lukasstockner97
Differential Revision: https://developer.blender.org/D6185
This change replaces old behavior when spline was toggled as cyclic
on double-click.
Doing so was tricky on a tablet and is rather non-intuitive in general.
Differential Revision: https://developer.blender.org/D6162
