The hash tables and vector blenlib headers were pulling many more
headers than they actually need, including the C base math header,
our C string API header, and the StringRef header. All of this
potentially slows down compilation and polutes autocomplete
with unrelated information.
Also remove the `ListBase` constructor for `Vector`. It wasn't used
much, and making it easy to use `ListBase` isn't worth it for the
same reasons mentioned above.
It turns out a lot of files depended on indirect includes of
`BLI_string.h` and `BLI_listbase.h`, so those are fixed here.
Pull Request: https://projects.blender.org/blender/blender/pulls/111801
The `EdgeHash` and `EdgeSet` data structures are designed specifically
as a hash of an order agnostic pair of integers. This specialization can
be achieved much more easily with the templated C++ data structures,
which gives improved performance, readability, and type safety.
This PR removes the older data structures and replaces their use with
`Map`, `Set`, or `VectorSet` depending on the situation. The changes
are mostly straightforward, but there are a few places where the old
API made the goals of the code confusing.
The last time these removed data structures were significantly changed,
they were already moving closer to the implementation of the newer
C++ data structures (aa63a87d37).
Pull Request: https://projects.blender.org/blender/blender/pulls/111391
Including <iostream> or similar headers is quite expensive, since it
also pulls in things like <locale> and so on. In many BLI headers,
iostreams are only used to implement some sort of "debug print",
or an operator<< for ostream.
Change some of the commonly used places to instead include <iosfwd>,
which is the standard way of forward-declaring iostreams related
classes, and move the actual debug-print / operator<< implementations
into .cc files.
This is not done for templated classes though (it would be possible
to provide explicit operator<< instantiations somewhere in the
source file, but that would lead to hard-to-figure-out linker error
whenever someone would add a different template type). There, where
possible, I changed from full <iostream> include to only the needed
<ostream> part.
For Span<T>, I just removed print_as_lines since it's not used by
anything. It could be moved into a .cc file using a similar approach
as above if needed.
Doing full blender build changes include counts this way:
- <iostream> 1986 -> 978
- <sstream> 2880 -> 925
It does not affect the total build time much though, mostly because
towards the end of it there's just several CPU cores finishing
compiling OpenVDB related source files.
Pull Request: https://projects.blender.org/blender/blender/pulls/111046
Fix an UBSAN warning about undefined behavior, by preventing additions
to `nullptr`:
```
blender/source/blender/blenlib/intern/BLI_memiter.c:136:42: runtime error:
applying non-zero offset 48 to null pointer
```
No functional changes.
This PR adds the Lacunarity and Normalize inputs to the Noise node
similar to the Voronoi node.
The Lacunarity input controls the scale factor by which each
successive Perlin noise octave is scaled. Which was previously hard
coded to a factor of 2.
The Noise node normalizes its output to the [0, 1] range by default.
The Normalize option makes it possible for the user to disable that.
To keep the behavior consistent with past versions it is enabled by
default.
To make the aforementioned normalization control easer to implement,
the fractal noise code now accumulates signed noise and remaps the
final sum, as opposed to accumulating positive [0, 1] noise.
Pull Request: https://projects.blender.org/blender/blender/pulls/110839
Listing the "Blender Foundation" as copyright holder implied the Blender
Foundation holds copyright to files which may include work from many
developers.
While keeping copyright on headers makes sense for isolated libraries,
Blender's own code may be refactored or moved between files in a way
that makes the per file copyright holders less meaningful.
Copyright references to the "Blender Foundation" have been replaced with
"Blender Authors", with the exception of `./extern/` since these this
contains libraries which are more isolated, any changed to license
headers there can be handled on a case-by-case basis.
Some directories in `./intern/` have also been excluded:
- `./intern/cycles/` it's own `AUTHORS` file is planned.
- `./intern/opensubdiv/`.
An "AUTHORS" file has been added, using the chromium projects authors
file as a template.
Design task: #110784
Ref !110783.
Using ClangBuildAnalyzer on the whole Blender build, it was pointing
out that BLI_math.h is the heaviest "header hub" (i.e. non tiny file
that is included a lot).
However, there's very little (actually zero) source files in Blender
that need "all the math" (base, colors, vectors, matrices,
quaternions, intersection, interpolation, statistics, solvers and
time). A common use case is source files needing just vectors, or
just vectors & matrices, or just colors etc. Actually, 181 files
were including the whole math thing without needing it at all.
This change removes BLI_math.h completely, and instead in all the
places that need it, includes BLI_math_vector.h or BLI_math_color.h
and so on.
Change from that:
- BLI_math_color.h was included 1399 times -> now 408 (took 114.0sec
to parse -> now 36.3sec)
- BLI_simd.h 1403 -> 418 (109.7sec -> 34.9sec).
Full rebuild of Blender (Apple M1, Xcode, RelWithDebInfo) is not
affected much (342sec -> 334sec). Most of benefit would be when
someone's changing BLI_simd.h or BLI_math_color.h or similar files,
that now there's 3x fewer files result in a recompile.
Pull Request #110944
In RNA collections storing ID references, the name of the collection
item may not always be unique, when several IDs from different libraries
are present.
While rare, this situation can become deadly to liboverride, by causing
random but exponential liboverride hierarchies corruptions.
This has already been alleviated by using preferably both name and index
in items lookup (a05419f18b) and by reducing the risk of name collision
in general between liboverrides and their linked reference (b9becc47de).
This commit goes further, by ensuring that references to items of RNA
collections of IDs stored in liboverride operations become completely
unambiguous. This is achieved by storing an extra pointer to the item's
ID itself, when relevant.
Lookup then requires a complete match `name + ID` to be successful,
which is guaranteed to match at most a single item in the whole RNA
collection (since RNA collection of IDs do not allow duplicates, and
the ID pointer is always unique).
Note that this ID pointer is implemented as an `std::optional` one
(either directly in C++ code, or using an new liboverride operation `flag`
in DNA). This allows to smoothly transition from existing data to the
added ID pointer info (when needed), without needing any dedicated
versioning. This solution also preserves forward compatibility as much
as possible.
It may also provide marginal performances improvements in some cases, as
looking up for ID items in RNA collections will first check for the
ID pointer, which should be faster than a string comparision.
Implements #110421.
Pull Request: https://projects.blender.org/blender/blender/pulls/110773
Part 1/3 of #109135, #110272
Adds a new DNA structure for defining node group interfaces without
using `bNodeSocket` and with additional node UI item types.
Node group interfaces are organized as a hierarchy of "items", which
can be sockets or panels. Panels can contain both sockets and other
panels (although nested panels beyond the root panel may be disabled to
avoid complexity on the user level).
Sockets can be added to the interface in any order, not just the
conventional outputs..inputs order. Sockets can be marked as both input
and output, generating 2 sockets on node instances.
The C++ API in the DNA struct allows manipulating the interface
declaration by adding and removing items, moving them inside the
interface or into a different panel.
Pull Request: https://projects.blender.org/blender/blender/pulls/110885
Both the `Math` node and the `Vector Math` currently only explicitly
support modulo using truncated division which is oftentimes not the
type of modulo desired as it behaves differently for negative numbers
and positive numbers.
Floored Modulo can be created by either using the `Wrap` operation or
a combination of multiple `Math` nodes. However both methods obfuscate
the actual intend of the artist and the math operation that is actually
used.
This patch adds modulo using floored division to the scalar `Math` node,
explicitly stating the intended math operation and renames the already
existing `"Modulo"` operation to `"Truncated Modulo"` to avoid confusion.
Only the ui name is changed, so this should not break compatibility.
Pull Request: https://projects.blender.org/blender/blender/pulls/110728
The root cause was a classic fixed-size epsilon issue. The code that
checked if an fcurve was effectively flat, and thus shouldn't be
normalized, used a fixed-size epsilon that was reasonable for values
close-ish to zero, but didn't work well for values >= 1.0.
This patch addresses the issue by introducing a new function
`ulp_diff_ff()` that robustly computes the number of floating point
steps between two floats, and using that to ensure that a minimum
number of representable floats exist between the min/max values
of the curve. This approach scales appropriately up and down to
both huge and tiny values.
This patch also updates the existing `compare_ff_relative()` function
to use the new robust ulps code for the ulps-based part of its
comparison, resolving an issue documented in its unit tests where
it behaved poorly for values close to zero.
Pull Request: https://projects.blender.org/blender/blender/pulls/110796
Implements part of #101689.
The "poly" name was chosen to distinguish the `MLoop` + `MPoly`
combination from the `MFace` struct it replaced. Those two structures
persisted together for a long time, but nowadays `MPoly` is gone, and
`MFace` is only used in some legacy code like the particle system.
To avoid unnecessarily using a different term, increase consistency
with the UI and with BMesh, and generally make code a bit easier to
read, this commit replaces the `poly` term with `poly`. Most variables
that use the term are renamed too. `Mesh.totface` and `Mesh.fdata` now
have a `_legacy` suffix to reduce confusion. In a next step, `pdata`
can be renamed to `face_data` as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/109819
Also see #103343.
Couldn't move two files yet:
* `softbody.c`: The corresponding regression test fails. It seems like the
conversion to C++ changes floating point accuracy, but it's not clear where that happens exactly.
* `writeffmpeg.c`: Is a bit more complex to convert because of the static array in `av_err2str`.
Pull Request: https://projects.blender.org/blender/blender/pulls/110182
The Voronoi distance output is clamped at 8, which is apparent for distance
metrics like Minkowski with low exponents.
This patch fixes that by setting the initial distance of the search loop to
FLT_MAX instead of 8. And for the Smooth variant of F1, the "h" parameter is set
to 1 for the first iteration using a signal value, effectively ignoring the
initial distance and using the computed distance at the first iteration instead.
Pull Request: https://projects.blender.org/blender/blender/pulls/109286
Add an offset indices utility to do fill constant size new offsets in
parallel, which was already done in the duplicate elements node.
For example, filling poly offsets for a new part of a mesh that is only
quads. In the extrude node this was single-threaded before, so the
new poly offsets is about 10x faster, saving about 10 out of 157 ms
when extruding 2 million faces.
The utility counts the number of occurrences of each index in an array.
It's used to build offsets for mesh topology maps, or to count the
number of connected elements. Some users are geometry nodes,
the subdivision draw cache, and mesh to curve conversion.
This PR parallelizes the counting to take advantage of multiple
threads. On a Ryzen 7950x, when counting connected edges to
vertices, I observed an improvement from 10.2 to 3.0 ms.
This most likely makes the counting less efficient, but it is
quite a nice performance improvement.
The new code was much slower for me at less than four threads,
so I added a check so that counting remains single threaded in
that case.
Pull Request: https://projects.blender.org/blender/blender/pulls/109628
String search & replace is a higher level function (unlike BLI_string.h)
which handlers lower level replacements for printing and string copying.
Also use BLI_string_* prefix (matching other utilities).
This makes it possible to use BLI_string in Blender's internal utilities
without depending on DynStr, MemArena... etc.
This utility counts the number of occurrences of each index in an array.
This is used for building mesh topology maps offsets, or for counting
the number of connected elements. Some users are geometry nodes,
the subdivision draw cache, and mesh to curve conversion.
See #109628
After some recent changes BLI_math_base got (indirectly) included
from DNA file, causing defines conflict in Cycles: Cycles wants the
default fast behavior of square root, and BLI color wants it to be
more preciese.
Proposed solution is to move the SSE block away from the math_base
closer to code which uses it. The initial intent was to make those
functions reusable, but for a long long time the color utilities
are the only users of those functions.
This change does not prevent the error from re-occurring in the
future if some code includes sse2neon and BLI color utilities, but
it makes such conflict situation much less likely to happen, for
now.
The downside of this change is that the code now need to include
BLI_simd.h explicitly to access BLI_HAVE_SSE2 instead of relying
on it being included indirectly with math headers. The mitigation
for this is to change semantic of the BLI_HAVE_SSE2: now it is
defined to 1 if SSE2 is supported and to 0 otherwise. This makes
it so the code needs to check if using `#if BLI_HAVE_SSE2` and
if the BLI_simd.h is not included it will generate warning when
using GCC or Clang.
This change in semantic is is something the current patches would
need to ensure is handled correctly.
Pull Request: https://projects.blender.org/blender/blender/pulls/109664
Is not visible on any of the officially platforms, as everywhere
SSE2 is available (on Apple Silicon via sse2neon).
Only got noticed by some intermittent issue during development
which made BLI_HAVE_SSE2 unaccessible.
Seems that transpose was done a bit wrong. Not sure if worth trying
to fold the equation into C++ types, as that requires extra memory
transfers for transpose. Opted for a more naive folding, which
avoids extra copies.
Added a regression test for it, verified against numpy, the BLI
SSE2 implementation.
Based on code-comments it seems vsnprintf didn't return the un-clamped
string length on MS-Windows, this is no longer the case.
BLI_dynstr used allocation doubling in a loop (with a 65536 limit)
in an attempt to allocate sufficient space.
This workaround isn't needed anymore. Expose BLI_sprintfN_with_buffer &
BLI_vsprintfN_with_buffer functions that take a fixed buffer to avoid
allocation for smaller strings.
This simplifies BLI_dynstr_appendf considerably.
