Switch from Standard Surface to OpenPBR as the exported MaterialX surface,
since this is the new standard more renderers are adopting and it more closely
matches the Principled BSDF implementation.
Anisotropy support is improved though still not quite the same, as formulas
are different. Nodes are generated to apply anisotropic rotation to the
tangent vector, as there is no corresponding parameter in OpenPBR.
Fixes#138164
Authored by Apple: Lee Kerley
Pull Request: https://projects.blender.org/blender/blender/pulls/138165
This patch adds support for the Factor and Percentage subtypes for
vector sockets. This is needed by the compositor, since it has some node
inputs that specify locations and sizes relative to image size, and
having factor and percentage subtypes for those improves the UX quite a
bit according to user feedback.
Pull Request: https://projects.blender.org/blender/blender/pulls/138805
"Origin to Geometry" was also affected
With very large meshes (report was about this failing for imported
terrain data), we lack precision in `BKE_mesh_center_median`.
First intuition was to just use doubles, but based on the work done
in !132759 to get a more numerically stable way to compute a mean,
we can use that instead.
So this PR moves `compute_sum` into `blender::array_utils`
and re-uses that for `BKE_mesh_center_median`
Pull Request: https://projects.blender.org/blender/blender/pulls/138813
Previously, the modifier name was used to identify it in a compute context or
viewer path. Using `ModifierData.persistent_uid` (which was only introduced
later) has two main benefits: * It is stable even when the modifier name
changes. * It's cheaper and easier to work with since it's just an integer
instead of a string.
Note: Pinned viewer nodes will need to be re-pinned after the change.
Pull Request: https://projects.blender.org/blender/blender/pulls/138864
Previously, the `UserData` and `LocalUserData` classes were only supposed to be
used by the lazy-function system. However, they are generic enough so that they
can also be used by the multi-function system. Therefore, this patch extracts
them into a separate header that can be used in both evaluation systems.
I'm doing this in preparation for being able to pass the geometry nodes logger
to multi-functions, to be able to report errors from there.
Pull Request: https://projects.blender.org/blender/blender/pulls/138861
This merges the public `uiItemS` and `uiItemS_ex` functions into an
object oriented API (`uiLayout::separator`), matching the python API.
This reduces the difference between the C++ API with the python version,
its also helps while converting code from python to C++ code
(or vice-versa), making it almost seamless.
Part of: #117604
Pull Request: https://projects.blender.org/blender/blender/pulls/138826
Previously, whenever a node had a non-trivial storage struct, there would have
to be code for it in `node.cc`. Now there is a general callback that new node
types can use to implement their blend read/write behavior.
Some existing nodes were converted to use this decentralized method. However,
some older nodes can't use it in the same way, because the node types were
introduced before there were node idnames. It's also somewhat hard to reason
about special cases that versioning code might have for these nodes, so they
remain unchanged.
The node callback only writes the non-trivial data, while the main node storage
struct is written automatically by relying on `bNodeType::storagename`. This
simplifies the callback in many cases or makes it unnecessary for trivial types.
Some nodes have specific handling for forward-compatibility. This
forward-compatibility code is kept in `node.cc` for now, because it also affects
the main storage struct and therefore has to be changed before that struct is
written.
Pull Request: https://projects.blender.org/blender/blender/pulls/138722
Previously, it was not possible to switch a menu based on another menu. This
patch adds support for this.
Usually, menu sockets are drawn without the label in nodes currently. Now there
is one exception: the Menu Switch node when it switches another menu. If the
label is not shown, the UI is missing crucial information.
Pull Request: https://projects.blender.org/blender/blender/pulls/138704
Previously, Switch node were using the fallback behavior when they were muted.
That implied that the generated internal link was generally not very useful.
This patch makes the behavior of muted switch nodes explicit. Now the internal
link will always point to the first value input and never to the condition
input. Note, for the Menu Switch node this does not make a difference yet,
because menu sockets are not supported there yet (#138704).
Pull Request: https://projects.blender.org/blender/blender/pulls/138724
This converts the public `uiItemO` function to an object oriented
API (`uiLayout::op`).
Also this rearranges `idname` paramether, since this the only one
required, and to make format similar to `uiItemFullO`
Note: One of the benefits of moving from a public function to class
method is to reduce API usage difference between C++ and Python. In
Python this method is called `UILayout::operator`, however `operator`
is a reserved keyword in C++.
Part of: #117604
Pull Request: https://projects.blender.org/blender/blender/pulls/138776
There are very rare use-cases for having multiple Group Output nodes. However,
it's something that's been supported for a long time and removing it may be a
regression for some. In practice, it's usually a mistake when someone has
multiple Group Output nodes.
This patch adds a simple warning on inactive Group Output nodes to help the user
notice this case.
Pull Request: https://projects.blender.org/blender/blender/pulls/138743
These are generic properties of grids (not stored in voxels) which are
useful to know in geometry nodes. The transform in particular defines
the voxel size. Background value is used outside of active voxels.
Pull Request: https://projects.blender.org/blender/blender/pulls/138592
This patch removes the Gamma option from the Defocus and Blur nodes. The
reasoning is as follows.
- The option was originally added when the compositor wasn't working on
a strictly linear workflow. So this is rarely needed now.
- It is easy to insert a Gamma node around Blur nodes to perform any
gamma correction if really needed.
- Since we are moving options to inputs, it doesn't seem worth it to
provide this option as an input in the process.
Pull Request: https://projects.blender.org/blender/blender/pulls/138673
This patch uses the add_node_discovery node registration mechanism
already used by Geometry and Function nodes. This is done to reduce the
number of places needed to add a new node.
Pull Request: https://projects.blender.org/blender/blender/pulls/138755
This adds a new `DNA_sdna_type_ids.hh` header:
```cpp
namespace blender::dna {
/**
* Each DNA struct has an integer identifier which is unique within a specific
* Blender build, but not necessarily across different builds. The identifier
* can be used to index into `SDNA.structs`.
*/
template<typename T> int sdna_struct_id_get();
/**
* The maximum identifier that will be returned by #sdna_struct_id_get in this
* Blender build.
*/
int sdna_struct_id_get_max();
} // namespace blender::dna
```
The `sdna_struct_id_get` function is used as replacement of
`SDNA_TYPE_FROM_STRUCT` in all places except the DNA defaults system. The
defaults system is C code and therefore can't use the template. There is ongoing
work to replace the defaults system as well though: #134531.
Using this templated function has some benefits over the old approach:
* No need to rely on macros.
* Can use type inferencing in functions like `BLO_write_struct` which avoids
redundancy on the call site. E.g. `BLO_write_struct(writer, ActionStrip,
strip);` can become `BLO_write_struct(writer, strip);` which could even become
`writer.write_struct(strip);`. None of that is implemented as part of this
patch though.
* No need to include the generated `dna_type_offsets.h` file which contains a
huge enum.
Implementation wise, this is done using explicit template instantiations in a
new file generated by `makesdna.cc`: `dna_struct_ids.cc`. The generated file
looks like so:
```cpp
namespace blender::dna {
template<typename T> int sdna_struct_id_get();
int sdna_struct_id_get_max();
int sdna_struct_id_get_max() { return 951; }
}
struct IDPropertyUIData;
template<> int blender:🧬:sdna_struct_id_get<IDPropertyUIData>() { return 1; }
struct IDPropertyUIDataEnumItem;
template<> int blender:🧬:sdna_struct_id_get<IDPropertyUIDataEnumItem>() { return 2; }
```
I tried using static variables instead of separate functions, but I didn't
manage to link it properly. Not quite sure yet if that's an actual limitation or
if I was just missing something.
Pull Request: https://projects.blender.org/blender/blender/pulls/138706
Previously, nodes which had their own special internal-links-behavior were
hardcoded in node tree update code. Now that is decentralized so that more nodes
can use this functionality without leaking special cases into general code.
Pull Request: https://projects.blender.org/blender/blender/pulls/138712
Remove the addition of the position attribute from the default
"init data" callback where we don't know the desired number
of points. Add it in the other functions that add the data-block
(except the version that purposefully doesn't add attributes).
Pull Request: https://projects.blender.org/blender/blender/pulls/138697
This converts the public `uiItemFullR` function to an object oriented
API (an overload of `uiLayout::prop`), matching the python API.
This reduces the difference between the C++ API with the python version,
its also helps while converting code from python to C++ code (or vice-versa),
making it almost seamless.
Part of: #117604
Pull Request: https://projects.blender.org/blender/blender/pulls/138683
This patch removes the translation Offset from the Scale node. The
reasoning is that it is easy to insert a Translate node afterwards to
perform any necessary translation. And since we are moving options to
inputs, it doesn't seem worth it to provide those offsets as inputs in
the process.
Pull Request: https://projects.blender.org/blender/blender/pulls/138668
Briefly about this change:
- OpenColorIO C-API is removed.
- The information about color spaces in ImBuf module is removed.
It was stored in global ListBase in colormanagement.cc.
- Both OpenColorIO and fallback implementation supports GPU drawing.
- Fallback implementation supports white point, RGB curves, etc.
- Removed check for support of GPU drawing in IMB.
Historically it was implemented in a separate library with C-API, this
is because way back C++ code needed to stay in intern. This causes all
sort of overheads, and even calls that are strictly considered bad
level.
This change moves OpenColorIO integration into a module within imbuf,
next to movie, and next to IMB_colormanagement which is the main user
of it. This allows to avoid copy of color spaces, displays, views etc
in the ImBuf: they were used to help quickly querying information to
be shown on the interface. With this change it can be stored in the
same data structures as what is used by the OpenColorIO integration.
While it might not be fully avoiding duplication it is now less, and
there is no need in the user code to maintain the copies.
In a lot of cases this change also avoids allocations done per access
to the OpenColorIO. For example, it is not needed anymore to allocate
image descriptor in a heap.
The bigger user-visible change is that the fallback implementation now
supports GLSL drawing, with the whole list of supported features, such
as curve mapping and white point. This should help simplifying code
which relies on color space conversion on GPU: there is no need to
figure out fallback solution in such cases. The only case when drawing
will not work is when there is some actual bug, or driver issue, and
shader has failed to compile.
The change avoids having an opaque type for color space, and instead
uses forward declaration. It is a bit verbose on declaration, but helps
avoiding unsafe type-casts. There are ways to solve this in the future,
like having a header for forward declaration, or to flatten the name
space a bit.
There should be no user-level changes under normal operation.
When building without OpenColorIO or the configuration has a typo or
is missing a fuller set of color management tools is applies (such as the
white point correction).
Pull Request: https://projects.blender.org/blender/blender/pulls/138433
This patch removes the Max Blur option from the Bokeh Blur node. The
reasoning is as follows.
- The option was unused in case of non-variable sized blur, which was
the default, so the option did nothing for the default case of the
node.
- The option was originally introduced to define the search window of
variable size blur. This is no longer the case, since we compute the
search window dynamically from the input using parallel reduction,
which is now very fast. So currently, it only works as an upper limit.
- The node options will be exposed as inputs, so the user will see two
inputs that control the radius, which can be confusing for users that
are not experienced.
- The plan is to make the node take absolute pixel sizes in the future,
instead of the arbitrary relative size now in place, which would make
it very easy for the user to impose such limits manually.
It is difficult to version this change, since the size is relative to
the image size, while max blur is in pixels. But we assume the user
chose a sufficiently large max blur for the node to be useful, so the
composite should not be expected to be drastically different.
Pull Request: https://projects.blender.org/blender/blender/pulls/138659
This converts the public `uiItemR` function to an object oriented
API (`uiLayout::prop`), matching the python API.
This reduces the difference between the C++ API with the python version,
its also helps while converting code from python to C++ code (or vice-versa),
making it almost seamless.
Part of: #117604
Pull Request: https://projects.blender.org/blender/blender/pulls/138617
Add a new shader node to control volume coefficients (scattering,
absorption and emission) directly, making it easier to model existing
volumes with measured data.
Pull Request: https://projects.blender.org/blender/blender/pulls/136287
This converts the public `uiItemL` function to an object oriented
API (`uiLayout::label`), matching the python API.
This reduces the difference between the C++ API with the python version,
its also helps while converting code from python to C++ code (or vice-versa),
making it almost seamless.
Part of: #117604
Pull Request: https://projects.blender.org/blender/blender/pulls/138608
This adds basic templating support to render output paths. By putting
"{variable_name}" in the path string, it will be replaced by the named
variable's value when generating the actual output path. This is similar
to how "//" is already substituted with the path to the blend file's
current directory.
This templating system is implemented for both the primary render output
path as well as the File Output node in the compositing nodes. Support
for using templates in other places can be implemented in future PRs.
In addition to the "{variable_name}" syntax, some additional syntax is
also supported:
- Since "{" and "}" now have special meaning, "{{" and "}}" are now
escape sequences for literal "{" and "}".
- "{variable_name:format_specifier}", where "format_specifier" is a
special syntax using "#", which allows the user to specify how numeric
variables should be formatted:
- "{variable_name:###}" will format the number as an integer with at
least 3 characters (padding with zeros as needed).
- "{variable_name:.##}" will format the number as a float with
precisely 2 fractional digits.
- "{variable_name:###.##}" will format the number as a float with at
least 3 characters for the integer part and precisely 2 for the
fractional part.
For the primary render output path: if there is a template syntax error,
a variable doesn't exist, or a format specifier isn't valid (e.g. trying
to format a string with "##"), the render that needs to write to the
output path fails with a descriptive error message.
For both the primary and File Output node paths: if there are template
syntax errors the field is highlighted in red in the UI, and a tooltip
describes the offending syntax errors. Note that these do *not* yet
reflect errors due to missing variables. That will be for a follow-up
PR.
In addition to the general system, this PR also implements a limited set
of variables for use in templates, but more can be implemented in future
PRs. The variables added in this PR are:
- `blend_name`: the name of the current blend file without the file
extension.
- `fps`: the frames per second of the current scene.
- `resolution_x` and `resolution_y`: the render output resolution.
Pull Request: https://projects.blender.org/blender/blender/pulls/134860
Previously, menu sockets were always drawn as dropdown. This patch adds the
ability to draw them expanded instead.
As before, in the node editor, only the expanded menu is drawn, without the
label. There is simply not enough space for both. However, in the modifier and
operator settings the label is drawn currently. We'll probably need to add a
separate `Hide Label` option (similar to `Hide Value`) for group inputs that
support it. That would also help a lot with e.g. object sockets.
Pull Request: https://projects.blender.org/blender/blender/pulls/138387
This patch adds a new `BLI_mutex.hh` header which adds `blender::Mutex` as alias
for either `tbb::mutex` or `std::mutex` depending on whether TBB is enabled.
Description copied from the patch:
```
/**
* blender::Mutex should be used as the default mutex in Blender. It implements a subset of the API
* of std::mutex but has overall better guaranteed properties. It can be used with RAII helpers
* like std::lock_guard. However, it is not compatible with e.g. std::condition_variable. So one
* still has to use std::mutex for that case.
*
* The mutex provided by TBB has these properties:
* - It's as fast as a spin-lock in the non-contended case, i.e. when no other thread is trying to
* lock the mutex at the same time.
* - In the contended case, it spins a couple of times but then blocks to avoid draining system
* resources by spinning for a long time.
* - It's only 1 byte large, compared to e.g. 40 bytes when using the std::mutex of GCC. This makes
* it more feasible to have many smaller mutexes which can improve scalability of algorithms
* compared to using fewer larger mutexes. Also it just reduces "memory slop" across Blender.
* - It is *not* a fair mutex, i.e. it's not guaranteed that a thread will ever be able to lock the
* mutex when there are always more than one threads that try to lock it. In the majority of
* cases, using a fair mutex just causes extra overhead without any benefit. std::mutex is not
* guaranteed to be fair either.
*/
```
The performance benchmark suggests that the impact is negilible in almost
all cases. The only benchmarks that show interesting behavior are the once
testing foreach zones in Geometry Nodes. These tests are explicitly testing
overhead, which I still have to reduce over time. So it's not unexpected that
changing the mutex has an impact there. What's interesting is that on macos the
performance improves a lot while on linux it gets worse. Since that overhead
should eventually be removed almost entirely, I don't really consider that
blocking.
Links:
* Documentation of different mutex flavors in TBB:
https://www.intel.com/content/www/us/en/docs/onetbb/developer-guide-api-reference/2021-12/mutex-flavors.html
* Older implementation of a similar mutex by me:
https://archive.blender.org/developer/differential/0016/0016711/index.html
* Interesting read regarding how a mutex can be this small:
https://webkit.org/blog/6161/locking-in-webkit/
Pull Request: https://projects.blender.org/blender/blender/pulls/138370
The special case that just returns a span was incorrect on the point
domain. It shouldn't apply in that case since the input indices are
meant to be curve indices.
Pull Request: https://projects.blender.org/blender/blender/pulls/138506
OpenVDB has a voxel size limit defined by the determinant of the grid
transform, which is equivalent to a uniform voxel size of
`sqrt3(3e-15) ~= 1.44e-5`.
The `mesh_to_density_grid` function was using an arbitrary threshold of
`1.0e-5` for the uniform voxel size.
In this case the voxel size is `~1.343e-5` so it passes the Blender
threshold but crashes in OpenVDB.
This fix adds some convenience functions to check for valid grid voxel
size and transform based on the same determinant metric. This is now
employed consistently in the mesh_to_density_grid, mesh_to_sdf_grid, and
points_to_sdf_grid functions to avoid exceptions in OpenVDB.
MOD_volume_to_mesh, node_geo_volume_to_mesh, BKE_mesh_remesh_voxel have
not been modified, since they have their own error checks with larger
thresholds.
Pull Request: https://projects.blender.org/blender/blender/pulls/138481
The "Active Element" node would return early if the mode was
not `OB_MODE_EDIT`.
For Grease Pencil, we want to be able to query the active layer index
from any mode.
This changes the logic to only return early for the `Point`, `Edge`,
and `Face` element if the mode is not edit mode.
Pull Request: https://projects.blender.org/blender/blender/pulls/138491
Blender would crash in the "Set Spline Resolution" when the
Grease Pencil object had a bezier curve and the resolution is
changed.
This was because the triangle cache of the drawing wasn't
recomputed after the number of evaluated points changed.
This converts the public `uiLayoutPanel` function to an object oriented
API (`uiLayout::panel`), matching the python API.
This reduces the difference between the C++ API with the python version,
its also helps while converting code from python to C++ code (or vice-versa),
making it almost seamless.
Pull Request: https://projects.blender.org/blender/blender/pulls/138461
This adds an Import VDB node. It loads all the grids from a .vdb file and hence
outputs a Volume geometry instead of an individual grid.
The grids are cached through the existing volume grid file cache, so they are
automatically deduplicated when volume grids are loaded from files in other
ways.
Pull Request: https://projects.blender.org/blender/blender/pulls/138380
Currently, the import nodes always reimport on each evaluation. This patch adds
support for caching the loaded geometries. This is integrated with
`BLI_memory_cache.hh` and thus also takes the cache size limit into account. If
an imported file is modified on disk, the cache is invalidated. However,
Geometry Nodes will not automatically reevaluate when a file changes, so the
user would have to trigger the evaluation in some other way.
This is an alternative solution to #124369. The main benefits are that the cache
invalidation happens automatically and that the cache system is more general and
does not have to know about e.g. the different file types.
Caching speeds up node setups that heavily rely on import nodes significantly.
Pull Request: https://projects.blender.org/blender/blender/pulls/138425
This adds a version of `BKE_id_new_nomain` that takes the ID type parameter as
template argument. This allows the function the return the newly created ID with
the correct type, removing the need to use `static_cast` on the call-site.
To make this work, I added a static `id_type` member to every ID struct. This
can also be used to create a similar API for other id management functions in
future patches.
```cpp
// Old
Mesh *mesh = static_cast<Mesh *>(BKE_id_new_nomain(ID_ME, "Mesh"));
// New
Mesh *mesh = BKE_id_new_nomain<Mesh>("Mesh");
```
Pull Request: https://projects.blender.org/blender/blender/pulls/138383
This patch removes the Premultiplied option from the Alpha Over node.
The reasoning is as follows:
- The option mixed between alpha being straight and premultiplied, a
state which doesn't happen in practice.
- The option conflicts with the Convert Premultiplied option, if it is
not zero, then Convert Premultiplied does nothing.
- The option is implemented in a lossy way. It premultiplies the alpha
assuming it is straight, then converts the result to straight again,
then mixed between both results. This is as opposed to mixing the
original straight input with the premultiplied input. The successive
alpha conversion causes data loss in transparent regions.
Pull Request: https://projects.blender.org/blender/blender/pulls/138428
This adds inital Grease Pencil support for node tools.
Node tools work in `Object Mode`, `Edit Mode`,`Sculpt Mode`,
and `Draw Mode`.
While Grease Pencil has many editing tools, including editing
multiple frames at the same time, for now, node tools only
allow editing the current frame.
Currently, the idea is that node tools can do arbitrary changes
to the drawings, but cannot do changes to the existing layer tree, e.g.
changing the order of layers, removing a layer or groups, etc.
All the node tool specific nodes like `Selection` and `Set Selection`
are adapted to work with Grease Pencil. In `Draw Mode`, we currently
interpret everything as selected.
The `Active Element` node has a `Layer` mode that provides the
index of the active layer (if there is one).
When `Auto-Key` is used, a new keyframe is created on the
current frame.
Locked/invisible layers cannot be edited with node tools.
Pull Request: https://projects.blender.org/blender/blender/pulls/136624
This patch removes the Convert Premultiplied option from the Brightness
and Contrast node. The reasoning is that it is the only node that has
the option to operate on straight alpha, while not being particularly
different. Adding alpha conversion nodes around it is also very easy.
Furthermore, alpha conversion is a lossy operation, so the option looses
data in emissive pixels, and since it is enabled by default, users not
familiar with the exact mechanism of the option wouldn't know how to fix
this.
Pull Request: https://projects.blender.org/blender/blender/pulls/138318
Fixes behavior for #137057 when sampling single point curves.
Previous behavior just checked the evaluated length cache size and
called fill_invalid(), it will now fill using the point value and terminate.
Pull Request: https://projects.blender.org/blender/blender/pulls/138153
This converts the public `uiLayoutSplit` function to an object oriented
API (`uiLayout::split`), matching the python API.
This reduces the difference between the C++ API with the python version,
its also helps while converting code from python to C++ code (or vice-versa),
making it almost seamless.
`uiLayout::split` now returns an `uiLayout` reference instead of a pointer.
New calls to this method should use references too.
Pull Request: https://projects.blender.org/blender/blender/pulls/138361
