Effectively, make GPU compositor available without need to enable
an experimental feature set.
The compositor device is now exposed in the Performance panel of
Render Buttons. It is also still available in the compositor's
N-panel, together with some other options which are more about how
editing works, and not exactly related to render performance.
Pull Request: https://projects.blender.org/blender/blender/pulls/121398
Reorganizes (and in some cases add missing operators to) all 'Select'
menus in all editors except 3D Viewport (done in a separate patch).
The goal of this change is to make menus as consistent as possible, and
to group & sort items according to a certain logic, which should be easy to
remember and users can always expect certain items to be always at same
place in every editor.
More details and images in the pull request.
Pull Request: https://projects.blender.org/blender/blender/pulls/121337
This allows to expose these settings in the Performance panel in the
render buttons. Also moves compositor-specific options away from the
generic node tree structure.
For the backwards-compatibility the options are still present in the
DNA for the bNodeTree. This is to minimize the impact on the Studio
which has used the GPU compositor for a while now. They can be
removed in a future release.
There is no functional changes expected.
Pull Request: https://projects.blender.org/blender/blender/pulls/121583
EEVEE-Next world volume are infinite like Cycles. EEVEE-Classic world volumes
end at the clip_end of the camera/viewport. This can lead to confusion as
it would render different then expected.
This PR adds an operator to convert a world volume into a mesh volume. The
operator can be found in the shader editor (world mode) and in the properties
panel/World/Volume.
**Why an operator?**
As this alters the content of the scene we want the artist to be in control of
the conversion. Doing it automatic lead to a lot of complexity and cases that
might not be expected by the user.
Pull Request: https://projects.blender.org/blender/blender/pulls/119734
This allows setting a color tag for node groups which affects the header
color of group nodes. With this, node groups can look even more similar
to built-in nodes. The only remaining difference is the node group icon in
the node header.
Blender has quite a few different built-in color tags. Most of those are
exposed with very few exceptions. For example, the layout, interface
and pattern categories are not exposed because they are only for built-in
nodes or are not used anymore.
It's generally agreed upon that the set of different color tags is likely too
large. Some differences between color make more sense in some contexts
than in others. In the interest of consistency, it was decided to expose all
these categories anyway. If we ever decide to consolidate them, the worst
that can happen is that a group looses it's category, which wouldn't be too bad.
Pull Request: https://projects.blender.org/blender/blender/pulls/121385
The initial motivation for this came from #121334, because now there
are two description inputs which look very alike and not's not obvious
at a glance where they belong to. Additionally, I find myself sometimes
looking for node properties in the group properties panel because of the same panel name.
This patch does the following changes to improve the situation:
* Reorder the node group properties and socket interface panel.
* Rename `Properties` panel to `Group` (similar to `Node` in the corresponding tab).
* Rename the `Interface` panel to `Group Sockets`.
* Add a `Name` field for the node group. This makes it even more obvious that
one is looking at the group properties. Also it makes it possible to rename
the group without having to go up one level to change the name in the group node.
* New layout-panel for the different usages. This only exists for geometry nodes.
Pull Request: https://projects.blender.org/blender/blender/pulls/121564
It was meant to be included into the previous commit in the area,
but was forgotten due to some technicalities.
Also remove the DisplaceSimpleOperation, which is now not used.
Pull Request: https://projects.blender.org/blender/blender/pulls/121580
There are few issues with the logic and implementation of this option:
- While the first pass is faster in the terms of a wall-clock time, it
is often not giving usable results to artists, as the final look of
the result is so much different from what it is expected to be.
- It is not supported by the GPU compositor.
- It is based on some static rules based on the node type, rather than
on the apparent computational complexity.
The performance settings are planned to be moved to the RenderData, and
it is unideal to carry on such limited functionality to more places. There
are better approaches to quickly provide approximated results, which we can
look into later.
Pull Request: https://projects.blender.org/blender/blender/pulls/121558
This allows node groups to have a description that is shown in the add menu
or when hovering over the node header.
This new description is stored in `bNodeTree.description`. Unfortunately, it
conflicts a bit with `ID.asset_data.description`. The difference is that the latter
only exists for assets. However, it makes sense for node groups to have
descriptions even if they are not assets (just like `static` functions in C++ should
also be able to have comments). In some cases, node groups are also generated
by addons for a specific purpose. Those should still have a description without
being reusable to make it easier to understand for users.
The solution here is to use the asset description if the node group is an asset,
and to use `bNodeTree.description` otherwise. The description is synced
automatically when marking or clearing assets.
A side benefit of this solution is that appended node group assets can keep their
description, which is currently always lost.
Pull Request: https://projects.blender.org/blender/blender/pulls/121334
This changes the menu switch socket to use the socket-items system
(`NOD_socket_items.hh`) that is already used by the simulation zone, repeat
zone, bake node and index switch node. By using this system, the per-node
boilerplate can be removed significantly. This is especially important as we
plan to have dynamic socket amounts in more nodes in the future.
There are some user visible changes which make the node more consistent with
others:
* Move the menu items list into the properties panel as in 0c585a1b8a.
* Add an extend socket.
* Duplicating a menu item keeps the name of the old one.
There is also a (backward compatible) change in the Python API: It's now
possible to directly access `node.enum_items` and `node.active_index` instead of
having to use `node.enum_definition.enum_items`. This is consistent with the
other nodes. For backward compatibility, `node.enum_definition` still exists,
but simply returns the node itself.
Many API functions from `NodeEnumDefinition` like
`NodeEnumDefinition::remove_item` have been removed. Those are not used anymore
and are unnecessary boilerplate. If ever necessary, they can be implemented back
in terms of the socket-items system.
The socket-items system had to be extended a little bit to support the case for
the menu switch node where each socket item has a name but no type. Previously,
there was the case without name and type in the index switch node, and the case
with both in the bake node and zones. The system was trivial to extend to this
case.
Pull Request: https://projects.blender.org/blender/blender/pulls/121234
This has some benefits:
* Nodes with dynamic socket amounts can remain more self-contained
(2 fewer files to edit with this patch).
* It's easier to reuse existing C++ code, reducing redundancy.
One new thing I'm doing here is to define operators in node files. It seems
reasonable to register operators that belong to a node together with that
node. Without this, code spreads out further than necessary without any real benefit.
This patch affects the simulation zone, repeat zone, bake node and index switch node.
The UI is slightly affected too. Since we had the UI defined in Python before,
it wasn't possible to integrate it into the node properties panel. That is possible
now and looks better anyway. The previous UI was an artifact of technical limitations.
Pull Request: https://projects.blender.org/blender/blender/pulls/121178
Part of modernizing scripts in Blender, where the previous convention
was to use percentage formatting which has become the "old" way to
format strings in Python.
See proposal for details #120453.
Ref !120552
Add a "Mouse Position" node that outputs the location of the mouse
cursor in region space and the overall size of the region, both in pixel
units. Both outputs are integers to help reflect their pixel units.
If there the mouse position is ever accessible in sub-pixels, they can
easily be changed to floats.
Also add a "Wait for Cursor" option similar to the one for some built-in
operators that delay's the operator's execution until there is a mouse
click in the viewport. That way the operator can be called from menus
even though it is interactive. This option is placed in the node editor
header. When there are more options, it will be part of an "Options"
popover panel similar to the existing "Modes" and "types" popovers.
Combined with the viewport transform node, and other nodes like Raycast,
these features can allow making tools that create geometry where you
click in the scene.
Pull Request: https://projects.blender.org/blender/blender/pulls/121043
The tiled compositor code is mainly still around, which is only
expected to be a short-lived period. Eventually it will also be
removed.
The OpenCL, Group Buffers, and Chunk size options are already removed.
Pull Request: https://projects.blender.org/blender/blender/pulls/118010
Visually it is the same as the execution time implemented for the
geometry nodes, and it is to be enabled in the overlay popover.
The implementation is separate from the geometry nodes, as it is
not easy or practical to re-use the geometry nodes implementation.
The execution time is stored in a run-time hash, indexed by a node
instance key. This is similar to the storage of the mode preview
images, but is stored on the scene runtime data and not on the node
tree. Indexing the storage by key allows to easily copy execution
statistics from localized tree to its original version.
The time is only implemented for full-frame compositor, as for the
tiled compositor it could be tricky to calculate reliable time for
pixel processing nodes which process one pixel at a time.
Pull Request: https://projects.blender.org/blender/blender/pulls/117885
This patch adds support for _Menu Switch_ nodes and enum definitions in
node trees more generally. The design is based on the outcome of the
[2022 Nodes Workshop](https://code.blender.org/2022/11/geometry-nodes-workshop-2022/#menu-switch).
The _Menu Switch_ node is an advanced version of the _Switch_ node which
has a customizable **menu input socket** instead of a simple boolean.
The _items_ of this menu are owned by the node itself. Each item has a
name and description and unique identifier that is used internally. A
menu _socket_ represents a concrete value out of the list of items.
To enable selection of an enum value for unconnected sockets the menu is
presented as a dropdown list like built-in enums. When the socket is
connected a shared pointer to the enum definition is propagated along
links and stored in socket default values. This allows node groups to
expose a menu from an internal menu switch as a parameter. The enum
definition is a runtime copy of the enum items in DNA that allows
sharing.
A menu socket can have multiple connections, which can lead to
ambiguity. If two or more different menu source nodes are connected to a
socket it gets marked as _undefined_. Any connection to an undefined
menu socket is invalid as a hint to users that there is a problem. A
warning/error is also shown on nodes with undefined menu sockets.
At runtime the value of a menu socket is the simple integer identifier.
This can also be a field in geometry nodes. The identifier is unique
within each enum definition, and it is persistent even when items are
added, removed, or changed. Changing the name of an item does not affect
the internal identifier, so users can rename enum items without breaking
existing input values. This also persists if, for example, a linked node
group is temporarily unavailable.
Pull Request: https://projects.blender.org/blender/blender/pulls/113445
In 13fac109 the node panels got support for individual option button
callbacks, but these were not included in the node editor side bar.
Only the older top-level buttons are drawn there.
The panel structure is currently not accessible in python since it is
part of the `NodeDeclaration` system. To draw node input sockets and
buttons in the correct panel order as they appear on the node, a new
template function `uiTemplateNodeInputs` has been added. This iterates
over declared panels and their contents in the appropriate order and
draws the buttons before sockets in the same panel.
Pull Request: https://projects.blender.org/blender/blender/pulls/116936
This adds a new `Bake` node which allows saving and loading intermediate geometries.
Typical use cases we want address with this currently are:
* Bake some data for use with a render engine.
* Bake parts of the node tree explicitly for better performance.
For now, the format that is written to disk is not considered to be an import/export format.
It's not guaranteed that data written with one Blender version can be read by another
Blender version. For that it's better to use proper interchange formats. Better support for
those will be added eventually as well. We also plan an `Import Bake` node that allows
reading the blender-specific baked data independent of the Bake node and at different frames.
The baking works very similar to the baking in the simulation zone (UI and implementation
wise). Major differences are:
* The Bake node has a `Bake Still` and `Bake Animation` mode.
* The Bake node doesn't do automatic caching.
Implementation details:
* Refactored how we create the Python operators for moving socket items so that it also
makes sense for non-zones.
* The `ModifierCache` stores an independent map of `SimulationNodeCache` and
`BakeNodeCache`, but both share a common data structure for the actually baked data.
* For baking, the `Bake` node is added as a side-effect-node in the modifier. This will make
sure that the node is baked even if it's currently not connected to the output.
* Had to add a new `DEG_id_tag_update_for_side_effect_request` function that is used
during baking. It's necessary because I want to evaluate the object again even though none
of its inputs changed. The reevaluation is necessary to create the baked data. Using
`DEG_id_tag_update` technically works as well, but has the problem that it also uses the
`DEG_UPDATE_SOURCE_USER_EDIT` flag which (rightly) invalidates simulation caches
which shouldn't happen here.
* Slightly refactored the timeline drawing so that it can also show the baked ranges of
Bake nodes. It does not show anything for baked nodes with a in Still mode though.
* The bake operator is refactored to bake a list of `NodeBakeRequest` which makes the
code easier to follow compared to the previous nested
`ObjectBakeData > ModifierBakeData > NodeBakeData` data structure.
* The bake operators are disabled when the .blend file is not yet saved. This is technically
only necessary when the bake path depends on the .blend file path but seems ok to force
the user anyway (otherwise the bake path may be lost as well if it's set explicitly).
* The same operators are used to bake and delete single bakes in `Bake` nodes and
`Simulation Zones`. On top of that, there are separate operators of baking and deleting all
simulation bakes (those ignore bake nodes).
* The `Bake` node remembers which inputs have been fields and thus may be baked as attributes.
For that it uses an `Is Attribute` flag on the socket item. This is needed because the baked data
may still contain attribute data, even if the inputs to the bake node are disconnected.
* Similar to simulation zones, the behavior of `Bake` nodes is passed into the geometry nodes
evaluation from the outside (from the modifier only currently). This is done by providing the
new `GeoNodesBakeParams` in `GeoNodesCallData` when executing geometry nodes.
Next Steps (mostly because they also involve simulations):
* Visualize nodes that have not been evaluated in the last evaluation.
* Fix issue with seemingly loosing baked data after undo.
* Improve error handling when baked data is not found.
* Show bake node in link drag search.
* Higher level tools for managing bakes.
Pull Request: https://projects.blender.org/blender/blender/pulls/115466
Add an "Index Switch" node which is meant as a simpler version of
the "Menu Switch" from #113445 that doesn't allow naming items
or displaying them in a dropdown, but still allows choosing between
an arbitrary number of items, unlike the regular "Switch" node.
Even when the Menu Switch is included (which should be in the
same release as this), it may still be helpful to have explicit mapping
of indices, and a fair amount of the internals can be shared anyway.
Pull Request: https://projects.blender.org/blender/blender/pulls/115250
Extend node tools to display tool assets in object mode as well
as edit and sculpt modes. For consistency with existing Blender
design, selection cannot be set and is just "true" in object mode
because it can't be visualized. The visibility of tools can be
customized per object type in object mode as well.
See #101778
Pull Request: https://projects.blender.org/blender/blender/pulls/114819
This patch adds support for full precision compositing for the Realtime
Compositor. A new precision option was added to the compositor to change
between half and full precision compositing, where the Auto option uses
half for the viewport compositor and the interactive render compositor,
while full is used for final renders.
The compositor context now need to implement the get_precision() method
to indicate its preferred precision. Intermediate results will be stored
using the context's precision, with a number of exceptions that can use
a different precision regardless of the context's precision. For
instance, summed area tables are always stored in full float results
even if the context specified half float. Conversely, jump flooding
tables are always stored in half integer results even if the context
specified full. The former requires full float while the latter has no
use for it.
Since shaders are created for a specific precision, we need two variants
of each compositor shader to account for the context's possible
precision. However, to avoid doubling the shader info count and reduce
boilerplate code and development time, an automated mechanism was
employed. A single shader info of whatever precision needs to be added,
then, at runtime, the shader info can be adjusted to change the
precision of the outputs. That shader variant is then cached in the
static cache manager for future processing-free shader retrieval.
Therefore, the shader manager was removed in favor of a cached shader
container in the static cache manager.
A number of utilities were added to make the creation of results as well as
the retrieval of shader with the target precision easier. Further, a
number of precision-specific shaders were removed in favor of more
generic ones that utilizes the aforementioned shader retrieval
mechanism.
Pull Request: https://projects.blender.org/blender/blender/pulls/113476
Labels in popover menus are always darker. That made the popovers for
Type and Modes to have a way too dark color. Specially when the values
were off.
This commit mimics what we do in the viewport Selectability &
Visibility menu. Basically we don't gray out the labels even if the
values are off.
Co-authored by: Hans Goudey <hans@blender.org>
Use "Hair Curves" instead of just curves, to clarify that it's just the
new curves system that's supported, not the legacy one. When the
old one is removed, the label will be changed to just say "Curves"
again.
Continue allowing spacebar search for all dropdown and context menus,
but also add the ability to allow some menus to have type to search,
like Add Modifiers, Objects, Nodes.
Pull Request: https://projects.blender.org/blender/blender/pulls/113520
Previously, it was only possible to inspect the data from the first iteration. That
applied to both, the viewer node as well as socket inspection. Now, there is a
new `Inspection Index` setting in the zone properties. It specifies which iteration
should be used by the inspection features.
In theory we could support features like counting the index from the end, but
that can be done separately as well, as it likely requires more UI.
Pull Request: https://projects.blender.org/blender/blender/pulls/112818
Node tools are no longer required to be assets, and they aren't assets
by default anymore. Non-assets don't have catalogs for header menu
organization, so they are only exposed in the "Unassigned" menu, which
is now just an icon so it takes less spac, makes the connection to the
asset browser, and signals more that it's not the "final" place for a
tool. Tool node groups have fake user set by default, since they don't
have users. The "Is Tool" status of a node group is configurable in the
editor N-panel, just like the modifier status.
This is similar to af3461c387, and has the same check for
whether a node group is "local."
Any geometry node group with the "Is Modifier" tag is exposed in the add
modifier menu. Local node groups that aren't assets are displayed in a
subsection of the "Unassigned" menu, as they are "asset wannabees"
that function similarly but aren't shared to other files.
Only modifier node groups can be assigned to the geometry nodes
modifier. Because of this, existing node groups are versioned to have
the tag if they have a geometry output.
Internally, this means the operator that used to only handle node group
assets has to also add local geometry node groups. That change isn't
so large though. The other changes are just UI, or changes to the
node group property poll functions.
Note: For assets, saving the file to generate asset meta-data may be
necessary for the versioning to affect the add modifier menu.
Pull Request: https://projects.blender.org/blender/blender/pulls/112918
