Implementation is incorrect compared to Cycles/Eevee.
Reported by @DrDubosc in comments of T88922.
Differential Revision: https://developer.blender.org/D12029
Label for snapping current frame to strips was cut off and not very readable.
Reviewed By: HooglyBoogly
Differential Revision: https://developer.blender.org/D11951
Cached OCIO processors were not freed, instead the color spaces were freed twice.
Reviewed By: brecht, sergey
Differential Revision: https://developer.blender.org/D12011
Fix for T85517
Bug: Couldn't type space while holding down the shift key in text spaces (e.g. when saving a file, changing the name of object).
Changes: Removing the key combination of Shift + space in `WM_event_is_ime_switch` method.
Reviewed By: harley, mont29
Maniphest Tasks: T85517
Differential Revision: https://developer.blender.org/D10452
Six years ago, Bug T44961 about unwanted spikes had me not do a loop
slide if the angle was too extreme, to avoid unwanted spikes.
The current bug showed that that angle was much too big, and limited
desired behavior in many cases. Changing the angle from 0.25 radians
to 0.0001 radians (about 0.006 degrees) still fixes the original bug
and seems very unlikely to be limiting desired behavior now.
The old modifier code, now just used for Fast, has code in it to
flip faces of arguments when their tranform's negativity differs
from the main object's transform's negativity.
I had neglected to put that logic in when I made the change that
skipped the round trip through BMesh.
Fixing this means that the results are more what the user expects
when some or all operands have negative scales.
This patch addresses the issue raised in T88340.
When entering a pose sliding operator bones would automatically get hidden.
While technically not a bug it was decided that it is too confusing.
Hiding with 'H' is still possible though, just won't happen automatically
Reviewed by: Sybren A. Stüvel
Differential Revision: https://developer.blender.org/D11883
Ref: D11883
Abbreviations are harder to read and understand thus it is best to be direct.
For example without understanding and context it is hard to know exactly what "Len" means.
This change transitions libmv/osd tests to our
blender_add_test_executable macro that explicitly
takes the include directories as a parameter.
This is in preparation for future clean-up of
global include directories.
Differential Revision: https://developer.blender.org/D12012
Reviewed By: sergey
This improve the cloth modeling workflow by allowing you to weld only the
edges that are used for the sewing forces.
Reviewed By: mano-wii, weasel
Differential Revision: https://developer.blender.org/D10710
**Drawing Changes:**
- F-curve drawing for Stretch, Multiply, Length and Frame Number.
- Value drawing when no keyframes for Stretch, Length and Frame Numbers.
General view of the new drawing for each speed effect mode:
{F9796642, size=full}
Detail of the horizontal zero (blue) line in the new `Multiply` mode:
{F9798520, size=full}
Nice to have (but I don't know how):
- Auto adjusting of endframe when using Multiply or Boost.
Differential Revision: https://developer.blender.org/D6110
Addresses T76003. When using VR with Eevee and viewport denoising,
scene geometry could sometimes be occluded for one eye. Solution is
to use a separate GPUViewport/GPUOffscreen for each VR view instead
of reusing a single one for rendering.
Reviewed By: Julian Eisel, Clément Foucault
Differential Revision: http://developer.blender.org/D11858
The core problem is that the geometry nodes modifier sometimes support
"mapping" (i.e. it remembers which new vertices correspond to edit mode
vertices) and sometimes it does not, depending on what the nodes are doing.
Also see rB07ce9910f7cc.
The solution here is that the fallback case in `BKE_mesh_foreach_mapped_edge`
does not call the callback with "invalid" indices.
Differential Revision: https://developer.blender.org/D12007
This might change the rotation of some instances after a Curve to Points.
Unfortunately, there is not much we can do about that, the math before
was just wrong. The forward and up axis stayed the same though.
Differential Revision: https://developer.blender.org/D12006
The problem was that the modifier was reevaluated all the time, even
between showing the attribute search and clicking on the attribute
name. This freed the data referenced by attribute search. The real bug
here was that the dependency graph was tagged for update even
though nothing changed. This was because the spreadsheet thought
its active context has changed and it wanted to compute the new
value to be shown in the spreadsheet.
The reason for the bug was that I confused how the tree-path of a
node editor works. The second element in the tree path contains
the name of the group node in the root tree that we're in (instead
of the first element).
Differential Revision: https://developer.blender.org/D12009
When the new "need_ids" flag is false and the output type is not
one of the valid BMesh kinds, there is no need to propagate even
a dummy id to all of the faces.
Share functionality for single and multi-threaded edge-split tagging.
Remove logic that ensured vert & loop indices in bm_mesh_edges_sharp_tag
(missing from fd9fc809b7).
Improves control over the XR reference space by using the stage ref
space (user-defined tracking bounds) instead of local ref space
(position at application launch), if available. Also adds an
"absolute tracking" session option to skip applying eye offsets that
are normally added for placing users exactly at landmarks.
By enabling absolute tracking, users can define the tracking origin
in a way that is not linked to the headset position. Instead, the
tracking values given by the XR runtime are left unadjusted and a
user can manually calibrate an "origin" landmark object to adjust to
their real world space.
Can be useful for applications that use external tracking systems
and those that primarily only need to use controllers and not the
headset (e.g. motion capture).
The absolute tracking option requires an update to the VR
Scene Inspection addon to be accessible by regular users.
Reviewed By: Julian Eisel
Differential Revision: http://developer.blender.org/D10946
This was added in 0b7f581397
but seems not to be needed as the assignment was never correct
since only one corner on either side of the smooth edge had the
vertex normal written to it.
Merge the sharp edge tagging into bm_mesh_loops_calc_normals,
this has the advantage that edge tagging can be performed as part of
walking over each vertices edges - instead of tagging in a separate loop.
Even though this will tag edges twice (once for each vertex),
the computation isn't heavy as it's only calculating a dot-product
between the two face users to compare the angle.
This change combined with 4ba06ad0a8
makes BM_loops_calc_normal_vcos around 5.68x faster,
with an overall speedup over 2.6x when transforming a high poly mesh.
(tested on a system with 32 cores).
Reviewed By: mont29
Ref D11970
Supported multi-threading for bm_mesh_loops_calc_normals.
This is done by operating on vertex-loops instead of face-loops.
Single threaded operation still loops over faces since iterating
over vertices adds some overhead in the case of custom-normals
as the order used for accessing loops must be the same as iterating
of a faces loops.
From isolated timing tests of bm_mesh_loops_calc_normals on high
poly models, this gives between 3.5x to 10x speedup,
with larger gains for meshes with custom-normals.
NOTE: this is part one of two patches for multi-threaded auto-smooth,
tagging edges as sharp is still single threaded.
Reviewed By: mont29
Ref D11928
Extract the slider gui implemented for the pose slide tools.
Generalise it so it can be used by other tools as well.
Reviewed by: Sybren A. Stüvel
Differential Revision: https://developer.blender.org/D9314
Ref: D9314
With this commit, node warnings added to nodes during evaluation
(not "Info" warnings) will also draw in the modifier. In the future
there could be a "search for this node" button as well.
Differential Revision: https://developer.blender.org/D11983
Because these handles are calculated lazily, we need to make sure they
are calculated before switching to a manually positioned mode.
I doubt it would ever be necessary, but theoretically this could happen
on a per-point level, to avoid calculating handles not in the selection.
