This modify most shader using the GBuffer to use the
`ClosureUndetermined`. This in turn reduces the amount
of duplicated data in the `GBufferReader` structure.
The most important part is the usage of fixed array
indices to access the `GBufferReader.closures[]`.
This avoid the struct to be moved from local register
to device memory and remove a huge performance penalty.
Pull Request: https://projects.blender.org/blender/blender/pulls/116772
This refactors the whole pipeline to be closure agnostic.
This mean we can have only one raytracing step that covers
any closure type. In practice, it means that there is
3 objects having 1 closure each with a different closure
types each, we can run the raytracing once.
This create a huge overhead during the tile classification
stage. This is fixed by #116772 and will be merged separately.
Pull Request: https://projects.blender.org/blender/blender/pulls/116670
The same is done for other geometry types. This allows us to use C++ types in
the run-time data more easily and avoids dumping runtime data into .blend files.
Pull Request: https://projects.blender.org/blender/blender/pulls/116840
Now that OIIO has proper `valid_file` APIs for the formats we care
about, and which take MemReaders, we can remove the code added to TIFF,
PSD, and PNG as part of 5cc8fea7e9.
Additionally, this change eliminates the recent console spew on startup
where the TIFF loader is asked to load non-TIFF files (it is based on
the ordering of the filetype array)[1]. We now make a `valid_file` check
during open to address this.
[1] `: Not a TIFF or MDI file, bad magic number 12150 (0x2f76).`
Pull Request: https://projects.blender.org/blender/blender/pulls/116826
Added support to Drag and Drop to file handlers, part of #111242.
If file handlers are registered with an import operator they can now be
invoked with drag and drop path data.
Import operators must either declare a `filepath` StringProperty or both
a `directory` StringProperty and a `files` CollectionProperty depending
on if they support single or multiple files respectively.
Multiple FileHandlers could be valid for handling a dropped path. When
this happens a menu is shown so the user can choose which exact handler
to use for the file.
Pull Request: https://projects.blender.org/blender/blender/pulls/116047
- Improve the look of them, so they feel less like from year
1998 (more details and images in the PR).
- Some of the scopes got slightly faster in the process, others
stayed the same performance (details below).
- Remove VSE Scopes related data from SpaceSeq DNA, move it into
runtime instead.
Overall the transition to C++ in the draw module is awkwardly half
complete, but moving more code to a C++ namespace makes cleaning up
this code in other ways much easier, and the next C++ cleanup steps
are clear anyway.
This commit adds a new helper to define expected properties when a
target needs to use the unity build feature.
That new helper does what was already done for existing cases, and in
addition add the target to the Ninja 'heavy' pooljobs if relevant.
Pull Request: https://projects.blender.org/blender/blender/pulls/116791
Instead of moving bone collections by absolute index, they can now be
moved by manipulating `.child_number`. This is the relative index of the
bone collection within the list of its siblings.
This replaces the much more cumbersome `collections.move_to_parent()`
function. Since that function is now no longer necessary (it's been
replaced by assignment to `.parent` and `.child_number`), it's removed
from RNA. Note that this function was never part of even a beta build of
Blender.
The `expect_bcolls()` function now no longer calls the `EXPECT_EQ` macro,
but returns a `testing::AssertionResult` instead. The function call does
need to be wrapped in an `EXPECT_TRUE()` call now, but that also means that
any failure message points directly to the call site.
Texture filtering does not work in the GPU compositor. That's because
filtering is set after textures are bound. It works in the viewport
compositor because the textures come pre filtered from the DRW texture
pool.
Add an RNA getter for `bone_collection.is_visible_effectively`. This
value could already be derived from other flags, but now that logic sits
in C++ and doesn't require duplicated logic in Python any more.
The ability to adjust the "Backwire Opacity" was mistakenly removed in
version 2.93 (b365cc017a).
As this issue went unnoticed by most users, it appears reasonable to
completely remove this setting from the code.
By making this change, there is no longer a need to define a default
value for `View3DOverlay::backwire_opacity`.
Pull Request: https://projects.blender.org/blender/blender/pulls/116799
The GPU implementation of the morphological feather erosion operator is
different from the CPU implementation. This is because the CPU does
erosion by doing dilation sandwiched between two inverse functions. So
this patch fixes the different by following the CPU implementation.
- Move code to C++ namespace for blenkernel
- Remove unnecessary prefixes based on namespace change
- Remove use of `RawVector` for function-scoped static variable
- Use `StringRef` instead of char pointer
- Use safer `STRNCPY` instead of `strcpy` in tests
- Give span instead of vector to users of API
Pull Request: https://projects.blender.org/blender/blender/pulls/116808
Allow our current simple confirmations to be customized and extended
with callbacks, allowing different behaviors, different icons, and
showing more information. Makes no changes to any existing dialogs.
Pull Request: https://projects.blender.org/blender/blender/pulls/104670
Blender's cameras don't have specific resolution configured to them,
instead they use the scene's resolution.
This is a problem when exporting a camera using Alembic. Other software
(like Houdini) expects the resolution parameters on the camera itself.
So now store the scene's resolution on each camera that is exported.
Since this is not part of the concept of a camera in alembic itself,
export these as `userProperties` in a way other software can read this.
Fixes#116375
Pull Request: https://projects.blender.org/blender/blender/pulls/116782
Bone collection visibility now respects their hierarchy.
A bone collection is only visible when it is marked as visible and all
its ancestors (so parents, greatparents, etc.) are visible. Root bone
collections have no ancestors by definition, and only consider their own
visibility.
The effective ancestors' visibility is stored on each bone collection,
in its `BONE_COLLECTION_ANCESTORS_VISIBLE` flag. This makes it possible
to determine the effective visibility from just the flags of the bone
collection itself.
The `BONE_COLLECTION_ANCESTORS_VISIBLE` flag is now stored, with the
other flags, in `BoneCollection::flags`. This means that it's stored in
DNA, even though it's derived data and should actually be stored in a
runtime struct. However, `BoneCollection` doesn't have any runtime
struct yet, and I don't feel that the introduction of this flag is a
good enough reason to introduce that just yet.
Pull Request: https://projects.blender.org/blender/blender/pulls/116784
When opening the menu to set/change the
active keying set, the top entry would
show "Active Keying Set" (if there is one).
(Open the menu with Ctrl+Shift+Alt+I)
Clicking this option would unset the active keying set
though as pointed out by Nika Kutsniashvili in #115798
This PR fixes it by splitting the function that dynamically generates the enum.
The core of the function has been extracted, and only the section
that creates the entry for "Active Keying Set" has been changed.
It now reads "Clear Active Keying Set"
Pull Request: https://projects.blender.org/blender/blender/pulls/116189
Moving a bone collection to another parent is now possible in Python by
assigning to `bone_collection.parent`.
Thanks to Sergey for the implementation.
Rename `ANIM_bonecoll_is_visible(armature, bone)` to
`ANIM_bone_in_visible_collection(armature, bone)`, as that reflects the
actual functionality.
No functional changes.
The issue was that the "Affect" options from the 3D viewport
were also used for the Graph Editor.
This was discussed in the Animation & Rigging module meeting.
https://devtalk.blender.org/t/2023-12-21-animation-rigging-module-meeting/32748
The consensus was that the Animation Editors should have their own copy of the "Affect" flags.
For this commit I opted for a more immediate solution that ignores the "Affect" flag in the animation editors.
The adding of the flag can be left for a feature PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/116781
This is reusing the generic system from 128eb6cbe9 which at that time
was only done for the mesh reader and is now done for the point reader
as well.
This allows for rendering with proper motion blur for alembic points
(which of course are still imported as meshes - were just lacking the
velocity attribute) when directly rendering as points in Cycles.
Came up in #109185 (where instancing is used - which is still not
supported, this patch is just for direct point rendering in Cycles).
Unsure about the status of https://archive.blender.org/developer/D11591
but until that lands, having velocities for points sounds useful enough
to support this now.
Fixes#95945
Pull Request: https://projects.blender.org/blender/blender/pulls/116749
This is only visible for very low resolution image strips; the math was
operating on integers as image size but doing division by two to get the
outline. For non-even image sizes the outline could be off by a pixel due
to rounding.
Images in the PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/116605
Bundling many tests in a single binary reduces build time and disk space
usage, but is less convenient for running individual tests command line
as filter flags need to be used.
This adds WITH_TESTS_SINGLE_BINARY to generate one executable file per
source file. Note that enabling this option requires a significant amount
of disk space.
Due to refactoring, the resulting ctest names are a bit different than
before. The number of tests is also a bit different depending if this
option is used, as one uses gtests discovery and the other is organized
purely by filename, which isn't always 1:1.
Co-authored-by: Sergey Sharybin <sergey@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/114604
