| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
This is an alternative method for fitting a curve which incrementally simplifies the curve, then re-fits.
Generally gives better results, also improves corner detection.
|
|
This reverts commit f12204196fb1ee985ab9745cf9c70877601145f9.
Campbell, sorry. have to revert this for the time being.
We've missed some very important bits, such as:
- FFmpeg is usually linked against OpenJPEG
- OIIO needs OpenJPEG as well.
For FFmpeg issues we can either disable OpenJPEG there (since
we don't really use it), or bump FFmpeg to version 3.1.1 which
can use either of OpenJPEG 1.5 or 2.1.
For OIIO we do need OpenJPEG support (otherwise Cycles will
not be able to use j2k/j2c textures) and currently there is
NO solution to make OIIO working with OpenJPEG 2.1.
According to Matthias Fauconneau (aka mfv) Larry is working
on the patch to get OIIO work with OpenJPEG 2.1, but it'll
take some time still.
I've tried to look into support of some sort of build system
flag and do ifdefs, but it all becomes quite nasty, especially
with bundled OpenJPEG bumped to 2.1.
Surely such an update is something we'll have to apply to
but at this exact moment it causes quite some pain for all
developers.
Suggest to wait for until OIIO supports OpenJPEG 2.1 and then
go with the updates for real.
|
|
Stream handling has changed so this required changes to how files & memory are accessed.
|
|
|
|
When this flag is set - even when the curve error is under the threshold,
keep attempting a better fit.
Enable this for freehand drawing, since it gives nicer results and isn't noticeably slower.
|
|
Add a new fallback method that uses offset distance from the curve to the line between both points,
for freehand drawing it typically only fives minor improvements (1-3% fewer points),
for curve dissolve the improvements are more noticeable.
|
|
|
|
|
|
|
|
|
|
|
|
|
