There seems to be a driver bug on Linux + Mesa + AMD
The bug only appears in renderdoc if looking at the film pass
but not in the motion blur pass nor the volume pass.
Adding a clear event seems to fix the issue.
- enum class StripEarlyOut instead of raw integer defines
- SeqRenderState default initializer instead of seq_render_state_init
- Vector<Sequence*> instead of manually sized arrays of pointers
- some const to several function arguments
Pull Request: https://projects.blender.org/blender/blender/pulls/117829
This patch unifies the implementation of the Bilateral Blur node across
CPU and GPU. The difference is due to two things. First, the CPU code
had a bug where the upper limit of the blur window was not included in
the accumulation. Second, CPU ignored pixels outside of the image while
GPU clamped them to the nearest boundary pixel. The latter difference
was aligned with GPU until we eventually add an option to control
boundary handing.
A few utilities were added to the node operation and memory buffer
classes to do clamped pixel reading.
Pull Request: https://projects.blender.org/blender/blender/pulls/117751
Linked bone collections are disabled in b79419914a
Include 'Disabled' tooltip for `move and assign to collection`
operation when bcol are linked.
In poll functions all other cases are already handled and also not
possible to get the index of hovered collection so just include
`poll_msg_set` in the end.
Pull Request: https://projects.blender.org/blender/blender/pulls/117715
isect_point_tri_v2 and isect_point_quad_v2 are handling tris/quads
in either clockwise or counter-clockwise vertex orderings. However,
for clockwise order it was considering points that lie on the edges
or vertices as "inside", whereas for counter-clockwise it was treating
them as "outside".
Visibly affected place is VSE: it has an optimization that checks
whether a fully opaque strip image fully covers the rendered area.
When the strip was scaled up to *exactly* cover the rendered area,
the check was failing since isect_point_quad_v2 was saying that a
point is outside the rect.
As far as I can tell, the functions have been "slightly wrong" in
this way for at least 15 years; harder to see through earlier
history in git.
Added a bunch of unit tests to cover this. Without the fix, "edge"
and "corner" cases against "cw" tri/quad were failing.
Performance (checked on clang15 on M1 Max):
- isect_point_tri_v2 is pretty much the same performance (assembly
several instructions shorter),
- isect_point_quad_v2 is about three times *faster* (assembly 2x
shorter), seemingly the compiler is able to use some SIMD now.
Pull Request: https://projects.blender.org/blender/blender/pulls/117786
This adds support for baking the volume component of a geometry. Previously,
volumes were just removed in the simulation and bake node.
On disk, each volume geometry is written to a separate `.vdb` file that is stored in
the bakes `blobs` directory and referenced from the corresponding meta `.json` file.
Technically, it would also be easy to write the volume data to the same `.blob`
files that we also write e.g. mesh attributes to. However, since `.vdb` is a well
known file format, it seems reasonable to just store it as a separate file. The
serialization code doesn't really care whether it's a separate file or embedded into
a bigger file, so this decision could be made at a higher level.
Just like with other geometry types, materials are preserved. Just note that when
using the written stand-alone .vdb files, materials are not preserved.
Currently, volume grids are not deduplicated on disk. This could be added in the
future if necessary.
Pull Request: https://projects.blender.org/blender/blender/pulls/117781
Replace: {BLENDER_RESOURCE_PATH_USER}/scripts/extensions
With: {BLENDER_RESOURCE_PATH_USER}/extensions
This makes more sense as not all extensions are scripts.
This adds the processing required to import and export, simple, material
graphs utilizing the UsdUVTexture Scale and Bias inputs.
Since Blender does not have equivalent inputs on its Image node, a
Multiply-Add node is used instead. This matches the calculation as per
the UsdPreviewSurface spec[1]
A complicating factor here is when these two inputs are used for normal
map textures. The Scale and Bias inputs are authored in such a way to
take the [0, 1] image data and expand into the [-1, 1] tangent space
range as per the spec. However, the Blender Normal Map node expects to
do this transformation itself. The processing in this patch needs to
account for this. For the case of normal maps it will:
- Apply the Scale-Bias calculation directly as authored
- Apply an additional transform to move from [-1, 1] back into [0, 1]
- Feeds this into the Normal Map node
This processing extends to Export as well. During material graph
traversal we need to "skip" the middle adjustment transform and only
export the "real" Scale-Bias data. Traversing the graph like this can be
error prone but is probably the best we can do without having a native
Scale-Bias concept on Blender's Image node.
[1] https://openusd.org/release/spec_usdpreviewsurface.html#texture-reader
Pull Request: https://projects.blender.org/blender/blender/pulls/115224
This adds hash-based data deduplication when baking in
geometry nodes. All arrays that are written to `.blob` files
are hashed. If an array is detected to have the same hash
as a previously written array, it is not written again. Instead
the same memory is reused.
We already have a similar optimization, but that only worked .with data that was already implicitly shared. Doing this kind
of deduplication with implicitly shared data has the benefit,
that the equality check is constant time. The hash based
approach implemented here requires linear time in the size
of the array, but works on all kinds of data. Both optimizations
work together. So the hashing is skipped if possible.
The hash-based deduplication primarily benefits cases where
the data is regenerated on each frame, so the data between .frames is not shared. One example used to require 2.9 GB
disk space. Now it only requires 542 MB. Additionally, the
duplicate arrays will now be implicitly shared between frames
when reading the baked data later.
An extended version of this approach which also detects partial
duplicates is implemented in #117749.
Pull Request: https://projects.blender.org/blender/blender/pulls/117768
- Use unique_ptr instead of raw pointers
- Use Vector instead of a linked list
- Use a destructor instead of a free function
- Remove the space type template-- it's much clearer to copy functional code
Pull Request: https://projects.blender.org/blender/blender/pulls/117766
Image vectorscope is getting some visual updates (#116974), here make the
Sequencer vectorscope match the look fairly closely:
- Use same scaling factor for both U & V, instead of trying to use all
the texture space.
- Instead of drawing hexagonal area between color primary "pure" and
"75% saturation safe" points, draw a circle with colored background
and five inner rings.
- Indicate "75% saturation primaries" as wire rectangles with a text label.
Images in PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/117738
Without doing a stroke "manually", colorspace initialization on
UnifiedPaintSettings was never done.
This lead to wrong colors in the past, since modern CS code with OIIO
this also crashes.
Colorspace was added into UnifiedPaintSettings in 6f153046e0 to avoid
doing this when sampling the brush texture images [which is good], but
the initalization was done in `paint_brush_update`.
We dont need to have this called for every step (it was skipped anyways
after one run), so it seems we can move this out of `paint_brush_update`
and put this into `paint_stroke_new`.
Thx @RevDr for initial findings.
Pull Request: https://projects.blender.org/blender/blender/pulls/117756
The render shadow loop would always tag new casters to update
the tiles that were already rendered. This patch split the
caster tagging into it's own pass and move it out of the loop.
Also adds a needed `async_flush_to_host` to make sure the
statistic buffer is up to date.
For ARMATURE_OT_move_to_collection, when moving to a NEW collection,
title of "Move to New Collection" and confirm button that says "Move".
For POSE_OT_paths_calculate, title of "Calculate Paths for the Selected
Bones", confirm button text of "Calculate"
Pull Request: https://projects.blender.org/blender/blender/pulls/117741
Part of overall "improve image filtering situation" (#116980), this PR addresses
two issues:
- Bilinear (default) image filtering makes half a source pixel wide transparent
border around the image. This is very noticeable when scaling images/movies up
in VSE. However, when there is no scaling up but you have slightly rotated
image, this creates a "somewhat nice" anti-aliasing around the edge.
- The other filtering kinds (e.g. cubic) do not have this behavior. So they do
not create unexpected transparency when scaling up (yay), however for slightly
rotated images the edge is "jagged" (oh no).
More detail and images in PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/117717
The root cause is still unknown. But replacing the
use of the depth texture by the hiz buffer fixes the
issue.
The issue was apparent on Linux + Mesa + AMD.
Store the 'expanded/collapsed' state of the bone collection tree view in
the DNA data of the bone collections themselves. This way the tree state
is restored when loading the file.
This commit also adds some code to the abstract tree view classes, for
supporting synchronisation of the extended/collapsed state between it
and external data. It follows the same approach as the handling of the
active element.
RNA wrappers have been added to make it possible for Python code to
expand/collapse parts of the tree.
Library overrides are supported for this property, so the
expanded/collapsed state of linked armatures can be locally saved. If
there is no override, the `is_expanded` property is still editable;
changes will not be saved to file in that case, though.
Pull Request: https://projects.blender.org/blender/blender/pulls/116940
The function name "operator poll message set" is rather troublesome, as:
- the message is only used when the operator is disabled, and
- the message is shown if the operator is disabled by any means, and not
just limited to the `poll()` function returning `false`.
A better name would be `CTX_wm_operator_disabled_msg_set`, but refactoring
that is for another time. Now at least the behaviour is documented.
No functional changes.
