When debugging the descriptor sets are unnamed. This PR sets the
active shader name. This helps when debugging so we don't need
to track down the shader it is complaining about.
```
the descriptor (VkDescriptorSet 0x66da6f0000001c58[workbench_prepass_mesh_opaque_studio_texture_no_clip_1022]
binding 7, index 0) is being used in draw but has never been updated via vkUpdateDescriptorSets() or a similar call.
```
This message direct directly to the shader including what part is
needed to be checked. No need to add break points and that sort
of things.
Pull Request: https://projects.blender.org/blender/blender/pulls/115944
No functional changes.
Before this PR the interpolation mode of a new keyframe
was read from the User Preference at the deepest level
where the keyframe is created.
In case where this shouldn't be done, the flag
`INSERTKEY_NO_USERPREF` was passed in.
In this case it would fall back to some default values.
In order to make these low level functions
more flexible, the keyframe settings are now passed in.
I've made a new struct `KeyframeSettings` that holds the
* interpolation
* key type
* handle type
and a function `get_keyframe_settings` that allows
you to quickly get this settings struct.
This is a first step that will allow to pass in the
interpolation mode from python in the future.
Part of #113278
Pull Request: https://projects.blender.org/blender/blender/pulls/115898
The reason for the artifacts was that the depth (`placement_loc_`) was
not initialized in surface draw mode, but used in case we didn't hit a
surface in the projection.
This fixes the issue by using a default depth defined by the object
origin. Also applies for the `NearestStroke` placement.
Node splitting seems to be broken and when triggered it crashes blender. The cause for
this is that SplitNodePair stores a full node and uses assign operators, that can free
unallocated space.
Although node splitting is important for performance point of view, we should reevaluate
how we want node splitting to work.
This PR only disables it, so it won't crash when used.
Pull Request: https://projects.blender.org/blender/blender/pulls/115928
When using any of the operators in `graph_slider_ops.cc` and cancelling the operation,
the location of the object in the 3D viewport might get stuck in the state prior to cancelling.
To fix this, explicitly update the depsgraph when cancelling.
I've only done that in case of cancelling, since that's where the issue came from.
For fear of introducing performance regressions I'm not tagging the depsgraph
for an update at any other point. (It might already do that at some other part of
the operator code though)
Pull Request: https://projects.blender.org/blender/blender/pulls/115810
This PR makes it so that locked materials as well as hidden materials will not have their edit points and edit lines visible.
Note: Previously in grease pencil, strokes with hidden materials would still display the edit lines. This behavior is now fixed in GPv3.
Pull Request: https://projects.blender.org/blender/blender/pulls/115740
Subtle regression in [0] caused context override to fail when
passing in the current context when a temporary screen was used.
While passing in a temporary screen as an override isn't supported,
this shouldn't raise an exception if the argument matches the current
context.
Also added sanity check that the window passed in exists
and code comments to give an explanation of the current behavior.
[0]: 6af92e1360
The ID to draw should start at one, in order to not draw the "1"
face set which displays as white by default. There is still an issue
with dynamic topology drawing, but that's likely unrelated.
This allows for parallel processing of refraction.
Also fix a limitation of using AO node in
refraction materials.
This is needed for the grouping of raytracing
passes.
This increases VRAM consumption a bit (8MB for fullHD
frame) but has no impact on performance.
This include a needed fix to the `draw::Texture::swap`.
### Later work
- Limit the memory overhead to the cases where it is needed.
Pull Request: https://projects.blender.org/blender/blender/pulls/115912
The commit cad81786d0 introduced
a crash. The memory from `curve_fit_cubic_to_points_fl` and
`curve_fit_corners_detect_fl` needs to be freed with `free` and
we need to check for `nullptr`.
This adds a tile classification pass to the gbuffer.
This is then compact into streams of tiles for each
complexity level of lighting evaluation.
The benefit over a simpler approach of using a per
object stencil value is that we can have a per
tile granularity of the lighting complexity.
To avoid quad overshading, we use a prepass that
tags different stencil values for each complexity
level. This allows to still use a fullscreen quad
for the light evaluation pass and remove the
diagonal overshading cost.
This doesn't use compute shader at all to leverage
render pass merging and in-tile memory loads.
Using `atomicOr` for adding together the `eClosureBits`
revealed to be too slow. Using multiple non-atomic
writes to many data values is faster and not much
memory hungry.
### Performance
The whole tile scheduling process takes ~70µs for
a half covered 3800x790 framebuffer and doesn't
get much more slower than this.
Using simpler lighting shader helps reduce the cost
of the lighting pass by half in most common cases.
SSS materials stay the most costly.
Pull Request: https://projects.blender.org/blender/blender/pulls/115820
This is a smaller rewrite/refactor of the VSE copy paste code to use the file copy buffer logic that is used in other places of Blender.
This makes Blender able to copy paste between Blender processes.
It can also paste successfully after closing and reopening Blender.
Other than that, the functionally should remain the exact same as the current copy paste operator with one exception: Scene strips does not retain their scene pointer when pasting into the same file.
This is to make it consistent with how it was before when copy pasting between .blend files.
(The scene data for the scene strips were never copied in when doing that)
Logic for pulling in or linking scenes into new or current files are purposely left for later when a proper proposal of how this would work in a nice fashion is done.
Now the strip data gets copied either fully or partially besides for scene strips. There only the script data gets copied and not the scene data.
If there is a audio/video data block of the same name as in the paste data, it will be reused to reduce potential duplication of data.
Pull Request: https://projects.blender.org/blender/blender/pulls/114703
Problem here is that `BKE_id_attribute_to_index` [which
`BKE_id_attributes_active_set` uses] does not match
`BKE_id_attribute_from_index` which can lead to "wrong" indices (there
are "wrong" layers included while iterating such as ".corner_vert" or
".corner_edge" for faces).
Deeper reason is that `get_domains_types` swaps `ATTR_DOMAIN_FACE` and
`ATTR_DOMAIN_CORNER` (originally introduced in eae36be372 -- but unclear
at this point why this was done). Historically, this was used for operators
[vertex color rotate/inverse] introduced in c75e1598dd & 771a4dee0b,
assumption is that eae36be372 was trying to make this more generic and make
it work for other domains as well (ATTR_DOMAIN_MASK_COLOR -- the tootip
was also changed from "Rotate vertex colors inside faces" to "Rotate color
attributes inside faces"), however, at this point in time the tools clearly only work
for the corner domain (and this was made more specific in ee18b625ca as well).
So now, remove the swapping all together and make
`BKE_id_attribute_from_index` & `BKE_id_attribute_to_index` in sync.
Also change the tooltip of said operators to use "face corner color attribute".
Pull Request: https://projects.blender.org/blender/blender/pulls/114797
The preprocessor checks around `renameat2` usage seem to confuse Clang
15 on FreeBSD at least, split them in two.
Caused by 050d48edfc, report and patch by Shane Ambler, thanks!
No functional changes.
To reduce the argument count of `insert_vert_fcurve`,
the x and y argumentsto define the position
of a keyframe can be merged into a single `float2`
Pull Request: https://projects.blender.org/blender/blender/pulls/115886
Crash occurs in debug mode after switching to draw mode if GP object is
empty (i.e. zero points)
This is due to accessing value which is empty i.e.`std::nullopt`
Pull Request: https://projects.blender.org/blender/blender/pulls/115795
There were some memory leaks in the `polyline_fit_curve` and
`polyline_detect_corners` functions, because the
c-style arrays that the library returns are never freed.
We only copy the data and return it.
The fix makes sure we free the temporary arrays.
A recent change[1] caused the `NC_SCENE | ND_FRAME` combination to no
longer perform a full Outliner rebuild. However, both Alembic and USD
importers were using this combination. The end result was that the
outliner would not show any of the newly imported objects/collections
until a rebuild was forced some other way (like going into Edit mode on
an object).
Change to use a more appropriate notification that corresponds to the
concept of new IDs being added to the scene instead: `NC_ID | NA_ADDED`
Also, remove the notification being sent from the startjob callback when
creating a new collection. It's unneeded in this situation and it could
be problematic being called from the callback.
[1] b549260aa4
Pull Request: https://projects.blender.org/blender/blender/pulls/115883
The Cryptomatte node considers preview channels as part of the
Cryptomatte layers, producing bad pick outputs at best and bad mattes at
worst.
The Cryptomatte specification specifies that a layer with the same name
as the typename is a (Now deprecated) preview layer, so it should be
ignored, which is what the patch does.
Pull Request: https://projects.blender.org/blender/blender/pulls/115879
This PR implements the Lookdev (HDRI) Spheres overlay for EEVEE-Next. There are
also improvements for lookdev:
* Scene lighting (direct and indirect are) applied to the spheres.
* Shadow is applied to the spheres.
This is done by virtually placing the balls at the near clip plane of the camera/viewport.
Pull Request: https://projects.blender.org/blender/blender/pulls/115465
In some cases the value that defines which ID is displayed as white is
mismatched between the original and evaluated mesh. Use the original
as the source of truth, since that's the mesh that's actively edited.
Similar to previous changes for masks and visibility, remove the mutable
pointer to face sets from the sculpt session. With implicit sharing,
this avoids a duplicate copy of face sets on the evaluated object when
face sets aren't edited.
Most retrieval of face sets now goes through the Mesh attribute API
instead of the pointer in sculpt session. This integrates sculpt code
with the rest of Blender, avoiding the need to reinvent things like
basic attribute access.
Similar to previous refactors to mask and visibility operators, refactor
the face set gesture and edit operators to be multithreaded and only
push undo steps and tag updates for actually changed nodes.
There is opportunity for more code deduplication in the future.
For now the aim is to reduce the number of confusing abstraction
levels though.
This will be useful for other types in the future (similar abstractions
for editing face sets), and it makes more semantic sense as a templated
utility function.
This avoids having to make the original data layer mutable when we
aren't going to modify it, meaning the memory can still be shared with
the evaluated mesh-- saving 1 byte per face in some situations. This was
made possible by previous commits that moved to using the Mesh attribute
API instead of the SculptSession pointer to edit this data. Eventually the
`hide_poly` pointer should be completely removed.
Also rename the functions and move a sculpt function that depended on
the mesh functions to a more proper place. And also use references and
nicer variable names for meshes.
