After creating a new shading material, the new node tree might become invisible and the user has to scroll down to see the nodes.
The idea of this PR is to create nodes with x-positions centered around zero, such that they are always visible no matter the screen size or workspace setup. Ideally, the nodes' position should depend on the region's zoom and pan. However, the node creation code currently does not depend on `SpaceNode`, so such solution would complicate the code a bit. Also, this heuristic seem to work well enough for most cases.
Note: this only affects newly created materials. The material of the default cube and the default world material still have invisible nodes sometimes. This is because they are saved in the startup file, which will be addressed in a different patch.
Pull Request: https://projects.blender.org/blender/blender/pulls/136926
Since nodes are not uniquely assigned to zones (some nodes are in two
zones at the same time), it's better not to expose this detail in multiple
APIs. This avoids having to explain the behavior multiple times.
Now one just has to use `get_zone_by_node/socket` and can then use
a seperate method to get the zone stack for that zone like before.
This patch turns the options of the Tone Map node into inputs.
In the process, a few changes were made. Input ranges were adjusted to
remove artificial limits. The papers indeed mention those limits, but
they were only mentioned as typical values, not valid ranges.
- The Key option is no longer limited to 1.
- Gamma is no longer limited to a value of 3.
- Intensity is no longer limited to [-8, 8].
- Contrast is no longer limited to [0, 1].
A few renames were done to clarify options and match the reference
papers.
- Offset was renamed to Balance, since it is not really an offset, but
balances between shadows and highlights. This can be looked up in the
paper.
- Correction was renamed to Chromatic Adaptation, since it doesn't
really correct anything.
- Adaptation was renamed to Light Adaptation to distinguish from
Chromatic Adaptation and now default to global tone mapping, since
this is more useful by default.
Reference #137223.
Pull Request: https://projects.blender.org/blender/blender/pulls/137589
Clearing a mesh's geometry without freeing the mesh has the requirement
that the mesh remain initialized afterwards. Freeing the mesh doesn't
have that requirement and corresponds to a destructor rather than move
construction with the default value. Avoiding conflating the two
operations simplifies some future feature additions (including #122398).
Making local an intermediate collection in a liboverride hierarchy e.g.
will likely break the link between the objects in that collection, and
their hierarchy root ID (typically the top overridden collection).
This is fixed by this commit, by:
* Adding a new util, `lib_override_root_is_valid`, that check whether a
given liboverride ID is still 'connected' to its hierarchy root.
* Using this test in `BKE_lib_override_library_main_hierarchy_root_ensure`
to strengthen the detection of invalid root hierarchy pointers.
Not sure why it was not done before... But it should be fine to
completely ignore the loopback relationships (mainly liboverride
hierarchy root pointers themselves, and owners of embedded and
shape key IDs) when handling hierarchies.
Quick tests on complex production cases here also showed no obvious
issue (or even change at all) with this tweak, so think it's safe to try
it out in main.
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
