| Age | Commit message (Collapse) | Author |
|---|
|
Adjust the threshold for switching from the base case to trace > 0,
based on very similar example code from www.euclideanspace.com to
avoid float precision issues when trace is close to -1.
Also, remove conversions to and from double, because using double
here doesn't really have benefit, especially with the new threshold.
Finally, add quaternion-matrix-quaternion round trip tests with
full coverage for all 4 branches.
Differential Revision: https://developer.blender.org/D9675
|
|
|
|
axis-constraining on release
Release confirm did not consider modal keymap events.
|
|
Properly use given reference pointer in
`lib_override_library_create_post_process` when it is a Collection one
too.
|
|
That function was adding given new collection to all ancestors of the
reference one, instead of only to its immediate parents.
|
|
Extract initialisation code of box selection into separate functions.
No functional changes.
Reviewed By: zeddb, sybren
Differential Revision: https://developer.blender.org/D9196
|
|
Fix various problems in the Action Group rearranging code. All fixes are
necessary to resolve the bug.
- Before groups are rearranged, the channels are moved into their
respective groups (so no longer referenced by `action->channels`). A
temporary group is made for ungrouped channels. The code made
assumptions about the channels being in the same order as the groups;
that assumption has been removed.
- Looping over channels in an Action Group should stop when reaching the
last channel, and not until `NULL`.
- After all the reshuffling is done, the `action->channels` linked list
wasn't terminated properly. Now `first.prev` and `last.next` are set
to `NULL` to avoid infinite loops.
|
|
Some minor cleanups to make an upcoming bugfix easier.
No functional changes.
|
|
Previously image accessor was sharing array pointer for tracks access.
Now it is possible to pass a temporary array valid only during the
initialization process.
Should be no functional changes.
|
|
This is something not-so-trivial to see from just reading code, which
shown an important of proper comments and clear naming.
Main source of confusion was that it is not immediately clear that
AutoTrack context is to see all tracks, but tracking to only operate on
selected ones.
|
|
This operators reset the vertex color information of the strokes.
If nothing is selected, all strokes are reset. If any is selected, only selected strokes are reset.
Also added a new menu Paint in Vertex Color mode.
Differential Revision: https://developer.blender.org/D9647
|
|
|
|
Was re-introduced after previous round of cleanups when was merging
refactor and master branches.
|
|
No functional changes, just allows to potentially extend the options
in the future, and also makes code more explicit.
|
|
Wrong comment was used for enumerator.
Also made it a real typed enumerator to ease use in the implementation
code.
Should be no functional changes.
|
|
This was a leftover from the 2.91 GPU module refactor.
This is an exception that should be removed when we remove BGL.
|
|
Some fields are still not really documented, but they are subject of
refactor/fix which will happen shortly.
|
|
Makes it more clear from intent and usage point of view.
The user was not used for anything else than frame number.
|
|
A no-functional-followup of the previous commit.
|
|
Tracking track which is used for plane track and movie clip having
a scene frame offset would have trigger re-calculation from a wrong
frame.
|
|
Should be no functional changes.
|
|
Was only assigned to truth, always. Never read back.
|
|
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.
|
|
The value of l[count-1] should be ready by the time hmin/hmax is computed.
Otherwise the left limit for the transition key would be scaled wrong.
|
|
|
|
The equation solver didn't handle the one unknown case correctly.
|
|
By error, the Bezier points were using the mesh vertex size, not the grease pencil vertex size.
|
|
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 incremental was taking priority but the other elements are mandatory.
|
|
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
|
|
Simplify conditions and declare variables `const` where possible.
No functional changes.
|
|
Prefix a return parameter with `r_` to follow the style guide. No
functional changes.
|
|
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.
|
|
You can uncomment the PERFDEBUG define to get timings.
|
|
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 is consistent with the UI for other modifier types.
|
|
These fill shaders were used with the old draw engine.
|
|
The event "value" is not really required since this operation works as a toogle.
This change cleans and simplifies the code.
|
|
Note that the whole thing need to be redone/properly fixed, but this is
a bit more complicated so for now fix in rB8a2270efc52a is 'good
enough'.
|
|
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.
|
