The old URL did have a Git commit hash in it, but apparently the server
was ignoring it and only used the `master` that was also mentioned in the
URL. As a result, every new download would get the latest version from
the `master` branch, invalidating the SHA256 checksum.
I replaced `master` with the actual commit hash. This should make the
situation stable.
No functional changes.
This updates python to the latest patch level available for 3.7
also updates some of the packages we rely on:
idna 2.9
urllib3 1.25.9
cerifi 2020.4.5.2
requests 2.23.0
numpy 1.17.5
This upgrade required a few changes:
- Some parts of our patch are no longer necessary, as the USD library
now includes those changes.
- The rest of the patch needed adjustment as the `pxr/base/lib/*`
directories in USD's source code have moved to `pxr/base/*`.
- Updated library names on Windows -- thanks @LazyDodo.
Note that this does not enable the USD Python API for inclusion in
Blender. It just aims at being an as-simple-as-possible version upgrade
of the USD library.
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
This diff updates:
FFmpeg : 4.3.2
libogg : 1.3.4
flac : 1.3.3
vpx : 1.8.2
xvid : 1.3.7
x264 : 33f9e1474613f59392be5ab6a7e7abf60fa63622
x264 seemingly has given up on even providing snapshots
and has been updated to the latest hash available at
this time.
faad has been removed since ffmpeg has not supported
it since 2010.
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
Freeetype 2.9.1 tags dllexport on most of its functions so these
are now exported from the blender binary. (Same issue as D6563
which fixed it for USD)
Issue has already been fixed upstream so a simple version bump
fixes it.
This patch bumps freetype to 2.10.1
Differential Revision: https://developer.blender.org/D6645
Reviewers: brecht , sergey
OSL 1.10.9 fixes osl-bug 866 [1] which is long standing issue
on windows where paths get un-escaped and osl breaks when you
install it to for instance c:\blender-tests\new-boolean
This patch bumps osl to 1.10.9, and since osl is llvm's
only consumer, llvm/clang were bumped 9.0.1
Removed some of the patches that were no longer needed
Builds and passes all tests on windows and linux
[1] https://github.com/imageworks/OpenShadingLanguage/issues/866
Differential Revision: https://developer.blender.org/D6744
Reviewers: brecht
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
Alembic 1.7.12 introduces a 'DCC FPS' hint, allowing Blender to write
the scene frame rate to the Alembic file. This will make it possible for
importers and converters to properly deal with situations where 'frame
number' is the only reference to time.
Writing this new DCC FPS hint will be done in a separate commit. Here
only the Alembic library is upgraded from 1.7.8 to 1.7.12.
The heap on windows is single threaded causing it to lag behind linux in performance in allocation heavy multithreaded scenarios, BVH building is a prime example.
See https://developer.blender.org/D6218 for benchmark results
for testing with the allocator enabled/disabled you can set the environment variable TBB_MALLOC_DISABLE_REPLACEMENT=1 to disable the TBB allocator.
Reviewed By: @sergey
Differential Revision: https://developer.blender.org/D6218
Opus support was enabled in 2ddfd51810. 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.
Newer OpenSubdiv brings fixes and improvements for non-manifold meshes,
which fixes some crashes we've experienced in the recent past when using
Gregory patches.
Additionally, thing new version of OpenSubdiv brings sparse patches,
which allows to multi-thread topology refinement step.
Most of the source tarballs are retrieved via http, but a few remain
that are still downloaded via ftp. This causes some pain with corporate
firewalls, so moving the last two URIs to http helps ease the build process.
Reviewers: sergey
Differential Revision: https://developer.blender.org/D4192
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
This involved getting SSL compiled from sources first, ensuring
it is a static library placement independent code. Configuration
is based on what Debian is using. CFlags required to have own
configuration file, which i didn't find a better place that next
to the corresponding CMake file.
It is OpenSSL btw.
It is set to Python via --with-openssl= configuration argument.
This works fine in a clean chroot, but having libssl-dev installed
might make Python to prefer system wide library, This was worked
around by using libssl_pic.a name for the library and modifying
setup.py. Would be cool to ensure system wide libraries are not
a problem, but official release builder is safe against this,
since it will catch possible non-static dependencies.
There is also a new map file which shadows bunch of Python
symbols. Without this Python's shared libraries might bring
conflicting symbols to Blender namespace at runtime.
Hopefully this doesn't break other platforms.
