Stupid mistake, 'original' filepath is a blender-flavored one, with
potentially weird things like the '//' relative 'header'... This can
work on linux (also it could have broken in other places too), but on
windows that is fully invalid path and python `os.path` library just
generates empty result here.
Simply using proper valid path instead fixes it...
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.
