On gcc 11.3, Ubuntu 22.04 the default constructor for
ColorSceneLinear4f did not zero the r,g,b,a member variables. Replacing
the empty constructor with a default constructor circumvents this
problem (compiler bug? ) even though it *should* be more or less
equivalent.
These functions were originally implemented because:
- Not all of them existed pre C++17, but now we are using C++17.
- The call stack depth is quite a bit deeper with the std functions, making
debugging slower and more annoying. I didn't find this to be a problem
anymore recently.
No functional changes are expected.
The following functions only supported back slashes on WIN32,
which can use both forward and back slashes.
- BLI_path_append
- BLI_path_append_dir
- BLI_path_slash_ensure
- BLI_path_slash_rstrip
Follow up to [0] which is a more limited bug-fix.
[0]: a16ef95ff6
Support both forward and back slashes on WIN32.
Forward slashes for paths in WIN32 was removed in [0] (for BLI_path_join)
& [1] (for BLI_path_name_at_index), this is correct on UNIX as back
slashes can be used in paths but not on WIN32 which can use both.
Note that other path functions such as BLI_path_append &
BLI_path_slash_ensure should be updated too, but this is out of scope
for a bug-fix.
Documenting and ensuring Windows path handling functions all handle
forward slashes can be done separately.
[0]: 8f7ab1bf46
[1]: 511ae22264
Reviewed By: harley
Ref D16700
The existing `DisjointSet` data structure only supports single
threaded access, which limits performance severely in some cases.
This patch implements `AtomicDisjointSet` based on
"Wait-free Parallel Algorithms for the Union-Find Problem"
by Richard J. Anderson and Heather Woll.
The Mesh Island node also got updated to make use of the new data
structure. In my tests it got 2-5 times faster. More details are in 16653.
Differential Revision: https://developer.blender.org/D16653
Using 32 does not make much sense, because there will be 4 remaining
padding bytes in the struct anyway. Using 64 instead does not actually
increase the size of the struct, but makes allocations less likely.
{F13294314}
# Process
In the pixel extraction process a larger domain will be extracted then the input mesh.
The borders of uv islands are extended with connected geometry of the input mesh.
The extended mesh is then fed into the pixel extraction process.
A mask is used to limit the extraction so UV islands will not overlap.
Input UV islands.
{F13206401}
Extended UV Island (only one showing).
{F13288764}
This patch doesn't include fixing uv seams at non-manifold edges (like suzannes eyes) as that
would require a different approach (edge extending or pixel copy-ing). The later has already been
implemented in D14702, but should be revisited to only use do the non-manifold edge fixing.
This patch supports fixing UV seams across UDIM textures.
There might be an issue when using a single texture on multiple uv maps.
Reviewed By: brecht, joeedh, JulienKaspar
Maniphest Tasks: T97352
Differential Revision: https://developer.blender.org/D14970
Issue was caused by imprecise math due to using float numbers.
Use double instead.
No negative performance impact was observed.
Reviewed By: jbakker
Differential Revision: https://developer.blender.org/D16517
a5e7657cee didn't account for slices of zero sizes, and the asserts
were slightly incorrect otherwise. Also, the change didn't apply to
`Span`, only `MutableSpan`, which was a mistake. This also adds "safe"
methods to `IndexMask`, and switches function calls where necessary.
Currently slicing a span clamped the final size so that it would be
within bounds of the input. However, in the vast majority of cases
that is already the case anyway, and we can use asserts to detect
when that assumption fails.
The clamping had a performance cost. On a test interpolating a boolean
attribute from 1 million curves to 4 million points, removing the
clamping saved about 10% of the time. That's an extreme case but
this probably slightly improves performance in other cases too.
Slicing is used a lot in the new curve code.
This commit introduces `slice_safe` which still does the clamping,
and uses it in the few places that needed it or where I wasn't
sure.
Bounding box calculation can be a large in some situations, especially
instancing. This patch caches the min and max of the bounding box in
runtime data of meshes, point clouds, and curves, implementing part of
T96968.
Bounds are now calculated lazily-- only after they are tagged dirty.
Also, cached bounds are also shared when copying geometry data-blocks
that have equivalent data. When bounds are calculated on an evaluated
data-block, they are also accessible on the original, and the next
evaluated ID will also share them. A geometry will stop sharing bounds
as soon as its positions (or radii) are changed.
Just caching the bounds gave a 2-3x speedup with thousands of mesh
geometry instances in the viewport. Sharing the bounds can eliminate
recalculations entirely in cases like copying meshes in geometry nodes
or the selection paint brush in curves sculpt mode, which causes a
reevaluation but doesn't change the positions.
**Implementation**
The sharing is achieved with a `shared_ptr` that points to a cache mutex
(from D16419) and the cached bounds data. When geometries are copied,
the bounds are shared by default, and only "un-shared" when the bounds
are tagged dirty.
Point clouds have a new runtime struct to store this data. Functions
for tagging the data dirty are improved for added for point clouds
and improved for curves. A missing tag has also been fixed for mesh
sculpt mode.
**Future**
There are further improvements which can be worked on next
- Apply changes to volume objects and other types where it makes sense
- Continue cleanup changes described in T96968
- Apply shared cache design to more expensive data like triangulation
or normals
Differential Revision: https://developer.blender.org/D16204
This gives a friendlier interface, an inline buffer, RAII, etc.
Also switch some BMesh functions that were only used by the snap
system's use of BVH utils.
* Support bidirectional type lookups. E.g. finding the base type of a
field was supported, but not the other way around. This also removes
the todo in `get_vector_type`. To achieve this, types have to be
registered up-front.
* Separate `CPPType` from other "type traits". For example, previously
`ValueOrFieldCPPType` adds additional behavior on top of `CPPType`.
Previously, it was a subclass, now it just contains a reference to the
`CPPType` it corresponds to. This follows the composition-over-inheritance
idea. This makes it easier to have self-contained "type traits" without
having to put everything into `CPPType`.
Differential Revision: https://developer.blender.org/D16479
Re-order checks to ensure a zeroed matrix results in a quaternion
without rotation. Also avoid some redundant calculation where the
'trace' was calculated but not used, flip the scaling value early
on instead of negating the quaternion after calculating it.
This patch introduces a new `CacheMutex` which makes it easy to implement
lazily computed caches in e.g. `Curves`. For more details see `BLI_cache_mutex.hh`.
Differential Revision: https://developer.blender.org/D16419
The new Xcode 14.1 brings the new Apple Clang compiler which
considers sprintf unsafe and geenrates deprecation warnings
suggesting to sue snprintf instead. This only happens for C++
code by default, and C code can still use sprintf without any
warning.
This changes does the following:
- Whenever is trivial replace sprintf() with BLI_snprintf.
- For all other cases use the newly introduced BLI_sprintf
which is a wrapper around sprintf() but without warning.
There is a discouragement note in the BLI_sprintf comment to
suggest use of BLI_snprintf when the size is known.
Differential Revision: https://developer.blender.org/D16410
As described in the comment on `BLI_task_isolate`, deadlocks can happen
when isolation is used with threading primitives that separate spawning tasks
from executing them. All threads are waiting the tasks to complete but no
thread is able to continue working due to task isolation.
The fix is to not pass lazy-threading hints through task isolations. This way
isolated regions can't create new tasks in a scheduler further up the call stack.
This may lead to minor slowdowns because less threading may be used.
It's generally possible to get rid of the slowdown again by sending the
lazy-threading hint before entering the isolated region.
