Previously, the BVH bounds were updated with a top-down approach
starting at the root. As explained in #136471, algorithms that visit
every node of the tree can become a bottleneck when sculpting high-res
meshes.
This patch refactors `flush_bounds_to_parents` by using a bottom-up
approach starting from the dirty leaf nodes. This requires calculating
and storing the parents of the nodes during the BVH build.
The change reduces the overhead measured in #136471 to near zero. The
same tests give the following results:
| Radius | Node Ratio | Speedup |
|--------------|---------|------------|
| 0.10m | 297 | 1.25x |
| 0.25m | 297 | 1.23x |
| 0.50m | 551 | 1.18x |
| 1.00m | 1930 | 1.13x |
where node ratio is the ratio between total nodes and nodes affected by
the brush. For reference, typical ratios when sculpting something like
a character are very roughly:
- tens when sculpting main forms
- low hundreds when sculpting secondary forms
- high hundreds to thousands when sculpting tertiary details
Pull Request: https://projects.blender.org/blender/blender/pulls/137019
For various purposes we traverse the computation done by a node tree (e.g. for
gizmos and socket usage infeferencing). For that we generally have to keep track
of the compute context we're in at any given time. During the traversal, it's
common to enter and exist the same compute contexts multiple times. Currently,
we'd always build a new compute context when that happens. That happens even
though the old one is generally still around, because other data may reference
it. This patch implements a `ComputeContextHash` type that avoids rebuilding the
same compute contexts over and over again.
I'm considering to also replace the usage of `ComputeContextBuilder` with this
cache somehow, but will see how that works out.
The reason I'm working on this now is that I have to traverse the node tree a
bit again to find where closures might be evaluated. I wanted to be able to
cache the compute contexts for a while already.
Pull Request: https://projects.blender.org/blender/blender/pulls/137360
The goal is to log information about which closures are evaluated where. This
information is not exposed in the UI yet, but will be needed to be able to debug
the evaluation and inspect socket values within closures.
Pull Request: https://projects.blender.org/blender/blender/pulls/137351
Remove long-deprecated constraints that will likely never be
implemented in this form.
- Rigid Body Joint Constraint was removed in 2.80, but some references
remained in the code. Versioning code was written that tried to
remove them on load, but since constraint initialization code sets
the type to CONSTRAINT_TYPE_NULL before versioning gets a chance,
the versioning code ended up never running. This has all been
removed.
- Python/Script Constraint never worked since 2.50 and showed an error
message in the UI panel.
These constraints now load as 'null' constraint, as seems to be
(looking at the code) the way that Blender currently deals with
removed constraint types. These still show up in the outliner and
python API, but have no UI panel. Removing such constraints completely
will be left for another time, as it is beyond the scope of removing
these two specific constraint types.
Pull Request: https://projects.blender.org/blender/blender/pulls/136672
Only geometry nodes is allowed to have no active output (the group output node acts as an explicit node tree output). The previous fix only considered geometry nodes and compositor cases, which was not enough.
Pull Request: https://projects.blender.org/blender/blender/pulls/137288
Prior to this commit, the set of brushes that ignore the gravity brush
effect and the set of brushes that dim the display of the related
options were mismatched.
Pull Request: https://projects.blender.org/blender/blender/pulls/137309
Prior to this commit, whether or not a brush was capable of using
certain options in Sculpt mode and whether or not these properties would
be shown to the user was spread across a number of files and
inconsistently applied.
This commit moves most of these checks to the bke::brush namespace so
that we have a single source of truth for these checks.
In total this commit:
* Changes all BrushCapabilitiesSculpt methods to use the equivalent
bke::brush function
* Removes brush type macros
* Renames BKE_brush_supports_secondary_color to fit the new pattern
* Refactors inverted logic for the `direction` property
Pull Request: https://projects.blender.org/blender/blender/pulls/137249
Simplifies implementation of curve tangent calculation for polylines
and evaluated curves. Loop now re-uses results from previous
iteration and adjusts for 0-length segments in the same loop,
removing need for a conditional extra loop.
Performance gain comes from removing a normalization and difference per
iteration. Curves with 0-length segments can benefit further.
For a single curve containing 860K points containing 0-length segments
measured improvement was 1.43x (from 33ms to 23ms).
Test does not utilize threading since it's threaded for curves, adding
threading to single/large curves might be better but would require
the current dependency to previous iterations to be removed.
Pull Request: https://projects.blender.org/blender/blender/pulls/137182
The attribute search for e.g the attribute name input in
the `Store Named Attribute` node did not list attributes
inside Grease Pencil drawings (curve and point domain).
The fix ensures that for the `GeometryComponent::Type::GreasePencil`
we also iterate over the attributes of each evaluated drawing.
Pull Request: https://projects.blender.org/blender/blender/pulls/137267
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
Failure to write an image that didn't set `errno` reported:
"Could not write image: Success"
Check errno is non-zero before using it's message,
ideally error prints would be shown here.
Caused by d3f84449ad.
The problem was that one SharedCache referenced the data of another,
without using the shared_ptr mechanism that is typically used for that
case. I had forgotten to avoid this-- I already did a similar fix a couple
years ago for curves: b07085fe3c
This time I kept the result as part of the cache to avoid the overhead
of attribute access on every call to `Mesh::face_normals()`.
Pull Request: https://projects.blender.org/blender/blender/pulls/137167
Broken by 4c9c9af2d6.
When Grease Pencil objects get converted (<= 4.2 to >= 4.3)
the code copies the legacy color over to the new one.
The issue is that the new color is a `float[3]` not a
`float[4]`! Thus the `flag` after the `color` was getting
overridden.
This fixes the issue by replacing the `copy_v4_v4` with a
`copy_v3_v3`.
Pull Request: https://projects.blender.org/blender/blender/pulls/137161
This commit allows to specialize or optimize properties editor for
particular workflows by hiding individual tabs. The filtering is done on
editor level, currently in editor options popover panel.
Primary motivation was to allow strip properties to be moved to
properties editor. The filtering is beneficial, as usually it does not
make sense to show strip propeties in modelling workspace and in video
editing workspace other properties would introduce quite a bit of noise.
Ref. #115626
Pull Request: https://projects.blender.org/blender/blender/pulls/115624
Support rendering to BMP images with alpha since OIIO supports this.
This was likely left disabled from when Blender's own BMP I/O didn't
support alpha.
Ref !137123
This showed: argument 1 range [18446744071562067968, 18446744073709551615]
exceeds maximum object size 9223372036854775807.
It seems to think signed integers might lead to this kind of overflow,
but it's unclear why these two cases are causing warnings specifically.
Refactor the code to sidestep it.
Add a "Pixel Density" sub-panel to render output settings which
can be used to set the density (as pixels per inch for example).
This is then written to images that support pixel density.
Details:
- The scene has two values a PPM factor and a and base unit.
- The base unit defaults to pixels per inch as this is the most
common unit used.
- Unit presets for pixels per inch/centimeter/meter are included.
- The pixel density is stored in the render result & EXR cache.
- For non 1:1 aspect renders, the density increases on the axis
which looks "stretched", so the PPM will print the correct
aspect with non-square pixels.
Ref !127831
**Problem**
When using Texture Paint mode, the Image Editor will show a UV Wireframe
to display the active object's UVs. In every other mode, this wireframe
is absent. This is currently a big problem for Sculpt Mode since the
Experimental Texture Paint system is a part of that mode, meaning that
the user can't see their UVs while they paint in Sculpt Mode. This is
also troublesome for users that would like to quickly view an object's
UVs without using Texture Paint Mode.
**Solution**
Since it's useful to be able to view an object's UVs at all times, the
Image Editor should display UV Wireframes in all Object Modes regardless
of the Image Editor's mode. This is the best solution since it means
that future Blender features, that would benefit from having a preview
of an object's UV Wireframes, will automatically have that option since
UV Wireframes are supported in all modes. Also, if a user doesn't want
to see UV Wireframes for any reason, it can be disabled with an Overlay
option.
Additionally, when multiple objects are selected, each object should
have its UV Wireframe drawn in the Image Editor. The selected objects
that aren't active should have less opaque wireframes to indicate which
wireframe belongs to the active object. This is the best approach for
having multiple objects selected since it allows the user to quickly
view the UV layout for all selected objects to troubleshoot UV problems,
like texture mapping. This is especially helpful when using a material
for multiple different objects.
An alternative solution would be to only show the UV Wireframe for the
active object, but this would be undesirable because it would make
troubleshooting UV positions tedious when working with multiple objects
since the user would need to select objects individually.
Co-authored-by: T0MIS0N <50230774+T0MIS0N@users.noreply.github.com>
Co-authored-by: Sean Kim <SeanCTKim@protonmail.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/135102
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
Implements a crash dialog for Windows.
The crash popup provides the following actions:
- Restart: reopen Blender from the last saved or auto-saved time
- Report a Bug: forward to Blender bug tracker
- View Crash Log: open the .txt file with the crash log
- Close: Closes without any further action
Pull Request: https://projects.blender.org/blender/blender/pulls/129974
Similar to eae60bc3e6.
The performance improvement depends on the attribute type, domain size,
and whether the cached vert to face map is used for something else like
vertex normal calculation during evaluation. In a simple test with a
large cube, I observed a 6.7x improvement in overall FPS for a 4x4
matrix attribute, a 1.12x improvement for a float attribute, and
roughly equivalent performance for booleans.
Pull Request: https://projects.blender.org/blender/blender/pulls/136941
This commit parallelizes attribute domain interpolation for meshes from
the face corner to vertex domain. Parallel iteration is implemented
using the vertex to face topology map. The same map is used for mesh
normal computations and benefits from potential cost amortization in
its shared cache. This approach then tries to maximize cache usage
while minimizing potential memory consumption by avoiding caching
multiple topology maps.
The performance gain is dependent on the attribute type and domain size.
For a mesh with 16M vertices and 4x4 matrix attribute interpolation,
a 4.5x performance improvement was observed (from 10.7s to 2.38s).
Pull Request: https://projects.blender.org/blender/blender/pulls/135372
This adds a new more accurate antialiasing to the Grease Pencil
render engine. This is only available for render.
This Accumulation AA doesn't replace the SMAA. SMAA is still
used by the viewport and for removing aliasing from the
depth buffer. However, using both at the same time can lead
to overblurred result.
Here are some measurements for how much the render time
increases compared to the baseline with different (SSAA) sample
counts (using an example production file, rendered at 1080p,
results might vary depending on the scene complexity):
* 8 samples: +0.14 s
* 16 samples +0.36 s
* 32 samples: +0.58 s
Co-authored-by: Falk David <falk@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/136551
This patch adds a new interpolation option to the Scale node to control
how pixels are sampled during scaling. For constant sizes, this stores
the interpolation for later realization, while for variable sizes, the
interpolation takes effect immediately.
Pull Request: https://projects.blender.org/blender/blender/pulls/135989
This implements bundles and closures which are described in more detail in this
blog post: https://code.blender.org/2024/11/geometry-nodes-workshop-october-2024/
tl;dr:
* Bundles are containers that allow storing multiple socket values in a single
value. Each value in the bundle is identified by a name. Bundles can be
nested.
* Closures are functions that are created with the Closure Zone and can be
evaluated with the Evaluate Closure node.
To use the patch, the `Bundle and Closure Nodes` experimental feature has to be
enabled. This is necessary, because these features are not fully done yet and
still need iterations to improve the workflow before they can be officially
released. These iterations are easier to do in `main` than in a separate branch
though. That's because this patch is quite large and somewhat prone to merge
conflicts. Also other work we want to do, depends on this.
This adds the following new nodes:
* Combine Bundle: can pack multiple values into one.
* Separate Bundle: extracts values from a bundle.
* Closure Zone: outputs a closure zone for use in the `Evaluate Closure` node.
* Evaluate Closure: evaluates the passed in closure.
Things that will be added soon after this lands:
* Fields in bundles and closures. The way this is done changes with #134811, so
I rather implement this once both are in `main`.
* UI features for keeping sockets in sync (right now there are warnings only).
One bigger issue is the limited support for lazyness. For example, all inputs of
a Combine Bundle node will be evaluated, even if they are not all needed. The
same is true for all captured values of a closure. This is a deeper limitation
that needs to be resolved at some point. This will likely be done after an
initial version of this patch is done.
Pull Request: https://projects.blender.org/blender/blender/pulls/128340
The issue was that the offset would offset by a different
amount depending on the scale property.
This is a regression from the legacy behavior,
and also harder to control in general.
The versioning code only touches FCurves that are not marked
as "legacy" because the legacy noise didn't have that issue.
Pull Request: https://projects.blender.org/blender/blender/pulls/136502
When file with legacy GP is opened in newer version, dopesheet
channel color is not transferred, they appear dark instead. To
fix this, copy color value from legacy GP layers in versioning code.
Pull Request: https://projects.blender.org/blender/blender/pulls/136876
Partial redrawing of the 3d viewport has not worked since the transition
to 2.8. Despite this, we still calculate the paint BVH bounds of the
affected area.
To avoid this wasted work and simplify the code, we remove the related
functions. Further work to enable partial redraws would not necessarily
be integrated in the same way. Additionally, a minor speedup of 1.05x
(1.00ms to 0.95ms) can be observed with this commit when performing
weight painting on a mesh with 2 million elements.
Similar to #136471
Pull Request: https://projects.blender.org/blender/blender/pulls/136912
* Change #define constant value to static constexpr
* Adds const where possible
* Uses reference instead of pointer where possible
* Uses `float3` instead of raw float array where possible
* Uses std::optional to indicate value that may be null
* Reduces scope of variables where possible
* Uses `std::array` instead of raw arrays where possible
* Combines assignment and declaration where possible
* Lengthens some names from single letters
Pull Request: https://projects.blender.org/blender/blender/pulls/135486
