There are still a few places that are more complicated where the replacement
to `IDP_New` isn't obvious, but this commit replaces most uses of the ugly
`IDPropertyTemplate` usage.
This limits the number of tilemaps per LOD that can be fed to avoid the
easy to hit "Too many shadow updates" (#119757).
This allows for a max 64 tilemaps to be updated at once at their lowest
requested LOD (so ~10.6667 point lights if every faces of the punctual
shadow map is needed, but likely more in practice).
Unfortunately this is still quite low and will surely be hit quite soon
with directional shadow added to it. One idea to workaround this would
be to time slice the update of some lights, but this opens a whole can
of worms that I'm not ready to open for now so I created #119890 for
future reference.
Some notes, most lights seems to request around 3 LODs. It might help
to allow requesting at least 2 LODs if we are rendering since volumes
might want lower LOD available for volumes.
I added a very simplistic heuristic that also lowers the max tilemaps
when transforming, animation playback or navigating the 3D view to
improve the responsiveness of the engine. Note that this doesn't
only lowers the resolution to the minimum requested one. So it should
be good enough in most cases.
Pull Request: https://projects.blender.org/blender/blender/pulls/119889
Use File Handlers to handle file drag-n-drop in the View 3d. Drop-boxes
still remain since they handle Texture ID drag-n-drop.
This will add-ons to handle drag-n-drop for images and movies while
still providing access to Blender's native support since File Handlers
let users choose which to invoke if there's multiple configured.
Pull Request: https://projects.blender.org/blender/blender/pulls/117728
This PR removes the modal callback for `PAINT_OT_visibility_invert`.
It does not use the provided data, nor is the `modal` function
invoked by a corresponding `invoke`.
Pull Request: https://projects.blender.org/blender/blender/pulls/119930
This PR introduces the ability for users to switch between boolean
solvers while using the sculpt *Trim* tools (*Box Trim* & *Lasso Trim*)
much like the mesh boolean modifier and geometry node. Because the
*Exact* solver has performance issues with larger meshes, the *Fast*
solver is set to be the default.
In my very rough timing tests on my laptop on a mesh with **1.7m**
vertices, a *Trim* operation with the *Fast* solver finishes in roughly
20 seconds as opposed to still being in progress after five minutes
with the *Exact* solver.
Addresses part of #84229
Pull Request: https://projects.blender.org/blender/blender/pulls/119699
Compute an index masks of points to remove to simplify the curve attribute using the Ramer-Douglas-Peucker algorithm.
The Ramer-Douglas-Peucker algorithm finds a set of points in a polyline to remove so that the overall shape of the polyline is similar. How similar can be controlled by the distance `epsilon`.
The function takes a `GSpan` so it can be used with any attribute (that has a type `float`, `float2`, or `float3`).
Pull Request: https://projects.blender.org/blender/blender/pulls/118560
Textures that are GPU-compressed already (in practice: from DDS files
that are DXT1/DXT3/DXT5 compressed) now can stay GPU compressed
in Vulkan, similar to how that works on OpenGL.
Additionally, fixed lack of mipmaps in Vulkan textures. The textures
were created with mipmaps (good), the sampler too (good), but
the vulkan image view was always saying "yo, this is mip 0 only"
because mip range variables were never set to anything than zero.
Pull Request: https://projects.blender.org/blender/blender/pulls/119866
A regression caused by 7a2d04a5c4.
The offending commit made it so selection tag does not imply parameters
update, which also avoids transitive re-evaluation of the curve geometry.
However, the active curve index is stored on a Curve, and curve modifier
stack creates a copy of the curve to hold the evaluation results, which
makes it so evaluated curve object does not intrinsically share the active
spline index.
This change makes it so changes in selection triggers geometry evaluation
on curves, matching the behavior prior to the offending commit.
AN ideal fix would somehow avoid such geometry re-evaluation, but it would
be a bigger change, not suitable for possible corrective release.
Potential candidate for 4.1.1.
Pull Request: https://projects.blender.org/blender/blender/pulls/119918
Every vulkan installation has a vk.xml file containing the vulkan specification
in a machine readable fasion.
This PR uses the vk.xml to generate to_string functions for data types blender uses.
When updating to a new specification or when changing features/extensions we
should re-generate the to_string functions.
The generator is implemented in `vk_to_string.py`.
Pull Request: https://projects.blender.org/blender/blender/pulls/119880
The compositor does not correctly free, wrap, or allocate images. That's
because the resetting mechanism didn't reset all members. This patch
rests all members and only retains the important ones.
This could happen when e.g. overriding context with just the area.
Now add poll functions that check for an active region when running
operators that require a region.
The fix is similar to 72688791dc
Alternatively, we could have a fix similar to a8892c7264 (getting the
correct region from the area), this would require less setup by
scripters, however for some operators the usage of the region is a
little further down the line, so implementation would be a bit more
involved. Also: for some of the operators, this would have to be done in
both `invoke` and `exec` (so would be more duplicate code changes).
Pull Request: https://projects.blender.org/blender/blender/pulls/119696
This patch refactors the backdrop offset to be stored as a float instead
of an int and to be stored in the image runtime structure instead of the
image itself.
Pull Request: https://projects.blender.org/blender/blender/pulls/119877
This is intended to be used in the new exact mesh boolean algorithm by @howardt.
The new `BLI_fixed_width_int.hh` header provides types like `Int256` and
`UInt256` which are like e.g. `uint64_t` but with higher precision. The code
supports many different integer sizes.
The following operations are supported:
* Addition
* Subtraction
* Multiplication
* Comparisons
* Negation
* Conversion to and from other number types
* Conversion to and from string (based on `GMP`)
Division is not implemented. It could be implemented, but it's more complex and
is not required for the new mesh boolean algorithm.
Some alternatives to having a custom implementation have been discussed in
https://devtalk.blender.org/t/fixed-length-multiprecision-arithmetic/29189/.
Generally, the implementation is fairly straight forward. The main complexity is
the addition/multiplication algorithm which isn't too complicated. It's nice to
have control over this part as it allows us to optimize the code more if
necessary. Also, from what I understand, we might be able to benefit from some
special cases like multiplying a large integer with a smaller one.
I tried some different ways to optimize this already, but so far the normal
compiler optimization turned out to work best. Not sure if the same is true on
windows though, as it doesn't have native support for an `int128` which helps
the compiler understand what I'm doing. Alternatives I tried so far are using
intrinsics directly (mainly `_addcarry_u64` and similar), writing inline
assembly manually and copying the assembly output from the compiler. I assume
the assembly implementation didn't help for me because it prohibited other
compiler optimizations.
Pull Request: https://projects.blender.org/blender/blender/pulls/119528
We already expose two other types that don't have a directly
corresponding socket type-- float2 and byte colors. This also solves
the inability to write to the nurbs_order attribute in geometry nodes.
Fixes#119843
Pull Request: https://projects.blender.org/blender/blender/pulls/119879
This was necessary when attributes were stored embedded in legacy
structs like `MPoly`. Nowadays that isn't the case anymore, and there
doesn't seem to be a reason to restrict the creation of attributes.
update_on_change_ shouldn't be called when creating an attribute but
not setting the array values. In that case it is UB to not set the values
elsewhere anyway, and that will cause its own update tag.
4d0936c7d7 explicitly avoids turning non-geometry object
instances into geometry instances. This code is called to prepare
geometry sets for baking, and baking currently assumes that the baked
instances are always geometry sets.
To fix this, just check the instance type and serialize an empty
geometry set for the crashing object instance case. Compared to before
the crash causing commit, there is no change in behavior, since that
would have created empty geometry sets too.
Pull Request: https://projects.blender.org/blender/blender/pulls/119892
All builtin attributes are now stored as named attributes, so the old
code path from where they were stored with non-generic types can be
removed. The stored type and attribute type don't have to be tracked
separately anymore either.
The change to use generic "capture field on geometry" utilities for this
node and other nodes like it means `AttributeWriter` with its update
tagging isn't being used anymore, the attribute is just being created
with the new values (for some cases anyway). To fix this, call the
attribute provider's update function when creating the attribute too.
This was noted as useful in 130701763b too.
The initialization of curve and point cloud runtime structs is moved
because they now have to be allocated before any attributes are added.
In the tiled compositor ensure_delta() can be called from multiple threads,
but without any threading synchronization. This worked fine when the node
only supported absolute transform: multiple threads would do the same work
and assign delta to the same values.
With the addition of relative transform in #115947 a code which adjusts
previously calculated delta was added, leading to possible double-applying
relative transform.
The solution is to avoid multiple threads modifying the same data by using
a double-locked check.
This issue does not happen in 4.2 (main branch) because it switched to full
frame compositor, which works differently.
Pull Request: https://projects.blender.org/blender/blender/pulls/119883
Previously, the bake settings in geometry nodes were not
editable even though they were stored on the overridden
object (instead of the not-overridden but linked node tree).
Pull Request: https://projects.blender.org/blender/blender/pulls/119874
USD files are now findable from the cachefile.open() and
cachefile.layer_add() operators. Removed the ".abc" appending when
looking for a file for the first time, as it no longer makes sense.
Pull Request: https://projects.blender.org/blender/blender/pulls/118685
This patch ports the GLSL SMAA library to the CPU compositor in order to
unify the anti-aliasing behavior between the CPU and GPU compositor.
Additionally, the SMAA texture generator was removed since it is now
unused.
Previously, we used an external C++ library for SMAA anti-aliasing,
which is itself a port of the GLSL SMAA library. However, the code
structure and results of the library were different, which made it quite
difficult to match results between CPU and GPU, hence the decision to
port the library ourselves.
The port was performed through a complete copy of the library to C++,
retaining the same function and variable names, even if they are
different from Blender's naming conversions. The necessary code changes
were done to make it work in C++, including manually doing swizzling
which changes the code structure a bit.
Even after porting the library, there were still major differences
between CPU and GPU, due to different arithmetic precision. To fix this
some of the bilinear samplers used in branches and selections were
carefully changed to use point samplers to avoid discontinuities around
branches, also resulting in a nice performance improvement. Some slight
differences still exist due to different bilinear interpolation, but
they shall be looked into later once we have a baseline implementation.
The new implementation is slower than the existing implementation, most
likely due to the liberal use of bilinear interpolation, since it is
quite cheap on GPUs and the code even does more work to use bilinear
interpolation to avoid multiple texture fetches, except this causes a
slow down on CPUs. Some of those were alleviated as mentioned in the
previous section, but we can probably look into optimizing it further.
Pull Request: https://projects.blender.org/blender/blender/pulls/119414
This patch unifies the sRGB to Linear color space conversion between the
CPU and GPU compositors. This is because CPU uses an optimized path that
produces values that are very slightly off. To fix this, for the GPU, we
do the conversion CPU side instead of doing it in a shader. Since images
are cached, the performance implications are not significant.
Another added benefit is that we no longer get differences due to the
order of alpha pre-multiplication and sRGB conversion, demonstrated in
#114305. And we no longer require any preprocessing of the images.
This patch adds some new utilities to the Image Buffer module to assign
float, byte, and compressed buffers along with their color spaces. It
also adds an ownership flag to compressed data. Those were added as a
way to facilitate the implementation.
Pull Request: https://projects.blender.org/blender/blender/pulls/118624
`asset_lib` is null when calling undo in active file browser space.
This causes crash in `asset undo poll`. So exit out of the poll function
when active file space is filebrowser.
Pull Request: https://projects.blender.org/blender/blender/pulls/119870
object_index is not found (-1) when all mesh data is deleted hence it
crashes when accessing base from the vector at index -1.
So skip the further execution to prevent crash.
Pull Request: https://projects.blender.org/blender/blender/pulls/119865
