| Age | Commit message (Collapse) | Author |
|---|
|
This caused the ocean modifier to be disabled.
|
|
For no apparent reason, when building Alembic the script would always
re-download and re-extract the Alembic source code. This is no longer the
case, and it now only happens if the source directory is missing. Since the
source directory name contains the Alembic version, it will automatically
trigger a download+extract when the version changes.
|
|
Previously, when an unknown parameter was passed to `install_deps.sh`,
the script would just show "Wrong parameter!" without any context. This
can make it hard to figure out what's exactly going wrong. Now it prints
which parameter it thinks is wrong.
|
|
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
|
|
|
|
When building with `WITH_USD=ON` on Apple but the USD library cannot be
found, the CMake script now just sets `WITH_USD=OFF`.
|
|
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.
|
|
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
|
|
The current authority we use RFC 3161 time stamp server,
so need to pass different command line argument.
|
|
The `subprocess.call()` function doesn't check the exit status code of the
subprocess. Use `subprocess.check_call()` or `subprocess.run()` instead.
|
|
On CentOS 7, `tar --use-compress-program='xz -9'` tries to run `xz -9` as
executable, rather than running `xz` with `-9` as argument. Passing the
`-9` option via the `XZ_OPT` environment variable, as suggested by
@campbellbarton in D6138, works fine.
|
|
Missed one in the previous commit.
|
|
|
|
Previously some important features like OpenSubdiv were disabled by default,
which caused confusion.
The purpose of disabling some of these features was to avoid potentiall build
errors on Linux. But with precompiled libraries, install_deps.sh and better
library availability checking this is hopefully not much of a problem anymore.
This makes "make full" obsolete, but it's kept to not break docs or shell
scripts that people may have, and the .cmake config file remains useful to
modify an existing build folder.
This also changes some option to only be available on platforms where they
are actually supported (WITH_JACK, WITH_TBB_MALLOC_PROXY and X11 options).
Fixes T69742
Differential Revision: https://developer.blender.org/D6306
|
|
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
|
|
xz compresses 25% better than bz2, reducing download times and server load.
The numbers:
blender-2.80-linux-glibc217-x86_64.tar.bz2 (release): 134 886 174 bytes
with xz: 96 181 604 bytes (-28.7%)
with xz -9: 93 871 548 bytes (-30.4%)
blender-2.81-7c1fbe24ca33-linux-glibc217-x86_64.tar.bz2 (beta): 173 600 363 bytes
with xz: 133 100 664 bytes (-23.3%)
with xz -9: 129 534 124 bytes (-25.4%)
xz also decompresses more than twice as fast as bz2, however compression needs
four times as long (on my 7-year-old laptop 3-4 minutes instead of <1).
Also xz has become more common than bz2, e.g. Debian/Ubuntu deb packages have
been xz-compressed for years, so the dpkg package manager as well as systemd
and grub all depend on liblzma being present, whereas bz2 is becoming more and
more optional.
Current Linux archives also include the UID/GID of whatever user account
happens to be used for building by the blender.org infrastructure. If someone
then installs these archives as root e.g. to /usr/local/... and doesn't pay
full attention the files remain owned by a regular user, which is a serious
security issue. This patch fixes that by setting the UID/GID to 0.
Differential Revision: https://developer.blender.org/D6138
|
|
This was added years ago to prepare for code-signing the executable
but was never used, buildbots use a different mechanism now to sign
so no need to keep this around.
|
|
It was possible that it would exceed when signing all the DLLs if the machine
is busy with some background tasks or when internet is slow.
|
|
|
|
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.
|
|
This is redundant as WITH_CPU_SSE adds these flags
when they're supported.
|
|
Seems that `git am` will force native EOL.
|
|
Was caused by "wrong" EOL characters used in the patch: the file is
actuallyu saved using CRLF EOL style.
The patch was using CRLF as well for until recent change in the C
runtime.
|
|
Using the release versions gave unpredictable results when
the msvc debugger was attached for some developers.
|
|
|
|
The script requires Python 3.7 as a very minimum, and CentOS is
only 3.6.
On macOC there was an access to a None object, due to missing
implementation of code signer on this platform.
|
|
|
|
This changes integrates code signing steps into a buildbot worker
process.
The configuration requires having a separate machine running with
a shared folder access between the signing machine and worker machine.
Actual signing is happening as a "POST-INSTALL" script run by CMake,
which allows to sign any binary which ends up in the final bundle.
Additionally, such way allows to avoid signing binaries in the build
folder (if we were signing as a built process, which iwas another
alternative).
Such complexity is needed on platforms which are using CPack to
generate final bundle: CPack runs INSTALL target into its own location,
so it is useless to run signing on a folder which is considered INSTALL
by the buildbot worker.
There is a signing script which can be used as a standalone tool,
making it possible to hook up signing for macOS's bundler.
There is a dummy Linux signer implementation, which can be activated
by returning True from mock_codesign in linux_code_signer.py.
Main purpose of this signer is to give an ability to develop the
scripts on Linux environment, without going to Windows VM.
The code is based on D6036 from Nathan Letwory.
Differential Revision: https://developer.blender.org/D6216
|
|
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
|
|
|
|
Makes it so compilation doesn't fail when the SVN updating
stumbles upon checkout which doesn't have correspondence in
a tag, but which isn't so risky as previous change.
|
|
This reverts commit 8e9e58895b32afc38f856053335c9b27324c6f9e.
The change broke behavior when typing `make update` from the root of
the sources: tests folder wouldn't be updated anymore.
Getting quite close to release now, so will revert to a safer change.
|
|
|
|
The issue was rooting to the fact that the script was iterating into
every directory inside of blender.git/../lib/ and attempted to switch
them to the desired path. This doesn't work in an environment where
both master and release branch are built (or any environment where
non-needed SVN directories are not automatically removed).
This change makes it so script explicitly generates a list of
directories which are required for the build. For example, the script
now stores an exact folder with ABI such as win64_vc14.
Only those explicitly listed directories will be updated.
This allows to:
- Solve compilation failure of 2.81 branch after checkout for
win64_vc15 libraries has been created.
- Fail compilation if actually expected tag is missing (for example,
when trying to build release branch prior to libraries tag).
Now, there was a confusing logic about possible .svn folder in
lib_dirpath (effectively, blender.git/../lib/.svn) which is not
something what is supposed to happen with the setup of buildbot we are
using for quite some time now. This logic has been removed now.
This change includes old-style string format(), mainly because it is
not know that the buidlbot scripts are run using python3 on CentOS
builder.
Differential Revision: https://developer.blender.org/D6230
|
|
|
|
|
|
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
|
|
|
|
This wasn't an issue in the real buildbot environment since the
precompiled libraries are compiled with same ABI as the compiler
used for Blender build. But it was causing issues when building
Blender using buildbot scripts (for troubleshooting purposes)
on a machine with different default compiler ABI.
Usually ABI detection is happening in platform_unix.cmake when
detecting whether there are any precompiled libraries folder
available. This detection is not happening when library folder
is provided explicitly, expecting ABI to be setup explicitly
as well.
|
|
|
|
Thanks to @JRottm for pointing out this issue.
|
|
Also rename "make tgz" to "make source_archive" as it wasn't clear
this only archived the source, not binaries.
D6153 by @JRottm with minor edits
|
|
Support for listing files which are known not to exist
(needed by standalone cycles).
|
|
|
|
This gives linking errors on build.
|
|
|
|
|
|
|
|
|
