There is no ideal solution here, but we can assume by default that we should
use the Alpha output from a texture used for transparency data.
This will break people using a dedicated B&W texture for this alpha
pass, but we cannot really handle all cases properly in this wrapper, we
only try to support the most common ones to some extent.
The issue was that the projection would be inverted.
So if you shifted 0.1 along the y axis, world_to_camera_view would act
as if you had shited it -0.1 along the y axis.
Before this commit, baking an action would only insert keys that are
necessary (i.e. using `INSERTKEY_NEEDED`). When baking to the current
Action, if there are no constraints that influence the final animation,
there are no additional keys necessary. This makes it appear as if
nothing happened. However, when baking to a new Action every additional
frame is necessary and thus a key is added for every frame.
@mont29 and I agreed that this behaviour is confusing, so this commit
changes the behaviour such that baking to the current action and to a
new action result in the same baked animation (that is, keyed on every
frame).
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
