This makes accessing these properties more convenient. Since we only ever have
const references to `CPPType`, there isn't really a benefit to using methods to
avoid mutation.
Pull Request: https://projects.blender.org/blender/blender/pulls/137482
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
As Relocate code temporarily removes some linked IDs from Main, this can
make collection hierarchy data invalid, in a way that will break
`BKE_main_collections_parent_relations_rebuild`.
For now, simply move that call outside of `BLO_library_link_end` and do
it after adding back all linked IDs to main.
Pull Request: https://projects.blender.org/blender/blender/pulls/135936
Relocation is the only case where old and new linked data may have
a different library. This makes remapping dependencies IDs for the
liboverrides that use these linked data somewhat more challenging and
complicated.
From basic tests with both simple data, and full production-level
Mikassa char, it seems to behave fairly well now.
So far it was only possible to relocate a whole library, now one can
also relocate a single linked ID (pulling in all of its dependencies).
This is essentially linking the new data, remapping local usages of the
old linked data to the new one, removing no more used IDs, and updating
liboverrides if needed.
Previously, internal links used the same heuristics as most other nodes. However,
this is more problematic here, because I intend to use the same internal links
for the case when no closure is connected. The behavior in this case should not
change in the future if we decide to change the heuristic for internal links for
muted nodes.
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
