The goal is to get to closer to removing `NOD_static_types.h` and to define all/most
aspects of a node in the node file itself instead. Data defined in node files is not
available when rna structs are created currently, because that happens in a preprocessing
step. This patch moves part of what was defined in `rna_nodetree.cc` to `node.cc` which
makes it easier to replace when `NOD_static_types.h` is removed.
Pull Request: https://projects.blender.org/blender/blender/pulls/110824
- Rename find_area_showing_r_result -> *find_area_showing_render_result.
- Only set the return window argument when the render area is found
instead of leaving this value set to the last window.
- Use doxygen sections.
The overall goal is to get rid of `NOD_static_types.h`. This patch removes
one usage of it to generate the `node.type` rna enum. Not all of the data
was available on `bNodeType` already, so I had to add the missing data there.
Pull Request: https://projects.blender.org/blender/blender/pulls/110810
Add three new nodes for operations and inputs specific to
node group operators.
- **Selection** Whether elements are selected in the viewport
- **Set Selection** Sets the edit/sculpt selection, on the point,
face, or curve domains
- **3D Cursor** Gives the location and rotation of the 3D cursor,
in the local space of the modified object.
- **Face Set** The face set value from mesh sculpt mode,
and whether the attribute exists.
- **Set Face Set** Set sculpt face set values.
In the add menu and search, the nodes are only visible in the
"Tool" context of the geometry node editor. They also give
errors when executed by a modifier.
Pull Request: https://projects.blender.org/blender/blender/pulls/109517
This function is used to retrieve the index of the n'th layer of
the specified type, if it exists. Currently the way it handles
an n value that is too big is inconsistent: if there are more
layers of different types following the ones of the correct type,
and n isn't too big, it will safely detect that the corresponding
layer is of a different type and return -1. However, if the value
results in a buffer overrun, it causes an assertion or crash.
This means that safe code should currently ensure n is always
correct, making the type check in this function pointless.
Moreover, checking the range in the caller may incur more
overhead than making this code safe.
This changes the assert into a check to ensure consistent behavior.
Pull Request: https://projects.blender.org/blender/blender/pulls/110812
- Use threadsafe normal computation (will be improved more in #93551)
- Copy data directly instead of loops when format is the same
- Use bke::CurvesGeometry wrapper and attribute API
- Avoid `push_back` when size is known ahead of time
Previously, simulation nodes would output default values when there is no
current simulation state and nothing should be computed. Now, the data is
just passed through which is usually less confusing.
Pull Request: https://projects.blender.org/blender/blender/pulls/110800
There were a bunch of duplicated usages of `NOD_static_types.h` in
`rna_nodetree.cc`. This patch reduces the duplication, making it easier
to reason about what is going on.
Pull Request: https://projects.blender.org/blender/blender/pulls/110805
Add support in the UI for the edit mode of curves, mesh, and point
cloud objects. It's possible to control for which mode sand object
types the asset is available with a dropdown in the node header.
To make this per-mode filtering possible, the static asset tree
cache is now unique per context mode.
See #101778
Pull Request: https://projects.blender.org/blender/blender/pulls/109526
The eventual goal is to get rid of `NOD_static_types.h` because that data should
be decentralized so that nodes can be more self-contained.
The switch cases are based on the state of `NOD_static_types.h` when the
versioning code was introduced in 4638e5f99a.
Pull Request: https://projects.blender.org/blender/blender/pulls/110804
This is currently meant mainly for testing, when "Developer Extras" is
enabled. The goal is to make interactive Hydra export and USD file export
identical. We are not there yet, and having the ability to compare both
in the viewport and automated tests should help us get and stay there.
Ref #110765
Hydra is a rendering architecture part of USD, designed to abstract the
host application from the renderer. A renderer implementing a Hydra
render delegate can run in any host application supporting Hydra, which
now includes Blender.
For external renderers this means less code to be written, and improved
performance due to a using a C++ API instead of a Python API.
Add-ons need to subclass bpy.types.HydraRenderEngine. See the example in
the Python API docs for details.
An add-on for Hydra Storm will be included as well. This is USD's
rasterizing renderer, used in other applications like usdview. For users
it can provide a preview of USD file export, and for developers it
serves a reference.
There are still limitations and missing features, especially around
materials. The remaining to do items are tracked in #110765.
This feature was contributed by AMD.
Ref #110765
Co-authored-by: Georgiy Markelov <georgiy.m.markelov@gmail.com>
Co-authored-by: Vasyl-Pidhirskyi <vpidhirskyi@gmail.com>
Co-authored-by: Brian Savery <brian.savery@gmail.com>
Co-authored-by: Brecht Van Lommel <brecht@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/104712
The simulation used to reset when the previously computed frame is the
same as the current one. However, in this case the output should just be
the same as in the previous computation.
Pull Request: https://projects.blender.org/blender/blender/pulls/110799
Add sculpt support to EEVEE Next.
It creates a new resource handle for sculpt object, since
BKE_object_boundbox_get returns a wrong (zeroed) bounding box.
This also adds a new `resource_handle` function to the `draw::Manager`
that works like the default one, but lets the caller optionally override the
object matrix and/or bounds.
Pull Request: https://projects.blender.org/blender/blender/pulls/110703
`identifier` should be a better measure than `name` to check if a socket
has the same meaning among different nodes. Sometimes two sockets can
have the same name in the UI but have different (physical) meanings,
they can specify different identifiers to avoid the values being copied
when the nodes are replaced.
Pull Request: https://projects.blender.org/blender/blender/pulls/110792
