scale and rotation in mapping node, there would be shearing, and the only way
to avoid that was to add 2 mapping nodes. This is because to transform the
texture, the inverse transform needs to be done on the texture coordinate
Now the mapping node has Texture/Point/Vector/Normal types to transform the
vector for a particular purpose. Point is the existing behavior, Texture is
the new default that behaves more like you might expect.
was regression in r59665 (fix for [#35002]).
now when checking a segment that lies on the same plane as the triangle intersects,
clip the segment by the triangle bounds so we know the points remain inside the triangle.
button under the mouse, and so clicking the button failed without first
moving the mouse. Similar issues could happen with popups and switching
windows.
The problem is that a notifier was being used to deactivate possible other
activated buttons, but as notifiers are delayed it could undo the correct
activation too. If anyone notices hanging tooltips or other issues after this
fix, please report them.
seems that somehow not having this is causing keyboard events to be caught by
SDL. This was removed because it broke addons that could use SDL, now set the
environment variable only temporary during SDL initialization.
This may have been causing issues with keyboard events getting missed in the
game engine, but I couldn't confirm the issue here.
normal and point parameter types of OSL shaders are creating SOCK_VECTOR sockets in the script node. When these sockets are in turn used to define the fixed input values for these parameters they get
converted as OSL vector always, losing the distinction of vector/normal/point. To prevent OSL rejecting the value due to type mismatch, explicitly define the parameter defaults in the OSL script node
compiler function as vector, normal and point (unused types will simply be ignored).
(which is also "[#36749] Joining objects with more than one uv map depends on list order")
Thanks Bastien Montagne and Brecht van Lommel for reviewing and some advice.
Suggestion by Jonathan Williamson, and thanks to
Walid Shouman for noticing that the existing code
worked if a test to prohibit it were removed.
Limitation: treats segments > 1 the same as
segments == 1 in this case; a TODO to do
something more intelligent.
In fact, the issue was that names of mloopuv/mtespoly layers could very easily get out of sync (a simple rename was enough), while most tools (such as the UVProject modifier) expect matching layers to have the same name!
Now matching names are check on load, and renaming of a layer through RNA is guaranted to be synchronized with its counterparts.
Thanks to Brecht & Campbell for reviews.
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.
