-
Subtler Aspects of Scene Description and Composition场景描写和构图的微妙方面
General Questions 一般问题
What is USD and why should I use it?
什么是美元，我为什么要使用它？
USD stands for “Universal Scene Description.” It is a system for encoding scalable, hierarchically organized, static and time-sampled data, for the primary purpose of interchanging and augmenting the data between cooperating digital content creation applications. USD also provides a rich set of composition operators, including asset and file references and variants, that let consumers aggregate multiple assets into a single scenegraph while still allowing for sparse overrides.
USD代表“通用场景描述”。它是一种用于对可缩放的、分层组织的、静态的和时间采样的数据进行编码的系统，其主要目的是在协作的数字内容创建应用之间交换和扩充数据。USD还提供了一组丰富的组合操作符，包括资产和文件引用和变体，允许消费者将多个资产聚合到单个场景图中，同时仍然允许稀疏覆盖。
See the Overview and Purpose section of the USD documentation for a more detailed discussion of what USD is (and isn’t).
请参阅USD文档的概述和用途部分，以获得关于什么是（和不是）USD的更详细讨论。
What programming languages are supported?
支持哪些编程语言？
USD consists of a set of C++ libraries with Python bindings for scripting.
USD由一组C++库和Python脚本绑定组成。
Isn’t USD just another file format?
美元不就是另一种文件格式吗？
No. While USD does provide interchange services (more below), its primary function is to compose together scene description spread across many files (or other data sources) in many different formats (extensible via user plugins) to present a single hierarchical scenegraph view of the data. This high-performance scenegraph helps USD stand on its own as a platform for live, collaborative scene construction.
不可以。虽然USD确实提供了交换服务（下文将详细介绍），但其主要功能是将分布在许多文件（或其他数据源）中的场景描述以许多不同格式（可通过用户插件扩展）组合在一起，以呈现数据的单个分层场景图视图。这种高性能的场景图帮助USD独立成为一个实时、协作场景构建的平台。
Well-known file formats for interchange in the VFX industry like OBJ, FBX, and Alembic primarily deal with interchanging flat/cached geometry, with no facility for assembling assets or editing the data directly. USD does serve the role of an “interchange file format,” more comprehensively than previous public efforts, because it already interchanges not only geometry, but also shading/materials, lights, rendering, linear-blend skinning and blend-shape animation, rigid body physics, and is extensible along numerous axes.
VFX行业中用于交换的众所周知的文件格式，如OBJ，FBX和Alembic，主要处理交换平面/缓存几何体，没有用于组装资产或直接编辑数据的设施。USD确实充当了“交换文件格式”的角色，比以前的公共努力更全面，因为它不仅可以交换几何，还可以交换着色/材质、灯光、渲染、线性混合蒙皮和混合形状动画、刚体物理，并且可以沿着许多轴扩展。
But USD possesses key features that distinguish it from interchange file formats: its composition engine and high-performance scenegraph. USD’s native file formats encode Composition Arcs that weave small (or large) scene components into assemblies, environments, and complete scenes, wherein each “elemental” asset can be efficiently shared between instances and scenes, and retain its integrity thanks to USD’s many non-destructive editing features. USD’s many plugin points, including customizable asset-resolution behavior, the ability to add new data schemas and associated imaging behaviors, and the ability to teach USD how to read other file formats, provide great power in adapting USD into existing pipelines and infrastructure.
但是USD具有将其与交换文件格式区分开来的关键特征：其合成引擎和高性能场景图。USD的原生文件格式对Composition Arcs进行编码，将小型（或大型）场景组件编织成集合，环境和完整的场景，其中每个“元素”资产可以在实例和场景之间高效共享，并由于USD的许多非破坏性编辑功能而保持其完整性。USD的许多插件点，包括可定制的资产解析行为，添加新数据模式和相关映像行为的能力，以及教USD如何读取其他文件格式的能力，为将USD适应现有管道和基础设施提供了强大的功能。
Pixar continues to focus on the scalability and performance of USD’s live scenegraph, which presents the “composed view” of all the references, layerings, variations, and other arcs encoded in the scene’s assets. But in addition to providing efficient, on-demand access to all data contained in the scene, the scenegraph is also interactive, allowing both destructive and non-destructive scene editing, with features designed to foster multi-user collaboration. These features, in combination with the modern Hydra rendering architecture that sits on top of USD’s scenegraph and is included in the USD distribution, have attracted a growing number of software vendors to use USD in its “live” capacity as an integral part of the user-experience, rather than simply as an interchange.
Pixar继续专注于USD的实时场景图的可扩展性和性能，它呈现了所有引用，分层，变化和场景资产中编码的其他弧线的“合成视图”。但是，除了提供对场景中包含的所有数据的高效、按需访问外，scenegraph还具有交互性，允许破坏性和非破坏性场景编辑，并具有旨在促进多用户协作的功能。这些功能，结合现代Hydra渲染架构，它位于USD的scenegraph之上，并包含在USD发行版中，吸引了越来越多的软件供应商将USD作为用户体验的一个组成部分，而不仅仅是作为交换。
So what file formats does USD support?
那么USD支持哪些文件格式呢？
Out of the box, USD the following three file formats:
开箱即用，USD支持以下三种文件格式：
Extension 延伸
Content 内容
.usda
Human-readable UTF-8 text
人类可读的UTF-8文本.usdc
Random-access “Crate” binary
随机存取“Crate”二进制.usd
Either of the above 以上任一项
It also includes plugins that provide support for reading and writing Alembic files, and for reading MaterialX files. Developers can extend USD to read and write from other file formats by writing a plugin that will translate the data in that format to the USD scenegraph.
它还包括一些插件，这些插件支持阅读和写入Alembic文件以及读取MaterialX文件。开发人员可以通过编写一个插件来扩展USD，以便从其他文件格式读取和写入数据，该插件将该格式的数据转换为USD scenegraph。
What file format is my .usd file?
什么文件格式是我的.usd文件？
As shown in the table above, USD files created with the plain .usd extension, can be either binary-backed Crate files, or text files. This can be advantageous in certain scenarios; for example, if one has USD files which contain references to plain .usd assets, those assets can be converted between binary and text without changing the sources which refer to them.
如上表所示，使用纯.usd扩展名创建的USD文件可以是二进制支持的Crate文件或文本文件。这在某些情况下可能是有利的;例如，如果一个人有USD文件，其中包含对普通.usd资产的引用，则这些资产可以在二进制和文本之间转换，而无需更改引用它们的源。
What character encoding does .usda support?
.usda支持哪些字符编码？
The .usda file format encodes text as UTF-8.
.usda文件格式将文本编码为UTF-8。
How can I convert USD files between binary and text?
如何在二进制和文本之间转换USD文件？
usdcat can be used to convert files between file formats. With plain, .usd files, you can change them using the --usdFormat option.
usdcat可用于在文件格式之间转换文件。对于普通的.usd文件，您可以使用选项更改它们。
Note 注记
Although you can specify --usdFormat usdc, it is not necessary, since the --out file.usd argument will, by default choose the usdc format.
虽然您可以指定，但这不是必需的，因为参数将默认选择usdc格式。
$ usdcat file.usd --out file.usd --usdFormat usda
Alternatively, one can convert files using the explicit file extensions, such as usda and usdc, directly.
或者，可以直接使用显式文件扩展名（如usda和usdc）转换文件。
$ usdcat file.usd --out file.usdc
For more information on USD file formats, see Converting Between Layer Formats.
有关USD文件格式的详细信息，请参见在图层格式之间转换。
What data types are supported?
支持哪些数据类型？
See the Basic Datatypes for Scene Description section of the USD documentation for a complete list of supported data types. USD does not support the addition of new basic datatypes via plugin.
有关支持的数据类型的完整列表，请参见USD文档的场景描述的基本数据类型部分。USD不支持通过插件添加新的基本数据类型。
What does a USD file look like?
什么是USD文件看起来像？
Here’s an example using references, inheritance, and variants. This is the representation generated by the native text file format, whose extension is .usda.
下面是一个使用引用、继承和变体的示例。这是由本机文本文件格式生成的表示，其扩展名为. usda。
#usda 1.0
class "_class_Planet"
{
bool has_life = False
}
def Xform "SolarSystem"
{
def "Earth" (
references = @./planet.usda@</Planet>
)
{
bool has_life = True
string color = "blue"
}
def "Mars" (
references = @./planet.usda@</Planet>
)
{
string color = "red"
}
def "Saturn" (
references = @./planet.usda@</Planet>
variants = {
string rings = "with_rings"
}
)
{
string color = "beige"
}
}
#usda 1.0
class "_class_Planet"
{
}
def Sphere "Planet" (
inherits = </_class_Planet>
kind = "model"
variantSets = "rings"
variants = {
string rings = "none"
}
)
{
variantSet "rings" = {
"none" {
bool has_rings = False
}
"with_rings" {
bool has_rings = True
}
}
}
This example is purely illustrative. It does not make use of all of the composition operators that USD provides and should not necessarily be taken as a model for how assets should be structured. Different users have different needs; USD simply provides the data encoding and composition operators and lets users decide how best to construct their assets.
该示例纯粹是说明性的。它没有使用USD提供的所有组合操作符，也不一定要作为资产结构化的模型。不同的用户有不同的需求; USD只提供数据编码和组合操作符，让用户决定如何最好地构建他们的资产。
The USD Tutorials page contains more examples as well as demonstrations of how to construct those examples using the provided APIs.
USD教程页面包含更多示例以及如何使用提供的API构建这些示例的演示。
Subtler Aspects of Scene Description and Composition
场景描述和构图的微妙方面
I have some layers I want to combine: Should I use SubLayers or References?
我有一些我想要联合收割机的图层：我应该使用子层还是引用？
If you have two or more layers that you want to combine so that they override in a particular order, you have two simple options, SubLayers and References. Which one you should choose depends on both the contents of the layers and what you will need to do with the resulting composition.
如果要联合收割机两个或更多图层，以便它们以特定顺序替代，则有两个简单的选项：“子图层”和“参照”。选择哪一个取决于图层的内容以及您需要对生成的合成执行的操作。
If it satisfies your requirements, prefer sublayering over referencing.
如果它满足您的要求，那么与引用相比，更喜欢子层。
Sublayering has the following advantages:
子分层具有以下优点：
Sublayering is the simplest Composition Arc and results in the most compact runtime data structures and efficient Value Resolution.
子层是最简单的组合弧，并导致最紧凑的运行时数据结构和有效的值解析。Layers combined via sublayering can easily participate in UsdStage Layer Muting.
通过子层组合的层可以轻松参与UsdStage层静音。Choosing layers to edit via Edit Targets is most straightforward for layers combined via sublayering.
对于通过子层组合的层，通过“编辑目标”选择要编辑的层最为简单。
What requirements might make SubLayering inappropriate?
哪些要求可能会使SubLayering不合适？
If the layers you need to combine to do not share the same namespace, sublayering will simply “overlay” the different namespaces without any possibility of renaming parts of the namespace. By contrast, references allow you to remap specific prims into a different namespace. For example, the prim /Bob in the file Bob.usd can be renamed to /Bob_1 as it is referenced onto the prim /Characters/Bob_1 in the file lineup.usd.
如果需要联合收割机的层不共享相同的名称空间，则子层将简单地“覆盖”不同的名称空间，而不可能重命名名称空间的部分。相比之下，引用允许您将特定的prim重新映射到不同的名称空间。例如，文件Bob.usd中的prim /Bob可以重命名为/Bob_1，因为它被引用到文件lineup. usd中的prim /Characters/Bob_1上。Related to the first point, if one or more of your layers contains root prims that you do not want “exposed” in the resulting composition, references provide a means of doing so: because each time you add a reference you target a specific prim within a layer, you may pick out just the prims you want/need in the composed result. You can add as many references (even on the same prim) as you require, targeting different prims in the same layer - even targeting prims in the same layer in which you are adding the reference.
与第一点相关的是，如果一个或多个层包含不希望在合成结果中“暴露”的根素数，则引用提供了一种方法：因为每次你添加一个引用时，你都是以一个层中的一个特定的prim为目标，你可以在合成的结果中只挑选出你想要/需要的prim。您可以根据需要添加任意多个引用（甚至在同一prim上），以同一层中的不同prim为目标-甚至以添加引用的同一层中的prim为目标。If you want to add VariantSets that override the result of your composition, you will need to reference your results together rather than sublayer them - or add another layer into the mix so that you can reference in the root layer of your sublayer stack. This is because the data in the layers that you SubLayer form the L in LIVRPS Strength Ordering, whereas opinions from VariantSets form the V, so anything defined in VariantSets will be weaker than the data in your sublayers. By extension, if you want to compose several layers into the existing file root.usd, if you sublayer them into root.usd, the direct opinions they contain will be stronger than any Inherits or VariantSet opinions in root.usd, whereas if you reference them in, their opinions will be weaker than any Inherits or VariantSets.
如果要添加覆盖合成结果的VariantSet，则需要一起引用结果而不是子层-或者在混合中添加另一个层，以便可以在子层堆栈的根层中引用。这是因为SubLayer中的层中的数据形成LIVRPS强度排序中的L，而VariantSets的意见形成V，因此VariantSets中定义的任何内容都将弱于子层中的数据。通过扩展，如果您想将多个层组合到现有文件root. usd中，如果您将它们子层到root.usd中，则它们包含的直接意见将比root.usd中的任何Inherits或VariantSet意见更强，而如果您在中引用它们，则它们的意见将比任何Inherits或VariantSet弱。
What happens to “overs” when their underlying prim is moved to a different location in the scenegraph?
当它们的底层prim被移动到场景图中的不同位置时，“over”会发生什么？
USD allows sparse overrides on assets that are brought in to the scenegraph via one of the various composition operators. These overrides are referred to as “overs.” For instance, consider the following example involving sublayers:
USD允许对通过各种合成操作符之一引入场景图的资源进行稀疏覆盖。这些覆盖被称为“覆盖”。例如，考虑以下涉及子层的示例：
#usda 1.0
def Xform "World"
{
def Xform "Sets"
{
def Xform "Bookshelf"
{
def Xform "Book_1"
{
string name = "Toy Story"
}
}
def Xform "Desk"
{
}
}
}
In this example, the book defined in sequence.usda has the title “Toy Story”. However, this layer is brought in to shot.usda via a sublayer statement, and the book’s title is overridden to “Wall-E.” The question is: what happens if a user independently working on sequence.usda moves Book_1 to Desk, or if Book_1 is renamed to Video_1? In such a case, the “over” in shot.usda would be “orphaned” and be ignored when composing and evaluating /World/Sets/Desk/Book_1 in shot.usda. It is the responsibility of the user working on sequence.usda to ensure that shot.usda is updated to avoid this problem.
在本例中，sequence.usda中定义的书的标题为“Toy Story”。但是，这个层是通过子层语句引入shot.usda的，并且书名被覆盖为“Wall-E”问题是：如果一个独立使用sequence.usda的用户将Book_1移动到Desk，或者将Book_1重命名为Video_1，会发生什么？在这种情况下，shot.usda中的“over”将被“孤立”，并在合成和评估shot. usda中的/World/Sets/Desk/Book_1时被忽略。使用sequence.usda的用户有责任确保更新shot.usda以避免此问题。
When can you delete a reference (or other deletable thing)?
什么时候可以删除引用（或其他可删除的东西）？
USD allows several kinds of data (including composition arcs) to be list-edited, i.e. prepending, appending, and deleting elements in a strong layer from a list that has been built up in weaker layers. In addition to all composition arcs except SubLayers, you can also list-edit Relationships, Attribute Connections, and custom string, token, and int metadata declared in plugInfo.json files. For any datatype that can be list-edited, it is syntactically legal and semantically meaningful to place a delete operator at any site (any path in any layer) on which the data can be hosted. What effect the delete will have depends on the type of the data, and is different for each of three categories of data.
USD允许列表编辑几种类型的数据（包括合成弧），即从已在较弱层中建立的列表中前置、追加和删除强层中的元素。除了SubLayers之外的所有复合弧之外，您还可以列表编辑关系，属性连接以及在plugInfo.json文件中声明的自定义字符串，令牌和int元数据。对于任何可以列表编辑的数据类型，在可以承载数据的任何站点（任何层中的任何路径）放置删除操作符在语法上是法律的的，在语义上是有意义的。删除的效果取决于数据的类型，并且对于三类数据中的每一类都是不同的。
List-edited string, token, and int metadata
列表编辑的字符串、令牌和int元数据
Custom, list-edited metadata is the simplest case. Items can be removed from the list (actually ordered set, since list-editing in USD de-duplicates items added more than once) anywhere in the composition graph.
自定义、列表编辑的元数据是最简单的情况。项目可以从列表中删除（实际上是有序集，因为USD中的列表编辑会删除多次添加的项目）。
List-edited relationships and connections
列表编辑的关系和连接
Similarly to custom, list-edited metadata, relationship and connection targets can be removed (and added!) anywhere in a composition graph. However, because most authoring takes place in the root layerStack of a composed UsdStage, we stipulate that when you delete a relationship or connection target, you specify not the originally authored path, but the translation of the path into the root layerStack. This is because one of the key behaviors USD provides as part of “composing a scene” is making sure that all paths are presented to you in the final namespace of the Stage that you open; See Path Translation for an example that includes deleting a relationship target that was defined “across” two levels of referencing.
与自定义、列表编辑的元数据类似，可以删除（和添加）关系和连接目标！）在组成图中的任何地方。但是，由于大多数创作发生在组合的UsdStage的根layerStack中，因此我们规定，当删除关系或连接目标时，不指定原始创作的路径，而是指定将路径转换到根layerStack中。这是因为USD提供的“组成场景”的关键行为之一是确保所有路径都在您打开的舞台的最终名称空间中呈现;有关包括删除“跨”两个引用级别定义的关系目标的示例，请参见路径转换。
List-edited composition arcs
列表编辑合成弧
Meaningfully deleting composition arcs imposes some restrictions, because of the central aspect of encapsulation in USD composition. Encapsulation means that whenever you use a references, payload, inherits, variantSet, or specializes arc on a prim, the result that gets woven into the composition is immutable by stronger layers - values can be overridden, and objects can be added, but the “internal referencing structure” of the arc’s target cannot be changed. This is important for several reasons:
有意义地删除复合弧会带来一些限制，因为USD复合中的封装是核心方面。封装意味着，无论何时你在prim上使用references、payload、inherits、variantSet或specialized arc，编织到组合中的结果都是不可变的--值可以被覆盖，对象可以被添加，但arc目标的“内部引用结构”不能改变。这一点很重要，原因如下：
It makes the LIVRPS composition algorithm explainable and (more easily) understandable, because it is properly recursive.
它使LIVRPS合成算法可解释和（更容易）理解，因为它是适当的递归。It enables more efficient composition engine implementations, because it allows great sharing of composition (sub)results
它支持更高效的合成引擎实现，因为它允许更好地共享合成（子）结果It preserves strength ordering of the internal referencing structure - we will explain this more below.
它保留了内部引用结构的强度排序-我们将在下面对此进行更多解释。
The rule, therefore, for meaningfully deleting composition arcs, is that you can only remove an arc if it was introduced in the same layerStack, as discussed with an example here. This means you cannot delete a reference that was introduced from across another reference.
因此，有意义地删除复合弧的规则是，您只能删除在同一layerStack中引入的弧，如这里的示例所讨论的。这意味着不能删除从另一个引用引入的引用。
There is a single exception to composition encapsulation in which we do allow a stronger layer to control how composition across an arc behaves, which is variant selections, and we can, with some preparatory work, use them to effectively delete arcs from across other arcs, though doing so may produce undesirable results! The whole point of variantSets in USD is to be able to make a selection, non-destructively, in an overriding layer, that will “pierce composition encapsulation” to guide which variant of a variantSet should be chosen and composed, regardless of how distant (in terms of composition arcs traversed) the actual variant definition(s) may be from the selection.
组合封装有一个例外，我们允许一个更强的层来控制跨弧组合的行为，这是变体选择，我们可以通过一些准备工作，使用它们来有效地删除跨其他弧的弧，尽管这样做可能会产生不希望的结果！USD中的variantSets的全部要点是能够在覆盖层中非破坏性地进行选择，该选择将“刺穿组合封装”以指导应该选择和组合variantSet的哪个变体，而不管实际变体定义可能离选择有多远（就遍历的组合弧而言）。
Therefore, in a context in which we would ordinarily just add a reference, if we instead create a variantSet with a single variant, and add the reference on the variant instead of on the prim itself, then in a stronger referencing context across an arbitrary number of arcs, we can simply add and select another variant to the variantSet, and add a different reference there. Because no such variant exists inside the referenced asset, the original reference will not be processed.
因此，在一个我们通常只添加引用的上下文中，如果我们创建一个具有单个变量的variantSet，并在变量上而不是在prim本身上添加引用，那么在一个跨越任意数量弧的更强引用上下文中，我们可以简单地添加和选择另一个变量到variantSet，并在那里添加一个不同的引用。因为在被引用的资源中不存在这样的变量，所以将不处理原始引用。
While this “works”, it creates a “strength inversion” that will likely be undesirable in most scenarios, and is a key reason why we believe encapsulation to be so valuable. The reference that you are adding in the outer referencing context will now be stronger than the context (and opinions) from which the original reference was introduced, so any overrides that context applied will no longer be overrides - they will instead be “underrides” because they are weaker. If you think of this in terms of building an environment out of referenced component models, you will see the problem with employing this technique at a shot-level in which the environment is referenced in: the environment places each object with transform overrides. But those overrides will now be weaker than the default transformation of the “swapped in” component at the shot level, and so its positioning will need to be redone or recovered manually from the environment layer. This will be true for all overrides the environment makes for each component-to-be-replaced. Following is a (very contrived, for brevity) example of how this technique works and doesn’t work. Given:
虽然这“工作”，但它创建了“强度反转”，这在大多数情况下可能是不希望的，这是我们认为封装如此有价值的关键原因。你在外部引用上下文中添加的引用现在将比引入原始引用的上下文（和观点）更强，因此上下文应用的任何覆盖将不再是覆盖-它们将改为“underrides”，因为它们更弱。如果您从从从引用的组件模型构建环境的角度考虑这一点，您将看到在快照级别使用此技术的问题，在快照级别中引用环境：环境将使用变换替代放置每个对象。但是，这些覆盖现在将比镜头级别的“换入”组件的默认转换弱，因此需要重新完成或从环境层手动恢复其定位。 对于环境为每个要替换的组件所做的所有覆盖，都是如此。下面是一个（为了简洁起见，非常人为的）例子，说明这种技术如何工作和不工作。 鉴于：
#usda 1.0
def Xform "CubeModel"
{
custom int levelOfNesting = 0
def Cube "Gprim"
{
}
}
def Xform "SphereModel"
{
custom int levelOfNesting = 0
def Sphere "Gprim"
{
}
}
then we can construct an assembly that dresses in an instance of one of the models, inside a variantSet:
然后我们可以在variantSet中构造一个程序集，该程序集穿着其中一个模型的实例：
#usda 1.0
(
defaultPrim = "FlexibleSet"
)
def Xform "FlexibleSet"
{
def "Model_1" (
prepend variantSets = "dressingVariant"
variants = {
string dressingVariant = "default"
}
)
{
variantSet "dressingVariant" = {
"default" (
references = @assets.usd@</CubeModel>
)
{
}
}
# Anything added at the set level has nesting level 1
custom int levelOfNesting = 1
}
}
Finally, in a shot, we can replace the assembly’s reference at Model_1 by adding a new variant for dressingVariant and adding a new reference inside the variant:
最后，在一个镜头中，我们可以通过为dressingVariant添加一个新的变量并在变量中添加一个新的引用来替换Model_1处的程序集引用：
#usda 1.0
(
defaultPrim = "World"
)
def Xform "World"
{
def "ShapeFactory" (
references = @assembly.usd@
)
{
over "Model_1" (
prepend variantSets = "dressingVariant"
variants = {
string dressingVariant = "shotOverride_1"
}
)
{
variantSet "dressingVariant" = {
"shotOverride_1" (
references = @assets.usd@</SphereModel>
)
{
}
}
}
}
}
If one were to inspect shot.usd in usdview's Composition inspector, one would find no trace of /CubeModel from assets.usd in the Index for /World/ShapeFactory/Model_1, so we have succesfully replaced it from across a reference. However, on the composed stage, the value of /World/ShapeFactory/Model_1.levelOfNesting has been reset to zero, which is unintuitive and almost certainly undesirable; The value of one is still present in the property’s PropertyStack , but it is now weaker than the value coming from the referenced leaf asset. By toggling the selection for dressingVariant in the Metadata inspector, you can see the value of levelOfNesting bounce between zero and one.
如果在usdview的Composition检查器中检查shot.usd，在/World/ShapeFactory/Model_1的Index中找不到assets.usd中的/CubeModel，因此我们成功地从引用中替换了它。然而，在合成舞台上，/World/ShapeFactory/Model_1.levelOfNesting的值被重置为零，这是不直观的，几乎肯定是不可取的;值1仍然存在于属性的PropertyStack中，但它现在比来自引用的叶资源的值弱。通过在“元数据”检查器中切换dressingVariant的选择，您可以看到levelOfNesting的值在零和一之间跳动。
We neither endorse nor discourage use of this construct, but simply wish to emphasize that it should be approached with care, when its use is warranted.
我们既不赞成也不反对使用这一概念，只是想强调，在有必要使用时，应谨慎处理。
What’s the difference between an “over” and a “typeless def” ?
“over”和“typeless def”有什么区别？
In a lot of usd files, I see something like:
在很多USD文件中，我看到类似这样的内容：
def "MyModel" (
payload = @./MyModel_payload.usd@
)
{
}
Since we’re not saying what type of prim “MyModel” is at this level, why isn’t it just
既然我们不是在说什么类型的一本正经的“MyModel”是在这个层面上，为什么不只是
over "MyModel"
Answer : When you def a prim, you’re providing more information to the system than when you over a prim.
回答：当你定义一个prim时，你向系统提供的信息比覆盖一个prim时要多。
def means “Even though I may not be declaring a typed prim in this layer, by the time the UsdStage has finished composing, I expect a type to have been provided by referenced/layered scene description” (in the example, presumably the type would be provided by the layer targeted by the payload arc.
def表示“即使我可能没有在该层中声明类型化的prim，但在UsdStage完成合成时，我期望类型已经由引用/分层场景描述提供”（在示例中，假定类型将由有效载荷弧所针对的层提供。over means “If some referenced layer happens to define this prim, then layer the information I contain onto it; but if not, just consider this information ancillary”
over的意思是“如果某个引用的层恰好定义了这个prim，那么就把我包含的信息层到它上面;但如果没有，就把这些信息当作辅助信息”
This distinction is actually used in the Usd core to define, for e.g., default stage traversal behavior, as UsdPrim::GetChildren only iterates over a prim’s defined children (regardless of whether they possess a type in the current view of the stage), skipping prims that are just over.
这种区别实际上在Usd核心中用于定义例如默认的阶段遍历行为，如UsdPrim：：GetChildren仅迭代prim的已定义子级（无论它们是否在阶段的当前视图中拥有类型），跳过刚刚结束的prim。
Why Can’t I Instance a Leaf Mesh Prim Directly?
为什么不能直接实例化叶网格Prim？
USD Native Instancing makes no restrictions on what “source scene description” can and cannot be instanced. A UsdStage is perfectly happy to have instances that target a single, leaf, source prim, although the “implicit prototype” that gets created as a result will be empty, and for that reason the instancing, in such a case, is meaningless, from a composition-cost and data sharing perspective. Perhaps most importantly, it is also meaningless from the perspective of being able to assume that anything is actually the same or similar between two instances of the same implicit prototype, because you can override any property or metadata of any instance - only prims beneath the implicit prototype’s root are protected from being overridden, per-prototype, and in this case there are none.
USD本机实例化对可以实例化和不能实例化的“源场景描述”没有限制。UsdStage非常乐意拥有针对单个叶源prim的实例，尽管作为结果创建的“隐式原型”将是空的，因此，从组合成本和数据共享的角度来看，在这种情况下，实例化是没有意义的。也许最重要的是，从能够假设相同隐式原型的两个实例之间的任何东西实际上是相同或相似的角度来看，这也是没有意义的，因为您可以覆盖任何实例的任何属性或元数据-只有隐式原型的根下的prims被保护不被覆盖，每个原型，在这种情况下没有。
Our imaging system, Hydra, cares very much about that last property, or lack thereof. Every renderer of which we’re aware that supports instancing requires that the basic geometric properties of a Mesh (or other gprim) must be unvarying across instances since it is the tessellation and storage/indexing costs of said geometry that we are trying to share for scalability. The UsdImaging Hydra scene delegate, therefore, imposes a further restriction on “meaningful” instancing and considers any “leaf instanced gprims” to be an error condition for which we issue a warning and do not image anything. To do otherwise would force the scene delegate to compare/hash all the “relevant” properties up-front to create buckets of “really instanceable instances”, since Hydra passes instances to render delegates in an explicit form that would otherwise assume the characteristics of the first instance it sees, dropping any variation in the other instances, thus potentially losing artistic intent, and producing non-deterministic results. Therefore we felt it better to treat this as an error condition, since we do not want to impose full instance deduplication on the scene delegate, and it is part of the “USD philosophy” that consumers of scene description should not need to care about where in the composition graph particular opinions come from.
我们的成像系统，Hydra，非常关心最后一个属性，或者缺乏它。我们所知道的支持实例化的每个渲染器都要求Mesh（或其他gprim）的基本几何属性必须在实例之间保持不变，因为我们试图共享所述几何的细分和存储/索引成本以实现可扩展性。因此，UsdImaging Hydra场景委托对“有意义的”实例化施加了进一步的限制，并将任何“叶实例化的gprims”视为错误条件，对此我们发出警告并且不对任何内容进行成像。 否则，将迫使场景委托预先比较/散列所有“相关”属性以创建“真正可实例化的实例”的桶，因为Hydra以显式形式传递实例以渲染委托，否则将假定其看到的第一个实例的特征，丢弃其他实例中的任何变化，从而可能失去艺术意图，并产生不确定的结果。因此，我们觉得最好将其视为错误条件，因为我们不想对场景委托强加完整的实例去重，并且这是“USD哲学”的一部分，即场景描述的消费者不需要关心组合图中的特定意见来自何处。
Some DCC’s that support instancing do so with an “explicit”, relationship-based (or equivalent) scheme, and in such schemes (as with UsdGeomPointInstancer), single gprim instancing is not problematic, because the “overrides” (which are generally selective/restrictive) are on separate prims from the prototype prims, and therefore the overrides are easy to identify. We realize that in this specific case, the USD model of instancing may be less user-friendly at first glance, but we wanted our instancing mechanism to be a natural extension of USD’s powerful composition operators, which provides pipeline benefits (such as the ability to de-instance and re-instance with a trivial, non-destructive edit, without losing any overrides) and scalability benefits (as mentioned in the glossary entry, instances from different assets can “unify” and share prototypes when assembled into an aggregate or scene), and the reality for Pixar is that we rarely instance single gprims, rather instancing entire models or parts of models.
支持实例化的一些DCC利用“显式”的、基于关系的（或等效的）方案来这样做，并且在这样的方案中（如利用UsdGeomPointInstancer），单个gprim实例化没有问题，因为“覆盖”（其通常是选择性的/限制性的）在与原型prim分离的prim上，并且因此覆盖易于识别。 我们意识到，在这个特定的案例中，USD的实例化模型乍一看可能不那么用户友好，但我们希望我们的实例化机制是USD强大的组合操作符的自然扩展，这提供了管道优势（比如通过简单的、非破坏性的编辑来解除实例化和重新实例化的能力，而不会丢失任何覆盖）和可伸缩性的好处（如术语表条目中所述，来自不同资产的实例可以“统一”并在组装成聚合或场景时共享原型），而Pixar的现实是我们很少实例化单个GPrim，而是实例化整个模型或模型的一部分。
Build and Runtime Issues
构建和运行时问题
Why Isn’t Python Finding USD Modules?
为什么Python没有找到USD模块？
If you get an error message when using USD’s Python bindings like this:
如果您在使用USD的Python绑定时收到如下错误消息：
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: No module named pxr
Make sure that the PYTHONPATH environment variable includes the directory containing the USD Python modules:
确保环境变量包括包含USD Python模块的目录：
$ export PYTHONPATH=$PYTHONPATH:<inst>/lib/python
Where <inst> represents the CMAKE_INSTALL_PREFIX set in your build configuration. See Advanced Build Configuration for more information.
其中表示生成配置中设置的CMAKE_INSTALL_PREFIX。有关详细信息，请参阅高级生成配置。
Why Isn’t This Plugin Being Built?
为什么这个插件没有被构建？
The plugins included in the USD distribution are disabled by default. See Advanced Build Configuration for instructions on how to enable these plugins.
默认情况下，USD发行版中包含的插件是禁用的。有关如何启用这些插件的说明，请参阅高级构建配置。
Why Isn’t My App Finding USD DLLs and Plugins on Windows?
为什么我的应用在Windows上找不到USD DLL和插件？
If you get errors similar to “This program can’t start because USD_AR.DLL is missing from your computer” or “Failed to load plugin ‘usd’: The specified module could not be found” when running your app, this means the USD DLLs or USD plugins can’t be located at runtime.
如果您收到类似于“此程序无法启动，因为您的计算机中缺少USD_AR.DLL”或“无法加载插件'usd'：运行您的应用时，无法找到指定的模块”，这意味着在运行时无法找到USD DLL或USD插件。
One way to fix this is to install the USD DLLs and USD plugins in the same directory as your executable. For example, if you built MyCustomUSDTool.exe and installed it into C:\MyPrograms\MyCustomUSDTool\, your directory layout might look something like:
解决此问题的一种方法是将USD DLL和USD插件安装在与可执行文件相同的目录中。例如，如果您将其构建并安装到中，则目录布局可能如下所示：
C:\MyPrograms\MyCustomUSDTool\MyCustomTool.exe
C:\MyPrograms\MyCustomUSDTool\tbb.dll
C:\MyPrograms\MyCustomUSDTool\usd_ar.dll
C:\MyPrograms\MyCustomUSDTool\(...remaining USD DLLs...)
C:\MyPrograms\MyCustomUSDTool\usd\plugInfo.json
C:\MyPrograms\MyCustomUSDTool\usd\ar\resources\plugInfo.json
C:\MyPrograms\MyCustomUSDTool\usd\(...remaining core USD plugin directories and files...)
C:\MyPrograms\MyCustomUSDTool\usd\(...other non-core plugin directories as needed...)
Another approach is to install your DLLs and plugins to a directory that is added to your Windows PATH environment variable. See Dynamic-link library search order for more details on how Windows searches for DLLs at runtime.
另一种方法是将DLL和插件安装到添加到Windows环境变量的目录中。有关Windows如何在运行时搜索DLL的详细信息，请参阅动态链接库搜索顺序。
If you prefer not to have to install a large number of DLLs, you can build a single monolithic USD DLL using the PXR_BUILD_MONOLITHIC cmake flag. See Advanced Build Configuration for more information. Note that you will still need to install the USD plugins directory along with the monolithic USD DLL.
如果您不想安装大量DLL，可以使用PXR_BUILD_MONOLITHIC cmake标志构建一个单一的USD DLL。有关详细信息，请参阅高级生成配置。请注意，您仍然需要安装USD插件目录沿着单片USD DLL。
1283
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
