Age | Commit message (Collapse) | Author |
|
|
|
We've got quite comprehensive BMesh based implementation, which is way easier
for maintenance than abandoned Carve library.
After all the time BMesh implementation was working on the same level of
limitations about manifold meshes and touching edges than Carve. Is better
to focus on maintaining one boolean implementation now.
Reviewers: campbellbarton
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D3050
|
|
This brings separate initialization for libcuda and libnvrtc, which
fixes Cycles nvrtc compilation not working on build machines without
CUDA hardware available.
Differential Revision: https://developer.blender.org/D3045
|
|
nvcc is very picky regarding compiler versions, severely limiting the compiler we can use, this commit adds a nvrtc based compiler that'll allow us to build the cubins even if the host compiler is unsupported. for details see D2913.
Differential Revision: http://developer.blender.org/D2913
|
|
This reverts commit ea31f0ac3b877eb0df4c47d0c908d11d1bff33e4.
|
|
|
|
D2860 by @miqlas
Even though Haiku is a niche OS, only minor changes are needed.
|
|
|
|
|
|
|
|
Previous update pulled too much of system-wide typedefs.
|
|
Brings new declarations from toolkit version 8.0, also fixes some
pointers used in function declarations.
|
|
|
|
The Issue
=======
For a long time now MinGW has been unsupported and unmaintained and at this point,
it looks like something that we should just leave behind and move on.
Why Remove
==========
One of the big motivations for MinGW back in the day is that it was free compared to MSVC which was licensed based.
However, now that this is no longer true we have basically stopped updating the need CMake files.
Along with the CMake files, there are several patches to the extern libs needed to make this work. For example, see:
https://developer.blender.org/diffusion/B/browse/master/extern/carve/patches/mingw_w64.patch
If we wanted to keep MinGW then we would need to make more custom patches to the external libs and
this is not something our platform maintainers are willing to do.
For example, here is the patches needed to build python: https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-python3
Fixes T51301
Differential Revision: https://developer.blender.org/D2648
|
|
Avoid calculating a new split-index when re-fitting.
While checking if a knot can be removed, the index with the highest error
can be used as a candidate to replace the knot
(in the case it can't be removed).
|
|
It is disabled by default, so should not affect existing configurations.
Main benefits of this goes as:
- Linux distros can use that to avoid libraries duplication and link
blender package against gflags package from the system.
- It it easier to test whether Blender works with updated version of
Gflags prior to re-bundling the library.
|
|
|
|
Needed to get access to some AMD extensions.
|
|
Patch by Bruno d'Arcangeli (@arcangeli), thanks!
|
|
|
|
|
|
|
|
|
|
There is syscall headers but no SYS_Write syscall.
|
|
This was fixed in upstream already. Time to re-bundle?
|
|
Something was conflicting here, causing C++ to consider bool as
a __vector(4) bool.
|
|
|
|
Brings all the fixes and improvements done in upstream within the last 13 months.
|
|
__inline instead of inline is needed.
|
|
Rewrite the current range-tree API used by dyn-topo undo
to avoid inefficiencies from stdc++'s set use.
- every call to `take_any` (called for all verts & faces)
removed and added to the set.
- further range adjustment also took 2x btree edits.
This patch inlines a btree which is modified in-place,
so common resizing operations don't need to perform a remove & insert.
Ranges are stored in a list so `take_any` can access the first item
without a btree lookup.
Since range-tree isn't a bottleneck in sculpting, this only gives minor speedups.
Measured approx ~15% overall faster calculation for sculpting,
although this number time doesn't include GPU updates and depends on how
much edits fragment the range-tree.
|
|
Fixes typo in README :)
Thanks to @jesterKing!
|
|
|
|
|
|
|
|
|
|
In practice the initial values are almost never used.
|
|
Was polluting compile output too much.
|
|
Solves issue reported in T49144.
|
|
In practice this wasn't likely to cause problems, but better fix.
|
|
|
|
Correct accidental float use
|
|
Fitting lines that exactly double back on themselves could give NAN length handles.
|
|
|
|
|
|
Required to get GMock working with GTest.
|
|
|
|
|
|
|
|
|
|
|