This repository has been archived on 2023-10-09. You can view files and clone it, but cannot push or open issues or pull requests.
Files
blender-archive/source/blender/io/common/IO_abstract_hierarchy_iterator.h

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

354 lines
16 KiB
C++
Raw Normal View History

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
/*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version 2
* of the License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software Foundation,
* Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
*
* The Original Code is Copyright (C) 2019 Blender Foundation.
* All rights reserved.
*/
/*
* This file contains the AbstractHierarchyIterator. It is intended for exporters for file
* formats that concern an entire hierarchy of objects (rather than, for example, an OBJ file that
* contains only a single mesh). Examples are Universal Scene Description (USD) and Alembic.
* AbstractHierarchyIterator is intended to be subclassed to support concrete file formats.
*
* The AbstractHierarchyIterator makes a distinction between the actual object hierarchy and the
* export hierarchy. The former is the parent/child structure in Blender, which can have multiple
* parent-like objects. For example, a duplicated object can have both a duplicator and a parent,
* both determining the final transform. The export hierarchy is the hierarchy as written to the
* file, and every object has only one export-parent.
*
* Currently the AbstractHierarchyIterator does not make any decisions about *what* to export.
* Selections like "selected only" or "no hair systems" are left to concrete subclasses.
*/
#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
IO: Fix bug exporting dupli parent/child relations Exporting a scene to USD or Alembic would fail when there are multiple duplicates of parent & child objects, duplicated by the same object. For example, this happens when such a hierarchy of objects is contained in a collection, and that collection is instanced multiple times by mesh vertices. The problem here is that the 'parent' pointer of each duplicated object points to the real parent; Blender would not figure out properly which duplicated parent should be used. This is now resolved by keeping track of the persistent ID of each duplicated instance, which makes it possible to reconstruct the parent-child relations of duplicated objects. This does use up some memory for each dupli, so it could be heavy to export a Spring scene (with all the pebbles and leaves), but it's only a small addition on top of the USD/Alembic writer objects that have to be created anyway. At least with this patch, they're created correctly. Code-wise, the following changes are made: - The export graph (that maps export parent to its export children) used to have as its key (Object, Duplicator). This is insufficient to correctly distinguish between multiple duplis of the same object by the same duplicator, so this is now extended to (Object, Duplicator, Persistent ID). To make this possible, new classes `ObjectIdentifier` and `PersistentID` are introduced. - Finding the parent of a duplicated object is done via its persistent ID. In Python notation, the code first tries to find the parent instance where `child_persistent_id[1:] == parent_persistent_id[1:]`. If that fails, the dupli with persistent ID `child_persistent_id[1:]` is used as parent. Reviewed By: sergey Differential Revision: https://developer.blender.org/D8233
2020-07-07 12:45:30 +02:00
#include "IO_dupli_persistent_id.hh"
#include "DEG_depsgraph.h"
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 <map>
#include <set>
#include <string>
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 Depsgraph;
struct DupliObject;
struct ID;
struct Object;
struct ParticleSystem;
namespace blender::io {
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
class AbstractHierarchyWriter;
IO: Fix bug exporting dupli parent/child relations Exporting a scene to USD or Alembic would fail when there are multiple duplicates of parent & child objects, duplicated by the same object. For example, this happens when such a hierarchy of objects is contained in a collection, and that collection is instanced multiple times by mesh vertices. The problem here is that the 'parent' pointer of each duplicated object points to the real parent; Blender would not figure out properly which duplicated parent should be used. This is now resolved by keeping track of the persistent ID of each duplicated instance, which makes it possible to reconstruct the parent-child relations of duplicated objects. This does use up some memory for each dupli, so it could be heavy to export a Spring scene (with all the pebbles and leaves), but it's only a small addition on top of the USD/Alembic writer objects that have to be created anyway. At least with this patch, they're created correctly. Code-wise, the following changes are made: - The export graph (that maps export parent to its export children) used to have as its key (Object, Duplicator). This is insufficient to correctly distinguish between multiple duplis of the same object by the same duplicator, so this is now extended to (Object, Duplicator, Persistent ID). To make this possible, new classes `ObjectIdentifier` and `PersistentID` are introduced. - Finding the parent of a duplicated object is done via its persistent ID. In Python notation, the code first tries to find the parent instance where `child_persistent_id[1:] == parent_persistent_id[1:]`. If that fails, the dupli with persistent ID `child_persistent_id[1:]` is used as parent. Reviewed By: sergey Differential Revision: https://developer.blender.org/D8233
2020-07-07 12:45:30 +02:00
class DupliParentFinder;
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
/* HierarchyContext structs are created by the AbstractHierarchyIterator. Each HierarchyContext
* struct contains everything necessary to export a single object to a file. */
struct HierarchyContext {
/*********** Determined during hierarchy iteration: ***************/
Object *object; /* Evaluated object. */
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
Object *export_parent;
Object *duplicator;
IO: Fix bug exporting dupli parent/child relations Exporting a scene to USD or Alembic would fail when there are multiple duplicates of parent & child objects, duplicated by the same object. For example, this happens when such a hierarchy of objects is contained in a collection, and that collection is instanced multiple times by mesh vertices. The problem here is that the 'parent' pointer of each duplicated object points to the real parent; Blender would not figure out properly which duplicated parent should be used. This is now resolved by keeping track of the persistent ID of each duplicated instance, which makes it possible to reconstruct the parent-child relations of duplicated objects. This does use up some memory for each dupli, so it could be heavy to export a Spring scene (with all the pebbles and leaves), but it's only a small addition on top of the USD/Alembic writer objects that have to be created anyway. At least with this patch, they're created correctly. Code-wise, the following changes are made: - The export graph (that maps export parent to its export children) used to have as its key (Object, Duplicator). This is insufficient to correctly distinguish between multiple duplis of the same object by the same duplicator, so this is now extended to (Object, Duplicator, Persistent ID). To make this possible, new classes `ObjectIdentifier` and `PersistentID` are introduced. - Finding the parent of a duplicated object is done via its persistent ID. In Python notation, the code first tries to find the parent instance where `child_persistent_id[1:] == parent_persistent_id[1:]`. If that fails, the dupli with persistent ID `child_persistent_id[1:]` is used as parent. Reviewed By: sergey Differential Revision: https://developer.blender.org/D8233
2020-07-07 12:45:30 +02:00
PersistentID persistent_id;
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
float matrix_world[4][4];
std::string export_name;
/* When weak_export=true, the object will be exported only as transform, and only if is an
* ancestor of an object with weak_export=false.
*
2020-03-11 21:39:56 +11:00
* In other words: when weak_export=true but this object has no children, or all descendants also
* have weak_export=true, this object (and by recursive reasoning all its descendants) will be
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
* excluded from the export.
*
2020-03-29 16:33:51 +11:00
* The export hierarchy is kept as close to the hierarchy in Blender as possible. As such, an
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
* object that serves as a parent for another object, but which should NOT be exported itself, is
* exported only as transform (i.e. as empty). This happens with objects that are part of a
* holdout collection (which prevents them from being exported) but also parent of an exported
* object. */
bool weak_export;
/* When true, this object should check its parents for animation data when determining whether
* it's animated. This is necessary when a parent object in Blender is not part of the export. */
bool animation_check_include_parent;
/*********** Determined during writer creation: ***************/
float parent_matrix_inv_world[4][4]; /* Inverse of the parent's world matrix. */
std::string export_path; /* Hierarchical path, such as "/grandparent/parent/objectname". */
ParticleSystem *particle_system; /* Only set for particle/hair writers. */
/* Hierarchical path of the object this object is duplicating; only set when this object should
* be stored as a reference to its original. It can happen that the original is not part of the
* exported objects, in which case this string is empty even though 'duplicator' is set. */
std::string original_export_path;
/* Export path of the higher-up exported data. For transforms, this is the export path of the
* parent object. For object data, this is the export path of that object's transform.
*
* From the exported file's point of view, this is the path to the parent in that file. The term
* "parent" is not used here to avoid confusion with Blender's meaning of the word (which always
* refers to a different object). */
std::string higher_up_export_path;
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 operator<(const HierarchyContext &other) const;
/* Return a HierarchyContext representing the root of the export hierarchy. */
static const HierarchyContext *root();
/* For handling instanced collections, instances created by particles, etc. */
bool is_instance() const;
void mark_as_instance_of(const std::string &reference_export_path);
void mark_as_not_instanced();
bool is_object_visible(const enum eEvaluationMode evaluation_mode) const;
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
};
/* Abstract writer for objects. Create concrete subclasses to write to USD, Alembic, etc.
*
* Instantiated by the AbstractHierarchyIterator on the first frame an object exists. Generally
* that's the first frame to be exported, but can be later, for example when objects are
* instantiated by particles. The AbstractHierarchyWriter::write() function is called on every
* frame the object exists in the dependency graph and should be exported.
*/
class AbstractHierarchyWriter {
public:
virtual ~AbstractHierarchyWriter() = default;
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
virtual void write(HierarchyContext &context) = 0;
/* TODO(Sybren): add function like absent() that's called when a writer was previously created,
* but wasn't used while exporting the current frame (for example, a particle-instanced mesh of
* which the particle is no longer alive). */
protected:
/* Return true if the data written by this writer changes over time.
* Note that this function assumes this is an object data writer. Transform writers should not
* call this but implement their own logic. */
virtual bool check_is_animated(const HierarchyContext &context) const;
/* Helper functions for animation checks. */
static bool check_has_physics(const HierarchyContext &context);
static bool check_has_deforming_physics(const HierarchyContext &context);
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
};
/* Determines which subset of the writers actually gets to write. */
struct ExportSubset {
bool transforms : 1;
bool shapes : 1;
};
/* EnsuredWriter represents an AbstractHierarchyWriter* combined with information whether it was
* newly created or not. It's returned by AbstractHierarchyIterator::ensure_writer(). */
class EnsuredWriter {
private:
AbstractHierarchyWriter *writer_;
/* Is set to truth when ensure_writer() did not find existing writer and created a new one.
* Is set to false when writer has been re-used or when allocation of the new one has failed
* (`writer` will be `nullptr` in that case and bool(ensured_writer) will be false). */
bool newly_created_;
EnsuredWriter(AbstractHierarchyWriter *writer, bool newly_created);
public:
EnsuredWriter();
static EnsuredWriter empty();
static EnsuredWriter existing(AbstractHierarchyWriter *writer);
static EnsuredWriter newly_created(AbstractHierarchyWriter *writer);
bool is_newly_created() const;
/* These operators make an EnsuredWriter* act as an AbstractHierarchyWriter* */
operator bool() const;
AbstractHierarchyWriter *operator->();
};
IO: Fix bug exporting dupli parent/child relations Exporting a scene to USD or Alembic would fail when there are multiple duplicates of parent & child objects, duplicated by the same object. For example, this happens when such a hierarchy of objects is contained in a collection, and that collection is instanced multiple times by mesh vertices. The problem here is that the 'parent' pointer of each duplicated object points to the real parent; Blender would not figure out properly which duplicated parent should be used. This is now resolved by keeping track of the persistent ID of each duplicated instance, which makes it possible to reconstruct the parent-child relations of duplicated objects. This does use up some memory for each dupli, so it could be heavy to export a Spring scene (with all the pebbles and leaves), but it's only a small addition on top of the USD/Alembic writer objects that have to be created anyway. At least with this patch, they're created correctly. Code-wise, the following changes are made: - The export graph (that maps export parent to its export children) used to have as its key (Object, Duplicator). This is insufficient to correctly distinguish between multiple duplis of the same object by the same duplicator, so this is now extended to (Object, Duplicator, Persistent ID). To make this possible, new classes `ObjectIdentifier` and `PersistentID` are introduced. - Finding the parent of a duplicated object is done via its persistent ID. In Python notation, the code first tries to find the parent instance where `child_persistent_id[1:] == parent_persistent_id[1:]`. If that fails, the dupli with persistent ID `child_persistent_id[1:]` is used as parent. Reviewed By: sergey Differential Revision: https://developer.blender.org/D8233
2020-07-07 12:45:30 +02:00
/* Unique identifier for a (potentially duplicated) object.
*
* Instances of this class serve as key in the export graph of the
* AbstractHierarchyIterator. */
class ObjectIdentifier {
public:
Object *object;
Object *duplicated_by; /* nullptr for real objects. */
PersistentID persistent_id;
protected:
ObjectIdentifier(Object *object, Object *duplicated_by, const PersistentID &persistent_id);
public:
static ObjectIdentifier for_graph_root();
static ObjectIdentifier for_real_object(Object *object);
static ObjectIdentifier for_hierarchy_context(const HierarchyContext *context);
static ObjectIdentifier for_duplicated_object(const DupliObject *dupli_object,
Object *duplicated_by);
bool is_root() const;
};
bool operator<(const ObjectIdentifier &obj_ident_a, const ObjectIdentifier &obj_ident_b);
bool operator==(const ObjectIdentifier &obj_ident_a, const ObjectIdentifier &obj_ident_b);
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
/* AbstractHierarchyIterator iterates over objects in a dependency graph, and constructs export
* writers. These writers are then called to perform the actual writing to a USD or Alembic file.
*
* Dealing with file- and scene-level data (for example, creating a USD scene, setting the frame
* rate, etc.) is not part of the AbstractHierarchyIterator class structure, and should be done
* in separate code.
*/
class AbstractHierarchyIterator {
public:
/* Mapping from export path to writer. */
typedef std::map<std::string, AbstractHierarchyWriter *> WriterMap;
/* All the children of some object, as per the export hierarchy. */
typedef std::set<HierarchyContext *> ExportChildren;
/* Mapping from an object and its duplicator to the object's export-children. */
IO: Fix bug exporting dupli parent/child relations Exporting a scene to USD or Alembic would fail when there are multiple duplicates of parent & child objects, duplicated by the same object. For example, this happens when such a hierarchy of objects is contained in a collection, and that collection is instanced multiple times by mesh vertices. The problem here is that the 'parent' pointer of each duplicated object points to the real parent; Blender would not figure out properly which duplicated parent should be used. This is now resolved by keeping track of the persistent ID of each duplicated instance, which makes it possible to reconstruct the parent-child relations of duplicated objects. This does use up some memory for each dupli, so it could be heavy to export a Spring scene (with all the pebbles and leaves), but it's only a small addition on top of the USD/Alembic writer objects that have to be created anyway. At least with this patch, they're created correctly. Code-wise, the following changes are made: - The export graph (that maps export parent to its export children) used to have as its key (Object, Duplicator). This is insufficient to correctly distinguish between multiple duplis of the same object by the same duplicator, so this is now extended to (Object, Duplicator, Persistent ID). To make this possible, new classes `ObjectIdentifier` and `PersistentID` are introduced. - Finding the parent of a duplicated object is done via its persistent ID. In Python notation, the code first tries to find the parent instance where `child_persistent_id[1:] == parent_persistent_id[1:]`. If that fails, the dupli with persistent ID `child_persistent_id[1:]` is used as parent. Reviewed By: sergey Differential Revision: https://developer.blender.org/D8233
2020-07-07 12:45:30 +02:00
typedef std::map<ObjectIdentifier, ExportChildren> ExportGraph;
/* Mapping from ID to its export path. This is used for instancing; given an
* instanced datablock, the export path of the original can be looked up. */
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
typedef std::map<ID *, std::string> ExportPathMap;
protected:
ExportGraph export_graph_;
ExportPathMap duplisource_export_path_;
Depsgraph *depsgraph_;
WriterMap writers_;
ExportSubset export_subset_;
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
public:
explicit AbstractHierarchyIterator(Depsgraph *depsgraph);
virtual ~AbstractHierarchyIterator();
/* Iterate over the depsgraph, create writers, and tell the writers to write.
* Main entry point for the AbstractHierarchyIterator, must be called for every to-be-exported
Alembic: new exporter based on the USD exporter structure The Alembic exporter has been restructured by leverages the `AbstractHierarchyIterator` introduced by the USD exporter. The produced Alembic files have not changed much (details below), as the Alembic writing code has simply been moved from the old exporter to the new. How the export hierarchy is handled changed a lot, though, and also the way in which transforms are computed. As a result, T71395 is fixed. Differences between the old and new exporter, in terms of the produced Alembic file: - Duplicated objects now have a unique numerical suffix. - Matrices are computed differently, namely by simply computing the evaluated transform of the object relative to the evaluated transform of its export-parent. This fixes {T71395}, but otherwise should produce the same result as before (but with simpler code). Compared to the old Alembic exporter, Subdivision modifiers are now disabled in a cleaner, more efficient way (they are disabled when exporting with the "Apply Subdivisions" option is unchecked). Previously the exporter would move to a new frame, disable the modifier, evaluate the object, and enable the modifier again. This is now done before exporting starts, and modifiers are only restored when exporting ends. Some issues with the old Alembic exporter that have NOT been fixed in this patch: - Exporting NURBS patches and curves (see T49114 for example). - Exporting flattened hierarchy in combination with dupli-objects. This seems to be broken in the old Alembic exporter as well, but nobody reported this yet. Differential Revision: https://developer.blender.org/D7664 Reviewed By: Sergey
2020-06-19 16:36:10 +02:00
* (sub)frame. */
virtual void iterate_and_write();
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
/* Release all writers. Call after all frames have been exported. */
void release_writers();
/* Determine which subset of writers is used for exporting.
* Set this before calling iterate_and_write().
*
* Note that writers are created for each iterated object, regardless of this option. When a
* writer is created it will also write the current iteration, to ensure the hierarchy is
* complete. The `export_subset` option is only in effect when the writer already existed from a
* previous iteration. */
void set_export_subset(ExportSubset export_subset_);
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
/* Convert the given name to something that is valid for the exported file format.
* This base implementation is a no-op; override in a concrete subclass. */
virtual std::string make_valid_name(const std::string &name) const;
/* Return the name of this ID datablock that is valid for the exported file format. Overriding is
* only necessary if make_valid_name(id->name+2) is not suitable for the exported file format.
* NULL-safe: when `id == nullptr` this returns an empty string. */
virtual std::string get_id_name(const ID *id) const;
/* Given a HierarchyContext of some Object *, return an export path that is valid for its
* object->data. Overriding is necessary when the exported format does NOT expect the object's
* data to be a child of the object. */
virtual std::string get_object_data_path(const HierarchyContext *context) const;
private:
void debug_print_export_graph(const ExportGraph &graph) const;
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
void export_graph_construct();
void connect_loose_objects();
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
void export_graph_prune();
void export_graph_clear();
void visit_object(Object *object, Object *export_parent, bool weak_export);
void visit_dupli_object(DupliObject *dupli_object,
Object *duplicator,
IO: Fix bug exporting dupli parent/child relations Exporting a scene to USD or Alembic would fail when there are multiple duplicates of parent & child objects, duplicated by the same object. For example, this happens when such a hierarchy of objects is contained in a collection, and that collection is instanced multiple times by mesh vertices. The problem here is that the 'parent' pointer of each duplicated object points to the real parent; Blender would not figure out properly which duplicated parent should be used. This is now resolved by keeping track of the persistent ID of each duplicated instance, which makes it possible to reconstruct the parent-child relations of duplicated objects. This does use up some memory for each dupli, so it could be heavy to export a Spring scene (with all the pebbles and leaves), but it's only a small addition on top of the USD/Alembic writer objects that have to be created anyway. At least with this patch, they're created correctly. Code-wise, the following changes are made: - The export graph (that maps export parent to its export children) used to have as its key (Object, Duplicator). This is insufficient to correctly distinguish between multiple duplis of the same object by the same duplicator, so this is now extended to (Object, Duplicator, Persistent ID). To make this possible, new classes `ObjectIdentifier` and `PersistentID` are introduced. - Finding the parent of a duplicated object is done via its persistent ID. In Python notation, the code first tries to find the parent instance where `child_persistent_id[1:] == parent_persistent_id[1:]`. If that fails, the dupli with persistent ID `child_persistent_id[1:]` is used as parent. Reviewed By: sergey Differential Revision: https://developer.blender.org/D8233
2020-07-07 12:45:30 +02:00
const DupliParentFinder &dupli_parent_finder);
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
void context_update_for_graph_index(HierarchyContext *context,
const ExportGraph::key_type &graph_index) const;
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
void determine_export_paths(const HierarchyContext *parent_context);
void determine_duplication_references(const HierarchyContext *parent_context,
std::string indent);
/* These three functions create writers and call their write() method. */
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
void make_writers(const HierarchyContext *parent_context);
void make_writer_object_data(const HierarchyContext *context);
void make_writers_particle_systems(const HierarchyContext *context);
/* Return the appropriate HierarchyContext for the data of the object represented by
* object_context. */
HierarchyContext context_for_object_data(const HierarchyContext *object_context) const;
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
/* Convenience wrappers around get_id_name(). */
std::string get_object_name(const Object *object) const;
std::string get_object_data_name(const Object *object) const;
typedef AbstractHierarchyWriter *(AbstractHierarchyIterator::*create_writer_func)(
const HierarchyContext *);
/* Ensure that a writer exists; if it doesn't, call create_func(context).
*
* The create_func function should be one of the create_XXXX_writer(context) functions declared
* below. */
EnsuredWriter ensure_writer(HierarchyContext *context, create_writer_func create_func);
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
protected:
/* Construct a valid path for the export file format. This class concatenates by using '/' as a
* path separator, which is valid for both Alembic and USD. */
virtual std::string path_concatenate(const std::string &parent_path,
const std::string &child_path) const;
/* Return whether this object should be marked as 'weak export' or not.
*
* When this returns false, writers for the transform and data are created,
* and dupli-objects dupli-object generated from this object will be passed to
* should_visit_dupli_object().
*
* When this returns true, only a transform writer is created and marked as
* 'weak export'. In this case, the transform writer will be removed before
2020-03-11 21:39:56 +11:00
* exporting starts, unless a descendant of this object is to be exported.
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
* Dupli-object generated from this object will also be skipped.
*
* See HierarchyContext::weak_export.
*/
virtual bool mark_as_weak_export(const Object *object) const;
virtual bool should_visit_dupli_object(const DupliObject *dupli_object) const;
virtual ExportGraph::key_type determine_graph_index_object(const HierarchyContext *context);
IO: Fix bug exporting dupli parent/child relations Exporting a scene to USD or Alembic would fail when there are multiple duplicates of parent & child objects, duplicated by the same object. For example, this happens when such a hierarchy of objects is contained in a collection, and that collection is instanced multiple times by mesh vertices. The problem here is that the 'parent' pointer of each duplicated object points to the real parent; Blender would not figure out properly which duplicated parent should be used. This is now resolved by keeping track of the persistent ID of each duplicated instance, which makes it possible to reconstruct the parent-child relations of duplicated objects. This does use up some memory for each dupli, so it could be heavy to export a Spring scene (with all the pebbles and leaves), but it's only a small addition on top of the USD/Alembic writer objects that have to be created anyway. At least with this patch, they're created correctly. Code-wise, the following changes are made: - The export graph (that maps export parent to its export children) used to have as its key (Object, Duplicator). This is insufficient to correctly distinguish between multiple duplis of the same object by the same duplicator, so this is now extended to (Object, Duplicator, Persistent ID). To make this possible, new classes `ObjectIdentifier` and `PersistentID` are introduced. - Finding the parent of a duplicated object is done via its persistent ID. In Python notation, the code first tries to find the parent instance where `child_persistent_id[1:] == parent_persistent_id[1:]`. If that fails, the dupli with persistent ID `child_persistent_id[1:]` is used as parent. Reviewed By: sergey Differential Revision: https://developer.blender.org/D8233
2020-07-07 12:45:30 +02:00
virtual ExportGraph::key_type determine_graph_index_dupli(
const HierarchyContext *context,
const DupliObject *dupli_object,
const DupliParentFinder &dupli_parent_finder);
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
/* These functions should create an AbstractHierarchyWriter subclass instance, or return
* nullptr if the object or its data should not be exported. Returning a nullptr for
* data/hair/particle will NOT prevent the transform to be written.
*
* The returned writer is owned by the AbstractHierarchyWriter, and should be freed in
* delete_object_writer().
*
* The created AbstractHierarchyWriter instances should NOT keep a copy of the context pointer.
* The context can be stack-allocated and go out of scope. */
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
virtual AbstractHierarchyWriter *create_transform_writer(const HierarchyContext *context) = 0;
virtual AbstractHierarchyWriter *create_data_writer(const HierarchyContext *context) = 0;
virtual AbstractHierarchyWriter *create_hair_writer(const HierarchyContext *context) = 0;
virtual AbstractHierarchyWriter *create_particle_writer(const HierarchyContext *context) = 0;
/* Called by release_writers() to free what the create_XXX_writer() functions allocated. */
virtual void release_writer(AbstractHierarchyWriter *writer) = 0;
AbstractHierarchyWriter *get_writer(const std::string &export_path) const;
ExportChildren &graph_children(const HierarchyContext *parent_context);
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
};
} // namespace blender::io