On Linux, precompiled libraries may be made with a glibc version that is
incompatible with the system libraries that Blender is built on. To solve
this we add a few -ffast-math symbols that can be missing.
Differential Revision: https://developer.blender.org/D6930
File Browser using Windows file attributes for decorating and hiding items.
Differential Revision: https://developer.blender.org/D6816
Reviewed by Campbell Barton
This applies the change from T73348 fix to related functions.
Instead of checking against an epsilon to avoid divide by zero,
perform the division and check the result is finite.
This is needed since small faces can have an area under 'FLT_EPSILON',
and dividing by values close to zero can result in 'inf'.
Comparing the drive letter was case sensitive,
causing 'BLI_path_rel' to fail in common cases
(manually entering a lower case drive letter for example).
Surprisingly this issue dates back to 2005 and wasn't reported.
- Unlock property range.
- Use triangular noise to keep perceptual noise error more uniform.
Remap range to preserve perceptual intensity.
- Center noise distribution around 0 for GPU implementation because of
rounding.
- Do dithering after merging overlays.
Effect of using triangular noise is not really noticeable if you don't use
really low bitdepth. But doing a test in the shader were we artificially
reduce the bitdepth (`col = (col * 16) / 16;`) reveals the real difference.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D6850
Currently the only option is to warp based on the transform of other
objects, which is inconvenient if you want to e.g. control it through
a driver - you need to set up a dummy object and go through that,
which is clunky and should be unneccessary.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D6690
This enables an extra layer of control in the sculpt brushes.
For now it is enabled only in Scrape, but it should work in all brushes (like normal radius). In the future it may also be enabled in other brushes.
You can tweak in this property in the scrape brush to achieve a much better behavior when working on curve surfaces and control how much volume you want to trim. In most cases, it also fixes the bug where the brush keeps trimming in the same area without disabling accumulate.
It should be possible to fix some other artifacts in other brushes by tweaking this default property.
Reviewed By: jbakker
Differential Revision: https://developer.blender.org/D5993
The changes come from the `functions` branch, where I'm using
these structures a lot.
This also includes a new `BLI::Optional<T>` type, which is similar
to `std::Optional<T>` which can be used when Blender starts using
C++17.
Not sure when this happened but apparently the lower bar is now windows 7 [1]
This patch bumps to API version to 0x0601 (Win7) and cleans up any uses that
worked around the globally set API version.
[1] https://www.blender.org/download/requirements/
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D6758
A big rework of the code now uses exact predicates for orientation
and incircle. Also switched the main algorithm to use a faster
divide and conquer algorithm, which is possible with the exact
predicates.
The dependency graph has to know whether a driver must be re-evaluated
every frame due to a dependency on the current frame number. For python
drivers it was using a heuristic based on searching for certain sub-
strings in the expression, notably including '('.
When the expression is actually evaluated using Python, this can't be
easily improved; however if the Simple Expression evaluator is used,
this check can be done precisely by accessing the parsed data.
Differential Revision: https://developer.blender.org/D6624
This is a more correct fix to the issue Brecht was fixing in D6600.
While the fix in that patch worked fine for linking it broke ASAN
runtime under some circumstances.
For example, `make full debug developer` would compile, but trying
to start blender will cause assert failure in ASAN (related on check
that ASAN is not running already).
Top-level idea: leave it to CMake to keep track of dependency graph.
The root of the issue comes to the fact that target like "blender" is
configured to use a lot of static libraries coming from Blender sources
and to use external static libraries. There is nothing which ensures
order between blender's and external libraries. Only order of blender
libraries is guaranteed.
It was possible that due to a cycle or other circumstances some of
blender libraries would have been passed to linker after libraries
it uses, causing linker errors.
For example, this order will likely fail:
libbf_blenfont.a libfreetype6.a libbf_blenfont.a
This change makes it so blender libraries are explicitly provided
their dependencies to an external libraries, which allows CMake to
ensure they are always linked against them.
General rule here: if bf_foo depends on an external library it is
to be provided to LIBS for bf_foo.
For example, if bf_blenkernel depends on opensubdiv then LIBS in
blenkernel's CMakeLists.txt is to include OPENSUBDIB_LIBRARIES.
The change is made based on searching for used include folders
such as OPENSUBDIV_INCLUDE_DIRS and adding corresponding libraries
to LIBS ion that CMakeLists.txt. Transitive dependencies are not
simplified by this approach, but I am not aware of any downside of
this: CMake should be smart enough to simplify them on its side.
And even if not, this shouldn't affect linking time.
Benefit of not relying on transitive dependencies is that build
system is more robust towards future changes. For example, if
bf_intern_opensubiv is no longer depends on OPENSUBDIV_LIBRARIES
and all such code is moved to bf_blenkernel this will not break
linking.
The not-so-trivial part is change to blender_add_lib (and its
version in Cycles). The complexity is caused by libraries being
provided as a single list argument which doesn't allow to use
different release and debug libraries on Windows. The idea is:
- Have every library prefixed as "optimized" or "debug" if
separation is needed (non-prefixed libraries will be considered
"generic").
- Loop through libraries passed to function and do simple parsing
which will look for "optimized" and "debug" words and specify
following library to corresponding category.
This isn't something particularly great. Alternative would be to
use target_link_libraries() directly, which sounds like more code
but which is more explicit and allows to have more flexibility
and control comparing to wrapper approach.
Tested the following configurations on Linux, macOS and Windows:
- make full debug developer
- make full release developer
- make lite debug developer
- make lite release developer
NOTE: Linux libraries needs to be compiled with D6641 applied,
otherwise, depending on configuration, it's possible to run into
duplicated zlib symbols error.
Differential Revision: https://developer.blender.org/D6642
Based on @fclem's suggestion in D6421, this commit implements support for
storing all tiles of a UDIM texture in a single 2D array texture on the GPU.
Previously, Eevee was binding one OpenGL texture per tile, quickly running
into hardware limits with nontrivial UDIM texture sets.
Workbench meanwhile had no UDIM support at all, as reusing the per-tile
approach would require splitting the mesh by tile as well as texture.
With this commit, both Workbench as well as Eevee now support huge numbers
of tiles, with the eventual limits being GPU memory and ultimately
GL_MAX_ARRAY_TEXTURE_LAYERS, which tends to be in the 1000s on modern GPUs.
Initially my plan was to have one array texture per unique size, but managing
the different textures and keeping everything consistent ended up being way
too complex.
Therefore, we now use a simpler version that allocates a texture that
is large enough to fit the largest tile and then packs all tiles into as many
layers as necessary.
As a result, each UDIM texture only binds two textures (one for the actual
images, one for metadata) regardless of how many tiles are used.
Note that this rolls back per-tile GPUTextures, meaning that we again have
per-Image GPUTextures like we did before the original UDIM commit,
but now with four instead of two types.
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D6456
This might be useful in some places. Much of the code makes the implicit
assumption that the rectangle has valid coordinate order, good to make
it more explicit.
E.g. "Cube" would be placed after "Cube.001", which is not what you'd
expect. 2.80 handled this correctly.
Loosely based on D6525 by @radcapricorn, but found a bug in that and
prefered to do some further adjustments.
Also activates test for this case.
