Files
test2/source/blender/io/usd/usd.hh

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

341 lines
9.4 KiB
C++
Raw Normal View History

/* SPDX-FileCopyrightText: 2019 Blender Authors
*
* SPDX-License-Identifier: GPL-2.0-or-later */
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
#pragma once
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
#include <memory>
#include "../common/IO_orientation.hh"
#include "DEG_depsgraph.hh"
#include "DNA_modifier_types.h"
#include "RNA_types.hh"
struct bContext;
struct CacheArchiveHandle;
2021-08-26 12:39:45 +10:00
struct CacheReader;
struct ListBase;
struct Mesh;
2021-08-26 12:39:45 +10:00
struct Object;
struct ReportList;
struct wmJobWorkerStatus;
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
Alembic/USD: Use GeometrySets to import data This rewrites the Alembic and USD data importers to work with and output GeometrySets instead of Meshes. The main motivation for this change is to be able to import properly point clouds, which are currently imported as Meshes, and curves data, which suffer from a lot of issues due to limitations of legacy curves structures (fixed by the new curves data-block) and are also converted to Meshes. Further, for Curves, it will allow importing arbitrary attributes. This patch was primarily meant for Alembic, but changes to USD import were necessary as they share the same modifier. For Alembic: There should be no behavioral changes for Meshes Curves are imported as the new Curves object type Points are imported as PointClouds For USD: There should be no behavioral changes for Meshes Curves are imported as the new Curves object type Note that the current USD importer does not support loading PointClouds, so this patch does not add support for it. For both Alembic and USD, knots arrays are not read anymore, as the new Curves object does not expose the ability to set them. Improvements can be made in the future if and when example assets are provided. This fixes at least the following: #58704: Animated Alembic curves don't update on render #112308: Curves have offset animations (alembic / USD) #118261: wrong motion blur from usd in cycles and reverting to the first frame when disabeling motion blur Co-authored-by: Jesse Yurkovich <jesse.y@gmail.com> Pull Request: https://projects.blender.org/blender/blender/pulls/115623
2024-02-28 03:02:38 +01:00
namespace blender::bke {
struct GeometrySet;
}
namespace blender::io::usd {
/**
* Behavior when the name of an imported material
* conflicts with an existing material.
*/
enum eUSDMtlNameCollisionMode {
USD_MTL_NAME_COLLISION_MAKE_UNIQUE = 0,
USD_MTL_NAME_COLLISION_REFERENCE_EXISTING = 1,
};
USD: Provide Import option for Material Purpose USD has the concept of material "purposes" which allows different materials to be associated for a prim and gives special meaning to them. These are somewhat similar to display purposes, which we already allow to be chosen, but are distinct concepts. This PR adds an option for Import allowing the user to chose which material purpose to load. Blender currently attempts to load purposes automatically. It starts with "allPurpose" and then moves to "preview" and "full" in that order. This behavior is now changed and the automated search is removed to instead give the user control which purpose to load. Additionally, USD already has its own fallback behavior during material resolution[1]: - When given "full" it will first check "full" and fallback to "allPurpose" if not found. An additional, Blender-specific fallback to "preview" is also implemented here upon request. - When given "preview" it will first check "preview" and fallback to "allPurpose" if not found - When given "allPurpose", it will only check "allPurpose" I have opt'd to keep this behavior directly as-is to not introduce differences that may surprise those already familiar with USD elsewhere. Additionally, I've set Blender's default import purpose to "full" to ensure we're loading in the highest quality assets first. Though this has the obvious risk that "full" assets tend to be quite heavy. We can change to "preview" if this proves too problematic later. This does not change how Blender exports materials. Blender always uses the "allPurpose" binding when writing its USD files. -------- [1] USD docs: https://openusd.org/release/api/class_usd_shade_material_binding_a_p_i.html#details https://openusd.org/release/api/class_usd_shade_material_binding_a_p_i.html#UsdShadeMaterialBindingAPI_MaterialResolution Pull Request: https://projects.blender.org/blender/blender/pulls/128206
2024-10-03 20:16:27 +02:00
/* Enums specifying the USD material purpose,
2024-10-04 11:45:26 +10:00
* corresponding to #pxr::UsdShadeTokens 'allPurpose',
USD: Provide Import option for Material Purpose USD has the concept of material "purposes" which allows different materials to be associated for a prim and gives special meaning to them. These are somewhat similar to display purposes, which we already allow to be chosen, but are distinct concepts. This PR adds an option for Import allowing the user to chose which material purpose to load. Blender currently attempts to load purposes automatically. It starts with "allPurpose" and then moves to "preview" and "full" in that order. This behavior is now changed and the automated search is removed to instead give the user control which purpose to load. Additionally, USD already has its own fallback behavior during material resolution[1]: - When given "full" it will first check "full" and fallback to "allPurpose" if not found. An additional, Blender-specific fallback to "preview" is also implemented here upon request. - When given "preview" it will first check "preview" and fallback to "allPurpose" if not found - When given "allPurpose", it will only check "allPurpose" I have opt'd to keep this behavior directly as-is to not introduce differences that may surprise those already familiar with USD elsewhere. Additionally, I've set Blender's default import purpose to "full" to ensure we're loading in the highest quality assets first. Though this has the obvious risk that "full" assets tend to be quite heavy. We can change to "preview" if this proves too problematic later. This does not change how Blender exports materials. Blender always uses the "allPurpose" binding when writing its USD files. -------- [1] USD docs: https://openusd.org/release/api/class_usd_shade_material_binding_a_p_i.html#details https://openusd.org/release/api/class_usd_shade_material_binding_a_p_i.html#UsdShadeMaterialBindingAPI_MaterialResolution Pull Request: https://projects.blender.org/blender/blender/pulls/128206
2024-10-03 20:16:27 +02:00
* 'preview', and 'render', respectively. */
enum eUSDMtlPurpose {
USD_MTL_PURPOSE_ALL = 0,
USD_MTL_PURPOSE_PREVIEW = 1,
USD_MTL_PURPOSE_FULL = 2
};
USD: Import and export custom properties Adding support for converting between Blender custom properties and USD user-defined custom attributes. Custom attributes on Xforms, many data types, and materials are all supported for round-tripping. Please see the USD attributes documentation for more information on custom attributes. Properties are exported with a userProperties: namespace for simple filtering in external apps. This namespace is stripped on import, but other namespace are allowed to persist. An "Import Attributes" parameter has been added with options "None" (do not import attributes), "User" (import attributes in the 'userProperties' namespace only), "All custom" (import all USD custom attributes, the default). An "Export Custom Properties" export option has been added. The property conversion code handles float, double, string and bool types, as well as tuples of size 2, 3 and 4. Note that USD quaternions and arrays of arbitrary length are not yet supported. There is currently no attempt to set the Blender property subtype based on the USD type "role" (e.g., specifying Color or XYZ vector subtypes). This can be addressed in future work. In addition to exporting custom properties, the original Blender object and data names are now saved as USD custom string attributes "userProperties:blender:object_name" and "userProperties:blender:data_name", respectively, on the corresponding USD prims. This feature is enabled with the "Author Blender Name" export option. If a Blender custom string property is named "displayName", it's handled in a special way on export in that its value is used to set the USD prim's "displayName" metadata. Co-authored-by: kiki <charles@skeletalstudios.com> Co-authored-by: Michael Kowalski <makowalski@nvidia.com> Co-authored-by: Charles Wardlaw <kattkieru@users.noreply.github.com> Pull Request: https://projects.blender.org/blender/blender/pulls/118938
2024-04-23 19:27:40 +02:00
/**
* Behavior for importing of custom
* attributes / properties outside
* a prim's regular schema.
*/
enum eUSDAttrImportMode {
USD: Import and export custom properties Adding support for converting between Blender custom properties and USD user-defined custom attributes. Custom attributes on Xforms, many data types, and materials are all supported for round-tripping. Please see the USD attributes documentation for more information on custom attributes. Properties are exported with a userProperties: namespace for simple filtering in external apps. This namespace is stripped on import, but other namespace are allowed to persist. An "Import Attributes" parameter has been added with options "None" (do not import attributes), "User" (import attributes in the 'userProperties' namespace only), "All custom" (import all USD custom attributes, the default). An "Export Custom Properties" export option has been added. The property conversion code handles float, double, string and bool types, as well as tuples of size 2, 3 and 4. Note that USD quaternions and arrays of arbitrary length are not yet supported. There is currently no attempt to set the Blender property subtype based on the USD type "role" (e.g., specifying Color or XYZ vector subtypes). This can be addressed in future work. In addition to exporting custom properties, the original Blender object and data names are now saved as USD custom string attributes "userProperties:blender:object_name" and "userProperties:blender:data_name", respectively, on the corresponding USD prims. This feature is enabled with the "Author Blender Name" export option. If a Blender custom string property is named "displayName", it's handled in a special way on export in that its value is used to set the USD prim's "displayName" metadata. Co-authored-by: kiki <charles@skeletalstudios.com> Co-authored-by: Michael Kowalski <makowalski@nvidia.com> Co-authored-by: Charles Wardlaw <kattkieru@users.noreply.github.com> Pull Request: https://projects.blender.org/blender/blender/pulls/118938
2024-04-23 19:27:40 +02:00
USD_ATTR_IMPORT_NONE = 0,
USD_ATTR_IMPORT_USER = 1,
USD_ATTR_IMPORT_ALL = 2,
};
USD: Import and export custom properties Adding support for converting between Blender custom properties and USD user-defined custom attributes. Custom attributes on Xforms, many data types, and materials are all supported for round-tripping. Please see the USD attributes documentation for more information on custom attributes. Properties are exported with a userProperties: namespace for simple filtering in external apps. This namespace is stripped on import, but other namespace are allowed to persist. An "Import Attributes" parameter has been added with options "None" (do not import attributes), "User" (import attributes in the 'userProperties' namespace only), "All custom" (import all USD custom attributes, the default). An "Export Custom Properties" export option has been added. The property conversion code handles float, double, string and bool types, as well as tuples of size 2, 3 and 4. Note that USD quaternions and arrays of arbitrary length are not yet supported. There is currently no attempt to set the Blender property subtype based on the USD type "role" (e.g., specifying Color or XYZ vector subtypes). This can be addressed in future work. In addition to exporting custom properties, the original Blender object and data names are now saved as USD custom string attributes "userProperties:blender:object_name" and "userProperties:blender:data_name", respectively, on the corresponding USD prims. This feature is enabled with the "Author Blender Name" export option. If a Blender custom string property is named "displayName", it's handled in a special way on export in that its value is used to set the USD prim's "displayName" metadata. Co-authored-by: kiki <charles@skeletalstudios.com> Co-authored-by: Michael Kowalski <makowalski@nvidia.com> Co-authored-by: Charles Wardlaw <kattkieru@users.noreply.github.com> Pull Request: https://projects.blender.org/blender/blender/pulls/118938
2024-04-23 19:27:40 +02:00
/**
* Behavior when importing textures from a package
* (e.g., USDZ archive) or from a URI path.
*/
enum eUSDTexImportMode {
USD_TEX_IMPORT_NONE = 0,
USD_TEX_IMPORT_PACK,
USD_TEX_IMPORT_COPY,
};
/**
* Behavior when the name of an imported texture
* file conflicts with an existing file.
*/
enum eUSDTexNameCollisionMode {
USD_TEX_NAME_COLLISION_USE_EXISTING = 0,
USD_TEX_NAME_COLLISION_OVERWRITE = 1,
};
enum eSubdivExportMode {
/** Subdivision scheme = None, export base mesh without subdivision. */
USD_SUBDIV_IGNORE = 0,
/** Subdivision scheme = None, export subdivided mesh. */
USD_SUBDIV_TESSELLATE = 1,
/**
* Apply the USD subdivision scheme that is the closest match to Blender.
* Reverts to #USD_SUBDIV_TESSELLATE if the subdivision method is not supported.
*/
USD_SUBDIV_BEST_MATCH = 2,
};
USD: optionally author subdivision schema on export USD: optionally author subdivision schema on export This PR adds support for exporting USD assets which have the subdivision schema applied. Current behavior prior to this PR is that the effects of Subdivision Surface modifiers are always applied to their mesh prior to export, such that it is not possible to recover the original base mesh. In this PR we provide three options for the subdiv schema type: Ignore - Export base mesh without subdivision with USD Scheme = None Tessellate - Export subdivided mesh with USD Scheme = None Best Match (default) - Export base mesh with USD Scheme = Catmull-Clark "Best Match" here means that Blender will set a subdiv scheme type in the exported USD asset when it is possible to closely match the subdivision surface type that was authored in Blender. At this time Blender provides two subdivision types: Catmull-Clark and Simple. Because Simple does not have a corresponding subdivision type in USD, we do not attempt to convert or represent it, and instead the Simple subdiv modifier will be evaluated and applied to the mesh during export. Whenever a Catmull-Clark Subdivision Surface modifier is applied to an object, and is the last modifier in the stack, it is possible to set the subdiv scheme to Catmull-Clark for the respective prim in the exported USD file. Authored by Apple: Matt McLin Co-authored-by: Matt McLin <mmclin@apple.com> Co-authored-by: Brecht Van Lommel <brecht@blender.org> Pull Request: https://projects.blender.org/blender/blender/pulls/113267
2023-12-15 21:11:41 +01:00
enum eUSDXformOpMode {
USD_XFORM_OP_TRS = 0,
USD_XFORM_OP_TOS = 1,
USD_XFORM_OP_MAT = 2,
};
enum eUSDZTextureDownscaleSize {
USD_TEXTURE_SIZE_CUSTOM = -1,
USD_TEXTURE_SIZE_KEEP = 0,
USD_TEXTURE_SIZE_256 = 256,
USD_TEXTURE_SIZE_512 = 512,
USD_TEXTURE_SIZE_1024 = 1024,
USD_TEXTURE_SIZE_2048 = 2048,
USD_TEXTURE_SIZE_4096 = 4096
};
/**
* Behavior when exporting textures.
*/
enum eUSDTexExportMode {
USD_TEX_EXPORT_KEEP = 0,
USD_TEX_EXPORT_PRESERVE,
USD_TEX_EXPORT_NEW_PATH,
};
enum eUSDSceneUnits {
USD_SCENE_UNITS_CUSTOM = -1,
USD_SCENE_UNITS_METERS = 0,
USD_SCENE_UNITS_KILOMETERS = 1,
USD_SCENE_UNITS_CENTIMETERS = 2,
USD_SCENE_UNITS_MILLIMETERS = 3,
USD_SCENE_UNITS_INCHES = 4,
USD_SCENE_UNITS_FEET = 5,
USD_SCENE_UNITS_YARDS = 6,
};
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
struct USDExportParams {
bool export_animation = false;
bool selected_objects_only = false;
bool visible_objects_only = true;
bool export_meshes = true;
bool export_lights = true;
bool export_cameras = true;
bool export_curves = true;
bool export_points = true;
bool export_volumes = true;
bool export_hair = true;
bool export_uvmaps = true;
bool rename_uvmaps = true;
bool export_normals = true;
bool export_mesh_colors = true;
bool export_materials = true;
USD: Support armature and shape key export New functionality to export armatures and shape keys as USD skeletons and blend shapes. Added "Armature", "Only Deform Bones" and "Shape Key" USD export options. Added USDArmatureWriter class. Extended USDMeshWriter to write skinned meshes for binding with skeletons and 'neutral' meshes with blend shape targets. Specifically, when exporting an armature, a skinned mesh is written in its pre-modified rest position. When exporting to blend shapes, a mesh with shape keys is saved with its vertices in the shape key basis shape position. Added USDHierarchyIterator::process_usd_skel() function to finish processing skeleton and blend shape export after the writer instances completed writing. This is necessary because some of the export operations require processing multiple prims at once. Extended USDTransformWriter::do_write() to write transforms sparsely, to avoid saving redundant transform values when exporting armatures. Added a create_skel_roots() function, called on the stage at the end of the export. This function attempts to ensure that skinned prims and skeletons are encapsulated under SkelRoot primitives, which is required in USD for correct skinning behavior. When exporting blend shape animations for multiple meshes bound to a single skeleton, we need to merge the blend shape time samples of the different meshes into a single animation primitive at the end of the export. This requires some tricky book keeping, where the weight time samples for a given mesh are initially saved by the mesh writer to a temporary attribute on the mesh and are later copied to the animation primitive as one of the final steps. When writing blend shapes and skinned meshes, the pre-modified mesh is exported. This is to ensure that the number of blend shape offsets matches the number of points, and so that the skinned mesh is saved in its rest position. Because the pre-modified mesh must be exported, modifiers in addition to Armature modifiers will not be applied. This still allows the round trip UsdSkel -> Blender -> UsdSkel, but some additional setup might be required to export to UsdSkel when there are multiple modifiers (for example, applying mirroring modifiers that precede the armature modifier). Exporting bendy bones or absolute shape keys isn't currently supported. Co-authored-by: Charles Wardlaw <charleswardlaw@noreply.localhost> Pull Request: https://projects.blender.org/blender/blender/pulls/111931
2024-01-02 15:51:39 +01:00
bool export_armatures = true;
bool export_shapekeys = true;
bool only_deform_bones = false;
bool convert_world_material = true;
bool merge_parent_xform = false;
bool use_instancing = false;
bool export_custom_properties = true;
bool author_blender_name = true;
bool allow_unicode = false;
eSubdivExportMode export_subdiv = USD_SUBDIV_BEST_MATCH;
enum eEvaluationMode evaluation_mode = DAG_EVAL_VIEWPORT;
bool generate_preview_surface = true;
USD: Add MaterialX shader export This change adds the ability to export MaterialX networks into the resulting USD layer. Details: A new export option has been added to the USD export to enable MaterialX export. It is off by default currently due to reasons in the caveats section. When enabled, it exports the MaterialX shading network alongside the UsdPreviewSurface network, on the same USD Material. This allows the same material to be used by renderers that don't support MaterialX, using the USDPreviewSurface as a fallback. This is similar to setups in other DCC packages, and matches the format we've used in our Reality Composer Pro asset library. It uses the existing MaterialX framework used to generate MaterialX documents for rendering, to act as the basis for the USD graph. In this process it also re-uses the existing texture export code as well if provided and necessary. Once the MaterialX document is created, use usdMtlx to generate a USD shading network. Unfortunately, usdMtlx generates a graph that is unlike what other DCCs that support MaterialX-embedded-in-USD generates. It generates several extra prim hierarchies, and externalizes all shader inputs, making them difficult to edit in other MaterialX graph editors. To workaround this, generate the MaterialX shading network onto a temporary stage, where we then run various pre-processing steps to prevent prim collisions and to reflow the paths once they're converted. The PrimSpecs are then copied over to their new path. The resulting prim hierarchy matches what many artists we've worked with prefer to work with. Caveats: The Export MaterialX check is off by default. When using the Principled BSDF, the resulting graph is very usable. However, when using some of the other BSDFs, the shading networks generated by the existing MaterialX framework in Blender generate some shading graphs that are difficult for usdview and other DCC's to understand. The graph is still correct, but because we're trying to prioritize compatibility, the default is off. In future PRs we can aim to make the graphs for those other BSDFs play better with other DCCs. Other Implementation Details: As part of this commit we've also done the following: * Place some of the materialx graphs inside a passthrough nodegraph to avoid node conflicts. * Better handle some shader output types , and better handle some conflict cases. * Moved the ExportTextureFunction to materials.h due to some difficult to resolve header ordering issues. This has no effect on any runtime code. * There is a test for the MaterialX export that does some basic checking to make sure we get an export out the other end that matches our expectations Authored by Apple: Dhruv Govil This PR is based on an earlier implementation by Brecht van Lommel , as well as Brian Savery and his teams' work at AMD to implement the general MaterialX framework within Blender. Pull Request: https://projects.blender.org/blender/blender/pulls/122575
2024-06-05 20:43:44 +02:00
bool generate_materialx_network = true;
bool export_textures = false;
bool overwrite_textures = true;
bool relative_paths = true;
bool use_original_paths = false;
bool triangulate_meshes = false;
int quad_method = MOD_TRIANGULATE_QUAD_SHORTEDGE;
int ngon_method = MOD_TRIANGULATE_NGON_BEAUTY;
bool convert_orientation = false;
enum eIOAxis forward_axis = eIOAxis::IO_AXIS_NEGATIVE_Z;
enum eIOAxis up_axis = eIOAxis::IO_AXIS_Y;
eUSDXformOpMode xform_op_mode = eUSDXformOpMode::USD_XFORM_OP_TRS;
eUSDZTextureDownscaleSize usdz_downscale_size = eUSDZTextureDownscaleSize::USD_TEXTURE_SIZE_KEEP;
int usdz_downscale_custom_size = 128;
char root_prim_path[1024] = ""; /* FILE_MAX */
char collection[MAX_IDPROP_NAME] = "";
char custom_properties_namespace[MAX_IDPROP_NAME] = "";
eUSDSceneUnits convert_scene_units = eUSDSceneUnits::USD_SCENE_UNITS_METERS;
float custom_meters_per_unit = 1.0f;
/** Communication structure between the wmJob management code and the worker code. Currently used
* to generate safely reports from the worker thread. */
wmJobWorkerStatus *worker_status = nullptr;
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
};
struct USDImportParams {
char *prim_path_mask;
float scale;
float light_intensity_scale;
bool apply_unit_conversion_scale;
char mesh_read_flag;
bool set_frame_range;
bool is_sequence;
int sequence_len;
int offset;
bool import_defined_only;
bool import_visible_only;
bool import_cameras;
bool import_curves;
bool import_lights;
bool import_materials;
bool import_all_materials;
bool import_meshes;
bool import_points;
bool import_subdiv;
bool import_volumes;
bool import_shapes;
bool import_skeletons;
bool import_blendshapes;
bool create_collection;
bool create_world_material;
bool support_scene_instancing;
bool import_guide;
bool import_proxy;
bool import_render;
bool import_usd_preview;
bool set_material_blend;
bool validate_meshes;
bool merge_parent_xform;
USD: Provide Import option for Material Purpose USD has the concept of material "purposes" which allows different materials to be associated for a prim and gives special meaning to them. These are somewhat similar to display purposes, which we already allow to be chosen, but are distinct concepts. This PR adds an option for Import allowing the user to chose which material purpose to load. Blender currently attempts to load purposes automatically. It starts with "allPurpose" and then moves to "preview" and "full" in that order. This behavior is now changed and the automated search is removed to instead give the user control which purpose to load. Additionally, USD already has its own fallback behavior during material resolution[1]: - When given "full" it will first check "full" and fallback to "allPurpose" if not found. An additional, Blender-specific fallback to "preview" is also implemented here upon request. - When given "preview" it will first check "preview" and fallback to "allPurpose" if not found - When given "allPurpose", it will only check "allPurpose" I have opt'd to keep this behavior directly as-is to not introduce differences that may surprise those already familiar with USD elsewhere. Additionally, I've set Blender's default import purpose to "full" to ensure we're loading in the highest quality assets first. Though this has the obvious risk that "full" assets tend to be quite heavy. We can change to "preview" if this proves too problematic later. This does not change how Blender exports materials. Blender always uses the "allPurpose" binding when writing its USD files. -------- [1] USD docs: https://openusd.org/release/api/class_usd_shade_material_binding_a_p_i.html#details https://openusd.org/release/api/class_usd_shade_material_binding_a_p_i.html#UsdShadeMaterialBindingAPI_MaterialResolution Pull Request: https://projects.blender.org/blender/blender/pulls/128206
2024-10-03 20:16:27 +02:00
eUSDMtlPurpose mtl_purpose;
eUSDMtlNameCollisionMode mtl_name_collision_mode;
eUSDTexImportMode import_textures_mode;
char import_textures_dir[768]; /* FILE_MAXDIR */
eUSDTexNameCollisionMode tex_name_collision_mode;
USD: Import and export custom properties Adding support for converting between Blender custom properties and USD user-defined custom attributes. Custom attributes on Xforms, many data types, and materials are all supported for round-tripping. Please see the USD attributes documentation for more information on custom attributes. Properties are exported with a userProperties: namespace for simple filtering in external apps. This namespace is stripped on import, but other namespace are allowed to persist. An "Import Attributes" parameter has been added with options "None" (do not import attributes), "User" (import attributes in the 'userProperties' namespace only), "All custom" (import all USD custom attributes, the default). An "Export Custom Properties" export option has been added. The property conversion code handles float, double, string and bool types, as well as tuples of size 2, 3 and 4. Note that USD quaternions and arrays of arbitrary length are not yet supported. There is currently no attempt to set the Blender property subtype based on the USD type "role" (e.g., specifying Color or XYZ vector subtypes). This can be addressed in future work. In addition to exporting custom properties, the original Blender object and data names are now saved as USD custom string attributes "userProperties:blender:object_name" and "userProperties:blender:data_name", respectively, on the corresponding USD prims. This feature is enabled with the "Author Blender Name" export option. If a Blender custom string property is named "displayName", it's handled in a special way on export in that its value is used to set the USD prim's "displayName" metadata. Co-authored-by: kiki <charles@skeletalstudios.com> Co-authored-by: Michael Kowalski <makowalski@nvidia.com> Co-authored-by: Charles Wardlaw <kattkieru@users.noreply.github.com> Pull Request: https://projects.blender.org/blender/blender/pulls/118938
2024-04-23 19:27:40 +02:00
eUSDAttrImportMode attr_import_mode;
/**
* Communication structure between the wmJob management code and the worker code. Currently used
* to generate safely reports from the worker thread.
*/
wmJobWorkerStatus *worker_status;
};
/**
* This struct is in place to store the mesh sequence parameters needed when reading a data from a
* USD file for the mesh sequence cache.
*/
struct USDMeshReadParams {
double motion_sample_time; /* USD TimeCode in frames. */
int read_flags; /* MOD_MESHSEQ_xxx value that is set from MeshSeqCacheModifierData.read_flag. */
};
USDMeshReadParams create_mesh_read_params(double motion_sample_time, int read_flags);
/**
* The USD_export takes a `as_background_job` parameter, and returns a boolean.
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
*
* When `as_background_job=true`, returns false immediately after scheduling
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
* a background job.
*
* When `as_background_job=false`, performs the export synchronously, and returns
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
* true when the export was ok, and false if there were any errors.
*/
bool USD_export(const bContext *C,
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
const char *filepath,
const USDExportParams *params,
bool as_background_job,
ReportList *reports);
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
bool USD_import(const bContext *C,
const char *filepath,
const USDImportParams *params,
bool as_background_job,
ReportList *reports);
int USD_get_version();
/* USD Import and Mesh Cache interface. */
/* Similar to BLI_path_abs(), but also invokes the USD asset resolver
* to determine the absolute path. This is necessary for resolving
* paths with URIs that BLI_path_abs() would otherwise alter when
* attempting to normalize the path. */
void USD_path_abs(char *path, const char *basepath, bool for_import);
CacheArchiveHandle *USD_create_handle(Main *bmain, const char *filepath, ListBase *object_paths);
void USD_free_handle(CacheArchiveHandle *handle);
void USD_get_transform(CacheReader *reader, float r_mat[4][4], float time, float scale);
/** Either modifies current_mesh in-place or constructs a new mesh. */
Alembic/USD: Use GeometrySets to import data This rewrites the Alembic and USD data importers to work with and output GeometrySets instead of Meshes. The main motivation for this change is to be able to import properly point clouds, which are currently imported as Meshes, and curves data, which suffer from a lot of issues due to limitations of legacy curves structures (fixed by the new curves data-block) and are also converted to Meshes. Further, for Curves, it will allow importing arbitrary attributes. This patch was primarily meant for Alembic, but changes to USD import were necessary as they share the same modifier. For Alembic: There should be no behavioral changes for Meshes Curves are imported as the new Curves object type Points are imported as PointClouds For USD: There should be no behavioral changes for Meshes Curves are imported as the new Curves object type Note that the current USD importer does not support loading PointClouds, so this patch does not add support for it. For both Alembic and USD, knots arrays are not read anymore, as the new Curves object does not expose the ability to set them. Improvements can be made in the future if and when example assets are provided. This fixes at least the following: #58704: Animated Alembic curves don't update on render #112308: Curves have offset animations (alembic / USD) #118261: wrong motion blur from usd in cycles and reverting to the first frame when disabeling motion blur Co-authored-by: Jesse Yurkovich <jesse.y@gmail.com> Pull Request: https://projects.blender.org/blender/blender/pulls/115623
2024-02-28 03:02:38 +01:00
void USD_read_geometry(CacheReader *reader,
const Object *ob,
Alembic/USD: Use GeometrySets to import data This rewrites the Alembic and USD data importers to work with and output GeometrySets instead of Meshes. The main motivation for this change is to be able to import properly point clouds, which are currently imported as Meshes, and curves data, which suffer from a lot of issues due to limitations of legacy curves structures (fixed by the new curves data-block) and are also converted to Meshes. Further, for Curves, it will allow importing arbitrary attributes. This patch was primarily meant for Alembic, but changes to USD import were necessary as they share the same modifier. For Alembic: There should be no behavioral changes for Meshes Curves are imported as the new Curves object type Points are imported as PointClouds For USD: There should be no behavioral changes for Meshes Curves are imported as the new Curves object type Note that the current USD importer does not support loading PointClouds, so this patch does not add support for it. For both Alembic and USD, knots arrays are not read anymore, as the new Curves object does not expose the ability to set them. Improvements can be made in the future if and when example assets are provided. This fixes at least the following: #58704: Animated Alembic curves don't update on render #112308: Curves have offset animations (alembic / USD) #118261: wrong motion blur from usd in cycles and reverting to the first frame when disabeling motion blur Co-authored-by: Jesse Yurkovich <jesse.y@gmail.com> Pull Request: https://projects.blender.org/blender/blender/pulls/115623
2024-02-28 03:02:38 +01:00
blender::bke::GeometrySet &geometry_set,
USDMeshReadParams params,
const char **r_err_str);
bool USD_mesh_topology_changed(CacheReader *reader,
const Object *ob,
const Mesh *existing_mesh,
double time,
const char **r_err_str);
CacheReader *CacheReader_open_usd_object(CacheArchiveHandle *handle,
CacheReader *reader,
Object *object,
const char *object_path);
void USD_CacheReader_free(CacheReader *reader);
/** Data for registering USD IO hooks. */
struct USDHook {
/* Identifier used for class name. */
char idname[64];
/* Identifier used as label. */
char name[64];
/* Short help/description. */
char description[1024]; /* #RNA_DYN_DESCR_MAX */
/* rna_ext.data points to the USDHook class PyObject. */
ExtensionRNA rna_ext;
};
void USD_register_hook(std::unique_ptr<USDHook> hook);
/**
* Remove the given entry from the list of registered hooks and
* free the allocated memory for the hook instance.
*/
void USD_unregister_hook(USDHook *hook);
USDHook *USD_find_hook_name(const char idname[]);
double get_meters_per_unit(const USDExportParams &params);
}; // namespace blender::io::usd