Welcome to mirror list, hosted at ThFree Co, Russian Federation.

git.blender.org/blender.git - Unnamed repository; edit this file 'description' to name the repository.
summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2022-11-11deps: fix USD build on linuxtmp-vfx-platform-2023Ray Molenkamp
2022-11-08deps_builder: add missing oiio dep to USDRay Molenkamp
2022-11-08Fix USD/OpenColorIO build issues on macOSBrecht Van Lommel
2022-11-03deps: USD 21.11Ray Molenkamp
also small patch to OpenVDB due to USD (C++14) and OpenVDB(C++17) running into trouble together.
2022-08-27deps/win: Fix USD debug build linker errortmp_libupdate_34Ray Molenkamp
2022-08-25Clarify comment and code for enabling USD OpenGL support.Brecht Van Lommel
2022-08-24Enable OpenGL, Metal and OpenImageIO in USD libraryBrecht Van Lommel
Not tested on Windows.
2022-08-24Make OpenImageIO and OpenEXR dynamic libraries work on Linux / macOSBrecht Van Lommel
I tried to make the mechanism for setting the right environment for oslc and idiff a bit more generic, hopefully did not break Windows.
2022-08-24Set rpaths for all libraries in harvest stepBrecht Van Lommel
Each library has different logic here. Instead of trying to patch code or find the right build options for each, set rpath ourselves.
2022-08-20deps: fix USD windows debug buildRay Molenkamp
2022-08-16USD build options changesBrecht Van Lommel
* Enable OpenVDB * Remove custom usdBlender namespace
2022-08-16Various deps builder fixes for Linux/macOSBrecht Van Lommel
* Enable C++17. Silences warning in OpenVDB, and doing this right may be more important now that USD becomes a public C++ API. * Various fixes for OpenVDB * Ensure libraries have relative @origin or $ORIGIN rpath without absolute paths. Default assumption in most libs seems to be a fixed install location. * Don't link static Python lib with interpreter symbols into USD library. * Harvest fribidi and harfbuzz * Harvest OpenVDB and USD python modules into python site-packages * Don't harvest meson in site-packages
2022-08-11deps builder: updates for 3.4Ray Molenkamp
- Enable python bindings for openvdb - Move some more deps to ninja on windows - Bump openvdb to 9.1.0 since it had AX support for windows, but due to size concerns disabled - Fix dependencies for a few deps to sort out build order issues - Limit build_deps.cmd to a single core, so it won't oversubscribe the CPU
2022-08-06deps: fix windows usd python installRay Molenkamp
The debug/release python folders need to be separated since there is not easy way to keep creators installer from grabbing the wrong pyd's during install.
2022-08-05Updates for debug builds on windowsRay Molenkamp
2022-08-05Initial work of D15604Ray Molenkamp
2022-04-29Build: disable Metal for USD libraries also, it fails to build without OpenGLBrecht Van Lommel
This only affects macOS. Ref D14792
2022-04-28CMake: Reduce dependencies of USDSybren A. Stüvel
`PXR_ENABLE_OSL_SUPPORT=OFF`: OpenShadingLanguage is an optional dependency of the Imaging module. However, since that module was included for its support for converting primitive shapes (sphere, cube, etc.) to geometry, OSL is not necessary. Disabling it will make it simpler to build Blender; currently only Cycles uses OSL. `PXR_ENABLE_GL_SUPPORT=OFF`: GL support on Linux also links to X11 libraries. Enabling it would break headless or Wayland-only builds. OpenGL support would be useful if someone wants to work on a Hydra viewport in Blender; when that's actually being worked on, we could patch in a new PXR_ENABLE_X11_SUPPORT option (to separate OpenGL from X11) and contribute it upstream. `PXR_BUILD_OPENIMAGEIO_PLUGIN=OFF`: It's used for loading image textures in Hydra Storm / Embree renderers which we don't use. Reviewed By: LazyDodo, brecht, makowalski Differential Revision: https://developer.blender.org/D14792
2022-04-20Build: upgrade many library dependencies to new versions for Blender 3.2Ray Molenkamp
This only updates the build system, precompiled libraries for the various platforms will be committed over the coming week. New: fmt 8.0.0 level_zero v1.7.15 pystring v1.1.3 robinmap v0.6.2 webp 1.2.2 Updated: alembic 1.8.3 blosc 1.21.1 boost 1.78.0 embree 3.13.3 ffmpeg 5.0 fftw 3.3.10 flac 1.3.4 imath 3.1.4 ispc v1.17.0 jpeg 2.1.3 ogg 1.3.5 oidn 1.4.3 openal 1.21.1 opencolorio 2.1.1 openexr 3.1.4 openimageio v2.3.13.0 openjpeg 2.4.0 opensubdiv v3_4_4 openvdb 9.0.0 osl 1.11.17.0 sdl 2.0.20 tbb 2020_u3 tiff 4.3.0 usd 22.03 vorbis 1.3.7 vpx 1.11.0 x264 35fe20d1b zlib 1.2.12 Implemented by Ray Molenkamp, Sybren Stüvel and Brecht Van Lommel. Ref T95206
2022-03-22CMake: prep USD build & find scripts for USD >= 21.11Sybren A. Stüvel
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
2022-02-11File headers: SPDX License migrationCampbell Barton
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
2021-03-16Fix T86124: Self-hosting external libraries packagesSybren A. Stüvel
Allow downloading of source packages of Blender's dependencies, so that it's easier to provide a "full source archive" that contains the blender source + all dependencies archives. A `make` command for this will be introduced soon. This changes the deps builder slightly to be more flexible with the origin of our source packages. To support this a new CMake variable has been added called `PACKAGE_DIR` where all sources archives will be stored. default: a directory called `packages` in the build folder. alternative-default: if a directory called `packages` exists in the blender source folder that will be used. This is to support the "full source archive" use case. The download phase have been moved from the build phase to the configure phase. Configure will download all sources validate the hashes while downloading. All `[depname].cmake` files have been changed to take a local `file://[path_to_local_tarball]` path rather than a remote URI. A second requirement was that there needed to be an option to grab the sources from the blender SVN mirror rather than upstream. For this an option has been added PACKAGE_USE_UPSTREAM_SOURCES (default ON). The exact location in SVN still needs to be worked out, I tested with my local webserver and codewise it checks out. The path that is in there currently will not work (given there is no mirror there yet). To build this mirror our local package caches can be used. Reviewed By: lazydodo Differential Revision: https://developer.blender.org/D10598
2020-06-26deps: Fix build issue with USD on windows.Ray Molenkamp
When doing a release build the TBB debug libs are not set which was causing an error during the configure phase of USD, so always set them even if not used.
2020-06-12USD: Library upgrade 19.11 → 20.02Sybren A. Stüvel
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.
2020-06-05Fix make deps build errors with conflicting Boost system packagesBrecht Van Lommel
2020-05-04Windows: Move tbb to being dynamic libraryRay Molenkamp
Static tbb has always been frowned upon [1] sofar it has worked for us but given our reliance on tbb is about to increase (D7475), I'd like to move the library to more supported configuration. Which means moving it to be a dynamic library The libs part of this change is in rBL62416 Reviewed By: Brecht Differential Revision: https://developer.blender.org/D7570
2019-12-13USD: Introducing a simple USD ExporterSybren A. Stüvel
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