The idea is to create vertices along the coarse edges once, without
splitting coarse edges on separate ptex faces. This requires some
indexing magic, vertices within a patch are no longer sequential.
Not sure how to make it nicer without such a black magic looking
calculations (which are basically boiling down to mimicking order
of verts/edges creation).
In the current offsets calculation loose verts and edges are not
properly taken into account, but those are causing topology refiner
to fail anyway, so it needs a bit deeper change.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D3570
This is in preparation of upgrading our library dependencies, some of which
need C++11. We already use C++11 in blender2.8 and for Windows and macOS, so
this just affects Linux.
On many distributions this will not require any changes, on some
install_deps.sh will need to be run again to rebuild libraries.
Differential Revision: https://developer.blender.org/D3568
Damped Track by specification attempts to arrive at the desired
direction via the shortest rotation. However with opposite vectors
there are infinitely many valid 180 degree rotations. Currently
it gives up and does nothing.
I think that it would be more reasonable to resolve the ambiguity
arbitrarily, so that Damped Track won't have a weird dead zone.
To make it more predictable I use a local axis.
In addition, the singularity area vicinity has some floating
point precision problems that result in significant jitter.
This applies workarounds for two causes of instability.
Differential Revision: https://developer.blender.org/D3530
This patch adds a new matte node that implements the Cryptomatte specification.
It also incluces a custom eye dropper that works outside of a color picker.
Cryptomatte export for the Cycles render engine will be in a separate patch.
Reviewers: brecht
Reviewed By: brecht
Subscribers: brecht
Tags: #compositing
Differential Revision: https://developer.blender.org/D3531
There were two issues here, introduced by rB66aa4af836:
* Forgot to change length of some filter_glob var deep in filebrowser code.
* Truncating filter_glob in general can be dangerous, generating
unexpected patterns.
Last point was the root of the issue here, truncating to 63 chars string
left last group as 'match everything' `*` pattern.
To fix that to some extent, added a new BLI_path_extension_glob_validate
helper to BLI_path_util, which ensures we do not have last
wildcards-only group in our pattern, when there are more than one group.
All areas are toy use "local" number generator, in order to keep
behavior predictable and threadable. This is what BLI_rng_() API
is for.
There are still lots of usages of BLI_frand(), which are to be
ported to BLI_rng_get_float(). but that is somewhat involved.
For the time being, remove unsafe API, so new areas have zero
chance using it.
atoi usage in BLI_stringdec could overflow, use strtoll instead and
check
valid range with INT_MIN and INT_MAX
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D3452
In some heavy rigs matrix inverse can be 10% of computation time. This
reduces it to 2% by using Eigen's optimized 4x4 matrix inverse and SSE
matrix multiplication.
This commit contains the minimum to make clang build/work with blender, asan and ninja build support is forthcoming
Things to note:
1) Builds and runs, and is able to pass all tests (except for the freestyle_stroke_material.blend test which was broken at that time for all platforms by the looks of it)
2) It's slightly faster than msvc when using cycles. (time in seconds, on an i7-3370)
victor_cpu
msvc:3099.51
clang:2796.43
pavillon_barcelona_cpu
msvc:1872.05
clang:1827.72
koro_cpu
msvc:1097.58
clang:1006.51
fishy_cat_cpu
msvc:815.37
clang:722.2
classroom_cpu
msvc:1705.39
clang:1575.43
bmw27_cpu
msvc:552.38
clang:561.53
barbershop_interior_cpu
msvc:2134.93
clang:1922.33
3) clang on windows uses a drop in replacement for the Microsoft cl.exe (takes some of the Microsoft parameters, but not all, and takes some of the clang parameters but not all) and uses ms headers + libraries + linker, so you still need visual studio installed and will use our existing vc14 svn libs.
4) X64 only currently, X86 builds but crashes on startup.
5) Tested with llvm/clang 6.0.0
6) Requires visual studio integration, available at https://github.com/LazyDodo/llvm-vs2017-integration
7) The Microsoft compiler spawns a few copies of cl in parallel to get faster build times, clang doesn't, so the build time is 3-4x slower than with msvc.
8) No openmp support yet. Have not looked at this much, the binary distribution of clang doesn't seem to include it on windows.
9) No ASAN support yet, some of the sanitizers can be made to work, but it was decided to leave support out of this commit.
Reviewers: campbellbarton
Differential Revision: https://developer.blender.org/D3304
