In geometry nodes, the viewer gets activated by clicking on the preview icon. For the compositor, preview is enabled either using the image viewer or the backdrop.
Another difference is that all nodes can be previewed in the compositor. Which makes the preview icon on the composite and viewer node redundant.
Pull Request: https://projects.blender.org/blender/blender/pulls/127044
This exposes warnings that are propagated to the modifier in the Python API.
This allows people to show these warnings in custom UIs for their node groups.
Warnings are accessed like this:
```python
for warning in modifier.node_warnings:
print(warning.message)
print(warning.type)
```
Note that this only works on the geometry nodes modifier. These warnings may
be extended with more information in the future. E.g. it could be useful to know
which node created the warning.
Pull Request: https://projects.blender.org/blender/blender/pulls/127193
This introduces the concept of an #AttributeFilter. It's used to tell a geometry
algorithm which attributes it should process/propagate and which can be ignored.
We already had something similar before named
`AnonymousAttributePropagationInfo`. However, as the name implies, this was
specific to anonymous attributes. This had some downsides:
* A lot of code had to be aware of the concept of anonymous attributes even if
it did nothing special with anonymous attributes.
* For non-anonymous attributes we often had a separate `Set<std::string> skip`
parameter. It's not nice to have to pass two kinds of filters around and to
have to construct a `Set<std::string>` in many cases.
`AttributeFilter` solves both of these downsides.
Technically, `AttributeFilter` could also just be a `FunctionRef<bool(StringRef
attribute_name)>`, but that also has some issues:
* The `bool` return value is often ambiguous, i.e. it's not clear if it means
that the attribute should be processed or not. Using an enum works better.
* Passing function refs around and combining them works, but can very easily
lead to dangling references.
* The default value of a `FunctionRef` is "empty", i.e. it can't be called. It's
generally more nice to not have a special case for the default value. Now the
default `AttributeFilter` propagates all attributes without any extra handling
on the call-site.
Pull Request: https://projects.blender.org/blender/blender/pulls/127155
Previously, the `AttributeIDRef` wrapper was needed because it also had to
contain a pointer to an `AnonymousAttributeID`. However, since
b279a6d703 this is not necessary anymore.
Therefore we can use "raw" `StringRef` now which reduces the mental overhead
when working with attributes and also simplifies code.
Pull Request: https://projects.blender.org/blender/blender/pulls/127140
In some cases when there are no faces there are no corner domain
topology attributes. Though this could be changed theoretically,
it's simpler to just make sure they exist in the few places we resize
a mesh rather than creating a new one from scratch.
This removes `AnonymousAttributeID` which was "attached" to every anonymous
attribute before. It adds more complexity than is justified for its
functionality.
It was originally introduced to keep the reference count of the anonymous
attribute so that it can be deleted automatically when the attribute is not
referenced anymore. For quite some time we have had deterministic attribute
life-times though which don't rely on the reference count anymore.
Anonymous attributes are sometimes shown in the UI as "friendly looking" string
like `"UV Map" from Cube`. Some information necessary for this was also stored
in `AnonymousAttributeID`. However, this can also be solved differently.
Specifically, this functionality has now been added directly to
`AttributeFieldInput`.
This refactor also allows removing `AttributeIDRef` which was mainly introduced
because we had to keep the `AnonymousAttributeID` attached with the attribute
name. Just using simple string types to identify attributes can reduce the
mental overhead quite significantly. This will be done as a separate refactor
though.
Pull Request: https://projects.blender.org/blender/blender/pulls/127081
The Lens Distort node is different between CPU and GPU when jitter is
enabled. That's because GPU incorrectly assumed that jitter with no
dispersion would have no effect. So we fix this by adjusting the
identity condition.
Further more, the green channel was not jittered for the GPU, that's
because the jitter was only seeded by the integration steps and was thus
constant for all channels. And since the green channel is the result of
addition of two opposite accumulations, the green channel was left
unaltered. To fix this, we include the start channel of the integration
in the seed to the jitter to make sure different channels get different
jitter.
Pull Request: https://projects.blender.org/blender/blender/pulls/126993
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
Previously, all errors, warnings and info messages were propagated from the node
that generates it to the top level node group. This is a good default, but may
not always be desirable. For example, someone may build a node group asset that
generates some warning that is irrelevant to the user to the asset. Now, the
asset author can selectively disable propagating warnings from that node.
Each node has a new `Warning Propagation` setting. It controls if warnings from
this node should be propagated to the parent group node. By default, everything
is propagated. One can also choose to propagate nothing, only errors or only
errors and warnings.
Note, this does not affect whether the warning is shown in the node itself, only
if the warning is propagated one level up!
Pull Request: https://projects.blender.org/blender/blender/pulls/126786
This implements the `Warning` node that allows node groups to communicate
expectations about input values to the user.
By default, the `Warning` node is only evaluated if the node group that contains
it is evaluated in any way. This is better than always evaluating it, because
that could trigger lots of unnecessary evaluation in parts of the potentially
large node tree which should be ignored. In this basic mode, the output of the
node should not be connected to anything and it must not be in a zone.
For more fine-grained control for when the `Warning` node should be evaluated,
one can use the boolean output which is just a pass-through of the `Show` input.
If this output is used, the `Warning` node will only be evaluated if its output
is used. A simple way to use it is to control a Switch node with it that e.g.
"disables" a specific output when the inputs are invalid. In this case, the
`Warning` node may also be in a zone.
The node allows the user to choose between 3 severity levels: Error, Warning and
Info. Those are the same levels that we use internally. Currently, the error and
warning mode are pretty much the same, but that may change in the future.
Pull Request: https://projects.blender.org/blender/blender/pulls/125544
Add Metallic BSDF Node to the shader editor.
This node can primarily be used to create more realistic looking
metallic materials than the existing Glossy BSDF node.
This commit does not add any new closures to Cycles, it simply exposes
existing closures that were previous hard to access on their own.
- Exposes the F82 fresnel type that is currently used by the
metallic component of the Principled BSDF. Results should match
between the Metallic BSDF and Principled BSDF when using the same
settings.
- Exposes the Physical Conductor fresnel type that was previously
limited to custom OSL scripts. The Conductor fresnel type accepts
IOR and Extinction coefficients to define the appearance of the
material based off real life measurements.
EEVEE only supports the F82 fresnel type with internal code to convert
the the physical conductor inputs in to a colour format for F82,
which can lead to noticeable rendering differences with
some configurations.
Pull Request: https://projects.blender.org/blender/blender/pulls/114958
Ever since Blender 4.0 when the Principled BSDF was updated to
generally match the OpenPBR standard, it hadn't supported negative
specular ansiostropy.
Update the Principled BSDF tooltip to match this change.
Pull Request: https://projects.blender.org/blender/blender/pulls/126644
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 patch supports the viewer node in the new CPU compositor. To do
that, the context viewer output mechanism was refactored to allow CPU
storage by utilizing the result class as opposed to a GPU texture.
Just turn on the option for geometry nodes where attributes are
generally expected to be used. We could expose this and other
options at some point too but that requires a bit more thought.
This patch adds support for CPU side buffers for the result class. A new
storage type member was added to identify the type of buffer storage,
and allocation will either allocate a GPU texture or a CPU buffer based
on the context's GPU usage.
This patch allows the result to be allocated using new textures as
opposed to using pooled texture. This is useful to allow the result
class to be used for persistent data like cached resources which can't
be pooled since it spans multiple evaluations.
This adds the ability to customize the default width of a group node that's
created for a node group. This feature works towards the goal of unifying the
features available to built-in nodes and node groups. We often customize the
width of built-in nodes from them to looks slightly better (e.g. to avoid
cut-off labels).
Pull Request: https://projects.blender.org/blender/blender/pulls/126054
When a curve instance did not have a "opacity" attribute, the default would be 0.
This meant that when creating Grease Pencil layers from scratch, the user
would need to manually write a "opacity" attribute.
Now the default value is 1, so that this step is no longer necessary.
Previously, values for `ID.flag` and `ID.tag` used the prefixes `LIB_` and
`LIB_TAG` respectively. This was somewhat confusing because it's not really
related to libraries in general. This patch changes the prefix to `ID_FLAG_` and
`ID_TAG_`. This makes it more obvious what they correspond to, simplifying code.
Pull Request: https://projects.blender.org/blender/blender/pulls/125811
Temporary results are essentially results with a default reference count
of 1, so we default to 1 for all results and set the initial reference
count differently as need.
The specialized code for converting grease pencil layer attributes to
instance attributes was accessing the instance component without check.
This _should_ work because the component is explicitly created, but
still fails for empty grease pencil data, because the
`get_component_ptr` function checks if the component is "empty" as well
(zero instances).
Pull Request: https://projects.blender.org/blender/blender/pulls/125887
The File Output node doesn't provide an option to save byte formats like
PNG in a space that is not sRGB. This is problematic for data images
like normal maps, which need to be saved as non-color.
This patch adds a Color Space option to the File Output node to allows
users to override the assumed color space. This also adds a new global
Save As Render option that is used if Use Node Format is enabled.
Pull Request: https://projects.blender.org/blender/blender/pulls/124238
Bake nodes are not supported in a repeat zone. They used to just output
default values when used in a repeat zone, but now they just pass-through
the inputs like an unbaked bake node would.
This makes the behavior more like one would expect when using the same
node group in and outside of a repeat zone that happens to have a bake
node inside (which is not even used).
The newly added viewport compositor was missing a try-catch guard around
the OCIO `getProcessor` call. All prior call sites were protected except
this one. Unhandled exceptions can occur if the user tries to use a
colorspace config that is not present in their OCIO configuration.
The surrounding code paths need some work in order to not crash at a
later point, which would also impact builds with no OCIO support at all.
In the case of no OCIO support at all, a warning label is placed on the
node as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/125526
This shouldn't make any difference right now, because the main inputs
and outputs of a group always come first. But it's better to not rely on that
here if it can be avoided.
