This adds initial support for rendering Cycles and EEVEE shaders in Hydra
render engines that support MaterialX. Not all nodes are currently
supported, see the detailed compatibility list in #112864.
Co-authored-by: Georgiy Markelov <georgiy.m.markelov@gmail.com>
Co-authored-by: Vasyl Pidhirskyi <vpidhirskyi@gmail.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/111765
This changes the `action.frame_range` Python API to return an accurate
frame range for actions. Specifically, it was previously special-cased
to return a range with length 1 whenever the length was actually 0. This
led to a bizarre situation where a real frame range of `[0.0, 0.2]` would
return that range as-is, but a real frame range of `[0.0, 0.0]` would
instead return a range of `[0.0, 1.0]`.
The new behavior simply always returns the real frame range.
The reason for the previous behavior was obscure: the relevant code was
also used internally in Blender's NLA system, and returning a zero-length
range could result in NLA strips getting infinite scale. The code is now
separated out appropriately so that the NLA system still gets the
non-zero-length range, while the Python API for actions returns the real
range.
Pull Request: https://projects.blender.org/blender/blender/pulls/112709
Draw anim channel colors as a little rectangle in the channel list,
instead of taking over the entire channel name background. This keeps
the channel names readable, regardless of the channel colors.
Channel colors are typically set via the bone colors, and since those
are chosen for visual contrast in the 3D Viewport, they aren't
guaranteed to also be a suitable background color for the channel list.
Because of this, it's no longer used as such.
The channel 'data' background (i.e. the keyframe area) is now drawn with
a consistent color, and much more subtle.
This also enables the 'Channel Group Colors' setting in the preferences
by default, as it is now way less obnoxious and invasive.
Design task: https://projects.blender.org/blender/blender/issues/69059
Reviewed-On: https://projects.blender.org/blender/blender/pulls/112861
Use of node group assets relies on a few properties written to asset
meta-data for proper filtering of assets in menus (add modifier menu,
node add menu, 3D view menus for tools). Currently these meta-data
properties are written when updating their source properties and when
saving the file. That means they *aren't* written when marking a group
as an asset, which is necessary because the meta-data doesn't exist
before when the group isn't an asset. Currently users have to save the
file to update menus in this case, which isn't intuitive.
As a fix, call the function to write the meta-data when marking a
data-block as an asset.
Pull Request: https://projects.blender.org/blender/blender/pulls/112743
This was discussed in #112022 and on devtalk:
https://devtalk.blender.org/t/vertex-groups-generic-attributes-and-name-clashing/31073
While vertex groups with the same name as attributes should be avoided, since
it can cause ambiguities when using attributes, it's something we can handle
gracefully for now. Enforcing unique names for vertex groups resulted in breaking
other functionality under some circumstances.
This effectively reverts 12ef20990b, except for
the bug fix in `BKE_id_attribute_new`.
#112891 adds a warning to avoid make users aware of duplicate names so that they
can be avoided in practice.
Pull Request: https://projects.blender.org/blender/blender/pulls/112889
Currently the iteration over a PBVH node's vertices retrieves mutable
access to the mask custom data layer. This isn't threadsafe, but it is
done in the multithreaded loops over all nodes.
In general, we need to be more careful and conservative about storage
of non-const pointers to mesh data. Ideally we would only have one
mutable reference to a resource at a time. And we should avoid doing
work like looking up custom data layers more than we need to.
To that end, make the pointer to the custom data layer used everywhere
const, and retrieve mutable access before parallel node iteration with
a specific function, and write to the mask data with that in mind.
This pushes us in the direction of sharing less code per PBVH type.
In my opinion that's a good thing, because we can actually optimize for
each type. For example, `write_mask_data` gives a picture of
how each of these hot loops could become much simpler.
Pull Request: https://projects.blender.org/blender/blender/pulls/112690
Currently vertices are mapped to B-Bone segments without taking the
rest pose curve into account. This is very simple and fast, but causes
poor deformations in some cases where the rest curvature is significant,
e.g. mouth corners in the new Rigify face rig.
This patch implements a new mapping mode that addresses this problem.
The general idea is to do an orthogonal projection on the curve. However,
since there is no analytical solution for bezier curves, it uses the
segment approximation:
* First, boundaries between segments are used for a binary space
partitioning search to narrow down the mapping to one segment.
* Then, a position on the segment is chosen via linear
interpolation between the BSP planes.
* Finally, to remove the sharp discontinuity at the evolute surface
a smoothing pass is applied to the chosen position by blending to
reduce the slope around the planes previously used in the BSP search.
In order to make per-vertex processing faster, a new array with the
necessary vectors converted to the pose space, as well as some
precomputed coefficients, is built.
The new mode is implemented as a per-bone option in order to ensure
backward compatibility, and also because the new mode may not be
optimal for all cases due to the difference in performance, and
complications like the smoothed but still present mapping
discontinuities around the evolute surface.
Wiki: https://wiki.blender.org/wiki/Source/Animation/B-Bone_Vertex_Mapping
Pull Request: https://projects.blender.org/blender/blender/pulls/110758
Pull Request: https://projects.blender.org/blender/blender/pulls/110758
The order of collections in the light linking collection is important
as it is used for tie-breaking when the same object is reachable from
multiple linked collections with different light linking state.
This commit utilizes the generic tree view reordering operations to
allow insertion of elements to a specific location and to re-order
existing objects and collections in the light linking collection.
It is possible to re-order both collections and objects, even tough
re-ordering objects does not really make a difference for the light
linking behavior. It is not possible to place an object before
collections.
Pull Request: https://projects.blender.org/blender/blender/pulls/112849
The color returned by `ANIM_bonecolor_posebone_get()` is not supposed
to be edited, so just return it as `const` and take a `const bPoseChannel`
as argument.
This makes the function usable in a wider range of situations, for example
the drawing code (which shouldn't alter any of these colors).
Enable visual keying of bones that are influenced by an IK constraint.
This wasn't possible before, as the visual keying system only checked
constraints on the bone itself, and not whether the bone was part of an
IK chain.
This commit introduces a new `bPoseChannel::constflag` value
`PCHAN_INFLUENCED_BY_IK` that is set whenever the pose bone is part of
an IK chain.
The `pchan->constflag` field is computed during depsgraph evaluation. If
the depsgraph is active, it is now also written back to the original
pchan, so that it can be used in the "should visual keying be used"
function.
Fixes: #76791 "Different results when keyframing visual transforms and
applying transforms manually on IK constraint". Note that visually
keying does *not* copy the visual pose to the current pose. Furthermore,
when visually keying only part of the IK chain, the result of
re-evaluating the IK constraint (for example by moving the scene forward
and then backward by one frame) may still produce a different result, as
the IK chain now has a different start orientation.
Note that commit explicitly does not cover Spline IK constraints. They
can introduce heavy shear, especially with the default settings, which
cannot be represented by keys on loc/rot/scale.
For historical reference: 876cfc837e
introduces the 'use visual keying' preference option, where Blender
automatically chooses whether or not to use visual keying. This is why
there is a function at all that determines whether to use visual keying
or not.
Rename the `bPoseChannel::flag` `PCHAN_HAS_TARGET` to `PCHAN_HAS_NO_TARGET`
as that is actually the meaning of the flag (in the majority of the code).
Since the flag was so confusingly named, there were some mixups in the
armature overlay drawing code as well, which have been fixed now too.
Change the definition of the `PCHAN_HAS_CONST` pose channel flag. It used
to mean "has a constraint that is not IK or Spline IK", and now it just
means "has a constraint".
This has no direct effect yet, as the flag is only used in drawing code
when there is no (spline) IK constraint. However, I feel that the flag
name should match its expected behaviour, and IMO, in this case, making
that behaviour simpler is better than documenting more.
Refactor `BKE_pose_channel_copy_data()` so that it iterates over the entire
armature only once (instead of twice), and to use a `switch` instead of
a chain of `if`/`else if`/`else` clauses.
No functional changes.
Add a checkbox to node group inputs to force inputs to be single values
and not accept varying fields. While this could also be done more
automatically, and it could be argued that requiring the flexibility is
helpful for users who want to use attributes, there are cases where the
field inferencing doesn't work, or the "use attribute" option is just
unhelpful. People use workarounds with primitive nodes to get the same
behavior anyway.
Pull Request: https://projects.blender.org/blender/blender/pulls/112745
When texture painting on a Non-color byte texture with Texture limit active
(or the texture didn't fit on the GPU) the data for partial updating of a GPU
texture was incorrect.
`gpu_texture_update_scaled` expects an input buffer clipped to
the bounds of the input area that needs to be updated. In case for Byte
textures with Non Color colorspace it received the unmodified input
buffer, resulting in incorrect data to be uploaded to the GPU texture.
This PR fixes this by selecting the non-optimized branch when the
texture is a Byte buffer with Data color space and scaling should
happen.
Pull Request: https://projects.blender.org/blender/blender/pulls/112834
In preparation of https://projects.blender.org/blender/blender/pulls/112535, we need to make sure all layer tree manipulations are in functions on the `GreasePencil` struct so we can keep the `CustomData` for layers in sync with the layer tree.
This PR makes sure that all the functions that change the layer tree in any way are `protected` on the `LayerGroup` class. The `GreasePencil` struct is declared `friend` with `LayerGroup`.
We also cleanup and remove a lot of code duplication between layers and layer groups and try to write functions in a generic way for `TreeNode` (both layers and layer groups are tree nodes).
Pull Request: https://projects.blender.org/blender/blender/pulls/112837
The goal is to make the search faster to use by dynamically adapting to the user.
This can be achieved using the simple but common approach of showing recently
selected items at the top. Note, that the "matching score" between the query and
each search item still has precedence when determining the order. So the last used
item is only at the top, if there is no other search item that matches the query better.
Besides making the search generally faster to use, my hope is that this can also
reduce the need for manually weighting search items in some places. This is
because while the ordering might not be perfect the first time, it will always be
once the user selected the element that should be at the top once.
This patch includes:
* Support for taking recent searches into account in string searching.
* Keep track of a global list of recent searches.
* Store recent searches on disk similar to recently opened files.
* A new setting in the user preferences that allows disabling the functionality.
This can be used if deterministic key strokes are required, e.g. for automated tests.
In the future this could be improved in different ways:
* Add some kind of separator in the search list to indicate which elements are at
the top because they have been used recently.
* Store the recent search items per search, instead of in a global list. This way
it could adapt to the user even better.
Pull Request: https://projects.blender.org/blender/blender/pulls/110828
- Use `StringRef` over `StringRefNull`, since it handles `nullptr` in
its constructor and gives more flexibility about the string's source.
- Change `const char *` to `StringRef` as well, for improved ergonomics
and efficiency.
- Move `add_interface_socket_from_node` to a .cc file. It's not small
or performance sensitive enough to be inlined.
- Avoid allocating empty strings for item descriptions.
- Allocate with `BLI_strdupn` to avoid unnecessary `strlen` calls.
- Move a bit more code into a proper namespace.
Pull Request: https://projects.blender.org/blender/blender/pulls/112721
See #103343.
We had attempted to move the file to C++ twice before but found failing
tests each time. To find the code with changed behavior between C and
C++, I temporarily added a header declaring all the functions and moved
them one by one. The problem ended up being one function's use of `exp`
which used floats instead of doubles in C++.
Pull Request: https://projects.blender.org/blender/blender/pulls/112693
Instead of adding the default "Bones" bone collection to every Armature
data-block, only add it for Armatures that are added in the 3D View with
Shift+A > Armature.
This simplifies things like importers, which otherwise would have needed
to remove that default collection before creating the imported ones.
Additionally, this also ensures that the one bone you get by default is
actually assigned to the default bone collection.
Rather than always snapping the region size to the closest multiple of
the row height, remember the amount of rows displayed after the user
resized the region, and try to preserve that. This gives a lot more
predictable behavior, especially when the "Show Names" option is toggled
on and off, and the region resizes in response. With the old method the
amount of visible rows could change multiple times while toggling.
This also enables us to clamp the amount of rows (e.g. while the preview
size is increased and the region becomes too large for the area; or,
when a catalog tab is activated with fewer assets and thus fewer rows)
but still restore the amount of rows the user chose earlier, as soon as
possible.
Part of #107881.
Pull Request: https://projects.blender.org/blender/blender/pulls/112637
Blender 4.0 requires OpenGL 4.3 which always support SSBO's.
Platforms that don't support enough SSBO bind points will be marked
as unsupported.
Users who start Blender on those platforms will be informed via a
dialog. This PR also updates the `--debug-gpu-force-workarounds`
to match our minimum requirements. Note that some bugs are still
there that should be solved in other PRs:
* Workbench only renders the object using a unit matrix this is because
there is a bug in the workaround for shader_draw_parameters
* Navigating with middle mouse button is not working. Unsure what the
cause is, but might be a missing feature check in the OpenGL backend.
Related to #112224
Pull Request: https://projects.blender.org/blender/blender/pulls/112572
Use magenta fallback color for sockets without a `draw_color_simple`
callback. This is not ideal, but without a context or node instance
the older `draw_color` callback can't be used.
Pull Request: https://projects.blender.org/blender/blender/pulls/112658
The goal is to reduce redundancy by abstracting over the different types of node
tree zones. This makes it easier to add new zone types and makes the intend of
code more clear. For example, now it is more obvious what code deals with zones
in general and what does simulation specific things.
Pull Request: https://projects.blender.org/blender/blender/pulls/112531
It was possible to access a mutable drawing from a const GreasePencil
object. This sort of mistake is possible because DNA requires using raw
pointers.
This is a compatibility breaking change to rename all usages of the name
`asset_library_ref` with `asset_library_reference`. Brecht recently
suggested that such abbreviations should be avoided in public API names.
f6a6b27ac1 made the asset representation type available through context
wherever asset handle was previously. This moves us closer to replacing
the asset handle type.
Part of #102877 and #108806.
Makes the asset representation type available in RNA/BPY context
whenever the asset handle type is, so that it can be used instead. See
d04cd3f3e6. With this change we can now replace virtually all usages of
the asset handle type in Python with the asset representation. (Only for
the asset view template we require a collection property taking asset
handles still, for internal reasons.)
Idea is now to first get rid of all usages of asset handle in Python,
so that there's almost no need for further compatibility breaking
changes (unsure if the asset view template can be removed for 4.0
already though). Internal hacks related to it can be removed at any time
still.
Part of #102877 and #108806.
Blender has the option to disable SSBO support. This was accessible
as a command line option `--debug-gpu-disable-ssbo`.
Blender 4.0 has a hard requirement for OpenGL 4.3 which includes
SSBO support by default.
This PR removes the command line option as it makes no sense to
have it anymore.
Related to #112224
Pull Request: https://projects.blender.org/blender/blender/pulls/112571
In #112326 the socket visibility functions were updated to take the
open/closed state of panels into account for visibility of the socket
icon. However, in "hidden" (collapsed) nodes the panels should be
ignored entirely, drawing all sockets on the root level. This requires
looking at the node flags to determine socket icon visibility, so a
simple method of `bNodeSocket` is not sufficient.
This patch moves the more complex visibility queries for sockets into
`bNode`, where both node and socket flags can be accessed. These should
be used for actual visibility rather than the plain flag accessors on
`bNodeSocket`.
Renamed `is_visible_or_panel_closed` back to just `is_visible`, the
other `is_visible` variant is now integrated in `bNode::is_socket_drawn`.
Pull Request: https://projects.blender.org/blender/blender/pulls/112520
Bogdan Nagirniak
Nathan Vegdahl
Sybren A. Stüvel
Hans Goudey
Jacques Lucke
Alexander Gavrilov
Campbell Barton
Weizhen Huang
Sergey Sharybin
Jeroen Bakker
Falk David
Philipp Oeser
Julian Eisel
Lukas Tönne
Iliya Katueshenock