The PR allows specifying the method of line breaking. Current functions
gain an optional argument that defaults to "Minimal" which breaks as it
does now, only on space and line feed. "Typographical" breaks on
different types of spaces, backslashes, underscore, forward slash if
not following a number, dashes if not following a space, Chinese,
Japanese, and Korean Ideograms, and Tibetan intersyllabic marks. "Path"
breaks on space, underscore, and per-platform path separators. There is
also a "HardLimit" flag that forces breaking at character boundary at
the wrapping limit.
Pull Request: https://projects.blender.org/blender/blender/pulls/135203
It appears that 8 bit `blend_color_softlight_byte` call used a wrong
blending routing (overlay), while `blend_color_softlight_float` is
correct. Seems that this was never caught. The correct fomula should be
`dst = 2ab + a^2 * (1 - 2b)`.
Pull Request: https://projects.blender.org/blender/blender/pulls/135382
Unlike the legacy type, the radius isn't included in the bounds for the new
curves type. This hasn't been obvious because the drawing is quite broken
and doesn't use the radius properly.
This commit adds a separate cache for the bounds with the radius, which
is now used by default. The old cache is kept around for backward
compatibility in the bounding box geometry node, where a new
"Use Radius" option accesses the old behavior.
Pull Request: https://projects.blender.org/blender/blender/pulls/135584
The issue was that sometimes the group inputs of a node group were shuffled
around unexpectedly and thus inputs were passed to the wrong sockets.
The `or_socket_usages` function sorts the given span so that the key is more
likely to be reused, reducing the number of nodes inserted in the graph. The
issue was that `build_warning_node` passes `group_output_used_sockets_` into the
function the order of which is important. It thus should not be reordered.
The fix is to just never reorder the span passed to `or_socket_usages` but to
make a local copy instead which can be sorted without problems. Often this copy
is done already anyway when the span is inserted into
`graph_params.socket_usages_combination_cache` as `Vector`.
This fix also makes an assumption about `Map.lookup_or_add_cb` which was not
documented before. Namely it assumes that the key is moved into the map only
after the callback has been called. This behavior is now documented and there is
a unit test for it.
Pull Request: https://projects.blender.org/blender/blender/pulls/135528
The general idea is to keep the 'old', C-style MEM_callocN signature, and slowly
replace most of its usages with the new, C++-style type-safer template version.
* `MEM_cnew<T>` allocation version is renamed to `MEM_callocN<T>`.
* `MEM_cnew_array<T>` allocation version is renamed to `MEM_calloc_arrayN<T>`.
* `MEM_cnew<T>` duplicate version is renamed to `MEM_dupallocN<T>`.
Similar templates type-safe version of `MEM_mallocN` will be added soon
as well.
Following discussions in !134452.
NOTE: For now static type checking in `MEM_callocN` and related are slightly
different for Windows MSVC. This compiler seems to consider structs using the
`DNA_DEFINE_CXX_METHODS` macro as non-trivial (likely because their default
copy constructors are deleted). So using checks on trivially
constructible/destructible instead on this compiler/system.
Pull Request: https://projects.blender.org/blender/blender/pulls/134771
Allows to use this code from C++ code/data, without duplicating strings
to char arrays. C-compatible API is kept as a wrapper around the new
implementation.
No behavioral change is expected from this commit.
Part of !135199.
There is no need for amortized growth for the field interface.
Array seems slightly better than Vector because it's smaller and
doesn't give the impression that the size might change.
Pull Request: https://projects.blender.org/blender/blender/pulls/135257
Float->byte rendered image dithering uses triangle noise algorithm. Keep
the algorithm the same, just make some improvements and fix some issues:
1) The hash function for noise was using "trig" hash from "On generating
random numbers" (Rey 1998), but that is not a great quality hash, plus it
can produce very different results between CPUs/GPUs. Replace it with
"iqint3" (recommended by "Hash Functions for GPU Rendering", JCGT 2020),
which is same performance on GPU, faster on CPU, and much better quality.
This is the same hash as Cycles already uses elsewhere. Also it is purely
integer based, so exactly the same results on all platforms.
2) For the above point, replace `dither_random_value` to take integer
pixel coordinates and adjust calling code accordingly. Some previous
callers were (accidentally?) passing integer coordinates already. Other
places actually get a tiny bit simpler, since they now no longer need an
extra multiplication.
3) The CPU dithering path was wrongly introducing bias, i.e. making the
image lighter. The CPU path also needs dither noise to be in [-1..+1]
range (not [-0.5..+1.5]!) just like GPU path does, since the later
float->byte conversion already does rounding.
4) The CPU dithering path was using thread-slice-local Y coordinate,
meaning the dithering pattern was repeating vertically. The more CPU cores
you use, the worse the repetition.
5) Change the way that uniform noise is converted to triangle noise.
Previous implementation was based on one shadertoy from 2015, change it
to another shadertoy from 2020. The new one fixes issues with the old way,
and it just works on the CPU too, so now both CPU and GPU code paths are
exactly the same.
6) Cleanup: remove DitherContext, just a single float is enough
Performance and image comparisons in the PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/135224
This adds three new functions to find the first 0 or 1 bit in an arbitrarily
long bit span:
```cpp
blender::bits::find_first_0_index(BitSpan) -> std::optional<int64_t>
blender::bits::find_first_1_index(BitSpan) -> std::optional<int64_t>
blender::bits::find_first_1_index_expr(Expr, BitSpans...) -> std::optional<int64_t>
```
The two first ones are implemented in terms of the third. The `*_expr` variant
allows e.g. finding the first set bit when ORing two bit spans together without
computing the entire intermediate result first. Or it can be used to find the
first index where two bit spans are different.
Pull Request: https://projects.blender.org/blender/blender/pulls/134923
The main goal of these changes are to improve static (i.e. build-time)
checks on whether a given data can be allocated and freed with `malloc`
and `free` (C-style), or requires proper C++-style construction and
destruction (`new` and `delete`).
* Add new `MEM_malloc_arrayN_aligned` API.
* Make `MEM_freeN` a template function in C++, which does static assert on
type triviality.
* Add `MEM_SAFE_DELETE`, similar to `MEM_SAFE_FREE` but calling
`MEM_delete`.
The changes to `MEM_freeN` was painful and useful, as it allowed to fix a bunch
of invalid calls in existing codebase already.
It also highlighted a fair amount of places where it is called to free incomplete
type pointers, which is likely a sign of badly designed code (there should
rather be an API to destroy and free these data then, if the data type is not fully
publicly exposed). For now, these are 'worked around' by explicitly casting the
freed pointers to `void *` in these cases - which also makes them easy to search for.
Some of these will be addressed separately (see blender/blender!134765).
Finally, MSVC seems to consider structs defining new/delete operators (e.g. by
using the `MEM_CXX_CLASS_ALLOC_FUNCS` macro) as non-trivial. This does not
seem to follow the definition of type triviality, so for now static type checking in
`MEM_freeN` has been disabled for Windows. We'll likely have to do the same
with type-safe `MEM_[cm]allocN` API being worked on in blender/blender!134771
Based on ideas from Brecht in blender/blender!134452
Pull Request: https://projects.blender.org/blender/blender/pulls/134463
Right now this code is only used to convert boolean arrays to bits (e.g. for
faster `IndexMask` generation). This patch extracts a more general function that
converts bytes to bits using a rule that is passed in as parameter. This may
become useful to speedup parsing e.g. CSV files to speedup detection of
delimiters and other special byte values.
This code is already covered by unit tests, so no new tests have been added.
Pull Request: https://projects.blender.org/blender/blender/pulls/134798
Move the mask_random function to BLI_index_mask.hh, so it can be shared between curves, grease pencil and point cloud.
Copied/inspired by the curves select code.
Pull Request: https://projects.blender.org/blender/blender/pulls/134624
The new CPU compositor in v4.4 is much slower than the old CPU
compositor in v4.3 on Windows. This is because MSVC does not inline many
of the core methods in the Result class of the compositor. To fix this,
we force inline those methods, adding a new macro for inlining methods
in the process, since the existing macro has the static keyword, which
only works for functions, not methods.
Pull Request: https://projects.blender.org/blender/blender/pulls/134748
This reimplements the CSV parser used by the (still experimental) Import CSV
node.
Reliability is improved by:
* Properly handling quoted fields.
* Unit tests.
* Generalizing the parser to be able to handle customized delimiter, quote and
escape characters (those are not exposed in the node yet though).
* More accurate detection of column types by actually taking all values of a
column into account instead of only the first row.
Performance is improved by designing the parser in a way that supports
multi-threaded parsing. I'm measuring about 5x performance improvement which
mainly comes from multi-threading. Some files I wanted to use for benchmarking
didn't load in the version that's in `main` but do load fine with this new
version.
The implementation is now split up into two parts:
1. A general CSV parser in `blenlib` that manages splitting a buffer into
records and their fields.
2. Application specific parsing of fields into e.g. floats and integers which
remains in `io/csv/importer`.
This separation simplifies unit testing and makes the core code more reusable.
Pull Request: https://projects.blender.org/blender/blender/pulls/134715
Remove the padding optimization, it's not significant with the size
of this struct. And by removing the extra padding for bias the size
is the same as before.
Pull Request: https://projects.blender.org/blender/blender/pulls/134769
Note: The point cloud bounding box is not being updated once the points are deleted.
This is a known issue with BKE_pointcloud_nomain_to_pointcloud and Hans is looking into it.
Code inspired/built based on the Delete Geometry node.
Pull Request: https://projects.blender.org/blender/blender/pulls/134622
All 2D vectors related to image transform code were changed to float2.
Previously, it was decided, that 4x4 matrix should be used for 2D
affine transform, but this is changed to 3x3 now.
Texture painting code did rely on `IMB_transform` with 4x4 matrix.
To avoid large changes, I have added function
`BLI_rctf_transform_calc_m3_pivot_min`.
Main motivation is cleaner code - ease of use of c++ API, and avoiding
returning values by arguments.
Pull Request: https://projects.blender.org/blender/blender/pulls/133692
Now all creation, deletion and API is embedded in the struct. The
public API is only a thin wrapper around the struct API.
Previous code was mixing C and C++ code in confusing ways, and was
causing issues with changes worked on in blender/blender!134463, aiming
at better sanity and safety of our data allocations/creations and
freeing/deletions.
NOTE: There could likely be much more refactor fo this code, current
changes are kept to a (reasonable) minimum, to avoid spending too much
time on it.
Pull Request: https://projects.blender.org/blender/blender/pulls/134504
Don't template size for matrix is_negative. These are causing random
build failures on the Windows buildbot.
Note that these already have the assumption of 3D coordinates baked
in. For 2D or 4D coordinates the implementation would have to be
different. So templating these for arbitrary dimensions does not
make much sense.
Pull Request: https://projects.blender.org/blender/blender/pulls/134137
