The "Red Alert" color is currently hard-coded, which causes problems in
themes. It also has an Enum value of 0, which precludes using this
value as "unset". We also use Error, Warning, and Info colors that are
part of the Info Editor. This PR moves these out of the Info Editor
and into the "State" part of the theme. And then makes TH_REDALERT use
the TH_ERROR color.
Pull Request: https://projects.blender.org/blender/blender/pulls/131127
This patch uses OCIO luminance for implicit conversion from color to
float in the compositor. This is done to match other node systems, and
because luminance is a much better default than the average formula used
before.
Versioning was added to retain average conversion for old files.
Pull Request: https://projects.blender.org/blender/blender/pulls/133206
Reason for this is that all the brushes in essentials assets have a zero
default `mask_stencil_pos` / `mask_stencil_dimension`.
At that time, they have been created resetting a brush to defaults and
using that as a starting point.
At that time though, these settings didnt have a default (which
b2dd308dca fixed, so that method should not result in those settings
being zero).
The brushes in essentials assets still do though, now correct these in
versioning code.
Pull Request: https://projects.blender.org/blender/blender/pulls/133374
Previously, when evaluated on the face corner domain, the normal input
node just returned the face normals, as if the mesh was completely flat
shaded. This ignores face and edge smoothness, and custom face corner
normals. In the past couple years the expected behavior of accessing
normals has become much clearer and this behavior is clearly a mistake
in retrospect.
This commit exposes the same face corner normals used everywhere else
in Blender when the node is evaluated on the corner domain. The old
behavior is accessible with a node property in the sidebar. There is
versioning so old files have the property set and get the same results.
This is split from !132583.
Pull Request: https://projects.blender.org/blender/blender/pulls/133340
The hardcoded value doesn't work well with real scale human heads for
example (was already adjusted once in a76b5d3a07).
The result for too high values is a complete "freeze" of the whole curve
(since the solution from e7606139ba has the problem that it keeps
running into max iterations of the collision solver).
As long as no better solver is implemented, it is better to have an
adjustable value (to work on differently sizes objects) to not run into
the above issue (same as the old particle hair system had) and show it
in sculptmode next to the button which enables collision.
This is done per `Curves` (same as the flag
`CV_SCULPT_COLLISION_ENABLED`), similar to symmetry settings
[alternatively, it could be part of `BrushCurvesSculptSettings` but I
think it makes more sense in Curves] and then passed on to the
`CurvesConstraintSolver`.
Includes versioning code (to set the default for old files).
Pull Request: https://projects.blender.org/blender/blender/pulls/132997
Cycles has a sample offset feature allowing users to render X samples
in a single frame on one device, then the remaining Y samples later or
on a different device and combine them back together at the end.
However in most situations the result from using this method was
different, and usually lower quality than rendering all the samples in
one go.
This was because Cycles tunes it's random number sequence for the
number of samples being rendered. And the random number sequence was
being tuned for the wrong number of samples in the case that a user
was using the sample offset.
This commit fixes this issue by adding a "sample subset" feature.
The user specifies the total sample count being rendered across all
devices in the existing `Max Samples` parameter, then specifies per
device which subset of samples will be rendered (E.g. Render samples
0-1024 out of a 0-2048 range).
This commit also contains some additional clean up work
inside Cycles related to the area being changed.
Co-authored-by: Brecht Van Lommel <brecht@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/132961
This patch normalizes the Bloom output to be more energy conserving and
in a reasonable range. This is essentially constructed such that the
impulse response to a constant input maintains the same input.
The reason why Bloom has a very high range is because it accumulates a
downsampling chain without any sort of attenuation, so the final result
can be quite large. EEVEE fixed that by making the Strength range in the
[0, 0.1] range, so users who are used to that range think the default
value of a unit Strength in the glare node is large and hard to work
with. Hence the need for this patch.
The normalization factor is simply the length of the chain, since for a
constant input, all chain images will have the same constant input.
We need to version this change in a similar manner to how the glare node
was versioned in 004e3d39fa, where the scene render size is assumed. We
also assume the inputs are not connected, because they were turned into
inputs just last week, so we needn't worry about that case.
This is a partial implementation of #124176 to address #131325.
Pull Request: https://projects.blender.org/blender/blender/pulls/133037
This patch adds two new inputs to the Glare node, Highlights Smoothness
and Max Highlights. Smoothness allows the user to control how smooth the
highlights are after thresholding and Max allows the user to suppress
very high brightness pixels.
Those are essentially similar to the Knee and Clamp options in old EEVEE
bloom, though they work differently.
The issue with the Knee parameter in old EEVEE bloom, aside from being
named after a body part, is that it actually isn't smooth or continuous
around zero if the threshold is sufficiently close to zero relative to
the Knee parameter. That's because zero lies in the smoothing kernel
region in those cases, and since zero pixels becoming highlights is very
bad, EEVEE just returned zero as a special case for zero brightness, but
values like 0.0001 will be full blown highlights.
The new nicely named Smoothness input uses adaptive smoothing such that
the smoothing kernel size will be reduced as the threshold nears zero,
such that smoothed highlights will be continuous and smooth around zero.
The Max Highlights input is similar to clamped, it it suppresses very
bright highlights such that their brightness doesn't exceed the
specified max.
This is a partial implementation of #124176 to address #131325.
Pull Request: https://projects.blender.org/blender/blender/pulls/132864
This patch redesigns the Glare node to improve the user experience. The
improvements are as follows.
Two new outputs were added, Glare and Highlights. The Glare output gives
the generated glare without the input, and is useful when the user wants
to adjust the glare before adding it to the image. The Highlights output
gives the areas that are considered highlights when computing the glare,
and is useful if the user wants to temporally check the highlights while
doing adjustments or wants to use those as a base for creating a custom
glare setup.
The Mix node option was removed and a new Strength single value input
was added to serve the same functionality. The Mix option had a range of
[-1, 1], where the [-1, 0] sub-range essentially controlled the strength
of the glare, 0 being full strength and -1 being zero strength. While
the [0, 1] range returned the generated glare with an attenuated version
of the image added, that is, it was useless except for the value of 1,
which returned the generate glare only.
Aside from being a very intuitive range, it also meant that the power of
glare can't be boosted beyond the full strength of, you guessed it, 0.
The newly added Strength input has a soft range of [0, 1] and can be
boosted beyond 1. If the users want the glare only, they can use the
newly provided Glare output.
The Size node option used for Bloom and Fog Glow was removed and a new
Size single value input was added. The Size node option had yet another
very intuitive range of [1, 9], and it was related exponentially to the
actual size of the Glare. For Bloom, the actual bloom size relative to
the image was 2^(Size-9), so a Size of 8 means the bloom covers half of
the image. For Fog Glow, the actual bloom size in pixels is 2^Size, so
the glare size is not relative to the image size and would thus change
as the image resolution change. Furthermore, the maximum possible glare
size was 512 pixels, and the user couldn't make fine adjustments to the
size.
The newly added Size input has a range [0, 1], where 1 means the glare
covers the entire image, 0.5 means it covers half the image, and so on.
That means it is consistent between Bloom and Fog Glow, it is relative
to the image size, it allows as large of a glare as possible, it is
continuous for Fog Glow, but not for Bloom because that requires an
algorithmic change that will be implemented separately.
The Threshold, Streaks, Streaks Angle, Iterations, Fade, and Color
Modulation node option was turned into a single value node input to
allow the option to be used in node groups.
---
Versioning was added to transfer node options into sockets, but it is
not all 1:1 versioning, since the old Size option was not relative to
the image size, so it depends on runtime information of the input size.
As a guess, we assume the render size in that case. Versioning the
[0, 1] range of the Mix option intentionally omits the attenuation of
the image input, because that is almost certainly not what the user
wants and was probably done thinking it controls the strength.
Glare code now sets the alpha channel to 1, that's because it was
already ignored in the mixing step, but now that we expose the Glare
output, we need to set it to 1. So this is not a functional change.
The get_glare_size() method was renamed for clarity since it now
conflicts with the newly added Size input.
---
This is a partial implementation of #124176 to address #131325. In
particular, it adjust existing functionality, it doesn't add any new
ones. Those will be added in separate patches.
Pull Request: https://projects.blender.org/blender/blender/pulls/132499
This commit exposes the "Quality" option of the Open Image Denoiser
to the user for the denoise node in the compositor.
There are a few quality modes:
- High - Highest quality, but takes the longest to process.
- Balanced - Slightly lower quality, but usually halves
the processing time compared to High.
- Fast - Further reduce the quality, for a small increase in
speed over Balanced.
Along with that there is a `Follow Scene` option which will use the
quality set in the scene settings.
This allows users that have multiple denoise nodes
(E.g. For multi-pass denoising), to quickly switch all nodes between
different quality modes.
Performance (denoising time):
High: 13 seconds
Balanced: 6 seconds
Fast: 5 seconds
Test setup:
CPU: AMD Ryzen 9 5950X
Denoising a 3840x2160 render
---
Follow ups:
Ideally the "Denoise Nodes" UI panel in the render properties panel
would be hidden if the compositor setup does not contain any
denoise nodes.
However implementing this efficiently can be difficult and so it was
decided this task was outside the scope of this commit.
Pull Request: https://projects.blender.org/blender/blender/pulls/130252
For some reason, the file in this report had its second mix shader socket with
the identifier "Socket.001" instead of the current "Socket_001". The age of
the file roughly corresponds to when we switched to the node declaration
system. I'm not sure why it has `.` instead of `_`, since the old socket template
system also used `_` as the deliminator. I vaguely remember some issue like
this but it's been a while and I can't find anything online.
The fix is to just manually change the socket identifier. The subversion bump
isn't conceptually necessary, it's just to stop the versioning from running
more often than necessary once the file is saved again.
Pull Request: https://projects.blender.org/blender/blender/pulls/132199
This commit implements most features needed for simple text editing.
Active text strip can be edited in preview by pressing tab key, which
enabled text editing mode. With this mode active, outline matches text
boundary box and cursor is drawn.
Cursor can be moved with usual keys. Pressing shift starts selection.
Selection and navigation works when text is scaled or rotated. Mirrored
text is not supported in this PR. it can be done, but the text is
unreadable that way, so I kept it simple.
Multi line text is supported. Pressing return key starts new line.
Copy/paste operator uses OS copy paste buffer, so text from other apps
can be pasted.
Text is still limited to 512 characters. Text string property still
exists in side panel and is limited to single line. Individual
characters can not be styled in different way like in 3D viewport, but
the code is mostly ready for such feature.
Ref: #126547
Pull Request: https://projects.blender.org/blender/blender/pulls/127239
The issue here was sometimes an output socket of a `Group Input` node has a
reference to a data-block. The value stored on these output sockets are never
used, and thus is not exposed in the UI which made it impossible for the user to
find that there still is a data-block reference.
The root cause for this seems to have been fixed a few releases ago. I can
reproduce that the pointer was set in 3.3, but not in 3.6.
This patch only adds some versioning to remove the unnecessary data-block
references to fix old files that might have this issue (e.g. the file from the
report).
Pull Request: https://projects.blender.org/blender/blender/pulls/131900
The "use attribute" and "attribute name" IDProperties were missing
the overrideable status and the static type status. This was an oversight
from when those tags were added.
This commit fixes the flag on new modifier properties as they're created
and applies versioning to old properties. It also fixes the poll of the toggle
input attribute operator so that it isn't possible on non-editable objects.
Pull Request: https://projects.blender.org/blender/blender/pulls/131768
Currently each node's position is stored in the coordinate space of
its parent. To find the location of a node on the canvas, we have to
apply the translation of each of its parents. Also, nodes have hidden
"offset" values used while transforming frame nodes. Together,
those made the system much more complicated than necessary,
and they made the Python API ineffective.
This commit removes usage of the offset values and moves nodes
to be stored in the "global" space of the node canvas. It also resolves
some weird behavior when resizing frame nodes, and fixes a few bugs.
The change is forward compatible, so we still write files with nodes in
the old parent-space format. In 5.0 the conversion when writing can be
removed. The existing Python API also stays the same. A new
"location_absolute" property gives node locations in global space,
and changing the old property also moves the child nodes of frames.
Resolves#92458, #72904.
Pull Request: https://projects.blender.org/blender/blender/pulls/131335
Missed in 9945d511a9
The previous commit fixed files that had not yet been saved in 4.3,
however, the versioning code was not bumped which means that a user who
had a file in a version prior to 4.2 that then saved with the full
release of 4.3 would not have the corrected versioning applied for their
texture paint workspaces.
This commit re-applies similar versioning code and bumps the version
to ensure files are up to date.
Pull Request: https://projects.blender.org/blender/blender/pulls/131337
Add a Mesh implementation of triangulation, which is currently just
implemented for BMesh. The main benefit of this is performance and
decreased memory usage. The benefit is especially large because the
node currently converts to BMesh, triangulates, and then converts back.
But the BMesh implementation is entirely single threaded, so it will
always be much slower.
The new implementation uses the principle of "never just process a
single element at a time" but it also tries to avoid processing _too_
many elements at once, to decrease the size of temporary buffers.
Practically that means the work is organized into chunks of selected
faces, but within each chunk, each task is done in a separate loop.
Arguably I went a bit far with some optimizations, and some of the
complexity isn't necessary, but I hope everything is clear anyway.
Unlike some other Mesh ports like the extrude node or the split edges
code, this generates a new mesh. I still go back and forth on that
aspect, but reusing the same mesh would have required reallocating
face attributes from scratch anyway. Implicit sharing is used to
avoid copying vertex attributes though.
The result mesh is reorganized a bit. Unselected face data comes first,
then selected triangles, then triangulated NGons, then triangulated
quads. This makes attribute interpolation and internal calculations
more efficient.
The "Minimum Vertices" socket is replaced with versioning. In the new
implementation it would have an impact on code complexity, and for a
builtin "atomic" node it makes more sense as part of the selection.
The performance difference depends on the number of CPU threads, the
number of attributes, and the selection size. As all of those numbers
go up, the benefit will grow. The "modes" also affect the performance,
obviously.
With a Ryzen 7950x, I tested performance in a few situations (in ms):
| | Selection | Before | After | Change |
| -------------------------- | --------- | ------ | ----- | ------ |
| 1.4 m quads (fixed) | 50% | 1533 | 15.9 | 96x |
| 10 m quads (shortest) | 100% | 9700 | 165.0 | 59x |
| 1 m 10-side Ngons (beauty) | 90% | 3785 | 115.9 | 33x |
| 1 m quads many attributes | 100% | 54600 | 332.3 | 164x |
In follow-up commits, I'll move other areas to use mesh triangulation
instead of BMesh. This is the last geometry node using BMesh besides
the Ico Sphere primitive.
Pull Request: https://projects.blender.org/blender/blender/pulls/112264
This PR changes the default theme color for TH_FACE_FRONT, used by the
Face Orientation overlay, to have zero alpha. That way, by default, it
can be used always and not interfere with the display of (normal) front
faces.
Pull Request: https://projects.blender.org/blender/blender/pulls/130618
Currently the node behaves differently from the modifier by default
because it lacks the option to use the limit surface. This is mainly
an oversight, since the option gives better results and better
performance.
This adds a new "Limit Surface" option. Because it's on by default,
there is also versioning to turn it off for existing files.
Resolves#112912.
Pull Request: https://projects.blender.org/blender/blender/pulls/130243
So far asset browsers always sorted assets by name, which resulted in
barely related assets being placed together, and related assets being
scattered. This can make navigating assets tedious, and introduces a lot
of visual noise because of scattered preview image styles.
Related assets are typically put into common asset catalogs, and related
catalogs are typically organized close to each other in the catalog
hierarchy. This makes catalogs a better characteristic to sort by,
solving the mentioned issues.
For asset shelves sorting by catalogs was introduced in 471378c666. This
PR exposes this feature to the asset browser, by introducing a new
option to sort either by name or by catalog. The new default is sorting
by catalog. Within a single catalog, assets are still sorted alphabetically.
Pull Request: https://projects.blender.org/blender/blender/pulls/129480
3a708a27f9 and c8e75c03c3 include a version bump in the release branch.
The main branch should also get a version bump so the same versioning
code runs for files saved with main.
This commit takes the 'Slotted Actions' out of the experimental phase.
As a result:
- All newly created Actions will be slotted Actions.
- Legacy Actions loaded from disk will be versioned to slotted Actions.
- The new Python API for slots, layers, strips, and channel bags is
available.
- The legacy Python API for accessing F-Curves and Action Groups is
still available, and will operate on the F-Curves/Groups for the first
slot only.
- Creating an Action by keying (via the UI, operators, or the
`rna_struct.keyframe_insert` function) will try and share Actions
between related data-blocks. See !126655 for more info about this.
- Assigning an Action to a data-block will auto-assign a suitable Action
Slot. The logic for this is described below. However, There are cases
where this does _not_ automatically assign a slot, and thus the Action
will effectively _not_ animate the data-block. Effort has been spent
to make Action selection work both reliably for Blender users as well
as keep the behaviour the same for Python scripts. Where these two
goals did not converge, reliability and understandability for users
was prioritised.
Auto-selection of the Action Slot upon assigning the Action works as
follows. The first rule to find a slot wins.
1. The data-block remembers the slot name that was last assigned. If the
newly assigned Action has a slot with that name, it is chosen.
2. If the Action has a slot with the same name as the data-block, it is
chosen.
3. If the Action has only one slot, and it has never been assigned to
anything, it is chosen.
4. If the Action is assigned to an NLA strip or an Action constraint,
and the Action has a single slot, and that slot has a suitable ID
type, it is chosen.
This last step is what I was referring to with "Where these two goals
did not converge, reliability and understandability for users was
prioritised." For regular Action assignments (like via the Action
selectors in the Properties editor) this rule doesn't apply, even though
with legacy Actions the final state ("it is animated by this Action")
differs from the final state with slotted Actions ("it has no slot so is
not animated"). This is done to support the following workflow:
- Create an Action by animating Cube.
- In order to animate Suzanne with that same Action, assign the Action
to Suzanne.
- Start keying Suzanne. This auto-creates and auto-assigns a new slot
for Suzanne.
If rule 4. above would apply in this case, the 2nd step would
automatically select the Cube slot for Suzanne as well, which would
immediately overwrite Suzanne's properties with the Cube animation.
Technically, this commit:
- removes the `WITH_ANIM_BAKLAVA` build flag,
- removes the `use_animation_baklava` experimental flag in preferences,
- updates the code to properly deal with the fact that empty Actions are
now always considered slotted/layered Actions (instead of that relying
on the user preference).
Note that 'slotted Actions' and 'layered Actions' are the exact same
thing, just focusing on different aspects (slot & layers) of the new
data model.
The "Baklava phase 1" assumptions are still asserted. This means that:
- an Action can have zero or one layer,
- that layer can have zero or one strip,
- that strip must be of type 'keyframe' and be infinite with zero
offset.
The code to handle legacy Actions is NOT removed in this commit. It will
be removed later. For now it's likely better to keep it around as
reference to the old behaviour in order to aid in some inevitable
bugfixing.
Ref: #120406
Part of: https://projects.blender.org/blender/blender/issues/128066
Adds a "Filter by Active Tool" option for the brush asset shelves,
enabled by default. If enabled, the asset shelf only shows brushes
matching the brush type of the current tool. If the general "Brush" tool
is active, only brushes that are not covered by another tool are
displayed. The popup brush selector always shows all assets.
The option is stored in the Preferences, toggled in the "Display
Settings" popover of the asset shelf.
Note: This is committed to the 4.3 release branch, which was discussed
in advance.
Pull Request: https://projects.blender.org/blender/blender/pulls/128450
This does the following changes:
* Show info "warnings" in modifier too. Previously those were skipped. The
different behavior of info/warning/error messages causes confusion.
* Add a new `Warnings` panel that only shows when there are warnings. In its
title, it shows how many warnings there are.
* In the panel, warnings are sorted by severity and alphabetically.
Pull Request: https://projects.blender.org/blender/blender/pulls/128395
Customizable highlighting of editor edges that can be used to help
differentiate between areas, indicate active area, and/or help users
with visual impairment. Can be completely removed as well. This
replaces the active area header highlighting, which doesn't work for
transparent headers.
Pull Request: https://projects.blender.org/blender/blender/pulls/116684
It is too easy to accidentally enable skipping the simulation while moving the
node around without noticing. Now it is necessary to pass in a boolean value
from another node to modify the skip value. Existing files that had this
checkbox checked are updated by versioning code.
This implements #127506.
Pull Request: https://projects.blender.org/blender/blender/pulls/127988
This adds a new type of zone to Geometry Nodes that allows executing some nodes
for each element in a geometry.
## Features
* The `Selection` input allows iterating over a subset of elements on the set
domain.
* Fields passed into the input node are available as single values inside of the
zone.
* The input geometry can be split up into separate (completely independent)
geometries for each element (on all domains except face corner).
* New attributes can be created on the input geometry by outputting a single
value from each iteration.
* New geometries can be generated in each iteration.
* All of these geometries are joined to form the final output.
* Attributes from the input geometry are propagated to the output
geometries.
## Evaluation
The evaluation strategy is similar to the one used for repeat zones. Namely, it
dynamically builds a `lazy_function::Graph` once it knows how many iterations
are necessary. It contains a separate node for each iteration. The inputs for
each iteration are hardcoded into the graph. The outputs of each iteration a
passed to a separate lazy-function that reduces all the values down to the final
outputs. This final output can have a huge number of inputs and that is not
ideal for multi-threading yet, but that can still be improved in the future.
## Performance
There is a non-neglilible amount of overhead for each iteration. The overhead is
way larger than the per-element overhead when just doing field evaluation.
Therefore, normal field evaluation should be preferred when possible. That can
partially still be optimized if there is only some number crunching going on in
the zone but that optimization is not implemented yet.
However, processing many small geometries (e.g. each hair of a character
separately) will likely **always be slower** than working on fewer larger
geoemtries. The additional flexibility you get by processing each element
separately comes at the cost that Blender can't optimize the operation as well.
For node groups that need to handle lots of geometry elements, we recommend
trying to design the node setup so that iteration over tiny sub-geometries is
not required.
An opposite point is true as well though. It can be faster to process more
medium sized geometries in parallel than fewer very large geometries because of
more multi-threading opportunities. The exact threshold between tiny, medium and
large geometries depends on a lot of factors though.
Overall, this initial version of the new zone does not implement all
optimization opportunities yet, but the points mentioned above will still hold
true later.
Pull Request: https://projects.blender.org/blender/blender/pulls/127331
The reroute node used to be a bit special in the sense that its data type was
only stored in the sockets. However, typically, the ground truth data should be
stored in the node storage and then the socket types are derived from that.
For users, there should not be a noticable difference. However, from Python
it's not possible to modify the socket type directly on the socket anymore.
This is forbidden for other built-in nodes already too.
Instead, one can use the new `reroute_node.socket_idname` property to change
the type of a node. This internally also recreates the sockets with the correct
type.
Pull Request: https://projects.blender.org/blender/blender/pulls/121146
As of 2a56403cb0, bevel weight data is stored as a generic
attribute. The bevel modifier is currently hard-coded to use the
`bevel_weight_edge` attribute as the data source for the weights.
This commit adds a string textbox where the user can specify alternate
attributes for the bevel's edge weights.
The string name field is added as a search button which provides a list
of all attributes in the original mesh. This is meant to work similarly
to geometry nodes, so mismatched attribute data types and domains are
automatically converted/interpolated as necessary. Attributes created
by previous modifiers can also be used, but they won't appear in the
search menu.
Co-authored-by: Hans Goudey <hans@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/117366
