| Age | Commit message (Collapse) | Author |
|---|
|
This diff somewhat snowballed out of updating OIDN to 1.4.1 it had some
changes that allowed us to remove the arm hacks we had in place and
revert to using identical versions for a whole bunch of deps. But that
required an update to ISPC which needed a newer LLVM and if we're
updating LLVM we may as well update OSL, and when we update OSL, OIIO
may as well be dragged in soo......anyhow...
This diff updates:
LLVM 9.0.0 (11.0.1 for mac/arm) -> 12.0.0
OIIO 2.1.15.0 -> 2.2.15.1
OSL 1.11.10.0 -> 1.11.14.1
winflex_bison 2.5.5-> 2.5.24 (ispc needed newer bison, windows only dep)
OIDN 1.4.0 -> 1.4.1
ISPC v1.14.1(random hash for mac/arm) -> v1.16.0
Flex 2.6.4 (ISPC needed newer Flex than available on CentOS 7)
and removes most of the "special arm/mac" versions. I think just ssl and
embree are left with special versions.
notable changes:
@LazyDodo included some clang headers in the linux/mac harvest which are
needed to start writing custom clang based tooling like D9465 these were
already shipping on windows, but not the other platforms.
[macOS] Change the `LC_ID_DYLIB` of OpenMP for {D11997}. This changes
where the executables look for dylibs.
Reviewed By: sebbas, LazyDodo
Differential Revision: https://developer.blender.org/D11748
|
|
Having zstd available is a requirement for landing D5799
Reviewed By: sybren
Differential Revision: https://developer.blender.org/D11079
|
|
|
|
Differential Revision: https://developer.blender.org/D10958
|
|
This bumps OSL to 1.11.10.0. OSL Has a new build time
dependency: Clang, and more importantly it expects
clang and llvm to share a library folder, which it
previously for us did not.
This patch changes:
-OSL Update to 1.11.10.0
-refactor the llvm/clang/clang-tools-extra builds into the llvm
build using the llvm-project tarball for building that has all
of the subprojects in it.
-update ispc/openmp builds since clang no longer its own dependency
and they have to depend on the llvm build now.
-Update the windows builder to use the 64 bit host tools since it
ran out of ram linking clang
-Since OSL now needs clang to link successfully a findclang.cmake
has been provided for linux/OSX
Differential Revision: https://developer.blender.org/D10212
Reviewed By: brecht, sebbas, sybren
|
|
The upgraded Mesa (see D10282) stores library files in `mesa/lib64`.
|
|
This required using a fork of Embree, newer LLVM version, unreleased ISPC
version and sse2neon directly from Git. Hopefully over time all the required
changes end up in official releases. For now we deviate from other platforms.
Based on contributions by Apple and Stefan Werner.
Ref D9527, D8237, T78710
|
|
The following packages also have received updates:
- IDNA 2.10
- CHARDET 4.0.0
- URLLIB3 1.26.3
- CERTIFI 2020.12.5
- REQUESTS 2.25.1
- NUMPY 1.19.5
numpy has gained a hard dependency on cython:
- CYTHON 0.29.21
Notes:
- This only updates the build environment files,
once these are built, Blender can default to Python 3.9.
- The 'm' suffix for Python binaries/libs has been removed.
- The macOS patch in Python 3.7 is has been removed.
Reviewed By: sybren, campbellbarton, sebbas
Ref D10257
|
|
Decision: https://lists.blender.org/pipermail/bf-committers/2020-December/050836.html
Adds CMake dependency builder support. Tested on
macOS and Windows (Thanks @LazyDodo).
Reviewed By: #platform_macos, LazyDodo, sebbas
Maniphest Task: T84836
Differential Revision: https://developer.blender.org/D9928
|
|
This patch builds clang-extra-tools on macOS for the
clang-tidy binary. The script "run-clang-tidy.py" is
also harvested because using the `CMAKE_C[XX]_CLANG_TIDY`
option can miss out some files (like makesrna), and using the
script is faster as it does not compile the files.
Thanks to `@LazyDodo` for the base patch D8502.
Reviewed By: LazyDodo, sebbas, #platform_macos
Differential Revision: https://developer.blender.org/D9450
|
|
This separates out PugiXML that was previously
bundled by OIIO.
As this linux/mac libs are not available
this commit only contains the builder and windows
changes, and the option to enable pugixml is
guarded by a platform if, this can be removed
once all platforms have committed the svn libs.
For details see D8628
|
|
Changes NanoVDB to be a standalone dependency that is independent of the OpenVDB one.
It works by downloading the "feature/nanovdb" branch of OpenVDB, but using the NanoVDB
CMake in the "nanovdb" subdirectory. Since it is header-only, only the install target is used.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D9383
|
|
NanoVDB is a platform-independent sparse volume data structure that makes it possible to
use OpenVDB volumes on the GPU. This patch uses it for volume rendering in Cycles,
replacing the previous usage of dense 3D textures.
Since it has a big impact on memory usage and performance and changes the OpenVDB
branch used for the rest of Blender as well, this is not enabled by default yet, which will
happen only after 2.82 was branched off. To enable it, build both dependencies and Blender
itself with the "WITH_NANOVDB" CMake option.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D8794
|
|
For work the GP team plans to land soon (T79877) potrace was taken
on as an additional optional dependency.
This diff adds building the library to the deps builder and takes
care of the integration into the build-system with the `WITH_POTRACE`
cmake switch.
Differential Revision: https://developer.blender.org/D8662
Reviewed by: brecht, sergey
|
|
Required for the new boolean code, disabled by default
until all platforms have landed the libs and the boolean
code actually lands in master.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D8384
|
|
|
|
Enabling all `make deps` dependencies with the exception of Embree and OIDN.
After that, Blender can be compiled on an Apple Silicon Mac just like on any
Intel based Mac. There are still compiler warnings that need to be
investigated and there are probably a couple of bug still to be discovered
and to be fixed.
Most patches to the dependencies are simple and are about disabling SSE and
setting the proper architecture to compiile for. Notable exception is Python,
where I back ported a yet to be accepted PR for upstream Python:
https://github.com/python/cpython/pull/21249
Cross compiling or buliding a Universal Binary is not supported yet.
The minimum macOS target version for x86_64 remains at 10.13, the target
for arm64 is 11.00.
Differential Revision: https://developer.blender.org/D8236
|
|
Ref T76184
|
|
This is a follup to 0c384362272.
No functional changes to Blender, just the build scripts.
|
|
This is the cluster of OIIO and friends , since they are all kinda tangled best to deal with this as a single unit
OIIO 2.1.15.0
png 1.6.37
jpeg 2.0.4
opencolorio 1.1.1
tiff 4.1.0
OSL 1.10.10
pugixml 1.10
openjpeg 2.3.1
Differential Revision: https://developer.blender.org/D7727
Reviewed by: brecht
|
|
Unsure what it is that upsets it so much, but when linking
both sndfile and fftw dynamically, the linker gets confused
and thinks that fftw is importing sf_close from the blender
binary (which makes *NO* sense) leading to a start-up error.
Generating the import library from the .def file using the
ms lib tool creates an import library that works fine.
|
|
- Harvest to a proper location.
- Disable STD's filesystem which is experimental and caused
linking errors when OpenXR is usedi n Blender.
|
|
The OpenXR-SDK contains utilities for using the OpenXR standard
(https://www.khronos.org/openxr/). Namely C-headers and a so called
"loader" to manage runtime linking to OpenXR platforms ("runtimes")
installed on the user's system.
The WITH_XR_OPENXR build option is disabled by default for now, as there
is no code using it yet. On macOS it will remain disabled for now, it's
untested and there's no OpenXR runtime in sight for it.
Some points on the OpenXR-SDK dependency:
* The repository is located at
https://github.com/KhronosGroup/OpenXR-SDK (Apache 2).
* Notes on updating the dependency:
https://wiki.blender.org/wiki/Source/OpenXR_SDK_Dependency
* It contains a bunch of generated files, for which the sources are in a
separate repository
(https://github.com/KhronosGroup/OpenXR-SDK-Source).
* We could use that other repo by default, but I'd rather go with the
simpler solution and allow people to opt in if they want advanced dev
features.
* We currently use the OpenXR loader lib from it and the headers.
* To use the injected OpenXR API-layers from the SDK (e.g. API
validation layers), the SDK needs to be compiled from this other
repository.
The extra "XR_" prefix in the build option is to avoid mix-ups of OpenXR
with OpenEXR.
Most of this comes from the 2019 GSoC project, "Core Support of Virtual
Reality Headsets through OpenXR"
(https://wiki.blender.org/wiki/User:Severin/GSoC-2019/).
Differential Revision: https://developer.blender.org/D6188
Reviewed by: Campbell Barton, Sergey Sharybin, Bastien Montagne, Ray
Molenkamp
|
|
|
|
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
|
|
|
|
This commit introduces the first version of an exporter to Pixar's
Universal Scene Description (USD) format.
Reviewed By: sergey, LazyDodo
Differential Revision: https://developer.blender.org/D6287
- The USD libraries are built by `make deps`, but not yet built by
install_deps.sh.
- Only experimental support for instancing; by default all duplicated
objects are made real in the USD file. This is fine for exporting a
linked-in posed character, not so much for thousands of pebbles etc.
- The way materials and UV coordinates and Normals are exported is going
to change soon.
- This patch contains LazyDodo's fixes for building on Windows in D5359.
== Meshes ==
USD seems to support neither per-material nor per-face-group
double-sidedness, so we just use the flag from the first non-empty
material slot. If there is no material we default to double-sidedness.
Each UV map is stored on the mesh in a separate primvar. Materials can
refer to these UV maps, but this is not yet exported by Blender. The
primvar name is the same as the UV Map name. This is to allow the
standard name "st" for texture coordinates by naming the UV Map as such,
without having to guess which UV Map is the "standard" one.
Face-varying mesh normals are written to USD. When the mesh has custom
loop normals those are written. Otherwise the poly flag `ME_SMOOTH` is
inspected to determine the normals.
The UV maps and mesh normals take up a significant amount of space, so
exporting them is optional. They're still enabled by default, though.
For comparison: a shot of Spring (03_035_A) is 1.2 GiB when exported
with UVs and normals, and 262 MiB without. We probably have room for
optimisation of written UVs and normals.
The mesh subdivision scheme isn't using the default value 'Catmull
Clark', but uses 'None', indicating we're exporting a polygonal mesh.
This is necessary for USD to understand our normals; otherwise the mesh
is always rendered smooth. In the future we may want to expose this
choice of subdivision scheme to the user, or auto-detect it when we
actually support exporting pre-subdivision meshes.
A possible optimisation could be to inspect whether all polygons are
smooth or flat, and mark the USD mesh as such. This can be added when
needed.
== Animation ==
Mesh and transform animation are now written when passing
`animation=True` to the export operator. There is no inspection of
whether an object is actually animated or not; USD can handle
deduplication of static values for us.
The administration of which timecode to use for the export is left to
the file-format-specific concrete subclasses of
`AbstractHierarchyIterator`; the abstract iterator itself doesn't know
anything about the passage of time. This will allow subclasses for the
frame-based USD format and time-based Alembic format.
== Support for simple preview materials ==
Very simple versions of the materials are now exported, using only the
viewport diffuse RGB, metallic, and roughness.
When there are multiple materials, the mesh faces are stored as geometry
subset and each material is assigned to the appropriate subset. If there
is only one material this is skipped.
The first material if any) is always applied to the mesh itself
(regardless of the existence of geometry subsets), because the Hydra
viewport doesn't support materials on subsets. See
https://github.com/PixarAnimationStudios/USD/issues/542 for more info.
Note that the geometry subsets are not yet time-sampled, so it may break
when an animated mesh changes topology.
Materials are exported as a flat list under a top-level '/_materials'
namespace. This inhibits instancing of the objects using those
materials, so this is subject to change.
== Hair ==
Only the parent strands are exported, and only with a constant colour.
No UV coordinates, no information about the normals.
== Camera ==
Only perspective cameras are supported for now.
== Particles ==
Particles are only written when they are alive, which means that they
are always visible (there is currently no code that deals with marking
them as invisible outside their lifespan).
Particle-system-instanced objects are exported by suffixing the object
name with the particle's persistent ID, giving each particle XForm a
unique name.
== Instancing/referencing ==
This exporter has experimental support for instancing/referencing.
Dupli-object meshes are now written to USD as references to the original
mesh. This is still very limited in correctness, as there are issues
referencing to materials from a referenced mesh.
I am still committing this, as it gives us a place to start when
continuing the quest for proper instancing in USD.
== Lights ==
USD does not directly support spot lights, so those aren't exported yet.
It's possible to add this in the future via the UsdLuxShapingAPI. The
units used for the light intensity are also still a bit of a mystery.
== Fluid vertex velocities ==
Currently only fluid simulations (not meshes in general) have explicit
vertex velocities. This is the most important case for exporting
velocities, though, as the baked mesh changes topology all the time, and
thus computing the velocities at import time in a post-processing step
is hard.
== The Building Process ==
- USD is built as monolithic library, instead of 25 smaller libraries.
We were linking all of them as 'whole archive' anyway, so this doesn't
affect the final file size. It does, however, make life easier with
respect to linking order, and handling upstream changes.
- The JSON files required by USD are installed into datafiles/usd; they
are required on every platform. Set the `PXR_PATH_DEBUG` to any value
to have the USD library print the paths it uses to find those files.
- USD is patched so that it finds the aforementioned JSON files in a path
that we pass to it from Blender.
- USD is patched to have a `PXR_BUILD_USD_TOOLS` CMake option to disable
building the tools in its `bin` directory. This is sent as a pull
request at https://github.com/PixarAnimationStudios/USD/pull/1048
|
|
|
|
This change switches windows to the dynamic C runtime
avoiding issues coming from mixing the static and dynamic
runtime like the ones outlined in [1]
[1] https://developer.blender.org/D5387#122165
Differential Revision: https://developer.blender.org/D6175
Reviewed by: @Sergey
|
|
Only compiled on Linux.
|
|
Opus support was enabled in 2ddfd51810e0. This commit adds the Opus
library and configures FFmpeg to be compiled with Opus support.
NOTE: It may be required to run `cmake -U '*FFMPEG_LIBRARIES*' .` in
your Blender build directory in order to refresh the `FFMPEG_LIBRARIES`
setting and add libopus.
|
|
Previously this was done in the deps builder due to the fact we needed
both 32 and 64 bit versions of this dll and CMAKE does not support that
in a single build folder. Now that 32 bit support has been dropped, this
can be safely moved into the codebase.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D5633
|
|
This node is built on Intel's OpenImageDenoise library.
Other denoisers could be integrated, for example Lukas' Cycles denoiser.
Compositor: Made OpenImageDenoise optional, added CMake and build_env files to find OIDN
Compositor: Fixed some warnings in the denoising operator
build_environment: Updated OpenImageDenoise to 0.8.1
build_environment: Updated OpenImageDenoise in `make deps` for macOS
Reviewers: sergey, jbakker, brecht
Reviewed By: brecht
Subscribers: YAFU, LazyDodo, Zen_YS, slumber, samgreen, tjvoll, yeus, ponomarovmax, getrad, coder.kalyan, vitos1k, Yegor, DeepBlender, kumaran7, Darkfie9825, aliasguru, aafra, ace_dragon, juang3d, pandrodor, cdog, lordodin, jtheninja, mavek, marcog, 5k1n2, Atair, rawalanche, 0o00o0oo, filibis, poor, lukasstockner97
Tags: #compositing
Differential Revision: https://developer.blender.org/D4304
|
|
|
|
|
|
Were not needed previously, but the functions branch needs them.
|
|
This bring macOS on par with Windows and Linux. It uses the OpenMP library
added to our precompiled libraries.
Custom flags are set because FindOpenMP from CMake below 3.12 does not support
AppleClang, and more recent versions do not work with our custom directory
location either.
Differential Revision: https://developer.blender.org/D4257
|
|
It's already there for Windows.
|
|
|
|
Note that this is turned off by default and must be enabled at build time with the CMake WITH_CYCLES_EMBREE flag.
Embree must be built as a static library with ray masking turned on, the `make deps` scripts have been updated accordingly.
There, Embree is off by default too and must be enabled with the WITH_EMBREE flag.
Using Embree allows for much faster rendering of deformation motion blur while reducing the memory footprint.
TODO: GPU implementation, deduplication of data, leveraging more of Embrees features (e.g. tessellation cache).
Differential Revision: https://developer.blender.org/D3682
|
|
Mainly this is following Linux to build own xml2/lzma/ssl/sqlite and linking
them all statically. This ensures the Python ssl module uses a recent openssl
version rather than a very old one shipped with macOS.
|
|
The idea is to make find_package() to succeed without any
extra tips given. For this, we need header files to be
harvasted.
|
|
|
|
|
|
remove the commands that have already moved to the individual cmake files.
|
|
|
|
|
|
|
|
|
|
|
