We have our own assert implementation, `BLI_assert()` that is prefered over the
C standard library one. Its output is more consistent across compilers and
makes termination on assert failure optional (through `WITH_ASSERT_ABORT`).
In many places we'd include the C library header without ever accessing it.
The problem is due to lack of precision with small and coplanar triangles.
Also, triangles that have vertices with the same coordinate are at the
threshold of the intersection.
We could add an epsilon to consider the minimum distance for intersection.
But that would add a lot of overhead to the code.
The solution used is to increase precision using doubles.
The issue was two fold.
First something sets the loop element tag and doesn't clear it before
the UV code in question tries to use the tags. Added a sanity clear to
make sure that it operates on a clean tag state.
The next one was that the UV maps in question had quite a few points
that had zero length UV loop edges. This would lead to division by
zero.
Reviewed By: Jeroen Bakker, Brecht
Differential Revision: http://developer.blender.org/D8967
The ffmpeg, guardedalloc and blenlib are quite isolated and putting them in
their own executable separate from blender_test is faster for development than
linking the entire blender_tests executable.
For Cycles, this also bundles all the unit tests into one executable.
Ref T79958
Differential Revision: https://developer.blender.org/D8714
Since this buffer is used as an array of 12 32bits integers, and C++
string expect a NULL-terminated C-string, we need an extra char to
ensure last one is always NULL.
See D8906. Thanks to @brecht for noting this one too.
Also added code so that exact solver does the whole collection at once.
This patch allows users to use a collection (as an alternative to Object)
for the boolean modifier operand, and therefore get rid of a long modifier stack.
This adds a generic string search library in `BLI_string_search.h`.
The library has a simple to use C api that allows it's users to
filter and sort a set of possible search results based on some
query string.
Reviewers: Severin
Differential Revision: https://developer.blender.org/D8825
On systems with 512kb stack this happened at around 13k points.
This happened at times with grease-pencil, although callers that
frequently use complex polygons should be using BLI_polyfill_calc_arena.
Well, this only fixes the example if one uses the new Exact mode,
but since that is available, seems fair to call this fixed.
Since these were not closed-volume operands, the Exact mode needed
some adjustment to the threshold used for "inside-outside" tests
for the case of deciding if the cutter is inside the other shape
for a Difference.
The code to detect non-trivial coplanar intersection sometimes
falsely said there wasn't one. This caused some coplanar intersections
to be missed. Also added a test for this case.
This was reported for the "Add Node" search functionality, but is
relevant in other searches as well.
So e.g. when searching for "Separate XYZ", typing "sep", then " " (with
the intention to type "X" next) would clear the search field. Now use
the same method (matching against all search words) as in F3 searching
('menu_search_update_fn') in other searches as well [searching IDs,
property objects, finding nodes,...]
This should give a much nicer search experience in general.
Note: this does not touch other searches in the Dopesheet, Outliner,
Filebrowser or User Preferences that have other search implementations.
Maniphest Tasks: T78084
Differential Revision: https://developer.blender.org/D8232
The animated objects was not updated for each internal substep for the rigidbody sim.
This would lead to unstable simulations or very annoying clipping artifacts.
Updated the code to use explicit substeps and tie it to the scene frame rate.
Fix T47402: Properly updating the animated objects fixes the reported issue.
Reviewed By: Brecht, Jacques
Differential Revision: http://developer.blender.org/D8762
- Direct assignment caused ID user counts to be invalid.
- The first palette would always be used,
even when the named palette searched for was found.
Also pass 'const' string to `hex_to_rgb`, avoid casting to 'non-const'.
Instead of calculating exact normals for all faces, just do it
for those that potentially intersect. A big improvement for dense
meshes that only intersect in relatively few places.
