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.
- When string join truncates, break out of the outer loop too.
- Use BLI_string_len_array when calculating the array size for
BLI_string_join_array_by_sep_charN.
- Add tests.
Avoid BLI_strcpy_rlen use as this has the same problems as strcpy
(it just returned the length which is useful at times).
Use memcpy instead when the size is calculated immediately beforehand.
Other uses of have been replaced by BLI_string_join_array that prevents
buffer overruns by taking the destination buffer length.
The Voronoi Smooth F1 mode breaks when the Smoothness is 0 for OSL. This is
due to a zero division in the shader.
To fix this, standard F1 is used when Smoothness is 0.
Pull Request: https://projects.blender.org/blender/blender/pulls/109255
Use <= comparison for BLI_rctf_compare so two rectangles which
are exactly the same return true with a limit of zero.
Matches compare_ff, compare_v3v3 etc.
In practice, this shouldn't result in user visible functional changes.
Fractal noise is the idea of evaluating the same noise function multiple times with
different input parameters on each layer and then mixing the results. The individual
layers are usually called octaves.
The number of layers is controlled with a "Detail" slider.
The "Lacunarity" input controls a factor by which each successive layer gets scaled.
The existing Noise node already supports fractal noise. Now the Voronoi Noise node
supports it as well. The node also has a new "Normalize" property that ensures that
the output values stay in a [0.0, 1.0] range. That is except for the F2 feature where
in rare cases the output may be outside that range even with "Normalize" turned on.
How the individual octaves are mixed depends on the feature and output socket:
- F1/Smooth F1/F2:
- Distance/Color output:
The individual Distance/Color octaves are first multiplied by a factor of
`Roughness ^ (#layers - 1.0)` then added together to create the final output.
- Position output:
Each Position octave gets linearly interpolated with the combined output of the
previous octaves. The Roughness input serves as an interpolation factor with
0.0 resutling in only using the combined output of the previous octaves and
1.0 resulting in only using the current highest octave.
- Distance to Edge:
- Distance output:
The Distance octaves are mixed exactly like the Position octaves for F1/Smooth F1/F2.
It should be noted that Voronoi Noise is a relatively slow noise function, especially
at higher dimensions. Increasing the "Detail" makes it even slower. Therefore, when
optimizing a scene one should consider trying to use simpler noise functions instead
of Voronoi if the final result is close enough.
Pull Request: https://projects.blender.org/blender/blender/pulls/106827
Add a quaternion attribute type that will be used in combination with
rotation sockets for geometry nodes to give a more intuitive experience
and better performance when using rotations.
The most interesting part is probably the interpolation, the rest is
the same as the last attribute type addition, 988f23cec3.
We need to interpolate multiple values with different weights.
Based on Sybren's suggestion, this uses the `expmap` methods from
4805a54525 for that.
This also refactors `SimpleMixerWithAccumulationType` to use a
function rather than a cast to convert to the accumulation type.
See #92967
Pull Request: https://projects.blender.org/blender/blender/pulls/108678
During uv unwrapping and uv packing, certain floating point algorithms
have extreme sensitivity to round-off errors. These can produce very
different layouts even when given inputs which are only slightly different.
The root cause is that the two main types of CPUs used to run Blender,
namely x86 and Apple Silicon, produce slightly different results on some
math functions, including `sinf()`, `cosf()` and `atan2f()`.
* sinf(0.8960554599761962890625) = 0.780868828296661376953125 (Intel i7)
* sinf(0.8960554599761962890625) = 0.78086888790130615234375 (Apple M1)
This fix, and others that came before it [0], improve accuracy by using
double-precision to hide the differences between the CPUs.
[0] e.g. 0eba9e41bf
[1] See also #107829
Returning the pointer to the null byte when the character isn't found
is useful when handling null terminated strings that contain newlines.
This means the return value is never null and the line span always ends
at the resulting value.
