Files
test2/source/blender/python/intern/bpy_app_build_options.cc

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

357 lines
6.3 KiB
C++
Raw Normal View History

/* SPDX-FileCopyrightText: 2023 Blender Authors
*
* SPDX-License-Identifier: GPL-2.0-or-later */
/** \file
* \ingroup pythonintern
*/
#include <Python.h>
#include "BLI_utildefines.h"
#include "bpy_app_build_options.hh"
static PyTypeObject BlenderAppBuildOptionsType;
static PyStructSequence_Field app_builtopts_info_fields[] = {
/* names mostly follow CMake options, lowercase, after `WITH_` */
{"bullet", nullptr},
{"codec_avi", nullptr},
{"codec_ffmpeg", nullptr},
{"codec_sndfile", nullptr},
{"compositor_cpu", nullptr},
{"cycles", nullptr},
{"cycles_osl", nullptr},
{"freestyle", nullptr},
{"image_cineon", nullptr},
{"image_dds", nullptr},
{"image_hdr", nullptr},
{"image_openexr", nullptr},
{"image_openjpeg", nullptr},
{"image_tiff", nullptr},
{"image_webp", nullptr},
{"input_ndof", nullptr},
{"audaspace", nullptr},
{"international", nullptr},
{"openal", nullptr},
{"opensubdiv", nullptr},
{"sdl", nullptr},
{"coreaudio", nullptr},
{"jack", nullptr},
{"pulseaudio", nullptr},
{"wasapi", nullptr},
{"libmv", nullptr},
{"mod_oceansim", nullptr},
{"mod_remesh", nullptr},
{"collada", nullptr},
{"io_wavefront_obj", nullptr},
{"io_ply", nullptr},
{"io_stl", nullptr},
IO: New FBX importer (C++, via ufbx) Adds a C++ based FBX importer, using 3rd party ufbx library (design task: #131304). The old Python based importer is still there; the new one is marked as "(experimental)" in the menu item. Drag-and-drop uses the old Python importer; the new one is only in the menu item. The new importer is generally 2x-5x faster than the old one, and often uses less memory too. There's potential to make it several times faster still. - ASCII FBX files are supported now - Binary FBX files older than 7.1 (SDK 2012) version are supported now - Better handling of "geometric transform" (common in 3dsmax), manifesting as wrong rotation for some objects when in a hierarchy (e.g. #131172) - Some FBX files that the old importer was failing to read are supported now (e.g. cases 47344, 134983) - Materials import more shader parameters (IOR, diffuse roughness, anisotropy, subsurface, transmission, coat, sheen, thin film) and shader models (e.g. OpenPBR or glTF2 materials from 3dsmax imports much better) - Importer now creates layered/slotted animation actions. Each "take" inside FBX file creates one action, and animated object within it gets a slot. - Materials that use the same texture several times no longer create duplicate images; the same image is used - Material diffuse color animations were imported, but they only animated the viewport color. Now they also animate the nodetree base color too. - "Ignore Leaf Bones" option no longer ignores leaf bones that are actually skinned to some parts of the mesh. - Previous importer was creating orphan invisible Camera data objects for some files (mostly from MotionBuilder?), new one properly creates these cameras. Import settings that existed in Python importer, but are NOT DONE in the new one (mostly because not sure if they are useful, and no one asked for them from feedback yet): - Manual Orientation & Forward/Up Axis: not sure if actually useful. FBX file itself specifies the axes fairly clearly. USD/glTF/Alembic also do not have settings to override them. - Use Pre/Post Rotation (defaults on): feels like it should just always be on. ufbx handles that internally. - Apply Transform (defaults off, warning icon): not sure if needed at all. - Decal Offset: Cycles specific. None of other importers have it. - Automatic Bone Orientation (defaults off): feels like current behavior (either on or off) often produces "nonsensical bones" where bone direction does not go towards the children with either setting. There are discussions within I/O and Animation modules about different ways of bone visualizations and/or different bone length axes, that would solve this in general. - Force Connect Children (defaults off): not sure when that would be useful. On several animated armatures I tried, it turns armature animation into garbage. - Primary/Secondary Bone Axis: again not sure when would be useful. Importer UI screenshots, performance benchmark details and TODOs for later work are in the PR. Pull Request: https://projects.blender.org/blender/blender/pulls/132406
2025-04-16 09:55:00 +02:00
{"io_fbx", nullptr},
{"io_gpencil", nullptr},
{"opencolorio", nullptr},
{"openmp", nullptr},
{"openvdb", nullptr},
{"alembic", nullptr},
{"usd", nullptr},
{"fluid", nullptr},
{"xr_openxr", nullptr},
{"potrace", nullptr},
{"pugixml", nullptr},
{"haru", nullptr},
/* Sentinel (this line prevents `clang-format` wrapping into columns). */
{nullptr},
};
static PyStructSequence_Desc app_builtopts_info_desc = {
/*name*/ "bpy.app.build_options",
/*doc*/ "This module contains information about options blender is built with",
/*fields*/ app_builtopts_info_fields,
/*n_in_sequence*/ ARRAY_SIZE(app_builtopts_info_fields) - 1,
};
static PyObject *make_builtopts_info()
{
PyObject *builtopts_info;
int pos = 0;
builtopts_info = PyStructSequence_New(&BlenderAppBuildOptionsType);
if (builtopts_info == nullptr) {
return nullptr;
}
#define SetObjIncref(item) \
PyStructSequence_SET_ITEM(builtopts_info, pos++, (Py_IncRef(item), item))
#ifdef WITH_BULLET
SetObjIncref(Py_True);
#else
SetObjIncref(Py_False);
#endif
/* AVI */
SetObjIncref(Py_False);
#ifdef WITH_FFMPEG
SetObjIncref(Py_True);
#else
SetObjIncref(Py_False);
#endif
#ifdef WITH_SNDFILE
SetObjIncref(Py_True);
#else
SetObjIncref(Py_False);
#endif
/* Compositor. */
SetObjIncref(Py_True);
#ifdef WITH_CYCLES
SetObjIncref(Py_True);
#else
SetObjIncref(Py_False);
#endif
#ifdef WITH_CYCLES_OSL
SetObjIncref(Py_True);
#else
SetObjIncref(Py_False);
#endif
#ifdef WITH_FREESTYLE
SetObjIncref(Py_True);
#else
SetObjIncref(Py_False);
#endif
#ifdef WITH_IMAGE_CINEON
SetObjIncref(Py_True);
#else
SetObjIncref(Py_False);
#endif
/* DDS */
SetObjIncref(Py_True);
/* HDR */
SetObjIncref(Py_True);
#ifdef WITH_IMAGE_OPENEXR
SetObjIncref(Py_True);
#else
SetObjIncref(Py_False);
#endif
#ifdef WITH_IMAGE_OPENJPEG
SetObjIncref(Py_True);
#else
SetObjIncref(Py_False);
#endif
/* TIFF */
SetObjIncref(Py_True);
#ifdef WITH_IMAGE_WEBP
SetObjIncref(Py_True);
#else
SetObjIncref(Py_False);
#endif
#ifdef WITH_INPUT_NDOF
SetObjIncref(Py_True);
#else
SetObjIncref(Py_False);
#endif
#ifdef WITH_AUDASPACE
SetObjIncref(Py_True);
#else
SetObjIncref(Py_False);
#endif
#ifdef WITH_INTERNATIONAL
SetObjIncref(Py_True);
#else
SetObjIncref(Py_False);
#endif
#ifdef WITH_OPENAL
SetObjIncref(Py_True);
#else
SetObjIncref(Py_False);
#endif
#ifdef WITH_OPENSUBDIV
SetObjIncref(Py_True);
#else
SetObjIncref(Py_False);
#endif
#ifdef WITH_SDL
SetObjIncref(Py_True);
#else
SetObjIncref(Py_False);
#endif
#ifdef WITH_COREAUDIO
SetObjIncref(Py_True);
#else
SetObjIncref(Py_False);
#endif
#ifdef WITH_JACK
SetObjIncref(Py_True);
#else
SetObjIncref(Py_False);
#endif
#ifdef WITH_PULSEAUDIO
SetObjIncref(Py_True);
#else
SetObjIncref(Py_False);
#endif
#ifdef WITH_WASAPI
SetObjIncref(Py_True);
#else
SetObjIncref(Py_False);
#endif
#ifdef WITH_LIBMV
SetObjIncref(Py_True);
#else
SetObjIncref(Py_False);
#endif
#ifdef WITH_OCEANSIM
SetObjIncref(Py_True);
#else
SetObjIncref(Py_False);
#endif
#ifdef WITH_MOD_REMESH
SetObjIncref(Py_True);
#else
SetObjIncref(Py_False);
#endif
#ifdef WITH_COLLADA
SetObjIncref(Py_True);
#else
SetObjIncref(Py_False);
#endif
#ifdef WITH_IO_WAVEFRONT_OBJ
SetObjIncref(Py_True);
#else
SetObjIncref(Py_False);
#endif
#ifdef WITH_IO_PLY
SetObjIncref(Py_True);
#else
SetObjIncref(Py_False);
#endif
#ifdef WITH_IO_STL
SetObjIncref(Py_True);
#else
SetObjIncref(Py_False);
#endif
IO: New FBX importer (C++, via ufbx) Adds a C++ based FBX importer, using 3rd party ufbx library (design task: #131304). The old Python based importer is still there; the new one is marked as "(experimental)" in the menu item. Drag-and-drop uses the old Python importer; the new one is only in the menu item. The new importer is generally 2x-5x faster than the old one, and often uses less memory too. There's potential to make it several times faster still. - ASCII FBX files are supported now - Binary FBX files older than 7.1 (SDK 2012) version are supported now - Better handling of "geometric transform" (common in 3dsmax), manifesting as wrong rotation for some objects when in a hierarchy (e.g. #131172) - Some FBX files that the old importer was failing to read are supported now (e.g. cases 47344, 134983) - Materials import more shader parameters (IOR, diffuse roughness, anisotropy, subsurface, transmission, coat, sheen, thin film) and shader models (e.g. OpenPBR or glTF2 materials from 3dsmax imports much better) - Importer now creates layered/slotted animation actions. Each "take" inside FBX file creates one action, and animated object within it gets a slot. - Materials that use the same texture several times no longer create duplicate images; the same image is used - Material diffuse color animations were imported, but they only animated the viewport color. Now they also animate the nodetree base color too. - "Ignore Leaf Bones" option no longer ignores leaf bones that are actually skinned to some parts of the mesh. - Previous importer was creating orphan invisible Camera data objects for some files (mostly from MotionBuilder?), new one properly creates these cameras. Import settings that existed in Python importer, but are NOT DONE in the new one (mostly because not sure if they are useful, and no one asked for them from feedback yet): - Manual Orientation & Forward/Up Axis: not sure if actually useful. FBX file itself specifies the axes fairly clearly. USD/glTF/Alembic also do not have settings to override them. - Use Pre/Post Rotation (defaults on): feels like it should just always be on. ufbx handles that internally. - Apply Transform (defaults off, warning icon): not sure if needed at all. - Decal Offset: Cycles specific. None of other importers have it. - Automatic Bone Orientation (defaults off): feels like current behavior (either on or off) often produces "nonsensical bones" where bone direction does not go towards the children with either setting. There are discussions within I/O and Animation modules about different ways of bone visualizations and/or different bone length axes, that would solve this in general. - Force Connect Children (defaults off): not sure when that would be useful. On several animated armatures I tried, it turns armature animation into garbage. - Primary/Secondary Bone Axis: again not sure when would be useful. Importer UI screenshots, performance benchmark details and TODOs for later work are in the PR. Pull Request: https://projects.blender.org/blender/blender/pulls/132406
2025-04-16 09:55:00 +02:00
#ifdef WITH_IO_FBX
SetObjIncref(Py_True);
#else
SetObjIncref(Py_False);
#endif
#ifdef WITH_IO_GREASE_PENCIL
SetObjIncref(Py_True);
#else
SetObjIncref(Py_False);
#endif
Refactor: OpenColorIO integration Briefly about this change: - OpenColorIO C-API is removed. - The information about color spaces in ImBuf module is removed. It was stored in global ListBase in colormanagement.cc. - Both OpenColorIO and fallback implementation supports GPU drawing. - Fallback implementation supports white point, RGB curves, etc. - Removed check for support of GPU drawing in IMB. Historically it was implemented in a separate library with C-API, this is because way back C++ code needed to stay in intern. This causes all sort of overheads, and even calls that are strictly considered bad level. This change moves OpenColorIO integration into a module within imbuf, next to movie, and next to IMB_colormanagement which is the main user of it. This allows to avoid copy of color spaces, displays, views etc in the ImBuf: they were used to help quickly querying information to be shown on the interface. With this change it can be stored in the same data structures as what is used by the OpenColorIO integration. While it might not be fully avoiding duplication it is now less, and there is no need in the user code to maintain the copies. In a lot of cases this change also avoids allocations done per access to the OpenColorIO. For example, it is not needed anymore to allocate image descriptor in a heap. The bigger user-visible change is that the fallback implementation now supports GLSL drawing, with the whole list of supported features, such as curve mapping and white point. This should help simplifying code which relies on color space conversion on GPU: there is no need to figure out fallback solution in such cases. The only case when drawing will not work is when there is some actual bug, or driver issue, and shader has failed to compile. The change avoids having an opaque type for color space, and instead uses forward declaration. It is a bit verbose on declaration, but helps avoiding unsafe type-casts. There are ways to solve this in the future, like having a header for forward declaration, or to flatten the name space a bit. There should be no user-level changes under normal operation. When building without OpenColorIO or the configuration has a typo or is missing a fuller set of color management tools is applies (such as the white point correction). Pull Request: https://projects.blender.org/blender/blender/pulls/138433
2025-05-09 14:01:43 +02:00
#ifdef WITH_OPENCOLORIO
SetObjIncref(Py_True);
#else
SetObjIncref(Py_False);
#endif
2013-05-20 14:38:43 +00:00
#ifdef _OPENMP
SetObjIncref(Py_True);
#else
SetObjIncref(Py_False);
#endif
#ifdef WITH_OPENVDB
SetObjIncref(Py_True);
#else
SetObjIncref(Py_False);
#endif
#ifdef WITH_ALEMBIC
SetObjIncref(Py_True);
#else
SetObjIncref(Py_False);
#endif
USD: Introducing a simple USD Exporter 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
2019-12-13 10:27:40 +01:00
#ifdef WITH_USD
SetObjIncref(Py_True);
#else
SetObjIncref(Py_False);
#endif
#ifdef WITH_FLUID
SetObjIncref(Py_True);
#else
SetObjIncref(Py_False);
#endif
Build System: Add OpenXR-SDK dependency and WITH_XR_OPENXR build option 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
2020-03-04 16:39:00 +01:00
#ifdef WITH_XR_OPENXR
SetObjIncref(Py_True);
#else
SetObjIncref(Py_False);
#endif
#ifdef WITH_POTRACE
SetObjIncref(Py_True);
#else
SetObjIncref(Py_False);
#endif
#ifdef WITH_PUGIXML
SetObjIncref(Py_True);
#else
SetObjIncref(Py_False);
#endif
#ifdef WITH_HARU
SetObjIncref(Py_True);
#else
SetObjIncref(Py_False);
#endif
#undef SetObjIncref
return builtopts_info;
}
PyObject *BPY_app_build_options_struct()
{
PyObject *ret;
PyStructSequence_InitType(&BlenderAppBuildOptionsType, &app_builtopts_info_desc);
ret = make_builtopts_info();
/* prevent user from creating new instances */
BlenderAppBuildOptionsType.tp_init = nullptr;
BlenderAppBuildOptionsType.tp_new = nullptr;
2023-05-24 11:21:18 +10:00
/* Without this we can't do `set(sys.modules)` #29635. */
BlenderAppBuildOptionsType.tp_hash = (hashfunc)_Py_HashPointer;
return ret;
}