This follows the other CMake "modernization" commits, this time for
`bf_intern_openvdb` and the OpenVDB dependency itself.
The difference with this one is that `intern/openvdb` becomes an
"optional" dependency itself. This is because downstream consumers often
want to include this dependency rather than openvdb directly, so this
target must also be optional. Optional, in this case, means the target
always exists but may be entirely empty.
Summary
- If you are using BKE APIs to access openvdb features, then use the
`bf::blenkernel` target
- If you are only using `intern/openvdb` APIs then use the
`bf::intern::optional::openvdb` target (rare)
- For all other cases, use the `bf::dependencies::optional::openvdb`
target (rare)
context: https://devtalk.blender.org/t/cmake-cleanup/30260
Pull Request: https://projects.blender.org/blender/blender/pulls/137071
It's better for performance to use a single thread pool for all areas of
Blender, and this gets us closer to that.
Bullet, Quadriflow, Mantaflow and Ceres still contain OpenMP code, but it
was already disabled.
On macOS, our OpenMP libraries are no longer compatible with the latest
Xcode 16.3. By removing OpenMP we no longer have to solve that problem.
OpenMP was disabled for bpy module builds on Windows ARM64, which also no
longer needs to be solved.
Pull Request: https://projects.blender.org/blender/blender/pulls/136865
This continues the cmake modernization effort and introduces support for
allowing our optional dependencies to integrate properly. TBB is added
here as it's proven troublesome to maintain correctly.
Currently the only Blender project which uses the TBB headers directly
is `blenlib`. However, all downstream projects which require blenlib as
their dependency, and wish to properly make use of its threading
facilities, needed to define various TBB items in their CMake files. Not
only is this unnecessary and arcane, but several projects didn't do this
and ended up not using threading as well as producing ODR violations
along the way[1].
This PR makes TBB a modern dependency and exposes it PUBLIC'ly from
`blenlib`. All downstream projects which depend on blenlib will now
receive everything they require from TBB automatically. This includes
the `WITH_TBB` define, the headers, and the library itself.
[1] blender/blender@05241f47f5
Pull Request: https://projects.blender.org/blender/blender/pulls/124916
* Different fix for Mantaflow linker warnings that works with new OpenVDB.
* Use new linker for arm64 as it no longer produces warnings with latest
Xcode. Still use the old one for x86_64 as some warnings remain.
* Fix wrong x86_64 build target in deps builder.
For the upcoming 4.1 libraries.
Ref #113157
Pull Request: https://projects.blender.org/blender/blender/pulls/116708
The goal is to solve confusion of the "All rights reserved" for licensing
code under an open-source license.
The phrase "All rights reserved" comes from a historical convention that
required this phrase for the copyright protection to apply. This convention
is no longer relevant.
However, even though the phrase has no meaning in establishing the copyright
it has not lost meaning in terms of licensing.
This change makes it so code under the Blender Foundation copyright does
not use "all rights reserved". This is also how the GPL license itself
states how to apply it to the source code:
<one line to give the program's name and a brief idea of what it does.>
Copyright (C) <year> <name of author>
This program is free software ...
This change does not change copyright notice in cases when the copyright
is dual (BF and an author), or just an author of the code. It also does
mot change copyright which is inherited from NaN Holding BV as it needs
some further investigation about what is the proper way to handle it.
These warnings can reveal errors in logic, so quiet them by checking
if the features are enabled before using variables or by assigning
empty strings in some cases.
- Check CMAKE_THREAD_LIBS_INIT is set before use as CMake docs
note that this may be left unset if it's not needed.
- Remove BOOST/OPENVDB/VULKAN references when disable.
- Define INC_SYS even when empty.
- Remove PNG_INC from freetype (not defined anywhere).
Building against the existing 3.1 libraries should continue to work, until
the precompiled libraries are committed for all platforms.
* Enable WebP by default.
* Update Windows for new library file names.
* Automatically clear outdated CMake cache variables when upgrading to new
libraries.
* Fix static library linking order issues on Linux for OpenEXR and OpenVDB.
Implemented by Ray Molenkamp, Sybren Stüvel and Brecht Van Lommel.
Ref T95206
Use a shorter/simpler license convention, stops the header taking so
much space.
Follow the SPDX license specification: https://spdx.org/licenses
- C/C++/objc/objc++
- Python
- Shell Scripts
- CMake, GNUmakefile
While most of the source tree has been included
- `./extern/` was left out.
- `./intern/cycles` & `./intern/atomic` are also excluded because they
use different header conventions.
doc/license/SPDX-license-identifiers.txt has been added to list SPDX all
used identifiers.
See P2788 for the script that automated these edits.
Reviewed By: brecht, mont29, sergey
Ref D14069
All headers in the svn libraries should be
building with /W0 however MSVC 16.8/16.9
has broken this functionality making OpenVDB
emit lots of warnings.
The breakage was reported [1] in august to MS
but they still have not gotten around to
addressing the issue.
This change explicitly suppresses C4251 in the
module that emitted these warnings. As the warning
is useful in other parts of blender a localized
approach is taken rather than a global suppression.
[1] https://developercommunity.visualstudio.com/content/problem/1167590/bug.html
* USD and OpenVDB headers use deprecated TBB headers, suppress all deprecation
warnings there since we have no control over them.
* For our own TBB includes, use the individual headers rather than the tbb.h that
includes everything to avoid warnings, rather than suppressing all.
This is in anticipation of the TBB 2020 upgrade in D10359. Ref D10361.
Mainly updated the Mantaflow version. It includes the new viscosity solver plugin based on the method from 'Accurate Viscous Free Surfaces for Buckling, Coiling, and Rotating Liquids' (Batty & Bridson).
In the UI, this update adds a new 'Viscosity' section to the fluid modifier UI (liquid domains only). For now, there is a single 'strength' value to control the viscosity of liquids.
Issues were:
* Abusing of `WITH_PYTHON_INSTALL_NUMPY` by both Audaspace and
Mantaflow.
- `PYTHON_INSTALL` options only decide whether we copy python (and
some extra modules) in our Blender installation. On linux it
makes much more sense to use global python installation.
- Now we have instead a proper `WITH_PYTHON_NUMPY`
* Bad assumptions regarding path of headers relative to path of python
module.
- In current Debian testing, modules are under `python3.9`
directory, while headers are under `python3` directory.
- Now we properly `find_path` for headers as well, modifying
`find_python_package` to take an optional argument for headers.
Note that the required changes done to `extern` libraries are in
blender-specific files that do not exist upstream.
Differential Revision: https://developer.blender.org/D9773
Issues were:
* Abusing of `WITH_PYTHON_INSTALL_NUMPY` by both Audaspace and
Mantaflow.
- `PYTHON_INSTALL` options only decide whether we copy python (and
some extra modules) in our Blender installation. On linux it
makes much more sense to use global python installation.
- Now we have instead a proper `WITH_PYTHON_NUMPY`
* Bad assumptions regarding path of headers relative to path of python
module.
- In current Debian testing, modules are under `python3.9`
directory, while headers are under `python3` directory.
- Now we properly `find_path` for headers as well, modifying
`find_python_package` to take an optional argument for headers.
Note that the required changes done to `extern` libraries are in
blender-specific files that do not exist upstream.
Differential Revision: https://developer.blender.org/D9773
This resolves a long list of linker warnings that is currently only showing up on macOS arm builds.
The warnings themselves are of this shape (one example):
```
ld: warning: direct access in function 'Manta::MeshDataImpl<Manta::Vector3D<float> >::_W_39(_object, object, object*)' from file '../../lib/libextern_mantaflow.a(mesh.h.reg.cpp.o)' to global weak symbol 'typeinfo for Manta::MeshDataImpl<Manta::Vector3D<float> >' from file '../../lib/libextern_mantaflow.a(mesh.cpp.o)' means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
```
Just would like to get your opinion to make sure this is an acceptable way to handle this on all platforms.
Reviewed By: LazyDodo
Differential Revision: https://developer.blender.org/D9002
This patch changes openvdb from a static to a dynamic library.
this is in preparation for enabling pyopenvdb at some point
in the future.
Differential Revision: https://developer.blender.org/D8282
Reviewed by: brecht
Adjusted the fluid build system so that plugins that depend on numpy can be compiled as well.
Note that in this commit numpy support is still disabled. It can be enabled by re-running the Mantaflow update script with USE_NUMPY=1 and enabling WITH_MANTA_NUMPY in extern/mantaflow/CMakeLists.txt. This will happen in a future commit.
No longer including unused dependencies. Should numpy IO be needed at some point, the Manta source update script can be configured so that the required dependencies are included again.
This updated set of Mantaflow files includes the improved OpenVDB file IO. With this update it is finally possible to store multiple grids per file. It is also possible to save particle systems and particle data to OpenVDB files.
MSVC has a conformance mode (/permissive-) where the C++ standard is more strictly
enforced. This mode is available on MSVC 15.5+ [1]
This patch enables this mode on compilers that support it and cleans up the few violations it threw up in the process.
- Mantaflow was using M_PI without requesting them using the _USE_MATH_DEFINES define to opt in to non default behaviour.
- Collada did not include the right header for std::cerr, this seemingly was fixed for other platforms already but put inside a platform guard.
- Ghost had some scoping issues regarding uninitialized variables and goto behaviour
Second landing of this patch, earlier commit was reverted due to some compiler configurations having slipped though testing
[1] https://docs.microsoft.com/en-us/cpp/build/reference/permissive-standards-conformance
Differential Revision: https://developer.blender.org/D6824
Reviewed By: brecht
MSVC has a conformance mode (/permissive-) where the C++ standard is more strictly
enforced. This mode is available on MSVC 15.5+ [1]
This patch enables this mode on compilers that support it and cleans up the few violations it threw up in the process.
- Mantaflow was using M_PI without requesting them using the _USE_MATH_DEFINES define to opt in to non default behaviour.
- Collada did not include the right header for std::cerr, this seemingly was fixed for other platforms already but put inside a platform guard.
- Ghost had some scoping issues regarding uninitialized variables and goto behaviour
[1] https://docs.microsoft.com/en-us/cpp/build/reference/permissive-standards-conformance
Differential Revision: https://developer.blender.org/D6824
Reviewed By: brecht
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
This aligns with the VFX reference platform 2020 along with the decision
to stick to Python 3.7, see T68774.
Blosc was downgraded to 1.5 as recommended by the OpenVDB documentation.
IlmBase and OpenEXR are now built together with CMake rather separately
using autoconf.
Differential Revision: https://developer.blender.org/D6593
A bug in llvm < 9.0.1 causes the compiler to crash when
openmp is enabled. Since mantaflow uses tbb we can safely
disable this flag temporarily for this module.
Reviewed By: sebbas
Differential Revision: https://developer.blender.org/D6446
A collection of smaller changes that are required in the /blender/source files. A lot of them are also due to variable renaming.
Reviewed By: sergey
Maniphest Tasks: T59995
Differential Revision: https://developer.blender.org/D3855
