All the single-value texture inputs of Principled BSDF node should use
non-color colorspace profile, not sRGB one (issue raised in
https://blender.stackexchange.com/questions/155617, thanks).
That also revealed another issue - since those color space settings are
stored at the image level itself, not the node one, we need to
duplicate those image data-blocks when we use same picture for e.g. base
color (sRGB) and specular (non-color) inputs...
For now using a basic mechanism for that, might generate several extra,
uneeded copies of the image ID, but that’s better than breaking custom
settings and such.
Note that while this will modify the behavior of the impporters using
that node wrapper, no change should be needed in IO add-ons themselves.
Since rBbaaa89a0bc54 we have to access the mapping node differently.
This doesnt take actual linkage of the new sockets into account (but
this wasnt done for most sockets on the Principled BSDF node either)
Also the min/max of the mapping node was removed entirely.
It was decided upon removing this from node_shader_utils as well (and
replace this by existing access to the Extension parameter of the
Texture node).
Part of solving T69526.
Differential Revision: https://developer.blender.org/D5693
'is_data'
since the move from 'cycles_shader_compat' (2.79) to
'PrincipledBSDFWrapper' (2.8) we lost the ability to (automatically) set
this colorspace setting for imported textures. This was useful for e.g.
normalmaps to always assume 'Non-Color' data.
This adds the possibility to overide and uses this for normalmaps...
Fixes T66368
Reviewers: mont29, brecht
Maniphest Tasks: T66368
Differential Revision: https://developer.blender.org/D5176
scene.update() needs to be replaced with view_layer.update() after
rBe693918d4074
note: will go over other occurances of scene.update() in a different
commit
The choices are now World, View and 3D Cursor.
This breaks Python API compatibility, add-ons that add objects with this
parameter will need to be updated.
Differential Revision: https://developer.blender.org/D4706
Add Object.local_view_get/set
Alternate fix which supports removing from local view & checking
if an object is in local view.
Also avoids redundant refresh.
Matches 2.7x Object.layer_local_view capabilities more closely,
without exposing the flag directly.
This reverts commit 9054b39b27.
Using the region data to find the screen & space-data doesn't make sense
since local-view is space-data there is no reason to pass in a region
argument, then lookup the space-data.
There was no way to remove an object or check it's local view state
as there was in 2.7x.
This can be made closer to 2.7x API and simplified.
Caused by an error in rBe65784a0519e.
And since we are going over loop triangles anyways, we can remove the
part quecking for quads [remainder of tessface era] entirely.
Reviewers: campbellbarton
Maniphest Tasks: T61309
Differential Revision: https://developer.blender.org/D4324
Nice side-effect of using new __annotations__ thingy to store
dynamically-generated fields in a class: __annotations__ dict is not
ensured to exist for a given class, so we may end up modifying on of the
parents' one!
Use the same data format and loader that the default key-maps use.
This supports nested properties (needed for macros)
and fixes modal key-maps which weren't supported.
This format still needs to be documented.
bpy_extras were meant to be useful high-level helper functions for
script authors to perform common operations,
to avoid writing to verbose API's.
bpy_extras.keymap_utils contains some specialized API calls
mainly intended for Blender's own internal use.
Move keymap import export to internal API.
For Blender builtin configurations the option to choose the select mouse remains
and is now also in the splash screen. It works by changing the keymap dynamically
in the script, rather than using special events.
The system of automatic switching of events was not flexible enough to deal with
side effects that require further keymap changes, so it is now under more manual
control in the script.
This breaks compatibility for some scripts and exported key configurations.
These can be fixed by replacing SELECTMOUSE, ACTIONMOUSE, EVT_TWEAK_S and
EVT_TWEAK_A with appropriate LEFTMOUSE, RIGHTMOUSE, EVT_TWEAK_L and
EVT_TWEAK_R events.
Other than that, there should be no functional changes.
