This makes more sense to have no displacement if baking
non-normalized displacement map or have mid-level displacement
(which is likely be close to no displacement as well) when
baking normalized displacement.
In any way it's better than using default black color.
When setting keymap properties to values equalling the RNA default, they will
get "unset" and automatic operator behavior is used. There is no way to
explicitly set the default value as a user.
1) To allow distinguishing uninitialized (not set) properties in the keymap
items, a few changes to the RNA struct comparison function are needed: Instead
of allowing only strict/non-strict comparison of 2 properties A and B in a
struct, this now has 3 modes:
* STRICT: compare only the actual property values (same as 'strict' before)
* UNSET_MATCH_ANY: if either A or B is unset, consider them a match (same as
non-strict before)
* UNSET_MATCH_NONE: if one property is set and the other not, consider them a
mismatch.
The new UNSET_MATCH_NONE mode is useful for keymaps, because it allows keeping
user-defined property values in the keymap even if they match the default
property value (see wm_keymap_diff function in wm_keymap.c)
2) A new operator is added for unsetting ID properties in the RMB context menu
and in user preferences next to keymap properties. This only works on ID
properties and deletes the ID property storage, so that the default value is used.
In the user preferences for keymaps the properties are shown in an inactive
layout to indicate that the default value is used (which some operators such as
the "select linked" op from the report use to trigger automatic behavior). When
the user sets a property it gets set and stays that way until explicitly "unset"
using the new operator.
A crash was reported but without info to reproduce.
This is a likely crash introduced by previous fix
to allow linehits to snap to vertices.
The function to find connected linehits can't
assume all linehits have edges any more.
After discussion with Brecht decided that automatically updating the sockets of the node based on externally modified data (removed EXR file passes) is not desirable behavior. But at least making sure
the correct passes are assigned to the output sockets of the Image node is possible. Now the passes are matched by name instead of using the faulty index stored in the socket data, which is more
reliable. Still may break if changing pass names externally, but an image reload is highly recommended anyway and will fix that.
ERROR: Image not available. Keeping packed image
This was due to recent bugfix for #36639, the image should only be reloaded if
the path actually changed and it's not a packed file.
When printing operator reports, ommit unset properties.
This is needed because in some cases operators check if a value is set or not, so filling in default arguments may change behavior.
fix as suggested by Ton Roosendaal in tracker:
"the knife tool has a "MODE_PANNING" state, it could be nice to set this
in the modal map as well, to define the shortcut(s) that have to be passed on."
I caught this while looking at:
[#34663] Cannot rotate view while using Knife tool with Maya preset
(though it's not the original report).
I'll look at the other operators, there are probably a few in the same
situation as knife.
In fact, all curve objects were flipped in GLSL mode.
This is because of the way how normals are calculated
for them (inwards vs. outwards).
We might want to make normals consistent all over, but
that would be the bigger change. For ow just made some
tweaks to OpenGL setup.
Thanks Brecht for the review and tests!
wrong button.
Works by adding a flag to transform operators "remove_on_cancel". This is currently only used for node transforms, the idea is that if set, the operator will remove the transformed elements when it is
cancelled. It's not possible to do that in the original NODE_OT_add_node operator, because transform is modal and there is no way of reacting to a cancel outside of the transform itself (previous attempt
used a macro operator, but that also doesn't work because subsequent operators don't get executed if the previous transform cancels).
From the math point of view there're two cases:
- Clearing the keyframe between two other ones.
In this case tracker will first track plane from
left keyframe to right one without doing any kind
of blending. This will make plane stick to the
actual plane motion, but lead to possible jump
at the right keyframe.
Second step is to track from the right keyframe
to the left one with blending. This gives nice
transition at the point of second keyframe and
this mimics situation when you've been setting
keyframes from left to right.
- Clearing left-most/right-most keyframe.
In this case it's enough to only re-track the
plane without blending from the neighbor keyframe
without blending.
