This patch adds an `Integer` type to the Value to String node.
This allows for converting integer inputs into string outputs without
any loss of precision. Something which the original implementation is
not able to do.
This issue becomes evident at values greater than `2 ^ 24` or
`16,777,216`, where the precision loss is high enough that the float
implementation starts skipping certain integers.
Pull Request: https://projects.blender.org/blender/blender/pulls/128362
The additional division modes were implemented with float
division then rounding to match float > int conversion in
existing float to int node.
As pointed out in the bug report the precision here is limited.
This patch replaces the float division with integer math which
increases the precision to much higher numbers.
Divide Round by due to the way it is calculated has less precision
than Divide Floor and Divide Ceil.
Pull Request: https://projects.blender.org/blender/blender/pulls/128123
This makes the input field much wider. I enabled this for most string sockets
except for a few where it is important to see the label even if the user has
inserted a string already (usually because there is more than one string input).
Pull Request: https://projects.blender.org/blender/blender/pulls/127992
Provide building block support for integer operations.
Manipulation of integer based data should not be limited to using float math nodes.
Using float math comes with accuracy issues for larger integers and requires unnecessary
type conversions.
The node also adds some integer specific operations like GCM and LCD.
Pull Request: https://projects.blender.org/blender/blender/pulls/110735
This node hashes various types into an integer. Note that hashes
cannot generally used as unique identifiers because they are not
guaranteed to be unique. It can be used to generate somewhat
stable randomness though in cases where White Noise does not
offer enough flexibility.
It uses hash functions from BLI_noise.hh. These are also used in
the White Noise node.
Pull Request: https://projects.blender.org/blender/blender/pulls/110769
Use snake style naming for all the kernel nodes functions.
Omit kernel prefix in the names since of the using namespace.
Use full forms of the terms
('iter' -> 'iterator', 'ntree' -> 'node_tree', 'rem' -> 'remove', ...).
Pull Request: https://projects.blender.org/blender/blender/pulls/126416
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
