| Age | Commit message (Collapse) | Author |
|---|
|
In Blender 3.1 we can't run the source_archive_complete because the
cmake program is trying to download the packages from svn trunk. However
3.2 (aka master) already changed the version of some of the source
packages.
For example the OpenXR-SDK. It should be looking for
OpenXR-SDK-1.0.17.tar.gz in:
https://svn.blender.org/svnroot/bf-blender/tags/blender-3.1-release/lib/packages/
But instead it tries to look for it in:
https://svn.blender.org/svnroot/bf-blender/trunk/lib/packages/
Which can't be found since it was replaced with OpenXR-SDK-1.0.22.tar.gz
---
Release checklist: https://wiki.blender.org/wiki/Process/Release_Checklist
The release checklist was updated to include the new instructions:
`In the release branch, update and uncomment BLENDER_VERSION in download.cmake`
Differential Revision: http://developer.blender.org/D14292
|
|
Since USD 21.11 the libraries are prefixed with "usd_", i.e.
"libusd_m.a" became "libusd_usd_m.a". This commit adjusts our
`usd.cmake` (for building USD) and `FindUSD.cmake` (for finding the USD
libraries) so that they work with and without this `usd_` prefix.
See for more info:
https://github.com/PixarAnimationStudios/USD/blob/release/CHANGELOG.md#2111---2021-11-01
Reviewed By: LazyDodo, brecht, mont29
Differential Revision: https://developer.blender.org/D14334
|
|
|
|
Since Python 3.10 is now supported on all platform,
bump the minimum version to reduce the number of Python versions that
need to be supported simultaneously.
Reviewed By: LazyDodo, sybren, mont29, brecht
Ref D13943
|
|
When running `./blender/build_files/build_environment/install_deps.sh` on Ubuntu 20.04.3 LTS the following error can be seen:
```
./blender/build_files/build_environment/install_deps.sh: line 1266: [: too many arguments
```
This error results from the call:
```
check_package_version_ge_DEB $CLANG_FORMAT $CLANG_FORMAT_VERSION
```
with `CLANG_FORMAT_VERSION` being undefined.
Also as `clang-format` 13 is already released and hopefully didn't break anything `CLANG_FORMAT_VERSION_MEX` could use version bump.
Reviewed By: mont29
Differential Revision: https://developer.blender.org/D13924
|
|
|
|
|
|
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
|
|
Simple upgrade of OpenXR to 1.0.22, following the steps from
https://wiki.blender.org/wiki/Source/OpenXR_SDK_Dependency and
rBb69ab42982a1. No changes to Blender code were necessary, only a version
bump.
The primary motivation for this upgrade is to utilize the
`XR_HTCX_vive_tracker_interaction` extension introduced in ver. 1.0.20.
However, the latest release (1.0.22) also adds a number of potentially
useful extensions such as:
- `XR_FB_render_model`
- `XR_HTC_facial_expression`
- `XR_HTC_vive_focus3_controller_interaction`
Ref T95206
Reviewed By: LazyDodo, sybren, mont29
Maniphest Tasks: T95206
Differential Revision: https://developer.blender.org/D13950
|
|
|
|
Required to solve a crash on windows (T95367)
Mostly an uneventful update, except for FreeType
giving its cmake options a rename.
Reviewed By: brecht, sybren
Differential Revision: https://developer.blender.org/D13968
|
|
We need to get installed version of python *after* we actually install/update
the package.
|
|
This commit specifies the exact Python version which is included in the
package name, thereby allowing `install_deps.sh` to suggest
"`-D PYTHON_VERSION=3.10`" correctly.
Reviewed By: mont29
Differential Revision: https://developer.blender.org/D13925
|
|
Higher version requires a new version of the ztandard library itself.
Ref. T93161/D13922.
|
|
Downgrade the Python zstandard from 0.17.0 to 0.16.0. The Python package
should be linked against the exact same version of libzstd as Blender is,
otherwise it will refuse to load from within the Blender executable.
Python zstandard 0.17.0 links to 1.5.1, whereas we need 1.5.0.
|
|
While install_deps tries to stay as close as possible from official
Blender versions of the libraries, it also strives to use as many distro
packages as possible.
OSL 1.11.16.0 is the minimal version that builds with llvm13, which is
the default llvm/clang version in e.g. Debian testing.
|
|
|
|
Also included:
IDNA 3.2 -> 3.2
Charset Normalizer 2.0.6 -> 2.0.10
UrlLib3 1.26.7 -> 1.26.8
Requests 2.26.0 -> 2.27.1
Cython 0.29.24 -> 0.29.26
ZStandard 0.15.2 -> 0.17.0
Numpy 1.12.2 -> 1.22.0
Reviewed by: brecht
Differential Revision: https://developer.blender.org/D13922
|
|
This will allow building most deps with VS2019
SDL has some linker issues that are resolved in
a newer version, but that would be better handled
in a separate change.
VS2013 and VS2015 support which was broken has
been removed.
|
|
|
|
it was harvesting to the zstd folder which
is not where these libs ought to be.
|
|
The UI team requested adding woff2 support to freetype.
this required a new dependency brotli.
This changes adds brotili to the builder and bumps
freetype to version 2.11.0
As freetype now depends on other libraries, for consistency
all use of ${FREETYPE_LIBRARY} in cmake has been updated to
use ${FREETYPE_LIBRARIES} adjustments have been made in the
windows platform file, all other platforms use cmake's
FindFreeType.cmake which already sets this variable.
reviewed by: brecht
Differential Revision: https://developer.blender.org/D13448
|
|
llvm 13 is now default on debian testing, tried it quickly and it seems
to work fine, so raising exclusive maximum value for it to 14.
|
|
And change install_deps.sh to build shared (instead of static) FFMPEG
libraries, for consistency with other library dependencies and to simplify
the logic. This may require users of install_deps.sh to rebuild FFMPEG.
This is the last step that lets us get rid of LIBPATH variables and
link_directories() entirely, as recommended by the CMake docs.
Some fixes were needed in the find FFMPEG module to make it actually work,
this code was unused up to now.
Followup to D8855.
Differential Revision: https://developer.blender.org/D9177
|
|
This reverts commit 62a0de1673302fb7f15fe06efaf6f0f97d92d240. Linux buildbot
is giving link errors.
|
|
And change install_deps.sh to build shared (instead of static) FFMPEG
libraries, for consistency with other library dependencies and to simplify
the logic. This may require users of install_deps.sh to rebuild FFMPEG.
This is the last step that lets us get rid of LIBPATH variables and
link_directories() entirely, as recommended by the CMake docs.
Some fixes were needed in the find FFMPEG module to make it actually work,
this code was unused up to now.
Followup to D8855.
Differential Revision: https://developer.blender.org/D9177
|
|
Includes unwanted changes
This reverts commit 46e049d0ce2bce2f53ddc41a0dbbea2969d00a5d.
|
|
This patch implements the vector types (i.e:`float2`) by making heavy
usage of templating. All vector functions are now outside of the vector
classes (inside the `blender::math` namespace) and are not vector size
dependent for the most part.
In the ongoing effort to make shaders less GL centric, we are aiming
to share more code between GLSL and C++ to avoid code duplication.
####Motivations:
- We are aiming to share UBO and SSBO structures between GLSL and C++.
This means we will use many of the existing vector types and others
we currently don't have (uintX, intX). All these variations were
asking for many more code duplication.
- Deduplicate existing code which is duplicated for each vector size.
- We also want to share small functions. Which means that vector
functions should be static and not in the class namespace.
- Reduce friction to use these types in new projects due to their
incompleteness.
- The current state of the `BLI_(float|double|mpq)(2|3|4).hh` is a
bit of a let down. Most clases are incomplete, out of sync with each
others with different codestyles, and some functions that should be
static are not (i.e: `float3::reflect()`).
####Upsides:
- Still support `.x, .y, .z, .w` for readability.
- Compact, readable and easilly extendable.
- All of the vector functions are available for all the vectors types
and can be restricted to certain types. Also template specialization
let us define exception for special class (like mpq).
- With optimization ON, the compiler unroll the loops and performance
is the same.
####Downsides:
- Might impact debugability. Though I would arge that the bugs are
rarelly caused by the vector class itself (since the operations are
quite trivial) but by the type conversions.
- Might impact compile time. I did not saw a significant impact since
the usage is not really widespread.
- Functions needs to be rewritten to support arbitrary vector length.
For instance, one can't call `len_squared_v3v3` in
`math::length_squared()` and call it a day.
- Type cast does not work with the template version of the `math::`
vector functions. Meaning you need to manually cast `float *` and
`(float *)[3]` to `float3` for the function calls.
i.e: `math::distance_squared(float3(nearest.co), positions[i]);`
- Some parts might loose in readability:
`float3::dot(v1.normalized(), v2.normalized())`
becoming
`math::dot(math::normalize(v1), math::normalize(v2))`
But I propose, when appropriate, to use
`using namespace blender::math;` on function local or file scope to
increase readability.
`dot(normalize(v1), normalize(v2))`
####Consideration:
- Include back `.length()` method. It is quite handy and is more C++
oriented.
- I considered the GLM library as a candidate for replacement. It felt
like too much for what we need and would be difficult to extend / modify
to our needs.
- I used Macros to reduce code in operators declaration and potential
copy paste bugs. This could reduce debugability and could be reverted.
- This touches `delaunay_2d.cc` and the intersection code. I would like
to know @howardt opinion on the matter.
- The `noexcept` on the copy constructor of `mpq(2|3)` is being removed.
But according to @JacquesLucke it is not a real problem for now.
I would like to give a huge thanks to @JacquesLucke who helped during this
and pushed me to reduce the duplication further.
Reviewed By: brecht, sergey, JacquesLucke
Differential Revision: https://developer.blender.org/D13791
|
|
Reverted because the commit removes a lot of commits.
This reverts commit a2c1c368af48644fa8995ecbe7138cc0d7900c30.
|
|
This patch implements the vector types (i.e:float2) by making heavy
usage of templating. All vector functions are now outside of the vector
classes (inside the blender::math namespace) and are not vector size
dependent for the most part.
In the ongoing effort to make shaders less GL centric, we are aiming
to share more code between GLSL and C++ to avoid code duplication.
Motivations:
- We are aiming to share UBO and SSBO structures between GLSL and C++.
This means we will use many of the existing vector types and others we
currently don't have (uintX, intX). All these variations were asking
for many more code duplication.
- Deduplicate existing code which is duplicated for each vector size.
- We also want to share small functions. Which means that vector functions
should be static and not in the class namespace.
- Reduce friction to use these types in new projects due to their
incompleteness.
- The current state of the BLI_(float|double|mpq)(2|3|4).hh is a bit of a
let down. Most clases are incomplete, out of sync with each others with
different codestyles, and some functions that should be static are not
(i.e: float3::reflect()).
Upsides:
- Still support .x, .y, .z, .w for readability.
- Compact, readable and easilly extendable.
- All of the vector functions are available for all the vectors types and
can be restricted to certain types. Also template specialization let us
define exception for special class (like mpq).
- With optimization ON, the compiler unroll the loops and performance is
the same.
Downsides:
- Might impact debugability. Though I would arge that the bugs are rarelly
caused by the vector class itself (since the operations are quite trivial)
but by the type conversions.
- Might impact compile time. I did not saw a significant impact since the
usage is not really widespread.
- Functions needs to be rewritten to support arbitrary vector length. For
instance, one can't call len_squared_v3v3 in math::length_squared() and
call it a day.
- Type cast does not work with the template version of the math:: vector
functions. Meaning you need to manually cast float * and (float *)[3] to
float3 for the function calls.
i.e: math::distance_squared(float3(nearest.co), positions[i]);
- Some parts might loose in readability:
float3::dot(v1.normalized(), v2.normalized())
becoming
math::dot(math::normalize(v1), math::normalize(v2))
But I propose, when appropriate, to use
using namespace blender::math; on function local or file scope to
increase readability. dot(normalize(v1), normalize(v2))
Consideration:
- Include back .length() method. It is quite handy and is more C++
oriented.
- I considered the GLM library as a candidate for replacement.
It felt like too much for what we need and would be difficult to
extend / modify to our needs.
- I used Macros to reduce code in operators declaration and potential
copy paste bugs. This could reduce debugability and could be reverted.
- This touches delaunay_2d.cc and the intersection code. I would like to
know @Howard Trickey (howardt) opinion on the matter.
- The noexcept on the copy constructor of mpq(2|3) is being removed.
But according to @Jacques Lucke (JacquesLucke) it is not a real problem
for now.
I would like to give a huge thanks to @Jacques Lucke (JacquesLucke) who
helped during this and pushed me to reduce the duplication further.
Reviewed By: brecht, sergey, JacquesLucke
Differential Revision: http://developer.blender.org/D13791
|
|
Pretty straightforward update, nothing noteworthy to report.
Differential Revision: https://developer.blender.org/D13278
Reviewed by: brecht, sybren
|
|
Needed together with LLVM cleanup, otherwise things fail when LLVM gets
updated.
|
|
There are two issues in USD code that break building it with gcc-11,
one (in `demangle.cpp`) was already fixed upstream, the other (in
`singularTask.h`) is still pending (reported upstream, see
https://github.com/PixarAnimationStudios/USD/issues/1721).
CC #platforms_builds_tests_devices project.
|
|
Root path variables for those libraries is now using the 'standard' naming
scheme.
With tweaks/cleanups from @mont29.
Reviewed By: mont29
Differential Revision: https://developer.blender.org/D13591
|
|
Contributed by luzpaz.
Differential Revision: https://developer.blender.org/D13264
|
|
Build HIP kernels with NanoVDB, and patch NanoVDB to work with HIP.
This is a header only library so no rebuild is needed. The changes are being
submitted upstream to openvdb, so this patch should be temporary.
Thanks Thomas for help testing this.
|
|
This package allows Python scripts to handle compressed blend files (see
rB2ea66af742bc). This is for example needed by Blender Asset Tracer to
send files to a Flamenco render farm.
This change includes a new `WITH_PYTHON_INSTALL_ZSTANDARD` build-time
option, to control whether to actually install the package. For this the
already-existing approach for Requests was copied.
Reviewed By: LazyDodo, mont29, brecht
Differential Revision: https://developer.blender.org/D12777
|
|
certifi : 2020.12.5 → 2021.10.8
chardet : 4.0.0 → charset-normalizer 2.0.6
cython : 0.29.21 → 0.29.24
idna : 2.10 → 3.2
numpy : 1.19.5 → 1.21.2 (which makes it possible to remove our patch)
requests: 2.25.1 → 2.26.0
urllib3 : 1.26.3 → 1.26.7
Nowadays `requests` no longer depends on `chardet` but on
`charset-normalizer`. That project describes itself as:
> A library that helps you read text from an unknown charset encoding.
> Motivated by chardet, I'm trying to resolve the issue by taking a new
> approach. All IANA character set names for which the Python core library
> provides codecs are supported.
Reviewed By: LazyDodo, mont29, brecht
Differential Revision: https://developer.blender.org/D12777
|
|
Bump Python from 3.9.2 to 3.9.7, which is the latest 3.9 release at this
moment.
Updates to bundled Python packages will follow in a separate commit.
Reviewed By: LazyDodo, mont29, brecht
Differential Revision: https://developer.blender.org/D12777
|
|
We define the minimum exclusive number for our supported dependencies
versions, and not the maximum inclusive number.
Thanks to @sybren for raising this point and finding the 'mex' math
term.
|
|
|
|
Issue caused by our patch in rB1af722b81912
we replaced an array with a memory allocation
but we forgot to update the assert which now
used an invalid method to calculate the array
size.
SVN libs will have to be updated before
T91602 will be fixed for end users.
|
|
|
|
* Revert back to OpenMP 9.0.1 due to bug causing cloth physics test to fail.
* Skip flex build on macOS to avoid link error, only reason we build this is
due to old flex version on Linux CentOS 7.
* Fix PNG cmake argument that expects lowercase on instead of ON.
Ref T90507, T88438
|
|
For some reasons looks like those shortcuts could get out of sync, which
created weird hard to understand building errors.
So for sake of simplicity and security, just re-create them all the
time, just like we update ld paths.
|
|
This is causing issues for some users launching Blender, because EGL indirectly
requires GLVND, which is not installed by default on e.g. Ubuntu.
This reverts commit 0b18a618b88b22663e05eca0f4d976875710e7cc.
Fixes T90374
Ref D12034
|
|
This will replace GLX with EGL for X11. GLEW does not support GLX and EGL
at the same time. Most distributions build GLEW with GLX support, so we
have to use the externally provided GLEW and build with EGL support.
This effectively sets WITH_SYSTEM_GLEW to OFF for all Linux configurations.
Differential Revision: https://developer.blender.org/D12034
|
|
This caused a blender load error on windows N,
given we do not use these codecs they can safely
be disabled.
This will fix T90200 once the new libraries are
in SVN
|
|
Ref. T88438.
|
|
This has been a huge pain to get working, for several reasons (new flags
needed, patching is now mandatory, etc.).
Further more, discovered that debian OIIO package is now silently
relying on OpenCV, without even proper handling of this dependency (at
least in the `-dev` package), so had to revert to force-build own OIIO
again on that distro for the time being.
Ref. T88438.
|
