Previously, whenever the zone detection algorithm could not find a result, zones
were just not drawn at all. This can be very confusing because it's not
necessarily obvious that something is wrong in this case.
Now, invalid zones and links that made them invalid have an error.
Note, we can't generally detect the "valid part" of zones when there are invalid
links, because it's ambiguous which links are valid. However, the solution here
is to remember the last valid zones, and to look at which links would invalidate
those. Since the zone-detection results in runtime-only data currently, the
error won't show when reopening the file for now.
Implementation wise, this works by keeping a potentially outdated version of the
last valid zones around, even when the zone detection failed. For that to work,
I had to change some node pointers to node identifiers in the zone structs, so
that it is safe to access them even if the nodes have been removed.
Pull Request: https://projects.blender.org/blender/blender/pulls/139044
Previously modifiers can only filter single layers, now filtering by
layer group is also supported.
This adds a toggle to the layer filter to switch to filtering by groups.
Resolves #123323.
Pull Request: https://projects.blender.org/blender/blender/pulls/123353
This converts the public `uiItemMenuF` and `uiItemMenuFN`
functions to an object oriented API (an `uiLayout::menu_fn`
and `uiLayout::menu_fn_argN_free` respectively), following
recent uiLayout changes.
Part of: #117604
Pull Request: https://projects.blender.org/blender/blender/pulls/138902
This PR intends to replace the current face corner normals calculation.
Compared to the existing code it has a few benefits:
- It's much easier to understand.
- It doesn't require edges, ideally helping to remove them from caches
and eventually to make them optional.
- It is completely multithreaded using the vert to face map, which is
already used for vertex normals and domain interpolation. The previous
code has a significant single threaded portion that scales with the
size of the mesh.
- Lower peak memory usage: It doesn't require a temporary edge to corner
map, the corner to face map, or a corner domain sized bit vector.
- The code sorting corners around a vertex should be easy to reuse.
- It's over twice as fast. On a test file with custom normals I observe
an overall FPS increase of 2.56x, from 37 to 95.
Pull Request: https://projects.blender.org/blender/blender/pulls/138013
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
Work around an issue with expanded menus that exists for a long time
already. I briefly tried fixing it, but does not seem straight forward unfortunately
without breaking stuff.
Also see the comment in `ui_item_enum_expand_exec`.
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
The old name `modifier_panel_end` was not great because:
* There is no corresponding `*_begin`.
* It sounds more magical then it really is (it just draws the error message).
* It doesn't even have to be at the end as is sometimes the case when there are subpanels.
Pull Request: https://projects.blender.org/blender/blender/pulls/138797
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
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
Starting with C++20, `fmt::format` will process the format string at
compile time by default. We need to opt out in the cases where this is
not possible by using `fmt::runtime(...)`, like, for example, when using
our various translation utilities.
This mirrors prior commit e62aa986b2 and
fixes 2 cases that have slipped back in.
Pull Request: https://projects.blender.org/blender/blender/pulls/138640
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
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
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
This converts the public uiLayoutPanelPropWithBoolHeader function to an
object oriented API (`uiLayout::panel_prop_with_bool_header`), following
similar changes to the uiLayout API.
Pull Request: https://projects.blender.org/blender/blender/pulls/138523
This converts the public `uiLayoutPanelProp` function to an object oriented
API (`uiLayout::panel_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.
Pull Request: https://projects.blender.org/blender/blender/pulls/138501
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 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
* Remove `DEG_get_evaluated_object` in favor of `DEG_get_evaluated`.
* Remove `DEG_is_original_object` in favor of `DEG_is_original`.
* Remove `DEG_is_evaluated_object` in favor of `DEG_is_evaluated`.
Pull Request: https://projects.blender.org/blender/blender/pulls/138317
This converts the public `uiLayoutColumnWithHeading` function to an
object oriented API (an `uiLayout::column` overloaded version), matching
the python API.
Like the original `uiLayout::column`, this overloaded version now also
returns an `uiLayout` reference instead of a pointer. New calls to this
method should use references too.
Part of: #117604
Pull Request: https://projects.blender.org/blender/blender/pulls/138056
This converts the public `uiLayoutColumn` function to an object oriented
API (`uiLayout::column`), 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::column` 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/138034
This converts the public `uiLayoutRowWithHeading` function to an object oriented
API (an `uiLayout::row` overloaded version), 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.
Same as the original `uiLayout::row`, this overloaded version also now returns an
`uiLayout` reference instead of a pointer.
New calls to this method should use references too.
Part of: #117604
Pull Request: https://projects.blender.org/blender/blender/pulls/138014
This converts the public `uiLayoutRow` function to an object oriented
API (`uiLayout::row`), 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::row` now returns an `uiLayout` reference instead of a pointer.
New calls to this method should use references too.
Part of: #117604
Pull Request: https://projects.blender.org/blender/blender/pulls/137979
This allows users to implement arbitrary camera models using OSL by writing
shaders that take an image position as input and compute ray origin and
direction.
The obvious applications for this are e.g. panorama modes, lens distortion
models and realistic lens simulation, but the possibilities are endless.
Currently, this is only supported on devices with OSL support, so CPU and
OptiX. However, it is independent from the shading model used, so custom
cameras can be used without getting the performance hit of OSL shading.
A few samples are provided as Text Editor templates.
One notable current limitation (in addition to the limited device support)
is that inverse mapping is not supported, so Window texture coordinates and
the Vector pass will not work with custom cameras.
Pull Request: https://projects.blender.org/blender/blender/pulls/129495
The object to world transform was applied to the result (which was
meant to be in world space), rather than the inverse. However, the
processing of transforms is more complicated than necessary. Instead
of passing around a separate "target transform" that's meant to be used
inverted after the boolean operation, just make the input transforms
transform the input meshes into the desired transform space of the
output (object-local space for the modifier).
Pull Request: https://projects.blender.org/blender/blender/pulls/137919
Adds the 'manifold' solver option to the Boolean geo node and to
the Boolean modifier. This solver is about as fast, or faster,
than the current float solver, and is robust against floating
point issues like the Exact solver. But currently it only
works on mesh arguments that are strictly manifold.
See https://projects.blender.org/blender/blender/issues/120182
for many more details.
It's safer to pass a type so that it can be checked if delete should be
used instead. Also changes a few void pointer casts to const_cast so that
if the data becomes typed it's an error.
Pull Request: https://projects.blender.org/blender/blender/pulls/137404
This makes it possible to search layer names in the
`Named Layer Selection` node as well as boolean
modifier inputs that are marked as a `Layer Selection`.
The layer selection UI is slightly updated:
* Use a slightly larger default width for the
`Named Layer Selection` node.
* Use the layer icon in the field that search for layer names.
* Use `Layer` placeholder string
Pull Request: https://projects.blender.org/blender/blender/pulls/137273
The goal here is to avoid having to cast to and from `ID` when getting the
evaluated or original ID using the depsgraph API, which is often verbose and not
type safe. To solve this, there are now `DEG_get_original` and
`DEG_get_evaluated` methods which are templated on the type and use a new
`is_ID_v` static type check to make sure it's only used with valid types.
This allows removing quite some verbosity on all the call sites. I also removed
`DEG_get_original_object`, because that does not have to be a special case
anymore.
Pull Request: https://projects.blender.org/blender/blender/pulls/137629
This adds support for having viewer nodes in closures. The code attempt to
detect where the closure is evaluated and shows the data from there.
If the closure is evaluated in multiple Evaluate Closure nodes, currently it
just picks the first one it finds. Support for more user control in this case
may be added a bit later. If the Evaluate Closure node is in e.g. the repeat or
foreach zone, it will automatically use the inspection index of that zone to
determine what evaluation to look at specifically.
Overall, not too much had to change conceptually to support viewers in closures.
Just some code like converting between viewer paths and compute contexts had to
be generalized a little bit.
Pull Request: https://projects.blender.org/blender/blender/pulls/137625
This adds a simple `compute_context_for_edittree` function that returns the
"active" compute context for the given node editor. This is used in various
places, but previously one had to construct the compute context in multiple
steps (first find the root context (modifier/operator), then handle the tree
path). Since the edittree already has a specific active context, there should be
an easy way to retrieve that.
This also adds a few extra check that avoid redundant work that was done before.
Pull Request: https://projects.blender.org/blender/blender/pulls/137525
While `ComputeContextBuilder` worked well for building simple linear compute
contexts, it was fairly limiting for all the slightly more complex cases where
an entire tree of compute contexts is built. Using `ComputeContextCache` that is
easier to do more explicitly. There were only very few cases where using
`ComputeContextBuilder` would have still helped a bit, but it's not really worth
keeping that abstraction around just for those few cases.
Pull Request: https://projects.blender.org/blender/blender/pulls/137370
Use `get_influence_vertex_weights` for thickness modifier. This returns
array of values 0 when group is empty (see `lookup_or_default`).
Function also controls the invert state for vertex group.
Pull Request: https://projects.blender.org/blender/blender/pulls/137455
When a stroke has a gradient fill material that starts with a color with
zero alpha, the tint modifier would behave as if it's not effective at
all, this is caused by referencing source material color only with the
starting color in this case, and since the alpha is zero, the tint is
applied wrongly. Now use average color of start and end color of the
gradient to mix with the tint modifier color.
Note that this isn't technically correct still, since material gradient
is computed in the shader, and tint modifier isn't able to get the
acutal fill color at a given vertex (especially for the radial gradient
case) however the result of this patch looks visually good enough, and
users can always set all alpha to 1 when they feel the color is off.
Pull Request: https://projects.blender.org/blender/blender/pulls/134549
The main goal here is to add `GeoTreeLogger.tree_orig_session_uid`. Previously,
it was always possible to derive this information in `ensure_node_warnings`.
However, with closures that's not possible in general anymore, because the
Evaluate Closure node does not know statically which node tree the closure zone
is from that it evaluates. Therefore, this information has to be logged as well.
This patch initializes `tree_orig_session_uid` the same way it initializes
`parent_node_id`, by scanning the compute context when creating the tree logger.
To make this work properly, some extra contextual data had to be stored in some
compute contexts.
This is just a refactor with no expected functional changes. Node warnings for
closures are still not properly logged, because that requires storing
source-location data in closures, which will be implemented separately.
Pull Request: https://projects.blender.org/blender/blender/pulls/137208
Reading curves from alembic files did not interpolate the curves between
frames, leading to incorrect motion blur. This uses the existing
`use_vertex_interpolation` flag on the MeshSequenceCache to enable the
subframe interpolation.
Pull Request: https://projects.blender.org/blender/blender/pulls/135698
When releasing a mesh from a `GeometrySet` one has to take manual control over
owner-management. In some cases, the geometry set was not the owner of the mesh,
but was just referencing it. This is generally fine in a limited set of
circumstances and can avoid copies. However, when taking ownership of the mesh
in the geometry set, one has to be sure that the geometry set actually has
ownership.
This is similar to what is done in e.g. `modifier_modify_mesh_and_geometry_set`.
Pull Request: https://projects.blender.org/blender/blender/pulls/137150
This fixes most "One Definition Rule" violations inside blender proper
resulting from duplicate structures of the same name. The fixes were
made similar to that of !135491. See also #120444 for how this has come
up in the past.
These were found by using the following compile options:
-flto=4 -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing
Note: There are still various ODR issues remaining that require
more / different fixes than what was done here.
Pull Request: https://projects.blender.org/blender/blender/pulls/136371
Add a "dumb vector" storage option for custom normals, with the
"custom_normal" attribute. Adjust the mesh normals caching to
provide this attribute if it's available, and add a geometry node to
store custom normals.
## Free Normals
They're called "free" in the sense that they're just direction vectors
in the object's local space, rather than the existing "smooth corner
fan space" storage. They're also "free" in that they make further
normals calculation very inexpensive, since we just use the custom
normals instead. That's a big improvement from the existing custom
normals storage, which usually significantly decreases
viewport performance. For example, in a simple test file just storing
the vertex normals on a UV sphere, using free normals gives 25 times
better playback performance and 10% lower memory usage.
Free normals are adjusted when applying a transformation to the entire
mesh or when realizing instances, but in general they're not updated for
vertex deformations.
## Set Mesh Normal Node
The new geometry node allows storing free custom normals as well as
the existing corner fan space normals. When free normals are chosen,
free normals can be stored on vertices, faces, or face corners. Using
the face corner domain is necessary to bake existing mixed sharp and
smooth edges into the custom normal vectors.
The node also has a mode for storing edge and mesh sharpness, meant
as a "soft" replacement to the "Set Shade Smooth" node that's a bit
more convenient.
## Normal Input Node
The normal node outputs free custom normals mixed to whatever domain is
requested. A "true normal" output that ignores custom normals and
sharpness is added as well.
Across Blender, custom normals are generally accessed via face and
vertex normals, when "true normals" are not requested explicitly.
In many cases that means they are mixed from the face corner domain.
## Future Work
1. There are many places where propagation of free normals could be
improved. They should probably be normalized after mixing, and it
may be useful to not just use 0 vectors for new elements. To keep
the scope of this change smaller, that sort of thing generally isn't
handled here. Searching `CD_NORMAL` gives a hint of where better
propagation could be useful.
2. Free normals are displayed properly in edit mode, but the existing
custom normal editing operators don't work with free normals yet.
This will hopefully be fairly straightforward since custom normals
are usually converted to `float3` for editing anyway. Edit mode
changes aren't included here because they're unnecessary for the
procedural custom normals use cases.
3. Most importers can probably switch to using free normals instead,
or at least provide an option for it. That will give a significant
import performance improvement, and an improvement of Blender's
FPS for imported scenes too.
Pull Request: https://projects.blender.org/blender/blender/pulls/132583
In `lineart_geometry_check_visible` it could recieve a valid mesh
without any vertices, this causes `bounds` below to be invalid.
Now return early if encountered such situation.
Pull Request: https://projects.blender.org/blender/blender/pulls/136819
