The method of accumulating values to create a hash for each chunk has
been improved for ~16% better distribution of the resulting hashes.
Improve performance of array de-duplication, see: #105046.
Accumulating hashes with a byte/boolean array didn't include enough
information for a useful hash, creating hashes with many collisions.
This is the root cause of a performance regression since 3.3 where
mesh data (used for storing edit-mesh undo steps) was changed to store
selection in a boolean array, creating a bottleneck de-duplicating
chunks of that array for edit-mesh undo's custom-data de-duplication.
Resolve by increasing hash accumulation for arrays with smaller elements,
so each chunk of memory (a candidate for de-duplication) isn't as likely
to have hash collisions.
`char` (single byte) arrays now accumulate 22 values instead of 7, it's
taking more values into account was necessary as these are effectively
bits in the case of boolean arrays, 2-byte values accumulate 32 bytes,
4-byte elements accumulate 44 bytes, larger structs accumulate
`sizeof(type) * 7` bytes (as before).
Also ensure the accumulation read-ahead never exceeds the chunk size -
technically a fix although this would only happen when passing a small
`chunk_count` to BLI_array_store_create (in the range of 1-16) so this
didn't happen in practice.
Improve performance of array de-duplication, see: #105046.
Use uint32_t since it's sufficient for hashing, using an int64_t was
especially inefficient when allocating an int64_t for every boolean
(when compacting an array of booleans).
Improve performance of array de-duplication, see: #105046.
The reasoning is that the detail namespace is not to be used
outside the module itself. But one might want to use different
number types with these templates.
The `Base` suffix was chosen in order to be consistent with `MatBase`
and `Vector` naming convention.
This patch re-implement the whole C rotation API into a more type
oriented C++ API. See the #104444 design task for more details about
the goals.
The list of C to C++ equivalent syntax can be found attached.
This adds `AngleRadian`, `AngleCartesian` and `AngleFraction` as
different angle types with the same interface. Each of them have
specific benefits / cons. See inline documentation for detail.
This adds `Axis` and `AxisSigned` class wrapped enums to increase type
safety with axes selection.
This adds `CartesianBasis` to represent orthonormal orientations.
Added a weight accumulation to dual-quaternions to make normalization
error proof. Creates the overhead of summing the total weight twice
(which I think is negligible) and add an extra float.
Named the dual-quaternion `DualQuaternion` to avoid naming ambiguity
with `DualQuat` which come up quite often (even with namespace).
Pull Request: https://projects.blender.org/blender/blender/pulls/104941
Increase the buffer sizes used for `BLI_str_format_uint64_grouped` to
prevent overflow on strings representing numbers within the uint64
range. Also creates and uses defines for all the formatted string
buffer sizes.
Pull Request #105263
This commit adds the default .usdz export capability.
The importer already supports usdz so no change is required other than updating the text in menu to match the updated exporter text.
On export, a .usd/a/c file has to be created first, and then converted to .usdz. A weird change of directory is required because of a quirk with the USD conversion to usdz. If an absolute filepath is passed into the `UsdUtilsCreateNewUsdzPackage` function, the usd files inside the usdz archive will have the same directory structure, i.e. if one tries to create a file at `C:\code\BlenderProjects\file.usdz`, when the usdz file is created, inside it will have the structure `\code\BlenderProjects\file.usdc`.
This is counteracted by setting the current working directory to the temporary session directory where both the usdc and usdz files are created, and just passing the file name to `UsdUtilsCreateNewUsdzPackage` without any filepath. Once the usdz file is created it is moved to the intended directory.
There is a separate `UsdUtilsCreateNewARKitUsdzPackage` capability for exporting usdz for iOS devices that will be implemented in a follow up patch as it will require some more small UI changes.
Co-authored-by: Charles Wardlaw (@CharlesWardlaw)
Co-authored-by: Sonny Campbell (@SonnyCampbell_Unity)
Co-authored-by: Bastien Montagne (@mont29)
Pull Request #105185, based on #104556.
Pull Request #105223
While some implementations of `getcwd` may return an allocated string
instead of the given char buffer in some cases, this is not the expected
behavior of the BLI wrapper. Not to mention the danger of returning a
pointer to a static char buffer...
Improve `ChangeWorkingDirectoryTest` to be more 'full check' regarding
behavior of both `BLI_current_working_dir` and `BLI_change_working_dir`.
Also move call to `BLI_threadapi_init` into proper `SetUp` method (to
have correct symmetry with the call to `BLI_threadapi_exit` in the
`TearDown` one).
Based on investigation by Charles Wardlaw (@CharlesWardlaw).
Pull Request #105220
Add `BLI_change_working_dir(path)` to change the current working directory.
This change is required for adding USDZ support to Blender. When exporting to that format, we are required to do a weird change of directory because of a quirk with the USD library's USDZ functionality. If an absolute filepath is passed into the `UsdUtilsCreateNewUsdzPackage` function, the USDZ archive will store that full path.
macOS uses `NSFileManager` through some new Mac-only wrapper functions.
Ref #99807
Pull Request #104525
This commit adds the default .usdz export capability.
The importer already supports usdz so no change is required other than updating the text in menu to match the updated exporter text.
On export, a .usd/a/c file has to be created first, and then converted to .usdz. A weird change of directory is required because of a quirk with the USD conversion to usdz. If an absolute filepath is passed into the `UsdUtilsCreateNewUsdzPackage` function, the usd files inside the usdz archive will have the same directory structure, i.e. if one tries to create a file at `C:\code\BlenderProjects\file.usdz`, when the usdz file is created, inside it will have the structure `\code\BlenderProjects\file.usdc`.
This is counteracted by setting the current working directory to the temporary session directory where both the usdc and usdz files are created, and just passing the file name to `UsdUtilsCreateNewUsdzPackage` without any filepath. Once the usdz file is created it is moved to the intended directory.
There is a separate `UsdUtilsCreateNewARKitUsdzPackage` capability for exporting usdz for iOS devices that will be implemented in a follow up patch as it will require some more small UI changes.
Co-authored-by: Charles Wardlaw (@CharlesWardlaw)
Co-authored-by: Sonny Campbell (@SonnyCampbell_Unity)
Co-authored-by: Bastien Montagne (@mont29)
Pull Request #105185, based on #104556.
While some implementations of `getcwd` may return an allocated string
instead of the given char buffer in some cases, this is not the expected
behavior of the BLI wrapper. Not to mention the danger of returning a
pointer to a static char buffer...
Improve `ChangeWorkingDirectoryTest` to be more 'full check' regarding
behavior of both `BLI_current_working_dir` and `BLI_change_working_dir`.
Also move call to `BLI_threadapi_init` into proper `SetUp` method (to
have correct symmetry with the call to `BLI_threadapi_exit` in the
`TearDown` one).
Based on investigation by Charles Wardlaw (@CharlesWardlaw).
Pull Request #105220
Add `BLI_change_working_dir(path)` to change the current working directory.
This change is required for adding USDZ support to Blender. When exporting to that format, we are required to do a weird change of directory because of a quirk with the USD library's USDZ functionality. If an absolute filepath is passed into the `UsdUtilsCreateNewUsdzPackage` function, the USDZ archive will store that full path.
macOS uses `NSFileManager` through some new Mac-only wrapper functions.
Ref #99807
Pull Request #104525
This reverts commit 19222627c6.
Something went wrong here, seems like this commit merged the main branch
into the release branch, which should never be done.
This reverts commit 68181c2560.
I merged 3.6 into 3.5 by mistake. Basically I had a PR against main,
then changed it in the last minute to be against 3.5 via the
web-interface unaware that I shouldn't do it without updating the
patch.
Original Pull Request: #104889
Note that the node group has its sockets names
translated, while the built-in nodes don't.
So we need to use data_ for the built-in nodes names,
and the sockets of the created node groups.
Pull Request #104889
This better aligns with OSX/Linux warnings.
Although `__pragma(warning(suppress:4100))` is not the same as
`__attribute__((__unused__))` in gcc (which only affects the attribute
instead of the line), it still seems to be better to use it than to
hide the warning entirely.
During hair grooming in curves sculpt mode, it is very useful when hair strands
are prevented from intersecting with the surface mesh. Unfortunately, it also
decreases performance significantly so we don't want it to be turned on all the time.
The surface collision is used by the Comb, Pinch and Puff brushes currently.
It can be turned on or off on a per-geometry basis.
The intersection prevention quality of this patch is not perfect yet. This can
be improved over time using a better solver. Overall, perfect collision detection
at the cost of bad performance is not necessary for interactive sculpting,
because the user can fix small mistakes very quickly. Nevertheless, the quality
can probably still be improved significantly without too big slow-downs depending
on the use case. This can be done separately from this patch.
Pull Request #104469
