| Age | Commit message (Collapse) | Author |
|---|
|
Since this was added, Linux libraries have been included in `../lib/`.
This made `make bpy` on Linux install the `bpy` module into the bundled
SVN libraries which isn't very useful.
Now leave WITH_INSTALL_PORTABLE unset (defaulting to ON).
Python developers may reference their systems Python and disable the
option if they wish for a system-wide module installation.
|
|
As portable is already the default, setting it meant using the lite
configuration would always reset the value if was intentionally changed.
This was also inconsistent as other configurations left this unset.
|
|
This was a kind of "lite" target, disabling options such as FFMPEG and
ALEMBIC which may be useful to read/write data from the Python module.
Now fewer options have been changed.
The following options are now disabled:
- Audio support (to prevent audio devices being initialized on startup).
- Input device support such as NDOF and IME as there is no GUI.
- Blender thumbnail extraction as it's not installed as part of
the Python module.
Instead of attempting to predict what is useful to enable when building
as a Python module, developers can mix combine options e.g.
"make bpy release" or "make bpy lite".
|
|
|
|
|
|
Fix typo in blender_release.cmake, and ensure that "make release" still works
when ocloc is not available. While a fatal error is useful for debugging, the
current convention is to disable features, especially in cases like this where
there is no simple way to make the feature work.
Differential Revision: https://developer.blender.org/D15774
|
|
|
|
|
|
|
|
Windows still needs some work on the buildbot side, so keep
that disabled for the time being.
|
|
Currently, the compositor can be disabled using the WITH_COMPOSITOR
build option. Since, we intent to always build the realtime compositor,
we need to make the distinction between both compositors clear.
So this patch renames the option to WITH_COMPOSITOR_CPU. Additionally,
the check for the option was moved inside the compositor modules' own
CMake file in preparation for the realtime compositor code.
Differential Revision: https://developer.blender.org/D15622
Reviewed By: Jeroen Bakker, Ray Molenkamp
|
|
0f50ae131f54d51f778424d4c9655128cafbbefc didn't do it reliably
since it was deactivated explicitly a bit above.
|
|
with a very high min-driver version requirement, placeholder until JIT
CentOS runtime compilation issue gets fixed in a defined version.
min-driver version check can be worked around by setting
CYCLES_ONEAPI_ALL_DEVICES environment variable.
|
|
This patch adds a new Cycles device with similar functionality to the
existing GPU devices. Kernel compilation and runtime interaction happen
via oneAPI DPC++ compiler and SYCL API.
This implementation is primarly focusing on Intel® Arc™ GPUs and other
future Intel GPUs. The first supported drivers are 101.1660 on Windows
and 22.10.22597 on Linux.
The necessary tools for compilation are:
- A SYCL compiler such as oneAPI DPC++ compiler or
https://github.com/intel/llvm
- Intel® oneAPI Level Zero which is used for low level device queries:
https://github.com/oneapi-src/level-zero
- To optionally generate prebuilt graphics binaries: Intel® Graphics
Compiler All are included in Linux precompiled libraries on svn:
https://svn.blender.org/svnroot/bf-blender/trunk/lib The same goes for
Windows precompiled binaries but for the graphics compiler, available
as "Intel® Graphics Offline Compiler for OpenCL™ Code" from
https://www.intel.com/content/www/us/en/developer/articles/tool/oneapi-standalone-components.html,
for which path can be set as OCLOC_INSTALL_DIR.
Being based on the open SYCL standard, this implementation could also be
extended to run on other compatible non-Intel hardware in the future.
Reviewed By: sergey, brecht
Differential Revision: https://developer.blender.org/D15254
Co-authored-by: Nikita Sirgienko <nikita.sirgienko@intel.com>
Co-authored-by: Stefan Werner <stefan.werner@intel.com>
|
|
The following CMake options have been added (enabled by default),
except for the lite build configuration.
- WITH_IO_STL
- WITH_IO_WAVEFRONT_OBJ
- WITH_IO_GPENCIL (for grease pencil SVG importing).
Note that it was already possible to disable grease pencil export
by disabling WITH_PUGIXML & WITH_HARU.
This is intended to keep the lite builds fast and small for building,
linking & execution.
Reviewed By: iyadahmed2001, aras_p, antoniov, mont29
Ref D15141
|
|
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
|
|
|
|
This adds the remaining bits to enable Metal on macOS. There are still
performance optimizations and other improvements planned, but it should
now be ready for early testing.
This is currently only enabled on in Arm builds for M1 GPUs. It is not
yet working on AMD or Intel GPUs.
Ref T92212
Differential Revision: https://developer.blender.org/D13503
|
|
* Don't link embree / OSL when WITH_CYCLES is disabled
* Simplify lite config by disabling Cycles as a whole using this
* Remove code handling the removed WITH_CYCLES_NETWORK option
|
|
We've now done testing to confirm this works with RDNA and RDNA2 AMD GPUs
on Windows. The AMD driver needed for this will soon be released publicly.
|
|
Make building the thumbnail extraction executable optional,
disable on macOS as this was not linking, further, macOS doesn't use
this for thumbnail extraction so it could be left disabled.
|
|
WITH_CYCLES_DEBUG was used for rendering BVH debugging passes. But since we
mainly use Embree an OptiX now, this information is no longer important.
WITH_CYCLES_DEBUG_NAN will enable additional checks for NaNs and invalid values
in the kernel, for Cycles developers. Previously these asserts where enabled in
all debug builds, but this is too likely to crash Blender in scenes that render
fine regardless of the NaNs. So this is behind a CMake option now.
Fixes T90240
|
|
Blender did not support to input East Asian characters (Chinese, Japanese,
Korean) on macOS. This patch adds support for Japanese input, by implementing
the appropriate processing for the NSTextInputClient protocol.
Technical notes:
* The conversion candidate window is drawn by the input method program calling
`firstRectForCharacterRange`.
* The string before confirmation (called `composite` in blender) is handled in
the `setMarkedText` method called by the input method program.
* The string after confirmation (called `result` in the blender) is processed
in the `insertText` method called by the input method program.
Ref T51283
Differential Revision: https://developer.blender.org/D11695
|
|
Explicitly disable these, rather than relying on them not being found.
Also, don't duplicates the architectures list.
|
|
|
|
This adds CoreAudio as audio backend on macOS.
CoreAudio is the standard audio API on macOS.
Ref T86590
|
|
This adds WASAPI as audio backend on Windows.
WASAPI is the modern standard audio API on
Windows introduced with Windows Vista.
Ref T86590
|
|
This adds PulseAudio as audio backend on Linux.
PulseAudio is the main audio engine used on most,
if not all, Linux distributions today.
Ref T86590
|
|
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
|
|
Add them to the standard build configurations, disable properly when library
not found and print as part of configuration overview.
|
|
This caused warnings when e.g. building the lite profile because NanoVDB was not disabled, but
OpenVDB was. This Fixes this by setting the "WITH_NANOVDB" flag too.
|
|
With this patch the build system checks whether the "CUDA10_NVCC_EXECUTABLE" CMake
variable is set and if so will use that to build sm_30 kernels. Similarily for sm_8x kernels it
checks "CUDA11_NVCC_EXECUTABLE". All other kernels are built using the default CUDA
toolkit. This makes it possible to use either the CUDA 10 or CUDA 11 toolkit by default and
only selectively use the other for the kernels where its a hard requirement.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D9179
|
|
No functional change.
|
|
I didn't realize there were more duplicates while committing
{rBf1fee433be92}.
Original was added in {rB83f8223543f58c3b0881a03b6e9ddffff91}.
Duplicate was added in the merge {rB9e09b5c418c0a436e3c84ccf}.
Ref D8822
|
|
All platforms have landed the libs, this can be on
by default now.
|
|
* Don't link against Mesa OpenGL software emulation libraries from the
lib folder, they are not intended to be used for building, only install.
* Don't use static OpenMP library by default, it's usually not built to
work in shared libraries.
* Disable jemalloc on all platforms, the reason it fails is not specific
to Linux.
Differential Revision: https://developer.blender.org/D8827
|
|
It now follows the spacing around it.
|
|
|
|
This is for design task T67744, Boolean Redesign.
It adds a choice of solver to the Boolean modifier and the
Intersect (Boolean) and Intersect (Knife) tools.
The 'Fast' choice is the current Bmesh boolean.
The new 'Exact' choice is a more advanced algorithm that supports
overlapping geometry and uses more robust calculations, but is
slower than the Fast choice.
The default with this commit is set to 'Exact'. We can decide before
the 2.91 release whether or not this is the right choice, but this
choice now will get us more testing and feedback on the new code.
|
|
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
|
|
one is found
This patch changes the discovery of pre-compiled kernels, to look for any PTX, even if
it does not match the current architecture version exactly. It works because the driver can
JIT-compile PTX generated for architectures less than or equal to the current one.
This e.g. makes it possible to render on a new GPU architecture even if no pre-compiled
binary kernel was distributed for it as part of the Blender installation.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D8332
|
|
|
|
|
|
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
|
|
System GLEW often is not new enough, which gives error on startup. The build
correctness should not be affected by using lite vs. full, so better to leave
this out than save compiling one extra file.
|
|
- Doesn't work
- If it worked, having a different CRT than the rest of
the process would not be a good thing.
|
|
This caused the ocean modifier to be disabled.
|
|
Smaller changes in the build files to reflect the new Mantaflow macro.
Reviewed By: sergey
Maniphest Tasks: T59995
Differential Revision: https://developer.blender.org/D3853
|
|
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
|
|
In older versions the ms crt was only a few dlls, in recent versions
this jumped to over 40 leading to quite a bit of clutter in our
bin folder.
This change moves the CRT into its own folder.
For developers that generally already have the runtime globaly
available on their machine, there is a new cmake option
(WITH_WINDOWS_BUNDLE_CRT, default ON) that you can use to toggle
installing the runtime to the blender bin folder, and save some
time during the initial build, this option is off by default for
only the developer profile.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D6132
|
