This adds support for attaching gizmos for input values. The goal is to make it
easier for users to set input values intuitively in the 3D viewport.
We went through multiple different possible designs until we settled on the one
implemented here. We picked it for it's flexibility and ease of use when using
geometry node assets. The core principle in the design is that **gizmos are
attached to existing input values instead of being the input value themselves**.
This actually fits the existing concept of gizmos in Blender well, but may be a
bit unintutitive in a node setup at first. The attachment is done using links in
the node editor.
The most basic usage of the node is to link a Value node to the new Linear Gizmo
node. This attaches the gizmo to the input value and allows you to change it
from the 3D view. The attachment is indicated by the gizmo icon in the sockets
which are controlled by a gizmo as well as the back-link (notice the double
link) when the gizmo is active.
The core principle makes it straight forward to control the same node setup from
the 3D view with gizmos, or by manually changing input values, or by driving the
input values procedurally.
If the input value is controlled indirectly by other inputs, it's often possible
to **automatically propagate** the gizmo to the actual input.
Backpropagation does not work for all nodes, although more nodes can be
supported over time.
This patch adds the first three gizmo nodes which cover common use cases:
* **Linear Gizmo**: Creates a gizmo that controls a float or integer value using
a linear movement of e.g. an arrow in the 3D viewport.
* **Dial Gizmo**: Creates a circular gizmo in the 3D viewport that can be
rotated to change the attached angle input.
* **Transform Gizmo**: Creates a simple gizmo for location, rotation and scale.
In the future, more built-in gizmos and potentially the ability for custom
gizmos could be added.
All gizmo nodes have a **Transform** geometry output. Using it is optional but
it is recommended when the gizmo is used to control inputs that affect a
geometry. When it is used, Blender will automatically transform the gizmos
together with the geometry that they control. To achieve this, the output should
be merged with the generated geometry using the *Join Geometry* node. The data
contained in *Transform* output is not visible geometry, but just internal
information that helps Blender to give a better user experience when using
gizmos.
The gizmo nodes have a multi-input socket. This allows **controlling multiple
values** with the same gizmo.
Only a small set of **gizmo shapes** is supported initially. It might be
extended in the future but one goal is to give the gizmos used by different node
group assets a familiar look and feel. A similar constraint exists for
**colors**. Currently, one can choose from a fixed set of colors which can be
modified in the theme settings.
The set of **visible gizmos** is determined by a multiple factors because it's
not really feasible to show all possible gizmos at all times. To see any of the
geometry nodes gizmos, the "Active Modifier" option has to be enabled in the
"Viewport Gizmos" popover. Then all gizmos are drawn for which at least one of
the following is true:
* The gizmo controls an input of the active modifier of the active object.
* The gizmo controls a value in a selected node in an open node editor.
* The gizmo controls a pinned value in an open node editor. Pinning works by
clicking the gizmo icon next to the value.
Pull Request: https://projects.blender.org/blender/blender/pulls/112677
Extract
- Add to Quick Favorites tooltip.
- "Mask", the name of a newly created mask (DATA_).
- "New" in the context of the new mask ID button.
- A few strings using BLI_STR_UTF8_ defines were not extracted.
Take the special characters out of the translation macros.
- "External" menu items from the filebrowser's Files context
menu (right-click on a file). These items were already extracted,
but not translated.
Improve
- Separate formatted error message "%s is not compatible with
["the specified", "any"] 'refresh' options" into two messages.
Disambiguate
- Use Action context for new F-modifiers' names. This is already used
for the "type" operator prop.
- Translate ImportHelper's default confirmation text using the
Operator context, as it uses the operator name which is extracted
with this context.
- "Scale" can be a noun, the scale of something, or a verb, to scale
something. The latter mostly uses the Operator context, so apply
this context to verbs, and the default contexts to nouns.
- "Scale Influence" can mean "Influence on Scale" (tracking
stabilization) and "to Scale the Influence" (dynamic paint canvas).
- "Object Line Art" as type of Line Art to add, as opposed to the
active object's Line Art settings.
- Float to Integer node: use NodeTree context for the node label, as
this is already extracted and used for the enum.
Do not translate
- Sequencer labels containing only a string formatting field.
Some issues reported by Gabriel Gazzán and Ye Gui.
Pull Request: https://projects.blender.org/blender/blender/pulls/122283
Move all header file into namespace.
Unnecessary namespaces was removed from implementations file.
Part of forward declarations in header was moved in the top part
of file just to do not have a lot of separate namespaces.
Pull Request: https://projects.blender.org/blender/blender/pulls/121637
This adds a new `Axes to Rotation` node which creates a new rotation.
In many cases, the primary and secondary axis inputs are a normal and
tangent of a mesh or curve. This provides a simpler and more direct way
to create this rotation compared to using two `Align Rotation to Vector` nodes.
This more direct way of computing the rotation also allows us to optimize
the case better.
The node rotates one axis (X, Y or Z) to the given primary axis direction. Then
it rotates around that primary direction to align the second axis to the given
secondary direction. Ideally, both input axes are orthogonal. However, the node
still creates the "best" rotation when they are not orthogonal. If one or the axes
is zero or both are (close to) parallel, the resulting rotation is unstable. There is
not too much the node can do to make it more stable.
Pull Request: https://projects.blender.org/blender/blender/pulls/104416
This assertion was added in assumption that sizes of input argument are always correct.
But this is not such. More correct is to depend on assertions of span access methods.
The size of the multi-function parameters is only guaranteed to be large enough so that
every index in the mask can be accessed. It may be larger.
Pull Request: https://projects.blender.org/blender/blender/pulls/121393
These nodes allow working with the raw values that make up a matrix.
This can be used to construct a 4x4 matrix directly, without using the
`Combine Transform` node. This allows building transforms with arbitrary
skew, or projection matrices.
Pull Request: https://projects.blender.org/blender/blender/pulls/121283
A version of "Align Euler to Vector" with the rotation socket
instead of the vector Euler socket. Other than that, and a few
cleanups to use newer math functions, the node is the same.
The old node is just "Deprecated" for now. We could remove
it with versioning, but we can also wait to do that.
In a simple test this node is about 1.7 times faster than the old one.
Pull Request: https://projects.blender.org/blender/blender/pulls/118565
With the matrix socket being introduced into geometry nodes, we
are starting to deal with more complex transforms like perspective
projection. For those matrices projecting a point is not as simple
as just matrix multiplication, there has to be an additional normalization
step after. To solve that in an intuitive way consistent with how it's
typically solved in code, add a new "Project Point" node.
The canonical use case for now is in combination with the mouse
position, viewport transform, and raycast nodes, to find where the
mouse clicked on the edited geometry.
Pull Request: https://projects.blender.org/blender/blender/pulls/120597
Previously, this conversion would often result in invalid quaternions or
hit an assert in `normalized_to_quat_fast`. It's not super nice to convert
to euler as an intermediate step performance wise, but it seems to be
the easiest solution for now. Extracting rotations from matrices should
not be done all that often anyway.
Pull Request: https://projects.blender.org/blender/blender/pulls/120568
Not all matrices are invertable (e.g. when a transformation matrix is has
a scale of zero), and it's sometimes important when a matrix is.
This also better specifies the behavior when the matrix is not invertable:
the identity matrix is returned.
Pull Request: https://projects.blender.org/blender/blender/pulls/120530
For various reasons, the animation system can't properly update the node tree
so that the socket availability caused by changing node enum properties
propagates completely. So animating node properties that affect
socket visibility to change isn't possible without issues like crashes.
Unfortunately that wasn't disallowed before. In this commit there is
a balance of disabling animation on sockets that could reasonably expected
to affect socket visibility, and minimizing breaking changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/119221
This fixes the following name collisions:
* Compositor Box/Ellipse Mask node: `width` -> `mask_width`
(also renamed the `height` property accordingly)
* Shader AOV Output node: `name` -> `aov_name`
* Geometry Color node: `color` -> `value`.
Those are breaking changes unfortunately, because looking up those property
names yielded the node-specific and not the common property. Therefore, this is
targeted at `main` instead of `4.1`.
Pull Request: https://projects.blender.org/blender/blender/pulls/119284
`sock_rotation` has higher priority (6) than the vector socket (4).
Hence inserting node between vector-vector link joins thorugh "rotation"
socket (`get_main_socket()` / `get_main_socket_priority()`).
This can be fixed by making "vector" input socket as default for link.
But this will break the link creation when node is inserted between
rotation-rotation link. It seems rotation is converted to vectors so
perhaps make sense to make "vector" as default socket for link.
Pull Request: https://projects.blender.org/blender/blender/pulls/116550
Implements the design from #116067.
The socket type is called "Matrix" but it is often referred to as "Transform"
when that's what it is semantically. The attribute type is "4x4 Matrix" since
that's a lower level choice. Currently matrix sockets are always passed
around internally as `float4x4`, but that can be optimized in the future
when smaller types would give the same behavior.
A new "Matrix" utilities category has the following set of initial nodes"
- **Combine Transform**
- **Separate Transform**
- **Multiply Matrices**
- **Transform Direction**
- **Transform Vector**
- **Invert Matrix**
- **Transpose Matrix**
The nodes and socket type are behind an experimental flag for now,
which will give us time to make sure it's the right set of initial nodes.
The viewer node overlay doesn't support matrices-- they aren't supported
for rendering in general. They also aren't supported in the modifier interface
currently. But they are supported in the spreadsheet, where the value is
displayed in a tooltip.
Pull Request: https://projects.blender.org/blender/blender/pulls/116166
In 4.1 we deprecate the `Rotate Euler` node in favor of the `Rotate Rotation`
node which uses the new rotation socket type. The node is not removed
(for now) because that would come with compatibility issues. More generally,
we'll likely run into the situation where nodes are deprecated more often in the
future, without actually removing them to keep compatibility. This patch improves
how such nodes are handled in the UI.
The patch does three things:
* Adds a new `Utilities > Deprecated` entry in the add node menu in geometry nodes.
* Moves search items which are deprecated to the bottom in the search results
(currently, this only works in English, can be fixed in bcon3).
* Adds a new `bNodeType->deprecation_notice` that will result in a deprecation
warning when the node is used.
Pull Request: https://projects.blender.org/blender/blender/pulls/117905
All the option does internally is reverse the order of the rotations,
but this is the same as old "Rotate Euler" node, and it's a bit more
intuitive this way. Also use the same socket names, "Rotation" and
"Rotate By" which are much more intuitive.
Technically it would be better to not have to duplicate the multi-
function just to switch the order of the arguments. But the
evaluator assumes that the order always matches the socket
order currently.
Pull Request: https://projects.blender.org/blender/blender/pulls/117899
This is meant as a replacement for the Rotate Euler node. Overall it
should be more performant, and the clarity given by the separate socket
type should help distinguish its purpose.
The Rotate Euler node is removed from search and the add menu by this
commit. In the future it can be versioned away. That isn't done now to
avoid a breaking API change and to make this commit less risky.
Pull Request: https://projects.blender.org/blender/blender/pulls/116106
The previous commit introduced a new `RPT_()` macro to translate
strings which are not tooltips or regular interface elements, but
longer reports or statuses.
This commit uses the new macro to translate many strings all over the
UI.
Most of it is a simple replace from `TIP_()` or `IFACE_()` to
`RPT_()`, but there are some additional changes:
- A few translations inside `BKE_report()` are removed altogether
because they are already handled by the translation system.
- Messages inside `UI_but_disable()` are no longer translated
manually, but they are handled by a new regex in the translation
system.
Pull Request: https://projects.blender.org/blender/blender/pulls/116804
Pull Request: https://projects.blender.org/blender/blender/pulls/116804
This commit adds a new helper to define expected properties when a
target needs to use the unity build feature.
That new helper does what was already done for existing cases, and in
addition add the target to the Ninja 'heavy' pooljobs if relevant.
Pull Request: https://projects.blender.org/blender/blender/pulls/116791
Due to changes in the build environment shader_builder wasn't able to
compile on macOs. This patch reverts several recent changes to CMake files.
* dbb2844ed9
* 94817f64b9
* 1b6cd937ff
The idea is that in the near future shader_builder will run on the buildbot as
part of any regular build to ensure that changes to the CMake doesn't break
shader_builder and we only detect it after a few days.
Pull Request: https://projects.blender.org/blender/blender/pulls/115929
This helps solving the problem encountered in #113553. The problem is that we
currently can't support link-drag-search for nodes which have a dynamic declaration.
With this patch, there is only a single `declare` function per node type, instead of
the separate `declare` and `declare_dynamic` functions. The new `declare` function
has access to the node and tree. However, both are allowed to be null. The final
node declaration has a flag for whether it depends on the node context or not.
Nodes that previously had a dynamic declaration should now create as much of
the declaration as possible that does not depend on the node. This allows code
like for link-drag-search to take those sockets into account even if the other
sockets are dynamic.
For node declarations that have dynamic types (e.g. Switch node), we can also
add extra information to the static node declaration, like the identifier of the socket
with the dynamic type. This is not part of this patch though.
I can think of two main alternatives to the approach implemented here:
* Define two separate functions for dynamic nodes. One that creates the "static
declaration" without node context, and on that creates the actual declaration with
node context.
* Have a single declare function that generates "build instructions" for the actual
node declaration. So instead of building the final declaration directly, one can for
example add a socket whose type depends on a specific rna path in the node.
The actual node declaration is then automatically generated based on the build
instructions. This becomes quite a bit more tricky with dynamic amounts of sockets
and introduces another indirection between declarations and what sockets the node
actually has.
I found the approach implemented in this patch to lead to the least amount of
boilerplate (doesn't require a seperate "build instructions" data structure) and code
duplication (socket properties are still only defined in one place). At the same time,
it offers more flexibility to how nodes can be dynamic.
Pull Request: https://projects.blender.org/blender/blender/pulls/113742
Strings that include Latin1 encoding or corrupt UTF8 byte sequences
could read past the buffer bounds (stepping over the null terminator).
Resolve by passing in the string length.
Other changes to support non-UTF8 byte sequences:
- BLI_str_utf8_offset_{to/from}_index were accumulating
the UTF8 offset without accounting for non-UTF8 characters
which could cause a buffer underflow or enter an eternal loop.
- BLI_str_utf8_offset_to_index would read past the buffer bounds if the
offset passed in if it was in the middle of a UTF8 byte sequence.
Now that specific menus can be searched directly (see 7f9d51853c),
there is no need to maintain separate search functionality for adding
nodes. This PR removes the add node search. In a way this brings us
closer to the `NodeItem` situation before, but the setup is more
flexible since the menus are more standard and easier to customize.
In the few ways we customized the node search items before, this gives
us the same results as before. Overall the searching is less flexible,
but I think that is just a tradeoff we have to accept for the simplicity
of searching menus. In the future menus could be made more dynamic,
with each builtin node's menu path stored on the node type, similar to
assets. That might be a nice compromise. In the meantime this code
is just dead weight.
Pull Request: https://projects.blender.org/blender/blender/pulls/112056
This was noted in code comments and checked in Python documentation
generation but not at build time.
Since these enums are identifiers that end up included in various places
enforce the `rna_enum_*_items` convention which was noted as
the convention but not followed strictly.
Partially reverts [0], avoids having to deal with multiple prefix types.
[0]: 3ea7117ed1
This PR adds an initial set of nodes using the new rotation socket.
6 nodes build rotations or convert them to other formats, a 7th rotates
a vector with a rotation, and the last inverts rotations.
The design task #109965 describes the choice to use separate nodes
for the rotation construction and separation operations. In the future,
a "Switch Node" operator (#111438) will help to make working with
these separated nodes faster.
- **Axis Angle to Rotation**
- **Rotation to Axis Angle**
- **Combine Quaternion**
- **Separate Quaternion**
- **Euler to Rotation**
- **Rotation to Euler**
- **Rotate Vector**
- **Invert Rotation**
See #92967
Pull Request: https://projects.blender.org/blender/blender/pulls/109030
This commit allows both `rna_enum_` and `rna_node_`to be used for enum prefixes
This also fixes one enum by adding `rna_` to the prefix.
Together these changes fix the API documentation generation.
