Color to grayscale conversions should take into account the colorspace,
and these are considered to be in scene linear colorspace.
No change with the default configuration.
Pull Request: https://projects.blender.org/blender/blender/pulls/133368
This makes specifying a legacy type for new node types optional (e.g.
`GEO_NODE_MESH_TO_CURVE`). Instead, only the `idname` is used as a stable
identifier for node types. So there is less redundancy for now.
This change helps with the decentralized definition of nodes and reduces the
number minimum number of files that need to be changed for a new node from 5 to
4. It especially helps when multiple nodes are worked on at the same time,
because the legacy type definition was very prone to have merge conflicts.
For compatibility reasons and because it's still used by existing code, the
`legacy_type` is not removed. All existing nodes keep their current
`legacy_type`. New nodes will receive an auto-incremented legacy type. It's
still necessary to give nodes unique legacy types, because some code checks if
two nodes have the same type by comparing their `legacy_type`. These types only
have to be unique at run-time though. Some randomness is used to avoid depending
on stable generated legacy types accidentally.
Pull Request: https://projects.blender.org/blender/blender/pulls/133044
This removes the second to last usage of `NOD_static_types.hh` which we intend
to remove. A nice benefit is that the idname is now finally more explicit when a
node is registered. Previously it was difficult to search for the definition of
a node in the code when one had only the idname, which is the main identifier
for nodes.
The main change is in `node_type_base`.
Pull Request: https://projects.blender.org/blender/blender/pulls/132815
As part of an effort to remove this header, reducing the need for macro/
include magic and making node definitions more independent, move
the node UI name and description definitions to each node's file.
The UI name, description, and idname are also moved to std::string
instead of char arrays.
Similar to b43e2168e3.
Pull Request: https://projects.blender.org/blender/blender/pulls/132708
This caused build errors on the docs builder, I can't seem to reproduce
locally, so revert for now and have another look at some point in the
future.
Sadly as these changes usually go, this took 5c515e26bb and
2f0fc7fc9f with it as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/132559
Add a node that finds the number of times a substring occurs in a string,
and the position of the start of the first match.
See the PR description for more rational and details.
Pull Request: https://projects.blender.org/blender/blender/pulls/129270
A followup for 5e7f3e5c84.
Make the NOD_static_types.h file less important by moving `enum_name_legacy`
to be defined in the register function of every node. This helps our gradual transition
away from this file.
Also add a fallback to the node idname so that newly added nodes no longer need
to define the string value.
Pull Request: https://projects.blender.org/blender/blender/pulls/132131
- Gives O(1) access to string length in more cases
- Convenient string manipulation functions
- Clarify difference between "no string" and "empty string"
- Avoid the need for raw pointers in the API
- Shows which API string arguments are optional
Pull Request: https://projects.blender.org/blender/blender/pulls/131473
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
