During revision of {D8952} one of the comments was to make a function that converts the render percentage to a factor. This to avoid code duplication. However the duplicated code was already all over the compositor code. So in order to avoid this code duplication for {D8952} I propose to first cleanup the duplicated code and build patch {D8952} based on this clean up.
The method that converts the render percentage to a factor is put in the CompositorContext. Why? The CompositorContext keeps DNA information like the renderdata. DNA, and thus the CompositorContext, keeps the size of the render resolution in percentage (user oriented). The compositor needs the size of the render resolution as a factor. So the CompositorContext seems like the obvious place to have this conversion method.
Why not in de NodeBase? The method could've been added to the nodebase, but I wanted to keep the nodebase as clean as possible and not put simple "conversion" methods into this base class. Also I didn't really like the call flow: you'd always have to get the renderdata size from the context and then convert.
Putting it in the CompositorContext avoids this extra invoke of a call.
Why not in the Converter? See nodebase. And the Converter seems more like a class for "structural" and complex node tree conversions. Not the simple conversions.
Reviewed By: Sergey Sharybin
Differential Revision: https://developer.blender.org/D9566
This commit replaces while loops and for loops with the equivalent
macro. This results in much more readable code in some places,
and it's now more apparent when the situation is more complicated
than just iterating through a linked list.
As proposed in T74432 and already implemented in several commits,
"region" is the preferred name for `ARegion` variables, rather than
any variant of "ar". This commit changes a few "ar" variables that have
popped up over time and also adjusted names of variants like "arnew".
By checking if a cell has already been processed in the finding patch
component code, an enormous speedup happens. This only will be
noticeable if there are lots of patches, and some cells with a
large number of patches.
In case where there are coplanar instersections where
each part has a lot of triangles, the finding-cells algorithm was
very inefficient. This uses a Set instead of a Vector to keep track
of a cell's patches, avoids going through all patch x patch combinations,
avoids going through all patches to renumber after a merge, and
merges smaller patch-sixe cells into larger ones.
All this reduces the time to find cells in the cited case by a factor of 10.
Ensure consistent order of pose bones. Now it should always match the
one from bones in armature obdata (as exposed by e.g. RNA, i.e.
children-first).
Previously when some pose bones would need to be added or removed from a
pose due to changes in the bone armature, or if bones in armature were
re-ordered, the bones order in pose would not match anymore the one from
armature, and could even become different between e.g. a proxy and its
linked source.
This was not really nice, but not a big issue before either. But with
diffing process of override, consistent order of items between reference
linked collection and local override one is crucial.
Reviewed By: #animation_rigging, sybren
Maniphest Tasks: T82758
Differential Revision: https://developer.blender.org/D9646
The change was intentional so that the orientation matrices match
(`rv3d->viewinv` becomes equal to the orientation matrix).
But, although in a projection matrix the Z axis is negative, this
should not be so from the user's point of view.
So the solution here is to negate the Z axis when the View orientation
is chosen.
This affects all modes, but is only evident for rotation.
---
Another change here is to use the final rotation value (`values_final`)
for the gizmo drawing since this value can be changed by the mode.
Avoid the evaluation of constraints when computing the parent-inverse
matrix.
Constraints are meant to be evaluated last; object transforms are
computed this order:
1. `parent->obmat` (the parent object's world matrix)
2. `ob->parentinv` (the object's parent-inverse matrix)
3. Object's loc/rot/scale
4. Object's constraint evaluation
When the constraints are used to compute the parent-inverse matrix,
their effect is moved from step 4 to step 2 in this list, potentially
rotating or scaling the object's local transform. This causes unwanted
movement as reported in T82156.
Reviewed By: looch
Differential Revision: https://developer.blender.org/D9413
Move the logic for determining if the item at a given x position is an
icon into the function. This is used for determining selection over an
icon, and will be used in a later commit for checking for hover over an
icon. No functional changes.
This adds support for incremental updates in the sculpt transform
code. Now tools can define if they need the displacement applied
for the original coordinates or incrementally.
This is needed for features like elastic transform or cloth deformation
target in the transform tool.
No functional changes.
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D9547
This was reported in the form of the eyedropper of the 'Parent' property
creating a custom property 'parent' if self was picked.
Problem arises when certain checks for setting rna pointer properties
failed (for example: the PROP_ID_SELF_CHECK check) and then a different
code path was entered (which was only meant for IDProperties).
Problem was introduced in rBa7b3047cefcb.
To solve, now first enter the branch for rna-based pointer properties,
then perform the sanity-checks (and if these fail: dont enter the other
unrelated codepath but instead do nothing)
Maniphest Tasks: T83055
Differential Revision: https://developer.blender.org/D9652
dynamic paint modifiers
Looks like prior to the introduction of mantaflow, the former
SmokeModifierData always had a domain initialized (even if its type was
set to None). Since mataflow, the FluidModifierData type needs to be set
to MOD_FLUID_TYPE_DOMAIN (otherwise domain is invalid)
Maniphest Tasks: T82729
Differential Revision: https://developer.blender.org/D9644
Code was actually not applying any override operation over linked data.
Reasonn behind that was that if library file is saved with latest
override applied then this is not needed, since data saved for the
override in the lib file is already up to date.
But this is actually fully breaking in case someone update the lib file
of the lib file, without re-saving the libfile itself.
So now we alwaya apply overrides also on linked data.
Note that this will not fix the case where a resync is needed.
The panel title text intersected any buttons in the header because
the label offset retrieved from the layout code was not scaled by
the block's zoom level. Error in rB0d93bd8d63980.
The transform modifiers are confirmed by releasing any button.
Thus, the operation can be falsely confirmed if the button that launched
the operation is released after the modifier has been activated.
Previously the events that confirmed the modifiers were hardcoded.
An option to fix this would be to add custom confirmation keyitens for
specific modifiers. But this can be a bit confusing and would make the
modal keymap even bigger.
So the solution here is to skip the button that launched the operation
when confirming the modifier.
Orthogonalize the constraint target's matrix before decomposing it into
Euler angles. This removes sheer, and is actually a requirement for
correct decomposition.
It's conceivable that someone has used the incorrect behaviour in a rig.
As the shear caused unpredictable flipping of the constrained object,
this is unlikely.
Reviewed By: angavrilov, sybren
Differential Revision: https://developer.blender.org/D8915
Previously, the alternate row color in the Video Sequence Editor was
just a shaded version of the editor's background color. This makes it
theme-able just like in the file browser and outliner, although the
default color is very slightly different.
Differential Revision: https://developer.blender.org/D9634
If the cursor is not over the mesh, the operator was still using the
last Face Set ID updated by the drawing cursor code when the cursor was
over the mesh.
This now cancels the operator instead of modifying a Face Set that will
look random to the user.
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D9545
The original name was chosen because symmetry was a property of
the Paint struct. Now symmetry is a property of meshes, which
also makes the name of the property easier to understand.
Reviewed By: sergey, dbystedt
Differential Revision: https://developer.blender.org/D9618
Since D6133 fluid particle code uses thread local storage to collect
springs created during a time step before adding them to the actual
spring array.
Prior to the switch to TBB there was a single finalize callback which
was called on the main thread, so it could use psys_sph_flush_springs
and insert the new entries into the final buffer. However in D7394 it
was replaced with a reduce callback, which is supposed to be thread
safe and have no side effects. This means that the only thing it can
safely do is copy entries to the other temporary buffer.
In addition, careful checking reveals that the 'classical' solver
doesn't actually add springs, so reduce isn't needed there.
Differential Revision: https://developer.blender.org/D9632
The roll value may not be as expected when a matrix is not orthogonal
or has a negative determinant.
This can lead to confusion as seen in T82930.
Therefore, make it clear that this is a limitation and that a value for
the roll is somewhat indeterminable in these cases.
This fixes T82930
In `calc_curve_deform` a factor is calculated without checking if
the divisior is zero or close to zero. This patch adds the missing
checks and sets the factor to zero if the division shouldn't be
computed.
Reviewed By: mont29
Differential Revision: https://developer.blender.org/D9645
