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
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.
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
The goal is to make it able to use pre-compiled CentOS libraries on a
more modern system. Main issue was that it's possible that the compiler
on a newer version is defaulting to different C++11 ABI.
This change makes it so that if there is NO native libraries in the
lib folder and there IS pre-compiled CentOS folder, it will be used and
compiler will be forced to old ABI.
Differential Revision: https://developer.blender.org/D6031
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.
This change switches the debug symbol format from /Zi to /ZI for
debug builds of blender, allowing Edit and Continue to work.
This allows limited [1] code changes in the debugger without
having to stop the process and recompile a new binary leading
to improved developer productivity.
All MSVC versions we support support this flag, Clang on
windows does not mind the /ZI flag, but doesn't currently
emit the required information to have this feature work.
[1] https://docs.microsoft.com/en-us/visualstudio/debugger/supported-code-changes-cpp
bf_intern_openvdb makes a significant number of template instantiations
causing it go over the maximum number of sections (int16) in a coff file
when doing a debug build.
This change switches the compiler to use the extended coff format which
has this field extended (int32) all linkers post msvc2005 can process
this format so there's no reason not to turn this on globally.
Clang on windows does not need this change since clang switches implicitly
to the extended format when required. [1]
[1] https://reviews.llvm.org/rL217812
This change removes 32 bit support from the helper make.bat scripts
as we are dropping official 32 bit support, you can still build for
32 bit by configuring your build yourself using cmake and pointing
the LIBDIR cmake variable to your own 32 bit library folder.
On GPUs that support it, we now present OpenGL contents via CAMetalLayer. This
fixes frame skipping issues found in T60043. If the system does not have a Metal
capable GPU, NSOpenGLView will continue to be used.
Patch by Tomoaki Kawada, with some changes by Brecht Van Lommel.
Differential Revision: https://developer.blender.org/D4619
This is in preparation of an the upcoming fix where we need to use a Metal
layer to avoid performance issue when drawing with OpenGL. Note that we already
only officially support 10.12+, the difference with this change is that Blender
will not start at all on 10.9 and 10.10.
This marks the headers in the LIBDIR as system headers
and changes the warn to /W0 on msvc versions that support it.
This resolves some warnings we would had to completely
repress otherwise.
This enables static linking of libstdc++ by default when building using
`WITH_STATIC_LIBS`. This makes builds more portable for anyone making
static builds (in particular for older systems).
Reviewed By: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4393
VS2019 is binary compatible with the existing vc14 libraries and no
new libraries libs are required in svn.
VS2019 support requires cmake 3.14.
VS2019 is still in pre-release state, you are required to explicitly
select the pre-release version by using:
make full 2019pre
VS2019 is binary compatible with the existing vc14 libraries and no
new libraries libs are required in svn.
VS2019 support requires cmake 3.14.
VS2019 is still in pre-release state, you are required to explicitly
select the pre-release version by using:
make full 2019pre
