The Cryptomatte node makes the UI very slow in Image mode. That's
because the node updates its available Cryptomatte layers on every
redraw, which is a blocking operation that is not very fast.
To fix this, we only update the layers when engine layers change for
the Scene mode, and when image settings change for Image mode.
Pull Request: https://projects.blender.org/blender/blender/pulls/124738
Cryptomatte layer initialization required the active scene to update the
image user frame, but the image user is already updated through other
mechanisms and is thus redundant to do at draw time, so we remove the
frame update call as well as the scene argument from the call chain. The
frame number of the image user is ignored at compositing time in any
case since it is set to the compositing scene frame.
This is needed for #124738.
This commit moves generated `RNA_blender.h`, `RNA_prototype.h` and
`RNA_blender_cpp.h` headers to become C++ header files.
It also removes the now useless `RNA_EXTERN_C` defines, and just
directly use the `extern` keyword. We do not need anymore `extern "C"`
declarations here.
Pull Request: https://projects.blender.org/blender/blender/pulls/124469
This adds a new mode to the Color Balance node, which applies a white point
transformation similar to the one applied in the view transform.
Unlike the view transform, the compositor node allows specifying both the
source and the destination white point for more flexibility. Both default
to the D65 white point, so just leaving the destination alone achieves the
same behavior.
Pull Request: https://projects.blender.org/blender/blender/pulls/124110
The projection was transformed by the object transform, but it's meant
to be in camera space, not affected by the camera view transform or by
the local object's transform. This fix makes viewport raycasting use
cases work without a manual fix in nodes.
Pull Request: https://projects.blender.org/blender/blender/pulls/124610
Currently the node tool operator stores the mouse position from
the first execution because it's not possible to retrieve it again from
the operator redo callback which doesn't have access to the event.
However, other inputs like the region size and the viewport transform
are retrieved again for every redo execution. This creates inconsistency
and generally makes redo less useful for node tools than it should be.
Generally tweaking an input in the redo panel should keep everything
else the same.
This commit adds the rest of the inputs as RNA properties just like
how mouse position is already handled.
Pull Request: https://projects.blender.org/blender/blender/pulls/124557
The vector pass and potentially other vectors that store 4 values are
stored wrongly, in particular, the last channel is ignored. To fix this
we identify if a vector pass is 4D and store the information in the
result meta data, then use this information to either save a 3D or a 4D
pass in the File Output node.
This is a partial fix for the GPU compositor only. The complete fix for
the CPU compositor will be submitted separately as it is not
straightforward and will likely require a refactor.
Pull Request: https://projects.blender.org/blender/blender/pulls/124522
The Cryptomatte layers in the compositor are saved compressed and saved
in half precision in the File Output node. That's because the EXR writer
makes decision about compression and half float based on channel names.
And Cryptomatte are currently saved using RGBA channel names like other
color images.
To fix this, we follow the Cycles convention of using lowercase rgba for
Cryptomatte images, allowing them to be saved without compression and
always in full precision since they are otherwise useless.
Fixes#124208, #87988.
Pull Request: https://projects.blender.org/blender/blender/pulls/124508
This patch adds support for meta data in the GPU compositor much like
the mechanism that already exist in the CPU compositor. Only Cryptomatte
meta data is handled at the moment because that is the only meta data
that the compositor supports.
The is_data member of the result was moved to the meta data structure for
consistency with the CPU compositor.
Fixes#124222.
Pull Request: https://projects.blender.org/blender/blender/pulls/124460
The lazy-function for a logical-or made the wrong assumption that
`try_get_input_data_ptr_or_request` returns null when `try_get_input_data_ptr`
returns null for the same input right before that. That's not true, because the
input might have been computed by another thread in the mean-time.
This wrong assumption lead to a bug because lazy-functions are always assumed to
either request more unavailable inputs, or compute all requested outputs. Here,
the lazy-function did neither. It wanted to request a new input, but it was
available already.
The solution is to handle the return value of
`try_get_input_data_ptr_or_request` properly.
Pull Request: https://projects.blender.org/blender/blender/pulls/124465
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
This addresses #124016. The report provides a scene to test the changes.
Currently, the Blender and MaterialX color spaces are not fully aligned,
but the linear/srgb heuristic should cover most cases however.
Pull Request: https://projects.blender.org/blender/blender/pulls/124315
This adds a new `name` member to the `GeometrySet` class. This name can be set
with the new `Set Geometry Name` node. Currently, the name is only used in the
spreadsheet when displaying instances.
The main purpose of this name is to help debugging in instance trees. However, in the
future it may also be used when exporting instance trees or when creating separate
objects from them.
Note, the name is not expected to be unique, it is fully in user control.
Naming geometries is necessary to make the spreadsheet more useful for instances,
because currently the user has no information for which geometry is used by each instance.
We also want to use this name to improve the integration with grease pencil where
sometimes layers become instances with the same name.
Pull Request: https://projects.blender.org/blender/blender/pulls/114910
Also see 06be295946.
These aren't all cases, but a few that I found by addding a static
assert in `MEM_new` so that it fails for trivially constructible types.
- Sort add menu alphabetically
- Use forward declaration for GeometrySet again
- Use `this->` to access class methods
- Use `MEM_cnew`
- Fix typo
- Pass Span by value
- Pass MutableSpan instead of Vector &
- Remove unnecessary whitespace
- Use `BLI_SCOPED_DEFER` for freeing non-RAII objects
- Use `is_empty()` instead of `size() == 0`
- Use `GeometrySet::from_mesh` ability to handle null argument
Add a node similar to the STL import node (d1455c4138) that
imports OBJ files, including both meshes and curves. The output consists
of a geometry instance for each mesh/curve in the file.
There are a few improvements to address in the future: Currently the node
has no inputs besides the file path. Options may be exposed in the future.
Materials are also not imported yet, because creating material data-blocks
during evaluation may not be trivial.
This is part of a GSoC project:
https://devtalk.blender.org/t/gsoc-2024-geometry-nodes-file-import-nodes/34482
Pull Request: https://projects.blender.org/blender/blender/pulls/123967
Update the description to mention the node is now based on the OpenPBR
model rather than the Disney Principled Model. This has been the
case since Blender 4.0.
Pull Request: https://projects.blender.org/blender/blender/pulls/124209
This patch supports the Cryptomatte picker in the 3D viewport. Instead
of picking a color from the viewport GPU texture, we instead sample the
scene directly to get the object or material under the cursor, then hash
their names to get the Cryptomatte hash value. We do this because the
viewport texture have limited precision, so it can't store the
Cryptomatte hash values.
Additionally, we adjust the Cryptomatte session code to extract the
Cryptomatte manifest from the scene directly, as opposed to the
RenderResult. This is done to make it work even when no RenderResult
exist, as is the case for the viewport compositor, which is needed
especially after #123378.
Pull Request: https://projects.blender.org/blender/blender/pulls/123815
The Bloom mode of the Glare node crashes if the input image is too
small. This is because bloom is computed using a down-sampling followed
by an up-sampling chain, and if the user supplied size is not maximum,
the computed chain length might be zero or negative, which is not
handled gracefully. To fix this, we just sanitize the chain length.
Pull Request: https://projects.blender.org/blender/blender/pulls/124089
Setting this option to a value above zero replaces the lambertian Diffuse term
with the modified energy-preserving Oren-Nayar BSDF, which matches the OpenPBR
behavior.
Pull Request: https://projects.blender.org/blender/blender/pulls/123616
Currently, the Render mode of the GPU Cryptomatte mode extracts the
Cryptomatte layers based on information in the RenderResult of the
scene. This means the node will not work if no RenderResult exists,
which is typically the case for the viewport compositor, and especially
after #123378.
To fix this, we simply acquire the passes directly from the appropriate
view layer based on the node's layer name. The render compositor context
implementation will handle the extraction from the RenderResult, while
the viewport compositor will just return the DRW passes.
Pull Request: https://projects.blender.org/blender/blender/pulls/123817
The goal here is to remove the assumption that multi-inputs will always
have a corresponding node that packs all individual values into a `Vector`
(which is what `LazyFunctionForMultiInput` is doing).
Disambiguate
- "Thickness": use "Material" for EEVEE's thickness material setting.
- "Generated": use "Texture" for texture coordinates, "Image" for
image source, keep default context for animation keyframe types.
Translate
- Split "Online access required to (check for|install) updates..."
into 2x2 messages individually translatable.
- "Geometry" input in bake node.
- "New" for the Palette ID: extract it as part of the
BLT_I18N_MSGID_MULTI_CTXT for "New".
Some issues reported by Gabriel Gazzán and Satoshi Yamasaki.
Pull Request: https://projects.blender.org/blender/blender/pulls/123404
