| Age | Commit message (Collapse) | Author |
|---|
|
Clang Tidy is a Clang based "linter" tool which goal is to help
fixing typical programming errors.
It is run as a separate compile step of every file, which slows
compilation down but allows to fully analyze the file the same
way as compiler does and catch non-trivial bugprone cases.
This change includes:
- CMake option called `WITH_CLANG_TIDY` which enables Clang Tidy
linter tool on all source in the `source/` directory.
This option is only available on Linux, as it is currently the
easiest platform to get the Clang Tidy toolchain to work.
- CMake module which is aimed to find latest available Clang Tidy.
- Set of rules which allows to have Blender fully compiled without
extra issues.
The goal of this change is to provide a base ground so that solving
all the warnings can happen later on, as a team effort.
It should be possible to use Clang Tidy side-by-side with both GCC
and Clang, but there seems to be some tweaks to be done in CMake to
make it really work for Blender. For now use Clang toolchain if
there are issues with GCC+Clang Tidy.
It will be worked on in the nearest future to bring seamless
experience for all configurations.
Currently there is no official way of getting Clang Tidy on macOS,
and on Windows there are some difficulties of hooking up Clang Tidy
from LLVM package to the MSVC compiler toolchain.
The actual warnings in the code will be addressed as a part of the
Code Quality Days, task T78535.
Differential Revision: https://developer.blender.org/D7937
|
|
This requires ISPC for building OpenImageDenoise, so that is now added as
a dependency as well. Blender itself does not need ISPC for building so it
is not included as part of the precompiled libraries.
Differential Revision: https://developer.blender.org/D7641
|
|
This is a follup to 0c384362272.
No functional changes to Blender, just the build scripts.
|
|
|
|
Search for all potential library names in each directory, otherwise e.g.
libImath-2_2.a from a system directory will be preferred over libImath.a even
if we specified a directory.
|
|
This patch enables TBB as the default task scheduler. TBB stands for Threading Building Blocks and is developed by Intel. The library contains several threading patters. This patch maps blenders BLI_task_* function to their counterpart. After this patch we can add more patterns. A promising one is TBB:graph that can be used for depsgraph, draw manager and compositor.
Performance changes depends on the actual hardware. It was tested on different hardwares from laptops to workstations and we didn't detected any downgrade of the performance.
* Linux Xeon E5-2699 v4 got FPS boost from 12 to 17 using Spring's 04_010_A.anim.blend.
* AMD Ryzen Threadripper 2990WX 32-Core Animation playback goes from 9.5-10.5 FPS to 13.0-14.0 FPS on Agent 327 , 10_03_B.anim.blend.
Reviewed By: brecht, sergey
Differential Revision: https://developer.blender.org/D7475
|
|
The spelling should match exactly between how package is called in
find_package and in FIND_PACKAGE_HANDLE_STANDARD_ARGS.
|
|
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
|
|
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
|
|
This extends FindOpenShadingLanguage.cmake to also look for the location of
stdosl.h and adds the path to the invocation of oslc to deal with the headers
being in different locations a little better.
Differential Revision: https://developer.blender.org/D6865
Reviewers: brecht
|
|
This commit adds the download, extract, patch, build, and install of the
Universal Scene Description (USD) library to the `install_deps.sh`
script.
Reviewed By: mont29, LazyDodo
Differential Revision: https://developer.blender.org/D6478
|
|
Reduce the number of possible locations used to find libraries,
to simplify troubleshooting.
Only keep '*_ROOT_DIR' and the path used by 'install_deps.sh'.
|
|
An educated guess to put ensure order of static libraries initialization.
A bit weird, since OpenImageDenoise should be depending on TBB, but that
is likely being ensured by bf_compositor.
Linking succeeded on my Intel machine, and blenloader_test was passing
when doing manual test on buildbot.
|
|
Similar fix as the one we did for the blender executable, see T72015.
|
|
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
|
|
Tests were missing a manifest, and were importing the
wrong version of Microsoft.Windows.Common-Controls
causing blenloader_test, bmesh_core_test and alembic_test
to fail due a loader error.
|
|
This new test class minimally sets up Blender so that it can load blend
files and construct a depsgraph without crashing.
Note that it hasn't been tested on very complex blend files, so it may
still crash when the loaded blend file references/requires uninitialised
data structures.
The test will certainly crash with Blend files created with Blender
older than 2.80, as the versioning code requires space types to be
registered. This is normally done by initialising the window manager,
which is not done in this test. The WM requires Python to run, which in
turn requires that Blender finds the release directory in the same
directory that contains the running executable, which is not the case
for GTest tests (they are written to `bin/tests/executablename`.
Reviewed By: sergey, mont29
Differential Revision: https://developer.blender.org/D6246
|
|
|
|
Problem was twofold
1) `GENERATOR_IS_MULTI_CONFIG` is a property not a variable so
the test for it would always be false, unless you set a custom
CMAKE_INSTALL_PREFIX (like the buildbot does) the unit tests
would have a wrong working directory and complain about missing
dlls or blender executable
2) Tests added outside of `/test` (like libmv) would have no working
folder set since the variable would not be visible for them.
consulted @sergey who voiced the opinion that duplicating the code
to the test macro was slightly less evil than moving it to the main
CMakeLists.txt
|
|
This uses hardware-accelerated raytracing on NVIDIA RTX graphics cards.
It is still currently experimental. Most features are supported, but a few
are still missing like baking, branched path tracing and using CPU memory.
https://wiki.blender.org/wiki/Reference/Release_Notes/2.81/Cycles#NVIDIA_RTX
For building with Optix support, the Optix SDK must be installed. See here for
build instructions:
https://wiki.blender.org/wiki/Building_Blender/CUDA
Differential Revision: https://developer.blender.org/D5363
|
|
Run these tests from the install directory so they can find dlls.
|
|
|
|
Split include directories into regular and system ones, which
makes it so strict flags are properly cancelled out for GFlags
headers.
|
|
Was happening in macros, polluting the namespace.
No functional changes, just making things cleaner.
|
|
CMake variables are case sensitive.
|
|
Previously cmake would error out if it couldn't find the static
libraries even though it can build with shared libraries just fine.
|
|
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
|
|
|
|
D5296 by @frispete
|
|
Differential Revision: https://developer.blender.org/D4704
|
|
|
|
|
|
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
|
|
|
|
With new jemalloc versions memory allocated by threads that then become
inactive is not longer automatically freed. Instead we have to enable a
background thread to do it.
Some testing is needed to find out of this is sufficient, because the
background thread only runs periodically.
|
|
|
|
Differential Revision: https://developer.blender.org/D3700
|
|
|
|
PCRE_LIBRARIES was not being set if the pcre library was found but not the headers.
|
|
all platforms have been updated
|
|
The library can get installed in a lib/static subdirectory, so search there
as well now.
|
|
The library can get installed in a lib/static subdirectory, so search there
as well now.
|
|
|
|
Wasn't finding the include path by on Linux.
|
|
|
|
* WITH_SYSTEM_OPENJPEG is removed and is now always on, this was already
the case for macOS and Windows.
* This should not break existing Linx builds. If there is no new enough
OpenJPEG installed, CMake will no find libopenjp2 and WITH_IMAGE_OPENJPEG
will be disabled.
* install_deps.sh was updated with new package names, since distributions
put this version in a new package.
Differential Revision: https://developer.blender.org/D3663
|
|
|
|
There is chance that on a system with both versions installed this
*might* cause some issues. Such system will be pain to support out
of the box anyway.
This change allows to use precompiled libraries without extra
modifications in the config.
|
|
|
|
|
