The sockets are not exposed in any nodes yet.
They work similar to the Object/Collection sockets, which also
just reference a data block.
This is part of D11222.
Was causing calculation issues later on in the kernel.
This change catches the most obvious case: missing attribute. The old
code was trying to set tangent to 0, but because it was transformed as
a normal it got converted to non-finite value. This change makes it so
that no transform is involved and 0 is written directly to the SVM
stack.
To cover all cases it will require using safe_normalize() in this node
and in the normal transform function. This is more involved change from
performance point of view, would be nice to verify whether we really want
to go this route.
I've left asserts in the BSDF allocation functions. Don't have strong
connection to them, but think they are handy and are not different from
having an assert in the path radiance checks.
Differential Revision: https://developer.blender.org/D11235
It is possible that BSDF allocation will advance pointer in the
allocation "pool" but will return null pointer if the weight is
too small.
One artist-measurable issue this change fixes is random issues
with denoising: normal pass for denoising could have accessed
non-initialized normal of a closure.
Differential Revision: https://developer.blender.org/D11230
When activated in modal, `translate`, `resize`, `rotate`, `shear` and
`edge_rotate_normal` use a different orientation than the set in scene.
This orientation needed to match since some of these modes can be switched
during operation.
The default orientation for these modes was `V3D_ORIENT_VIEW`.
And this changed when finishing the `translate` and `resize` to
`V3D_ORIENT_GLOBAL`.
But this could cause inconsistencies when inputting values from the
keyboard.
The solution now is to change the orientation when you change the mode.
---
Note: Although the user can expect the value entered to reflect the
orientation set in the scene, it would require a lot of changes and would
not be really useful.
Extracts `nlasnapshot_blend_get_inverted_upper_snapshot()` from
`BKE_animsys_nla_remap_keyframe_values()`
This introduces a new struct member:
`NlaEvalChannelSnapshot->remap_domain` and marks which values of
`blended_snapshot` are processed for remapping/used-for-inverting.
Effectively, it marks which values have successfully been remapped and
can be further used for remapping.
`nlasnapshot_blend_get_inverted_upper_snapshot()`:
output snapshot `r_upper_snapshot` has each channel's `remap_domain`
written to which effectively marks the successfully remapped values.
The only reason a value is not in the remap domain is if inversion
failed or it wasn't marked to be remapped.
`..get_inverted_upper_snapshot()` has a variant `nlasnapshot_blend()`
from {D10220}, but this patch doesn't depend on it at all. A third
variant will later be added `..get_inverted_lower_snapshot()`.
Altogether, these three functions allow solving for any of
(lower_snapshot, upper_snapshot, blended_snapshot) given the other two.
The function `..get_inverted_lower_snapshot()` will also similarly
process the remap domain of the blended and lower snapshot.
added assertions within `nlasnapshot_blend()` and
`..get_inverted_upper_snapshot()` to future proof branches dealing with
blendmode and mixmodes. (suggested by sybren)
No user functional changes
Reviewed By: sybren
Differential Revision: https://developer.blender.org/D10222
This turns links red if no implicit conversion can be made between the
from socket and the to socket. For geometry nodes this happens with
object, geometry, collection, and string sockets that are connected to
a different type. The change is simply implementing a callback that is
already implemented for other node tree types.
Differential Revision: https://developer.blender.org/D11229
Add translation/rotation/scale parameters for custom bones shapes. The
new scale is a 3D vector `custom_shape_scale_xyz`, and replaces the
`custom_shape_scale` float.
Reviewed By: #animation_rigging, sybren, zeddb
Differential Revision: https://developer.blender.org/D10974
Previously we had a lot merge conflicts since we always put the most
recently added node at the bottom. By sorting the list we will have
one fewer merge conflict when a node is added in most cases.
The id-property iterator referenced a PyObject pointer without
increasing it's user count - allowing for errors if the value
goes out of scope during iteration.
Similar to how `GVArray_For_VArray` implements `materialize_impl` to
forward the work to its non-generic virtual array, we can do the same
thing for the mutable version, `GVMutableArray_For_VMutableArray`.
This commit should have no visible changes, since as far as I can tell
the only user of this class does not implement special materialize
methods anyway.
This enables the overlay for instanced geometry.
After this change, objects that are an instance of the current active
object (which are also being modified in the current active mode) won't
fade, which is different from the previous behavior.
Reviewed By: fclem
Maniphest Tasks: T82155
Differential Revision: https://developer.blender.org/D9362
When checking if the mesh has only one Face Set only the current active
component for expand needs to be checked. Otherwhise other components
that won't be modified by Expand that contain other IDs will be taken
into account, making the Face Set deletion go into an infinite loop.
Reviewed By: JacquesLucke
Maniphest Tasks: T88060
Differential Revision: https://developer.blender.org/D11169
