USD introduces quite a few terms and concepts, some of which, unavoidably, already have different meanings in other contexts, so it can be quite daunting to make sense of all of our documentation and code until you have become fully indoctrinated. This document attempts to define and explain all the major concepts and behaviors referred to in other parts of the USD documentation.
USD引入了相当多的术语和概念，其中一些不可避免地在其他上下文中已经有了不同的含义，因此在您完全被灌输之前，要理解我们所有的文档和代码可能会非常困难。本文档试图定义和解释USD文档其他部分中提到的所有主要概念和行为。
Active / Inactive
活动/非活动
Activation is a metadatum/behavior of prims that models a “non destructive and reversible prim deletion” from a stage . Prims are active by default, which means they and their active children will be composed and visited by stage traversals. However, by making a prim inactive by calling UsdPrim::SetActive(false), we prevent the prim itself from being visited by default traversals, and we also prevent the prim’s descendant prims from even being composed on the stage, which makes deactivation a useful tool for pruning unneeded scene description for scalability and complexity management.
激活是引物的元态/行为，其模拟来自一个阶段的“非破坏性和可逆的引物缺失”。prim默认是活动的，这意味着他们和他们的活动子将被组成和访问阶段遍历。然而，通过调用UsdPrim：：SetActive（false）使prim不活动，我们防止prim本身被默认遍历访问，我们还防止prim的后代prim甚至在舞台上组成，这使得停用成为一个有用的工具，用于修剪不必要的场景描述，以实现可伸缩性和复杂性管理。
In the following example, the prim at path /Parent has been deactivated, so /Parent/Child1 and other descendants will not be composed. However, /Parent’s active metadatum can be overridden to true in a stronger layer, which would cause /Parent/Child1 and etc. to compose onto the stage.
在下面的示例中，路径/Parent处的primer已被停用，因此/Parent/Child 1和其他子代将不会被合成。但是，/Parent的活动元数据可以在更强的层中被重写为true，这将导致/Parent/Child 1等。上台作曲
失活引物示例
def Xform "Parent" (
active = false
)
{
def Mesh "Child1"
{
}
# other siblings of "Child1" ...
}
API Schema API架构
An API schema is a prim Schema that serves as an interface or API for authoring and extracting a set of related data, and may also contribute to a prim’s definition. In terms of the USD object model, an API schema is one that derives from UsdAPISchemaBase, but not from its subclass UsdTyped. That means UsdPrim::IsA<UsdModelAPI>() will never return true. In contrast to typed, “is a” schemas, think of API schemas as “has a” schemas. There are three types of API schema: non-applied, single-apply, and multiple-apply.
API模式是一种prim模式，用作用于创作和提取一组相关数据的接口或API，并且还可以对prim的定义做出贡献。就USD对象模型而言，API模式是从UsdAPISchemaBase派生的，但不是从它的子类UsdTyped派生的。这意味着UsdPrim：：伊萨（）永远不会返回true。与类型化的“is a”模式相反，可以将API模式视为“has a”模式。有三种类型的API模式：非应用、单应用和多应用。
-
Non-applied API Schemas 未应用的API架构
Non-applied API schemas are, in some sense, the “weakest” API schemas, since all they provide is API for setting and fetching some related properties and/or metadata, and do not contribute to a prim’s type or definition in any way. The UsdModelAPI is an example of a non-applied schema whose purpose is to interact with a few pieces of prim metadata related to models and assets; there is no way to tell whether a UsdModelAPI is present on a prim - instead one simply uses its methods to interrogate particular aspects.
在某种意义上，非应用的API模式是“最弱”的API模式，因为它们提供的只是用于设置和获取一些相关属性和/或元数据的API，并且不会以任何方式对prim的类型或定义做出贡献。UsdModelAPI是一个非应用模式的示例，其目的是与一些与模型和资产相关的原始元数据进行交互;没有办法知道UsdModelAPI是否存在于primer上-相反，人们只需要使用它的方法来询问特定的方面。Usd.ModelAPI(prim).SetKind(Kind.Tokens.subcomponent)One might also create a non-applied schema to interact with some related (for your purposes) properties that exist on some number of other typed schemas, which may allow for more concise coding patterns.
还可以创建一个非应用模式来与存在于其他类型模式上的一些相关（出于您的目的）属性交互，这可能允许更简洁的编码模式。 -
Single and Multiple Apply Schemas
单个和多个应用方案Applied schemas get recorded onto a prim in its apiSchemas metadata, which allows them to contribute to the prim’s definition, adding builtin properties, and submitting to presence queries, using UsdPrim::HasAPI<UsdShadeMaterialBindingAPI>(). The most common type of API schema is single-apply, which should be applied before using the schema’s authoring APIs. That is, whereas when we are authoring typed schemas we usually assign the type as we define the prim, before using the schema to author data, like:
应用的模式在prim的apiSchemas元数据中被记录到prim上，这允许它们使用UsdPrim：：HasAPI（）对prim的定义做出贡献，添加内置属性，并提交给presence查询。最常见的API模式类型是单应用，它应该在使用模式的创作API之前应用。也就是说，当我们创作类型化模式时，我们通常会在定义prim的同时分配类型，然后再使用模式创作数据，比如：mesh = UsdGeom.Mesh.Define(stage, path) mesh.CreateSubdivisionSchemeAttr().Set(UsdGeom.Tokens.bilinear)for applied API schemas we instead apply the type to an existing prim before using the schema to author data, like:
对于应用的API模式，我们在使用模式创建数据之前，将类型应用到现有的prim，例如：bindingAPI = UsdShade.MaterialBindingAPI.Apply(prim) bindingAPI.Bind(materialPrim)Multiple-apply schemas can be applied to a prim more than once, requiring an “instance name” to distinguish one application from another - the instance name will form part of the namespace in which the schema’s properties will be authored. UsdCollectionAPI is an example of a multiple-apply schema, which UsdShadeMaterialBindingAPI uses to assign materials to collections of prims, allowing multiple collections to be located on a single prim.
多应用模式可以多次应用于prim，需要一个“实例名称”来区分一个应用程序与另一个应用程序-实例名称将形成命名空间的一部分，在该命名空间中创建模式的属性。UsdCollectionAPI是一个多应用模式的示例，UsdShadeMaterialBindingAPI使用该模式将材质分配给prim集合，从而允许多个集合位于单个prim上。
Choose to create an applied API Schema when you have a group of related properties, metadata, and possibly associated behaviors that may need to be applied to multiple different types of prims . For example, if your pipeline has a set of three attributes that get authored onto every gprim, and you want to have a robust schema for authoring and extracting those attributes, you could create an applied API schema for them. Why not instead subclass the typed UsdGeomGprim schema and add the attributes there? Because you would then need to redefine all of the schema classes that derive from Gprim, thus preventing you from taking advantage of built-in DCC support for the UsdGeomGprim-derived classes. API schemas provide for “mix in” data organization.
当您有一组相关属性、元数据和可能关联的行为需要应用于多种不同类型的prim时，请选择创建应用的API架构。例如，如果您的管道有一组三个属性，它们被编写到每个gprim上，并且您希望有一个健壮的模式来编写和提取这些属性，您可以为它们创建一个应用的API模式。为什么不将类型化的UsdGeomGprim模式子类化并在其中添加属性呢？因为这样您就需要重新定义所有从Gprim派生的模式类，从而阻止您利用UsdGeomGprim派生类的内置DCC支持。API模式提供“混合”数据组织。
API schemas can be generated using the USD schema generation tools, and extended with custom methods, just as typed schemas can. We use schema generation even for non-applied API schemas that have no builtin properties, to ensure consistency.
API模式可以使用USD模式生成工具生成，并使用自定义方法进行扩展，就像类型化模式一样。即使对于没有内置属性的未应用的API模式，我们也使用模式生成，以确保一致性。
Assembly 组装
In USD an assembly is a kind of Model. Assemblies are group models, i.e. models that aggregate other models into meaningful collections. An assembly may consist primarily of references to other models, and themselves be published assets.
在USD中，组件是模型的一种。装配是组模型，即将其他模型聚合成有意义的集合的模型。程序集可能主要由对其他模型的引用组成，而程序集本身也是已发布的资源。
一个“集合”资产，在场景描述中声明
def Xform "Forest_set" (
kind = "assembly"
)
{
# Possibly deep namespace hierarchy of prims, with references to other assets
}
See also: model hierarchy
参见：模型层次结构
Asset 资产
Asset is a fairly common organizational concept in content-producing pipelines. In the most generic terms in USD, an asset is something that can be identified and located (via asset resolution) with a string identifier. To facilitate operations such as asset dependency analysis, USD defines a specialized string type, asset, so that all metadata and attributes that refer to assets can be quickly and robustly identified. In content pipelines, assets are sometimes a single file (e.g. a UV texture), or a collection of files anchored by a single file that in turn references others. A non-defining, but important quality of assets is that they are generally published and version-controlled. As an aid to asset management and analysis of composed scenes, USD provides an AssetInfo schema. The text .usda format uses a special syntax for asset-valued strings to make them easily differentiable from ordinary strings, using the “@” symbol instead of quotes to delimit their values, or “@@@” as delimiter if the asset path itself contains the “@” character. If an asset path must contain the string “@@@” then it should be singly escaped, as “\@@@”. See AssetInfo for examples of both forms.
资产是内容生产管道中一个相当常见的组织概念。在USD中最通用的术语中，资产是可以使用字符串标识符（通过资产解析）识别和定位的东西。为了方便资产依赖性分析等操作，USD定义了一个专门的字符串类型asset，以便可以快速可靠地识别引用资产的所有元数据和属性。在内容管道中，资源有时是单个文件（例如，UV纹理），或由单个文件锚定的文件集合，该文件又引用其他文件。资产的一个非定义性但重要的特性是它们通常是发布的并且是版本控制的。USD提供了AssetInfo模式，以帮助资产管理和分析组合场景。短信USDA格式对资产值字符串使用一种特殊语法，使其易于与普通字符串区分，使用“@”符号而不是引号来定界它们的值，或者如果资产路径本身包含“@”字符，则使用“@”作为分隔符。如果资产路径必须包含字符串“@”，则应将其单独转义为“\@”。有关这两种形式的示例，请参见AssetInfo。
AssetInfo ASSETINO
AssetInfo is a metadata dictionary that can be applied to any UsdPrim or UsdProperty to convey asset-identification-and-management-related information. Typically a UsdStage pulls in many assets through composition arcs. When interacting with prims and properties on the stage, however, the presence and location of the arcs and the identity of the assets they target is, by design, fairly deeply hidden as an implementation detail. We do provide low-level tools for examining the arc-by-arc index for each prim, but it can be difficult to reconstruct intent and asset identity from the arc structure alone. AssetInfo provides a mechanism for identifying and locating assets that survives composition (and even stage flattening) to allow clients to discover the namespace location at which an asset is introduced, and generally how to construct a reference to the asset.
AssetInfo是一个元数据字典，可应用于任何UsdPrim或UsdProperty，以传达资产标识和管理相关信息。通常，UsdStage通过组合弧拉入许多资产。然而，当与舞台上的prim和属性交互时，弧的存在和位置以及它们所瞄准的资产的身份，通过设计，作为实现细节被相当深地隐藏。我们确实提供了用于检查每个prim的逐弧索引的低级工具，但仅从弧结构中重建意图和资产身份可能很困难。AssetInfo提供了一种机制，用于识别和定位在组合（甚至阶段扁平化）中幸存下来的资产，以允许客户端发现资产被引入的命名空间位置，以及通常如何构造对资产的引用。
Note 注记
assetInfo authored in USD files is advisory data one supplies for client applications to use. It is not consulted or consumed by the USD core in any way during Stage loading/composition.
在USD文件中编写的assetInfo是提供给客户端应用程序使用的咨询数据。在阶段加载/合成期间，USD核心不以任何方式咨询或消耗它。
The AssetInfo dictionary can contain any fields a client or pipeline finds useful, but promotes four core fields, which each have direct API:
AssetInfo字典可以包含客户端或管道发现有用的任何字段，但提升了四个核心字段，每个字段都有直接的API：
identifier (asset) 标识符（资产）
Provides the asset identifier one would use to target the asset with a composition arc.
提供资产标识符，用于将组合弧作为资产的目标。name (string) name（string）
Provides the name of the asset as it would be identified, for example, in an asset database query.
提供资产的名称，例如，在资产数据库查询中标识的名称。payloadAssetDependencies (asset[])
payloadAssetDependencies（asset[]）Provides what can be a substantial optimization for dynamic asset dependency analysis. If your asset build/publish process can pre-compute, at publish-time, the external asset dependencies contained inside the asset’s payload(s), then shot/render-time dependency analysis (for asset isolation) need not load the payload.
为动态资产相关性分析提供了实质性的优化。如果您的资源构建/发布流程可以在发布时预先计算包含在资源有效载荷内的外部资源依赖关系，那么拍摄/渲染时依赖关系分析（用于资源隔离）就不需要加载有效载荷。version (string) version（string）
Provides the version of the asset that was/would-be targeted. In some pipelines, it may make sense to inject an asset’s revision control version into the published asset itself. In other pipelines, version is tracked in an external database, so the version assetInfo must be added in the referencing context when we add a reference to an asset.
提供目标资产的版本。在某些管道中，将资产的修订控制版本注入到已发布的资产本身中可能是有意义的。在其他管道中，版本在外部数据库中跟踪，因此当我们向资源添加引用时，版本assetInfo必须添加到引用上下文中。
A continuation of the example above that illustrates assemblies:
上例的延续，说明了程序集：
已发布组件资源上的AssetInfo
def Xform "Forest_set" (
assetInfo = {
asset identifier = @Forest_set/usd/Forest_set.usd@
string name = "Forest_set"
}
kind = "assembly"
)
{
# Example of an asset that embeds the '@', and so must be delimited
# with the "@@@" form
asset primvars:texture = @@@body_decal.exr@v3@@@
}
Asset Resolution 资产解决方案
Asset resolution is the process by which an asset path is translated into the location of a consumable resource. USD provides a plugin point for asset resolution, the ArResolver interface, which clients can implement to resolve assets discovered in a USD scene, using whatever logic and external inputs they require. This plugin also lets clients provide USD with an asset’s data without fetching the data to disk.
资产解析是将资产路径转换为可消耗资源位置的过程。USD提供了一个用于资产解析的插件点ArResolver接口，客户端可以使用他们需要的任何逻辑和外部输入来实现该接口来解析在USD场景中发现的资产。该插件还允许客户端向USD提供资产数据，而无需将数据提取到磁盘。
If no asset resolver plugin is available, USD falls back to a default resolver implementation that uses search paths to locate assets referenced via relative paths. See the examples for References.
如果没有可用的资产解析器插件，则USD福尔斯到默认的解析器实现，该实现使用搜索路径来定位通过相对路径引用的资产。参见参考文献的示例。
Attribute 属性设置
Attributes are the most common type of property authored in most USD scenes. An attribute can take on exactly one of the legal attribute typeNames USD provides, and can take on both a default value and a value each at any number of timeSamples. Resolving an attribute at any given timeCode will yield either a single value or no value. Attributes resolve according to “strongest wins” rules, so all values for any given attribute will be fetched from the strongest PrimSpec that provides either a default value or timeSamples. Note that this simple rule is somewhat more complicated in the presence of authored clips. One interacts with attributes through the UsdAttribute API.
属性是在大多数USD场景中编写的最常见的特性类型。一个属性可以完全采用USD提供的法律的属性typeNames之一，并且可以采用默认值和任意次数的timeSamples的值。在任何给定的时间解析属性Code将产生单个值或不产生任何值。属性根据“最强获胜”规则进行解析，因此任何给定属性的所有值都将从提供默认值或timeSamples的最强PrimSpec中获取。请注意，这个简单的规则在存在创作的剪辑时会稍微复杂一些。通过UsdAttribute API与属性交互。
A simple example of an attribute that has both an authored default and two timeSamples in the same primSpec:
下面是一个简单的属性示例，该属性在同一primSpec中同时具有一个创作的默认值和两个timeSamples：
同时具有Default和TimeSamples的属性
def Sphere "BigBall"
{
double radius = 100
double radius.timeSamples = {
1: 100,
24: 500,
}
}
Attribute Block 属性Block
Similarly to how prims can be deactivated through composing overriding opinions, the value that an attribute produces can be blocked by an overriding opinion of None, which can be authored using UsdAttribute::Block. A block itself can, of course be overridden by an even stronger opinion. The following example extends the previous attribute example, adding a DefaultBall prim that blocks the value of radius it references from BigBall, causing radius’s value to resolve back to its fallback at UsdTimeCode t (any blocked attribute that has no fallback will report that it has no value when we invoke UsdAttribute::Get):
类似于如何通过合成覆盖意见来停用prims，属性产生的值可以被覆盖意见None阻止，该意见可以使用UsdAttribute：：Block创建。当然，一个阻止本身可以被一个更强烈的观点所推翻。下面的示例扩展了上一个属性示例，添加了一个DefaultBall prime，该prime阻止它从BigBall引用的radius的值，从而导致radius的值在UsdTimeCode t解析回其回退（任何没有回退的被阻止的属性在我们调用UsdAttribute：：Get时将报告它没有值）：
DefaultBall阻止BigBall引用的半径值
def Sphere "BigBall"
{
double radius = 100
double radius.timeSamples = {
1: 100,
24: 500,
}
}
def "DefaultBall" (
references = </BigBall>
)
{
double radius = None
}
In addition to completely blocking an attribute’s value, sub time-ranges can be separately blocked, by blocking individual time samples. Consider the following examples:
除了完全阻止属性的值之外，还可以通过阻止各个时间样本来单独阻止子时间范围。考虑以下示例：
Example 1: 实施例1：
def Sphere "BigBall"
{
double radius.timeSamples = {
101: 12,
102: None,
}
}
For the attribute radius on BigBall:
对于BigBall上的属性半径：
Usd.Attribute.Get(t) will return 12 for Usd.TimeCode t in (-∞, 102).
Usd.Attribute.Get（t）将返回12，用于（-∞，102）中的Usd.TimeCode t。Usd.Attribute.Get(t) will return None for Usd.TimeCode t in [102, ∞).
Usd.Attribute.Get（t）将返回[102，∞）中的Usd.TimeCode t的None。
Example 2: 实施例2：
def Sphere "BigBall"
{
double radius.timeSamples = {
101: None,
102: 12,
}
}
For the attribute radius on BigBall:
对于BigBall上的属性半径：
Usd.Attribute.Get(t) will return None for Usd.TimeCode t in (-∞, 102).
Usd.Attribute.Get（t）将为（-∞，102）中的Usd.TimeCode t返回None。Usd.Attribute.Get(t) will return 12 for Usd.TimeCode t in [102, ∞).
Usd.Attribute.Get（t）将为[102，∞）中的Usd.TimeCode t返回12。
Note that the per-timeSample-blocking ability does not allow us to sparsely override timeSamples, i.e. in the following example:
注意，每时间样本阻塞能力不允许我们稀疏地覆盖时间样本，即在以下示例中：
def Sphere "BigBall"
{
double radius.timeSamples = {
101: 1,
102: 2,
}
}
def "DefaultBall" (
references = </BigBall>
)
{
double radius.timeSamples = {
101: None,
}
}
For the attribute radius on DefaultBall:
对于DefaultBall上的属性半径：
Usd.Attribute.Get(t) will return None for Usd.TimeCode t in (-∞, ∞).
Usd.Attribute.Get（t）将为（-∞，∞）中的Usd.TimeCode t返回None。
Attribute Connection 属性连接
See Connection. 请参见连接。
Attribute Variability 属性可变性
See Variability. 请参见可变性。
Change Processing 变更处理
Change processing is the action a UsdStage takes in response to edits of any of the layers that contribute to its composition. During change processing, prims on the stage may be re-indexed or disappear entirely, or new prims may come into being. The key things to understand about change processing are:
更改处理是UsdStage响应对其合成有贡献的任何层的编辑而执行的操作。在改变处理期间，阶段上的素数可以被重新索引或完全消失，或者新的素数可以形成。关于变更处理，需要了解的关键事项包括：
-
It is always active. Whenever you use the Usd or Sdf APIs to mutate any layers that contribute to a UsdStage’s composition, that stage will update itself immediately, in the same thread in which authoring was performed (though the change-processing itself may spawn worker threads), so that it always presents an accurate result to clients.
它总是活跃的。每当您使用Usd或Sdf API来改变对UsdStage的合成有贡献的任何层时，该阶段将在执行创作的同一线程中立即更新自身（尽管更改处理本身可能会产生工作线程），以便它始终向客户端呈现准确的结果。 -
When a stage has completed a round of change processing, it will send notification to clients who have registered interest, so that they may keep themselves updated in light of authored changes to the stage.
当阶段完成一轮变更处理时，它将向已注册兴趣的客户端发送通知，以便他们可以根据对阶段的创作变更来保持自己的更新。Note 注记
Clients listening to UsdStage notifications should not update themselves immediately upon receiving a notice, but instead note what has become out-of-date (dirty), and defer updating until necessary; this helps minimize the amount of work an application needs to undertake when many edits are being performed rapidly.
侦听UsdStage通知的客户端不应在收到通知后立即更新自己，而是注意哪些内容已过期（脏），并推迟更新，直到必要时;这有助于在快速执行许多编辑时最小化应用程序需要承担的工作量。 -
For all of the layers that contribute to a given UsdStage, only one thread at a time may be editing any of those layers, and no other thread can be reading from the stage while the editing and change processing are taking place. This is because we do not want to weigh down read access to UsdStage data with any kind of locking.
对于对给定UsdStage有贡献的所有层，一次只有一个线程可以编辑这些层中的任何一个，并且在编辑和更改处理发生时，没有其他线程可以从该阶段阅读。这是因为我们不希望使用任何类型的锁定来降低对UsdStage数据的读访问。
Class 分类
Class is one of the three possible specifiers a prim (and also a primSpec) can possess. A class prim and all of the prims nested inside it in namespace will report that they are abstract, via UsdPrim::IsAbstract, which causes the prims to be skipped by stage and child traversals, unless a client specifically asks to include abstract prims. The most common use of classes is to create prims from which other prims can inherit. Classes can define/override metadata as well as properties and nested prims. The following example contains a class _class_Ball that provides a value for the radius attribute for any prim that would inherit or reference it. The _class_ prefix is a Pixar convention for naming classes, and is not a requirement.
Class是prim（也是primSpec）可以拥有的三个可能的说明符之一。一个prim类和所有嵌套在命名空间中的prim类将通过UsdPrim：：IsAbstract报告它们是抽象的，这会导致prim被阶段和子遍历跳过，除非客户端特别要求包含抽象prim。类最常见的用途是创建其他prim可以继承的prim。类可以定义/覆盖元数据以及属性和嵌套prims。下面的示例包含一个class _class_Ball，它为将继承或引用它的任何prim的半径属性提供了一个值。_class_前缀是Pixar命名类的约定，不是必需的。
一个“类”prim包含的观点意味着要被继承？？
class "_class_Ball" {
double radius = 50
}
Clips 夹子
See Value Clips 请参见值片段
Collection 收藏
Collections build on the ability of relationships to identify objects in a USD scene. Whereas a relationship is (resolves to, by fetching its Targets) simply an ordered list of paths identifying other objects in the scene, a Collection uses a pair of relationships and extra rules to compactly encode potentially large sets of objects by identifying a set of paths to hierarchically include in the Collection, and a separate set of paths to hierarchically exclude. For example, the following Collection identifies all of the prims comprising the two buildings, except for all the prims organized under the Floor13 prim in each.
集合建立在关系识别USD场景中的对象的能力之上。尽管关系（通过获取其目标，解析为）仅仅是标识场景中的其他对象的路径的有序列表，但集合使用一对关系和额外规则来通过标识要分层地包括在集合中的路径集合和要分层地排除的单独路径集合来紧凑地编码潜在的大的对象集合。例如，下面的集合标识了构成两个建筑物的所有prim，除了每个建筑物中在Floor13 prim下组织的所有prim。
集合通过包含和排除越来越细的分支来细化层次结构集
over "World"
{
over "Buildings" (
prepend apiSchemas = "CollectionAPI:luckyBuildings"
)
{
uniform token collection:luckyBuildings:expansionRule = "expandPrims"
rel collection:luckyBuildings:includes = [
</World/Buildings/Skyscraper>,
</World/Buildings/Pyramid>,
]
rel collection:luckyBuildings:excludes = [
</World/Buildings/Skyscraper/Floor13>,
</World/Buildings/Pyramid/Floor13>,
]
}
}
We can see from the example that Collections in USD are expressed as “multiple apply” API Schemas, so that we can add as many different collections as we want, to any prim already in the scene. The expansionRule attribute specifies how the targets of the includes relationship should be expanded; we can include all prims, all prims and properties, or just the targeted objects themselves. In addition to prims and properties, a Collection can include another Collection, which allows us to hide internal details of assets when we publish them, as the aggregate scenes that consume the assets can do things like binding materials and illuminating the scene by targeting the asset’s collections (which break down the asset into meaningful groups) with other collections.
我们可以从这个例子中看到，USD中的集合被表示为“多个应用”API模式，这样我们就可以根据需要向场景中已经存在的任何prim添加任意多个不同的集合。expansionRule属性指定如何扩展includes关系的目标;我们可以包括所有的素数、所有的素数和属性，或者仅仅是目标对象本身。除了prims和properties之外，Collection还可以包含另一个Collection，这允许我们在发布资产时隐藏资产的内部详细信息，因为使用资产的聚合场景可以通过将资产的集合（将资产分解为有意义的组）与其他集合定位来执行绑定材质和照亮场景等操作。
We create and query Collections using UsdCollectionAPI.
我们使用UsdCollectionAPI创建和查询集合。
Component 组件
A component is a “leaf” kind of Model. Components can contain subcomponents, but no other models. Components can reference in other assets that are published as models, but they should override the kind of the referenced prim to “subcomponent”.
组件是一种“叶子”类型的模型。零部件可以包含子零部件，但不能包含其他模型。组件可以在其他作为模型发布的资产中引用，但是它们应该将引用的prim的类型覆盖为“subcomponent”。
“组件”资源，在场景描述中声明，覆盖“嵌套”资源引用的类型
def Xform "TreeSpruce" (
kind = "component"
)
{
# Geometry and shading prims that define a Spruce tree...
def "Cone_1" (
kind = "subcomponent"
references = @Cones/PineConeA.usd@
)
{
}
}
See also: model hierarchy
参见：模型层次结构
Composition 组成
Composition is the process that assembles multiple layers together by the composition arcs that relate them to each other, resulting in a UsdStage scenegraph of UsdPrims. Each UsdPrim contains an index that allows clients to subsequently extract “resolved values” for properties and metadata from the relevant layers. Composition occurs when first opening a UsdStage, when loading or unloading prims on the stage, and when layers that contribute to the stage are edited. One of the results of composition is path translation so that all the data in all layers contributing to the scene are accessed by their “scene level” namespace locations (paths).
组合是通过组合弧将多个层组合在一起的过程，组合弧将多个层彼此关联，从而生成UsdPrims的UsdStage场景图。每个UsdPrim都包含一个索引，允许客户端随后从相关层中提取属性和元数据的“解析值”。当首次打开UsdStage时、在舞台上加载或卸载prims时以及编辑对舞台有贡献的图层时，都会进行合成。合成的结果之一是路径转换，使得对场景有贡献的所有层中的所有数据通过它们的“场景级”命名空间位置（路径）来访问。
We also sometimes refer to “a composition” or “a composed prim” or “a composed scene”, in which contexts we are referring to the result of performing composition.
我们有时也指“一个组成”或“一个组成的prim”或“一个组成的场景”，在这种情况下，我们指的是执行组成的结果。
Composition Arcs 组合弧
Composition arcs are the “operators” that allow USD to create rich compositions of many layers containing mixes of “base” scene description and overrides. The arcs are:
合成弧是“操作符”，允许USD创建包含“基础”场景描述和覆盖混合的许多层的丰富合成。弧是：
We refer to these operators as arcs because each one targets either a layer, a prim, or a combination of layer and prim, and when diagramming a prim’s index to understand how a scene or value is composed, the composition operators represent the directional arcs that combine layers and primSpecs into an ordered graph that we traverse when performing value resolution. Except for subLayers, all composition arcs target a specific prim in a LayerStack, and allow the renaming of that target prim as the result “flows” across the arc. USD performs all the necessary path translation to ensure that stage-level queries always work in the stage-level namespace, regardless of how many different and/or nested composition arcs and name-changes contributed to the result.
我们将这些操作符称为弧，因为每个操作符都针对层、prim或层和prim的组合，并且当绘制prim的索引以了解场景或值是如何组成的时，组合操作符表示将层和primSpecs组合成有序图的方向弧，我们在执行值解析时遍历该有序图。除了subLayers之外，所有的复合弧都以LayerStack中的特定prim为目标，并允许在结果“流过”弧时重命名该目标prim。USD执行所有必要的路径转换，以确保阶段级查询始终在阶段级命名空间中工作，而不管有多少不同和/或嵌套的组合弧和名称更改对结果有贡献。
Except for subLayers, all composition arcs are list editable, which means that each layer in a layerStack can sparsely prepend, append, remove, or reset targets, which allows us to non-destructively edit the composition structure of a scene as it evolves or passes through multiple stages of a pipeline. Following is an example of list-edited references. The resolved value of references on /MyPrim that will be consumed during composition of superLayer.usd is a two-element list: [ @file1.usd@, @file3.usd@ ]
除了subLayers，所有的合成弧都是列表可编辑的，这意味着layerStack中的每个层都可以稀疏地前置、附加、移除或重置目标，这允许我们在场景演变或通过管道的多个阶段时非破坏性地编辑场景的合成结构。以下是列表编辑参照的示例。在superLayer.usd的合成过程中将使用的/MyPrim上的引用的解析值是一个包含两个元素的列表：[ @file1.usd@，@file3.usd@ ]
文件base.usd的内容
#usda 1.0
def "MyPrim" (
references = [
@file1.usd@,
@file2.usd@
]
)
{
}
文件superLayer.usd的内容
#usda 1.0
(
subLayers = [
@./base.usd@
]
)
# Removes reference to file2.usd, while adding a reference to file3.usd at the end of the list
over "MyPrim" (
delete references = [ @file2.usd@ ]
append references = [ @file3.usd@ ]
)
{
}
Connection 连接
Connections are quite similar to relationships in that they are list-edited “scene pointers” that robustly identify other scene objects. The key difference is that while relationships are typeless, independent properties, connections are instead a sub-aspect of USD attributes. Relationships serve to establish dependencies between prims as a whole, or the dependency of a prim as a whole upon a targeted property. But they lack the expressiveness to encode, for example, complex, typed, dataflow networks such as shading networks. In networks in which each node has multiple, value-typed inputs and/or outputs, we can represent the nodes as prims, and the inputs and outputs as attributes. Each attribute is strongly typed, and connections allow each input to target an output attribute from which, in some downstream consuming application, it may receive dataflow.
连接与关系非常相似，因为它们是列表编辑的“场景指针”，可以鲁棒地标识其他场景对象。关键的区别在于，虽然关系是无类型的、独立的属性，但连接是USD属性的一个子方面。关系用于建立作为整体的prim之间的依赖关系，或者prim作为整体对目标属性的依赖关系。但是它们缺乏编码的表现力，例如，复杂的、类型化的、数据流网络，诸如着色网络。在每个节点都有多个值类型输入和/或输出的网络中，我们可以将节点表示为素数，将输入和输出表示为属性。每个属性都是强类型的，并且连接允许每个输入以输出属性为目标，在一些下游消费应用中，它可以从该输出属性接收数据流。
Connections empower USD to robustly encode dataflow networks of prims, but USD itself provides no dataflow behavior across connections. Instead, USD stipulates that schemas can impose semantics on connections, to be interpreted/implemented by the schema or higher-level systems. We do so for two reasons:
连接使USD能够稳健地编码素数的数据流网络，但USD本身不提供跨连接的数据流行为。相反，USD规定模式可以在连接上施加语义，由模式或更高级别的系统解释/实现。我们这样做有两个原因：
Consulting connections during value resolution (UsdAttribute::Get()) would necessarily slow down all attribute value resolution, whether the attribute possesses connections or not.
在值解析（UsdAttribute：：Get（））期间查询连接必然会减慢所有属性值解析的速度，无论属性是否拥有连接。Interchange is an important aspect of USD, and we are not currently willing to tackle the conformance problem of different dataflow semantics between different DCCs.
交换是USD的一个重要方面，并且我们目前不愿意解决不同DCC之间的不同数据流语义的一致性问题。
A basic example of connections, from the Simple Shading in USD tutorial, which demonstrates how USD’s shading model uses input-to-output connections to indicated render-time dataflow between shaders, and output-to-output connections on Materials to bind shader outputs to important computed results consumed by the renderer:
连接的基本示例，来自USD中的简单着色教程，该教程演示了USD的着色模型如何使用输入到输出连接来指示着色器之间的渲染时数据流，以及材质上的输出到输出连接来将着色器输出绑定到渲染器使用的重要计算结果：
def Material "boardMat"
{
token inputs:frame:stPrimvarName = "st"
token outputs:surface.connect = </TexModel/boardMat/PBRShader.outputs:surface>
def Shader "PBRShader"
{
uniform token info:id = "UsdPreviewSurface"
color3f inputs:diffuseColor.connect = </TexModel/boardMat/diffuseTexture.outputs:rgb>
float inputs:metallic = 0
float inputs:roughness = 0.4
token outputs:surface
}
def Shader "stReader"
{
uniform token info:id = "UsdPrimvarReader_float2"
token inputs:varname.connect = </TexModel/boardMat.inputs:frame:stPrimvarName>
float2 outputs:result
}
def Shader "diffuseTexture"
{
uniform token info:id = "UsdUVTexture"
asset inputs:file = @USDLogoLrg.png@
float2 inputs:st.connect = </TexModel/boardMat/stReader.outputs:result>
float3 outputs:rgb
}
}
Crate File Format
Crate文件格式
The crate file format is USD’s own binary file format, whose file extension is .usdc, and which is losslessly, bidirectionally convertible to the .usda text format. The .usd file format is special, as files with that extension can be either crate or text files; this facilitates debugging as crate files can be converted to text in-place for rapid iterative hand-editing without needing to change any referencing layers. The primary differences between text and crate files (other than the obvious human readability aspect) are:
crate文件格式是USD自己的二进制文件格式，其文件扩展名为.usdc，并且可以无损地双向转换为.usda文本格式。.usd文件格式是特殊的，因为具有该扩展名的文件可以是crate或文本文件;这便于调试，因为crate文件可以就地转换为文本，以用于快速迭代的手工编辑，而不需要改变任何参考层。文本文件和crate文件之间的主要区别（除了明显的人类可读性方面）是：
Text files must be read in their entirety, parsed, and stored in-memory as soon as they are opened, whereas crate files read in only a small index of the file’s contents when they are opened, deferring access to big data until a client requests it specifically.
文本文件一打开就必须被完整地读取、解析并存储在内存中，而crate文件在打开时只读取文件内容的一小部分索引，推迟对大数据的访问，直到客户端特别请求。Except for very small files (under a few hundred kilobytes), crate files will be much more compact than text files.
除了非常小的文件（几百KB以下），crate文件将比文本文件更紧凑。
Crate was designed for low-latency and high-performance lazy queries, and we believe it to be the best file format choice for storing scene description consumed by USD. Some of its features include:
Crate是为低延迟和高性能的惰性查询而设计的，我们相信它是存储USD使用的场景描述的最佳文件格式选择。它的一些功能包括：
Aggressive, multi-level data deduplication yields small file sizes
积极的多级重复数据消除可缩小文件大小Lockless data extraction for high-bandwidth multi-threaded reading
用于高带宽多线程阅读的无锁数据提取Access to files either by mmap() or pread(), trading VM pressure for file descriptor consumption and system call overhead. By default crate uses mmap(), but the choice is configurable at runtime.
通过mmap（）或pread（）访问文件，用VM压力换取文件描述符消耗和系统调用开销。默认情况下，crate使用mmap（），但该选项在运行时可配置。Low latency in “cold file-system cache” network access, as all data needed to open a crate file for USD’s use is compacted into a contiguous footer section.
在“冷文件系统缓存”网络访问中的低延迟，因为打开USD使用的crate文件所需的所有数据都被压缩到一个连续的页脚部分。Editing crate files does not copy all data to a new file. Instead, it appends. Disused values consume disk space, so repeated editing may produce files larger than ideal. Use usdcat to rewrite files in their most compact form.
编辑crate文件不会将所有数据复制到新文件。相反，它会添加。废弃的值会占用磁盘空间，因此重复编辑可能会产生比理想大小更大的文件。使用usdcat以最紧凑的形式重写文件。
You can convert between file formats using usdcat.
您可以使用usdcat在文件格式之间转换。
Def 定义
Def is one of the three possible specifiers a prim (and also a primSpec) can possess. A def defines a prim, which, for most consumers of USD, equates to the prim being present on the stage and available for processing. Prims whose specifier resolves to class or over are actually present and composed on a stage, but will not be visited by UsdPrim::GetChildren or UsdStage::Traverse. A def may, but need not declare a schema type for the prim. For further information see the FAQ: What’s the difference between an “over” and a “typeless def” ?
Def是prim（也是primSpec）可以拥有的三个可能的说明符之一。def定义了prim，对于USD的大多数消费者来说，这相当于prim出现在舞台上并可用于处理。指定符解析为class或以上的Prim实际上存在并组成在舞台上，但不会被UsdPrim：：GetChildren或UsdStage：：Traverse访问。def可以但不需要声明prim的模式类型。有关更多信息，请参阅常见问题解答：“over”和“typeless def”有什么区别？
The following example defines a prim /Ball as belonging to the Sphere schema, and sets its radius to 50.
下面的示例将prim /Ball定义为属于Sphere架构，并将其半径设置为50。
一个“def”定义了一个prim
def Sphere "Ball" {
double radius = 50
}
Default Value 默认值
Many assets consist entirely of a static (with respect to time) definition, which really exists “outside time”. When encoding such assets in a format that only allows timeSamples, one must choose a “sentinel” time ordinate at which to record static data, and hope that no other application uses that sentinel time for any other purpose. This can be fragile, and also lead to the “static” definition becoming overshadowed and not easily accessible when overridden in a stronger layer.
许多资产完全由一个静态的（相对于时间）定义组成，它真正存在于“时间之外”。当以仅允许timeSamples的格式编码此类资产时，必须选择一个“哨兵”时间坐标来记录静态数据，并希望没有其他应用程序将该哨兵时间用于任何其他目的。这可能是脆弱的，并且还导致“静态”定义变得黯然失色，并且当在更强的层中被覆盖时不容易访问。
USD addresses this problem by providing a completely separate field for each attribute, called its default. This field can be authored and resolved in isolation of any authored timeSamples anywhere in an attribute’s index, by using the universal, reserved sentinel UsdTimeCode::Default as the (implicit or explicit) time ordinate to UsdAttribute::Get and UsdAttribute::Set. When resolving an attribute’s value at a non-Default time, defaults still participate, but within a given primSpec, an authored default is always weaker than authored timeSamples. However, an authored default in a stronger layer/primSpec is stronger than timeSamples authored in a weaker layer. In text USD layers, the default value is the single value that can be assigned directly to an attribute in the attribute declaration line:
USD通过为每个属性提供一个完全独立的字段（称为其默认值）来解决此问题。通过使用通用的保留标记UsdTimeCode：：Default作为UsdAttribute：：Get和UsdAttribute：：Set的（隐式或显式）时间纵坐标，可以与属性索引中任何位置的任何已编写的timeSamples隔离地编写和解析此字段。当在非Default时间解析属性值时，默认值仍然参与，但在给定的primSpec中，创作的默认值总是弱于创作的timeSamples。但是，在较强层/primSpec中创作的默认值比在较弱层中创作的timeSamples更强。在文本USD图层中，默认值是可直接分配给属性声明行中的属性的单个值：
覆盖球半径的默认值
over "Ball" {
double radius = 50
}
Direct Opinion 直接意见
A direct opinion for some property or metadatum of a prim at path /foo/bar/baz in a layerStack is one that is authored “directly” on the primSpec at /foo/bar/baz in contrast to an indirect opinion on a different primSpec that affects /foo/bar/baz due to the effect of one or more composition arcs. Two examples of where we find it useful to talk about direct vs. indirect opinions are:
对于layerStack中路径/foo/bar/baz处的prim的一些属性或元数据的直接意见是“直接”在/foo/bar/baz处的primSpec上创作的意见，与由于一个或多个组合弧的影响而影响/foo/bar/baz的不同primSpec上的间接意见形成对比。两个例子说明了我们认为讨论直接与间接意见是：
A direct reference is one authored on a prim itself, as opposed to an ancestral reference , authored on some ancestor of the prim. Ancestral references are weaker than direct references, so if the targets of both the direct and ancestral references contain opinions about the same property on the prim, the opinions of the direct reference will win. This “weaker ancestor” behavior is also true for direct vs ancestral Payloads, VariantSets, Inherits, and Specializes arcs.
直接引用是在prim本身上创作的引用，而不是在prim的某个祖先上创作的祖先引用。祖先引用比直接引用弱，因此如果直接引用和祖先引用的目标都包含关于prim上相同属性的意见，则直接引用的意见将获胜。这种“较弱的祖先”行为对于直接与祖先有效载荷、VariantSets、Inherits和Specializes弧也是如此。Specializes arcs. 专门化弧线。
When prim /root/derived specializes prim /root/base in a layer, direct opinions authored on the “derived” prim in any referencing context (that is, a layerStack that references the /root prim in the original layer, or any layerStack that references the new layerStack, ad infinitum) will always be stronger than any opinions expressed directly on the “base” prim in any of the referencing contexts. See specializes for examples.
当prim /root/derived专门化层中的prim /root/base时，在任何引用上下文中（即，引用原始层中的/root prim的layerStack，或引用新layerStack的任何layerStack，直到无限）在“派生”prim上创作的直接意见将始终强于在任何引用上下文中直接在“base”prim上表达的任何意见。有关示例，请参见专门化。
EditTarget 编辑目标
When authoring composed scene description, it is often desirable to edit the targets of various composition arcs in context of the scene you are constructing, rather than needing to edit individual layers in isolation. Edit Targets, embodied by the UsdEditTarget class, allow you to work with the composed stage and the UsdPrims it contains, while specifying which contributing site in the stage’s network of composition arcs should receive the opinions you are about to author using the composed prim. You can think of Edit Targets as an extension of the idea of “selecting a layer” in Photoshop. UsdEditTarget provides specific methods for selecting any sublayer in a stage’s root layerStack, or the currently selected variant of any defined top-level or nested variantSet. In addition, You can create an EditTarget from any “Node” in a prim’s PrimIndex, which allows you to target inherited classes, reference targets, etc.
创作合成场景描述时，通常需要在正在构造的场景的上下文中编辑各种合成弧的目标，而不需要单独编辑各个层。由UsdEditTarget类实现的Edit Targets允许您使用组合舞台及其包含的UsdPrims，同时指定舞台的组合弧网络中的哪个贡献站点应接收您将要使用组合prim创作的意见。您可以将“编辑目标”视为Photoshop中“选择图层”概念的扩展。UsdEditTarget提供了特定的方法，用于选择阶段的根layerStack中的任何子层，或任何已定义的顶级或嵌套variantSet的当前选定变体。此外，您可以从prim的PrimIndex中的任何“Node”创建EditTarget，这允许您针对继承的类，引用目标等。
Fallback 回退
Many IsA Schemas and applied API Schemas define attributes that have an identifiable value that makes sense in most situations. The USD schema generation process allows a schema creator to specify such values as a fallback that will be implicitly present on an attribute even when no values have been authored for it. The presence of fallback values allows us to keep our scene description sparse and compact, and allows for self-documenting behavior. Fallbacks are deployed extensively in the UsdGeom schemas, for example UsdGeomImageable’s visibility attribute has a fallback value of inherited, and UsdGeomGprim’s orientation attribute has a fallback of rightHanded.
许多伊萨模式和应用的API模式定义的属性具有在大多数情况下有意义的可识别值。USD模式生成过程允许模式创建者指定这样的值作为回退，该回退将隐式地存在于属性上，即使没有为其创作值。回退值的存在允许我们保持场景描述的稀疏和紧凑，并允许自记录行为。在UsdGeom模式中广泛部署了回退，例如UsdGeomImageable的visibility属性的回退值为inherited，而UsdGeomGprim的orientation属性的回退值为rightHanded。
Flatten Flatten
Even though USD derives great efficiencies from accessing data directly from the layers that a stage composes together as directed by the various composition arcs that weave the files together, it can sometimes be useful to “bake down the composition” into a single layer that no longer contains any composition arcs. A flattened stage is highly portable since its single layer is self-contained, and in some cases, it may be more efficient to compose and resolve, although this is definitely not a given. For example, flattening a stage to an text USD layer will generally produce extremely large files since assets that were referenced multiple times on a stage will be uniquely baked out into their own namespaces, with all data duplicated; the crate file format will perform better in this metric, at least, since it performs data deduplication. Regardless of file format, the action of flattening a stage will generally be memory and compute-intensive, and will not, at this time, benefit from multithreading.
尽管USD从直接从阶段如将文件编织在一起的各种合成弧所指示的那样合成在一起的层访问数据获得了很高的效率，但是有时将合成“烘焙”到不再包含任何合成弧的单个层中可能是有用的。扁平化阶段是高度可移植的，因为其单层是自包含的，并且在某些情况下，它可以更有效地合成和解析，尽管这绝对不是给定的。例如，将舞台展平为文本USD层通常会产生非常大的文件，因为在舞台上被多次引用的资产将被唯一地烘焙到其自己的名称空间中，所有数据都是重复的; Crate文件格式至少在该度量中表现更好，因为它执行数据去重复。 无论文件格式如何，展平阶段的操作通常都是内存和计算密集型的，并且此时不会从多线程中受益。
To flatten a stage, use UsdStage::Flatten or usdcat with the --flatten option.
若要展平舞台，请使用UsdStage：：Flatten或usdcat并使用选项。
To flatten individual layer stacks, use UsdUtilsFlattenLayerStack or usdcat with the --flattenLayerStack option.
若要展平单个图层堆栈，请使用UsdUtilsFlattenLayerStack或usdcat并选择。
Gprim Gprim
Gprim comes from Pixar’s RenderMan terminology, and is a contraction for “Geometric primitive”, which is to say, any primitive whose imaging/rendering will directly cause something to be drawn. Gprim is a first-class concept in USD, embodied in the class UsdGeomGprim. All Gprims possess the following qualities:
Gprim来自Pixar的RenderMan术语，是“几何图元”的缩写，也就是说，任何其成像/渲染将直接导致绘制的图元。Gprim是USD中的一个一流概念，具体体现在类UsdGeomGprim中。所有GPrims都具有以下特性：
Gprims are boundable, and should always submit to computing an extent (even if it be an empty extent), and valid UsdGeom scene description should always provide an authored extent on a gprim that captures its changing shape (if its shape is animated).
GPrim是有界的，并且应该始终服从于计算范围（即使它是空范围），并且有效的UsdGeom场景描述应该始终在捕获其变化形状的gprim上提供创作范围（如果其形状是动画的）。Gprims are directly transformable , which is the primary distinguishing factor between UsdGeomGprim and Autodesk Maya’s similar “shape” node type. Transformable gprims necessitate fewer prims overall in most 3D compositions, which aids scalability, since prim-count is one of the primary scaling factors for USD.
GPrim可直接变换，这是UsdGeomGprim与Autodesk Maya的类似“形状”节点类型之间的主要区别因素。在大多数3D合成中，可变换的gprims需要更少的prims，这有助于可扩展性，因为prim-count是USD的主要缩放因子之一。
Effectively structuring gprims in namespace
在命名空间中有效地构造GPrims
Please observe the following two rules when laying out gprims in a namespace hierarchy:
在命名空间层次结构中布局gprims时，请遵守以下两条规则：
-
Do not nest gprims in namespace.
不要在命名空间中嵌套gprims。We consider it invalid to nest gprims under other gprims, and usdchecker will issue warnings on scenes that contain this construct. This is because key features of USD apply hierarchically and are “pruning”, such as activation and visibility. When an ancestor gprim is deactivated or made invisible, there is no possible way to make any descendant gprim active or visible.
我们认为将gprims嵌套在其他gprims下是无效的，usdchecker将在包含此构造的场景上发出警告。这是因为USD的关键功能是分层应用的，并且是“修剪”的，例如激活和可见性。当祖先gprim被停用或不可见时，没有可能的方法使任何后代gprim活动或可见。 -
Do not directly instance gprims.
不要直接实例化gprims。Because the root-prims of instance prototypes possess no properties, it is pointless to instance a gprim directly. Renderers must not infer instanceability from an instance of a gprim prototype, because each instance is allowed to override any property defined originally on the referenced prototype root prim. One can use USD’s instancing feature to create gprim-level instancing, but to do so requires adding an Xform parent to the gprim in the prototype, and making the instances reference the parent, rather than the gprim, directly.
因为实例原型的根素数没有属性，所以直接实例化gprim是没有意义的。渲染器不能从gprim原型的实例中推断出可实例性，因为每个实例都可以覆盖最初在引用的原型根prim上定义的任何属性。可以使用USD的实例化特性来创建gprim级别的实例化，但是这样做需要在原型中向gprim添加Xform父对象，并使实例直接引用父对象，而不是gprim。
Group 组
In USD a group is a kind of Model. Groups are models that aggregate other models into meaningful collections. Whereas the specialized group-model kind assembly generally identifies group models that are published assets, groups tend to be simple “inlined” model prims defined inside and as part of assemblies. They are the “glue” that holds a model hierarchy together.
在USD中，组是一种模型。组是将其他模型聚合成有意义的集合的模型。尽管专门的组模型种类程序集通常标识作为已发布资产的组模型，但组往往是在程序集内部定义并作为程序集的一部分的简单的“内联”模型prim。它们是将模型层次结构保持在一起的“粘合剂”。
“装配”资产，包含用于组织其子部件的“组”模型
def Xform "Forest_set" (
kind = "assembly"
)
{
def Xform "Outskirts" (
kind = "group"
)
{
# More deeply nested groups, bottoming out at references to other assemblies and components
}
def Xform "Glade" (
kind = "group"
)
{
# More deeply nested groups, bottoming out at references to other assemblies and components
}
}
See also: model hierarchy
参见：模型层次结构
Hydra Hydra
Hydra is a modern rendering architecture optimized for handling very large scenes and “change processing” (i.e. responding to authored or time-varying changes to the scene inputs). It has three major components: the scene delegates (which provide scene data), the render index (responsible for change tracking and other scene management), and the render delegates (which consume the scene data to produce an image). This flexible architecture allows for easy integration within pipelines that have their own scene data, as well as their own renderers. Pixar uses Hydra for asset preview in many of its tools, including usdview and the Presto Animation System.
Hydra是一种现代渲染架构，针对处理非常大的场景和“更改处理”（即响应于对场景输入的创作的或时变的改变）。它有三个主要组成部分：场景委托（提供场景数据）、渲染索引（负责变化跟踪和其他场景管理）和渲染委托（消耗场景数据以产生图像）。这种灵活的体系结构允许在具有自己的场景数据以及自己的渲染器的管道内轻松集成。Pixar在其许多工具中使用Hydra进行资源预览，包括usdview和Presto Animation System。
Index 索引
An index, also referred to as a PrimIndex, is the result of composition, and the primary piece of information we compute and cache for a composed prim on a stage. A prim’s index contains an ordered (from strongest to weakest) list of “Nodes”, which are all of the locations in layers (also known as primSpecs) that contribute opinions to the data contained in the composed prim, as well as an indication of how each location was woven into the composite, i.e. what composition arc was traversed to discover it.
索引，也称为PrimIndex，是合成的结果，也是我们为舞台上的合成prim计算和缓存的主要信息。prim的索引包含“节点”的有序（从最强到最弱）列表，这些节点是层（也称为primSpecs）中的所有位置，这些位置对包含在合成prim中的数据提供意见，以及每个位置如何编织到合成中的指示，即是什么成分的弧被遍历来发现它。
All of the queries on USD classes except for stage-level metadata rely on prim indices to perform value resolution. USD also uses prim indices to compute primStacks for debugging, and to construct Edit Targets.
除了阶段级元数据之外，USD类上的所有查询都依赖prim索引来执行值解析。USD还使用prim索引来计算primStacks以进行调试，并构造Edit Targets。
Inherits 继承
Inherits is a composition arc that addresses the problem of adding a single, non-destructive edit (override) that can affect a whole class of distinct objects on a stage. Inherits acts as a non-destructive “broadcast” operator that applies opinions authored on one prim to every other prim that inherits the “source” prim; not only do property opinions broadcast over inherits arcs - all scene description, hierarchically from the source, inherits. Consider the following example:
Inherits是一个合成弧，它解决了添加单个非破坏性编辑（覆盖）的问题，该编辑可能会影响舞台上的整个不同对象类。Inherits充当一个非破坏性的“广播”操作符，它将在一个prim上创作的意见应用于继承“源”prim的每个其他prim;不仅属性意见在继承弧上广播-所有场景描述从源分层地继承。请考虑以下示例：
trees.usd，演示继承
#usda 1.0
class Xform "_class_Tree"
{
def Mesh "Trunk"
{
color3f[] primvars:displayColor = [(.8, .8, .2)]
}
def Mesh "Leaves"
{
color3f[] primvars:displayColor = [(0, 1, 0)]
}
}
def "TreeA" (
inherits = </_class_Tree>
)
{
}
def "TreeB" (
inherits = </_class_Tree>
)
{
over "Leaves"
{
color3f[] primvars:displayColor = [(0.8, 1, 0)]
}
}
If you paste the example into a .usda file and view the composed result in usdview, you will see that /TreeA and /TreeB both inherit the child prims and properties nested inside /_class_Tree You can also observe an important property of inherits behavior in /TreeB/Leaves, which is that inherited opinions are weaker than direct opinions on prims that inherit the opinions. This allows us to always create exceptions to the broadcast behavior of inherits, in the same layerStack in which we are broadcasting inherited overrides.
如果你将示例粘贴到.usda文件中，并在usdview中查看合成结果，你会看到/TreeA和/TreeB都继承了嵌套在/_class_Tree中的子素数和属性。你还可以观察到/TreeB/Leaves中的继承行为的一个重要属性，那就是继承的意见比继承意见的素数的直接意见弱。这允许我们总是在广播继承覆盖的同一个layerStack中创建继承广播行为的异常。
The specifier for /_class_Tree is class. This is not a requirement. A prim can inherit from any prim that is neither a descendant nor ancestor of itself, regardless of the prim’s specifier or type. However, when inherits are used as a “broadcast edit” facilitator, we don’t typically expect the prims into which we deposit the edits to be processed directly when we (for example) render a scene - their purpose is to convey edits to other prims, and may not even contain a complete definition of any prim(s). Using a class specifier for these “edit holders” ensures that standard stage traversals will skip the prims, and generally conveys intent that the prim will be inherited by other prim(s).
/_class_Tree的说明符是class。这不是一个要求。prim可以继承自任何既不是其后代也不是其祖先的prim，无论prim的说明符或类型如何。然而，当继承被用作“广播编辑”促进器时，我们通常不期望在我们（例如）渲染场景时直接处理我们存款编辑的prim-它们的目的是将编辑传达给其他prim，甚至可能不包含任何prim的完整定义。对这些“编辑保持器”使用类说明符确保标准阶段遍历将跳过prim，并且通常传达prim将被其他prim继承的意图。
A good way to understand inherits is to start by understanding references. In the above example, if you replace both “inherits = “ with “references = “ and view the composition, the results will be indistinguishable from each other! Within a layerStack (and ignoring any interaction with variantSets since VariantSets come between Inherits and References in LIVRPS) inherits are indistinguishable in effect from local references. The key difference between references and inherits is that references fully encapsulate their targets, and therefore “disappear” when composed through another layer of referencing, whereas the relationship between inheritors and their inherits target remains “live” through arbitrary levels of referencing. In other words, when a prim inherits from another prim, it subscribes itself and all referencing contexts to changes made to the inherited prim. You can see this difference with the following example that uses the previous example as Trees.usd:
理解继承的一个好方法是从理解引用开始。在上面的例子中，如果你用“references =“替换“inherits =“并查看组合，结果将无法区分彼此！在layerStack中（并且忽略与variantSets的任何交互，因为VariantSets位于LIVRPS中的Inherits和References之间），继承与本地引用的效果是不可区分的。引用和继承之间的关键区别在于，引用完全封装了它们的目标，因此当通过另一层引用组合时“消失”，而继承者和其继承目标之间的关系通过任意级别的引用保持“活”。换句话说，当一个prim从另一个prim继承时，它将自己和所有引用上下文订阅对继承的prim所做的更改。您可以通过下面的示例看到这种差异，该示例使用前面的示例Trees.usd：
Forest.usd，演示通过引用继承传播
#usda 1.0
# A new prim, of the same name as the original inherits target, providing new overrides
class "_class_Tree"
{
token size = "small"
# It's autumn in California
over "Leaves"
{
color3f[] primvars:displayColor = [(1.0, .1, .1)]
}
}
# TreeB_1 still inherits from _class_Tree because its referent does
def "TreeB_1" (
references = @./Trees.usd@</TreeB>
)
{
}
Viewing the flattened Forest.usd you can observe that /TreeB_1 has both all the structure inherited from /_class_Tree in Trees.usd, but also the size attribute it inherits from /_class_Tree in its own defining layer; as well, even though the referenced /TreeB had specified its own primvars:displayColor for its Leaves prim, the reddish color override in /class_Tree wins. Were you to change the inherits to references in Trees.usd, /TreeB_1 would not compose the size attribute and its Leaves would retain their original color, and the only way to broadcast changes to all instances of the original /_class_Tree in Forest.usd would be to destructively edit the Trees.usd file. There is a runtime cost to keeping inherits live, so you may want to avoid proactively adding inherits everywhere just in case you may want to “override all XXX”. Deploy inherits where they are likely to be useful; for example, at asset root-prims.
查看展平的Forest.usd，可以观察到/TreeB_1在Trees.usd中既有继承自/_class_Tree的所有结构，也有继承自/_class_Tree的size属性;同样，即使被引用的/TreeB为其Leaves prim指定了自己的primvars：displayColor，/class_Tree中的红色覆盖也会胜出。如果要更改Trees.usd中引用的继承，/TreeB_1将不会组成size属性，它的Leaves将保留它们的原始颜色，并且将更改广播到Forest.usd中原始/_class_Tree的所有实例的唯一方法是破坏性地编辑Trees.usd文件。保持继承活动会有运行时成本，因此您可能希望避免在任何地方主动添加继承，以防万一您可能希望“覆盖所有XXX”。在可能有用的地方部署继承;例如在资产根素数处。
Instanceable 可实例化
Instanceable is a metadatum that declares whether a given prim should be considered as a candidate for instancing, and is authored via UsdPrim::SetInstanceable. If instanceable = true on a prim, then the prim will become an instance of an implicit prototype when composed on a stage, if and only if the prim also contains one or more direct composition arcs. It does not matter whether instanceable is authored in a referenced layer (on the prim being referenced) or in the layer (or a super-layer) in which the reference is authored: only the composed value on the prim matters. See Instancing for more information.
Instanceable是一个元文件，它声明是否应该将给定的prim视为实例化的候选者，并通过UsdPrim：：SetInstanceable创作。如果instanceable = true，那么当且仅当prim还包含一个或多个直接合成弧时，prim将成为隐式原型的instance。instanceable是在被引用的层（在被引用的prim上）中创作还是在创作引用的层（或超层）中创作并不重要：只有基本上的组成值才重要。有关详细信息，请参见实例化。
Instancing 实例化
Instancing in USD is a feature that allows many instances of “the same” object to share the same representation (composed prims) on a UsdStage. In exchange for this sharing of representation (which provides speed and memory benefits both for the USD core and, generally, for clients processing the UsdStage), we give up the ability to uniquely override opinions on prims beneath the “instance root”, although it is possible to override opinions that will affect all instances’ views of the data. Instancing is controlled by authored metadata, and can be overridden in stronger layers, so it is possible to “break” an instance when necessary, if it must be uniquified.
USD实例化是一种允许“同一”对象的许多实例在USdStage上共享相同的表示（组合素数）的功能。作为这种表示共享的交换（这为USD核心以及通常为处理UsdStage的客户端提供了速度和内存优势），我们给予了唯一覆盖“实例根”下prim的意见的能力，尽管可以覆盖影响所有实例对数据的视图的意见。实例化由创作的元数据控制，并且可以在更强的层中被覆盖，因此如果必须统一实例，则可以在必要时“破坏”实例。
Background: 背景资料：
When you add a reference, inherits, specializes, or payload to a prim, the targeted scene description will be composed onto the referencing stage, causing new prims to compose beneath the anchoring prim, and allowing the referencing stage to override any of the targeted prims or properties. See, for example, the Trees.usd snippet in the Inherits entry. Often we build large environments by referencing in many copies of “simple” assets into a larger assembly; we add quotes around “simple” because it is a matter of perspective and scale: an office chair asset may consist of hundreds of prims, for example. Although the asset files are shared by a UsdStage each time we add a new reference to any given asset, we compose a unique copy of all of the prims that asset contains. This is a requirement to be able to non-destructively edit the prims, and conversely for clients to see the unique overrides that may be applied to each copy of the asset. However, since number of prims on a stage is one of the primary factors that governs how USD scales, this cost can become prohibitive as environment size grows, regardless of how many improvements we make over time to the per-prim cost in USD.
当您将引用、继承、专门化或负载添加到prime时，目标场景描述将合成到引用阶段，从而导致新的prime在锚定prime下面合成，并允许引用阶段覆盖任何目标prime或特性。例如，请参见Inherits条目中的Trees.usd片段。通常我们通过将许多“简单”资产的副本引用到一个更大的程序集中来构建大型环境;我们在“简单”周围加上引号，因为这是一个视角和规模的问题：例如，办公椅资产可以由数百个prim组成。尽管每次向任何给定资源添加新引用时，UsdStage都会共享资源文件，但我们会组成该资源包含的所有prim的唯一副本。这是一个要求，以便能够非破坏性地编辑prim，反过来，客户端可以看到可以应用于资产的每个副本的唯一覆盖。 但是，由于舞台上的prim数量是决定USD如何扩展的主要因素之一，因此，随着环境规模的增长，无论我们对以USD为单位的每prim成本进行了多少改进，该成本都可能变得过高。
Pay for what you need:
支付您所需的费用：
Often, however, an environment will need to express very few overrides on the assets it references, and the majority of the overrides it tends to need to override bind naturally on the root prim of the asset. This observation provides us with a means to apply a philosophy to which we try to adhere broadly in USD: pay runtime cost only for the features you need to use. By making a reference instanceable, we declare to USD that we will not need to express any overrides on the prims beneath the reference anchor (and any overrides already present in the referencing context will be ignored). In response to finding an instanceable composition arc, a UsdStage will prune its prim composition at the instanceable prim, and make note of the targeted layer(s) and the arcs used to target them, as an “instancing key”. The stage will create a prototype for each unique instancing key, composing fully - just once - all of the prims that would otherwise appear redundantly under each of the instances, and note the relationship between each instance and its prototype. Default stage traversals terminate at instances (because instances are not allowed to have prim children), and from any prim for which UsdPrim::IsInstance is true, a client can identify and process its prototype using UsdPrim::GetPrototype.
然而，通常情况下，一个环境将需要在它引用的资产上表达非常少的覆盖，并且它倾向于需要覆盖的大多数覆盖自然地绑定在资产的根prim上。这一观察为我们提供了一种方法来应用我们试图在USD中广泛坚持的哲学：只为你需要使用的特性支付运行时成本。通过使引用可实例化，我们向USD声明，我们将不需要在引用锚下的prims上表达任何覆盖（并且引用上下文中已经存在的任何覆盖将被忽略）。响应于找到可实例化合成弧，UsdStage将在可实例化引物处修剪其引物合成，并且记录目标层和用于将它们作为目标的弧，作为“实例化键”。 该阶段将为每个唯一的实例键创建一个原型，完全组成（仅一次）否则将在每个实例下冗余出现的所有素数，并注意每个实例与其原型之间的关系。默认阶段遍历在实例处终止（因为实例不允许有prim子级），并且从UsdPrim：：IsInstance为true的任何prim，客户端可以使用UsdPrim：：GetPrototype识别和处理其原型。
This behavior can be described as explicit instances, with implicit prototypes: clients are required to be explicit about what prims should be instanced, so that it is not possible to inadvertently defeat instancing by sublayering a new layer that (unintentionally) contains overrides beneath an instanced prim in namespace, and so that we can very efficiently determine where to apply instancing. Unlike “explicit prototype” schemes, which require (in USD terminology) a prim/tree to be explicitly added on a stage as concrete prims before adding instances using relationships, a UsdStage manages the creation of prototypes for you, as an implicit result of which instanceable layers you have referenced; this can lead to greater sharing than “explicit prototypes” because if instances of the same asset appear in more than one referenced assembly in a scene, they will be identified as sharing the same prototype, which is not true for explicit prototypes. Extending the Trees.usd example, by making both /TreeA and /TreeB instanceable, they will share the same composed Trunk and Leaves prims inside the prototype created out of /_class_Tree. Note that the override expressed on /TreeB/Leaves will be ignored, because we have declared /TreeB to be instanceable. Like most features in USD, instanceability can be overridden in stronger layers, so if a Forest.usd layer referenced /TreeB in Trees.usd and overrode instanceable = false, then in that context, /TreeB would get back its own Trunk and Leaves children, with the override for displayColor on its Leaves child prim.
这种行为可以描述为显式实例，带有隐式原型：客户端需要明确地知道应该实例化什么prim，从而不可能通过对命名空间中的实例化prim之下（无意地）包含覆盖的新层进行子层化而无意地使实例化失败，并且从而我们可以非常有效地确定在何处应用实例化。与“显式原型”方案不同，它要求（在USD术语中）在使用关系添加实例之前，将prim/tree显式添加到stage上作为具体prim，UsdStage为您管理原型的创建，作为您引用的可实例化层的隐式结果;这可以导致比“显式原型”更大的共享，因为如果相同资源的实例出现在场景中的多于一个被引用的集合中，则它们将被标识为共享相同的原型，这对于显式原型是不正确的。延伸树木。usd示例，通过使/TreeA和/TreeB都可实例化，它们将在/_class_Tree创建的原型中共享相同的组合Trunk和Leaves prims。注意，在/TreeB/Leaves上表达的覆盖将被忽略，因为我们已经声明/TreeB是可实例化的。像USD中的大多数功能一样，可实例性可以在更强的层中被覆盖，因此如果Forest.usd层引用Trees.usd中的/TreeB并覆盖instanceable = false，那么在该上下文中，/TreeB将返回自己的Trunk和Leaves子对象，并在其Leaves子对象prim上覆盖displayColor。
#usda 1.0
class Xform "_class_Tree"
{
def Mesh "Trunk"
{
color3f[] primvars:displayColor = [(.8, .8, .2)]
}
def Mesh "Leaves"
{
color3f[] primvars:displayColor = [(0, 1, 0)]
}
}
def "TreeA" (
inherits = </_class_Tree>
instanceable = true
)
{
}
def "TreeB" (
inherits = </_class_Tree>
instanceable = true
)
{
over "Leaves"
{
color3f[] primvars:displayColor = [(0.8, 1, 0)]
}
}
For more information on usage and examples, see Scenegraph Instancing in the USD Manual.
有关用法和示例的详细信息，请参阅USD手册中的场景图实例化。
Interpolation 插值
Interpolation appears in two different contexts in USD:
在USD中，插值出现在两种不同的上下文中：
-
Temporal Interpolation of values in attribute value resolution.
属性值解析中值的时间插值。By default, when UsdAttribute::Get resolves a value from timeSamples, if the value-type supports linear interpolation, the returned value will be linearly interpolated between the timeSamples that bracket the requested sample time. This behavior can be inhibited for all attributes on a stage by calling UsdStage::SetInterpolationType(UsdInterpolationTypeHeld), which will force all timeSamples to resolve with held interpolation.
默认情况下，当UsdAttribute：：Get解析timeSamples中的值时，如果值类型支持线性插值，则返回的值将在包含请求的采样时间的timeSamples之间进行线性插值。通过调用UsdStage：：SetInterpolationType（UsdInterpolationTypeHeld），可以禁止舞台上所有属性的此行为，这将强制所有timeSamples使用保持的插值进行解析。Linear interpolation is the default interpolation mode for timeSamples because composition arcs can apply time-scales and offsets to the data they reference, and therefore data that was originally smoothly sampled can easily become poorly filtered and sampled in a referencing context if value resolution preformed only point or held interpolation: it would become every client’s responsibility to attempt to sample the data smoothly, which would be difficult given that the function that maps stage-time to the time of the layer in which the timeSamples were authored is not easily accessible.
线性插值是timeSamples的默认插值模式，因为合成弧可以将时间尺度和偏移应用于它们所引用的数据，因此，如果值分辨率仅执行点插值或固定插值，则最初平滑采样的数据很容易在引用上下文中变得过滤和采样不佳：尝试平滑地对数据进行采样将成为每个客户端的责任，这将是困难的，因为将阶段时间映射到创作timeSamples的层的时间的函数不容易访问。 -
Spatial Interpolation of Primvar values across a gprim.
跨gprim的Primvar值的空间插值。Interpolation is also the name we give to the metadatum that describes how the value(s) in a primvar will interpolate over a geometric primitive when that primitive is subdivided for rendering. The interpretation of interpolation depends on the type of gprim; for example, on a Mesh primitive, a primitive can contain a single value to be held across the entire mesh, one value per-face, one value per-point to be interpolated either linearly or with the mesh’s subdivision basis function, or one value per face-vertex. For more information, see Interpolation of Primitive Variables.
插值也是我们给元数据集起的名字，它描述了当几何图元被细分以进行渲染时，primvar中的值将如何插值到该图元上。插值的解释取决于gprim的类型;例如，在网格基本体上，基本体可以包含要在整个网格上保持的单个值、每个面一个值、要线性地或用网格的细分基函数内插的每个点一个值、或者每个面顶点一个值。有关详细信息，请参见基本变量的插值。
IsA Schema 爸爸schema
An IsA schema is a prim Schema that defines the prim’s role or purpose on the Stage. The IsA schema to which a prim subscribes is determined by the authored value of its typeName metadata, from which it follows that a prim can subscribe to at most one IsA schema - unlike API schemas, to which a prim can subscribe many. In terms of the USD object model, IsA schemas derive from the C++ class UsdTyped and derive their name from the fact that UsdPrim::IsA<SomeSchemaClass>() will return true for any prim whose typeName is or derives from SomeSchemaClass.
伊萨架构是定义舞台上prim的角色或目的的prim架构。prim订阅的伊萨模式由其typeName元数据的创作值确定，由此得出prim最多可以订阅一个IsA模式-与API模式不同，prim可以订阅许多。在USD对象模型方面，伊萨模式派生自C++类UsdTyped，并从UsdPrim：：IsA（）将为typeName是SomeSchemaClass或从SomeSchemaClass派生的任何prim返回true的事实派生它们的名称。
IsA schemas can be either abstract or concrete; UsdGeomImageable is an abstract IsA schema: many prims will answer true to UsdPrim::IsA<UsdGeomImageable>(), but there is no UsdGeomImageable::Define() method because you cannot create a prim of type Imageable. UsdGeomMesh, however, is a concrete IsA schema, since it has a Define() method and prims can possess the typeName Mesh.
伊萨模式可以是抽象的，也可以是具体的; UsdGeomImageable是一个抽象的IsA模式：许多prim将对UsdPrim：：伊萨（）回答true，但没有UsdGeomImageable：：Define（）方法，因为您无法创建Imageable类型的prim。然而，UsdGeomMesh是一个具体的IsA模式，因为它有一个Define（）方法，并且prims可以拥有typeNameMesh。
IsA schemas can provide fallback values for the properties they define, which will be reflected at runtime in the prim definition.
伊萨模式可以为它们定义的属性提供回退值，这些回退值将在运行时反映在prim定义中。
IsA schemas can be generated using the USD schema generation tools, but they can also be created manually.
伊萨模式可以使用USD模式生成工具生成，但也可以手动创建。
Kind Kind
Kind is a reserved, prim-level metadatum whose authored value is a simple string token, but whose interpretation is backed by an extensible hierarchical typing-system managed by the KindRegistry singleton. We use kind to classify prims in USD into a higher-level categorization than the prim’s schema type provides, principally to assign roles according to USD’s organizational notion of “Model Hierarchy”. Out of the box, USD’s KindRegistry comes pre-loaded with a type hierarchy rooted with the base type of “model”, as well as an independent type “subcomponent”, like so:
Kind是一个保留的prim-level元数据，其创作的值是一个简单的字符串标记，但其解释由KindRegistry单例管理的可扩展分层类型系统支持。我们使用类分类在USD的prim到一个更高级别的分类比prim的模式类型提供，主要是分配角色根据USD的组织概念“模型层次”。开箱即用，USD的KindRegistry预装了一个以“model”为基础的类型层次结构，以及一个独立的类型“subcomponent”，如下所示：
model - base class for all model kinds. “model” is considered an abstract type and should not be assigned as any prim’s kind.
model -所有模型类型的基类。“model”被认为是抽象类型，不应被指定为任何prim的类型。group - models that simply group other models. See Model Hierarchy for why we require “namespace contiguity” of models
组-模型，简单地将其他模型分组。请参阅模型层次，了解为什么我们需要模型的“命名空间邻接”assembly - an important group model, often a published asset or reference to a published asset
组件-一个重要的组模型，通常是已发布的资产或对已发布资产的引用component - a “leaf model” that can contain no other models
组件-一个不能包含其他模型的“叶模型”subcomponent - an identified, important “sub part” of a component model.
子组件-组件模型的已识别的重要“子部分”。
You can query a prim’s kind using UsdModelAPI::GetKind; several other queries on UsdPrim are derived from a prim’s kind, such as the UsdPrim::IsModel and UsdPrim::IsGroup queries.
您可以使用UsdModelAPI：：GetKind查询prim的种类; UsdPrim上的其他几个查询都是从prim的种类派生出来的，比如UsdPrim：：IsModel和UsdPrim：：IsGroup查询。
Layer 层
A Layer is the atomic persistent container of scene description for USD. A layer contains zero or more PrimSpecs, that in turn describe Property and Metadata values. Each layer possesses an identifier that can be used to construct references to the layer from other layers.
层是USD场景描述的原子持久容器。一个图层包含零个或多个PrimSpecs，这些PrimSpecs依次描述“特性”和“元数据”值。每个层都拥有一个标识符，该标识符可用于构造从其他层到该层的引用。
SdfLayer provides both the “document model” for layers, and the interface by which USD authors to and extracts data from layers. The SdfLayer interface serves data according to the USD prim/property/metadata data model, but the actual encoding of data in the backing file is quite flexible, thanks to the SdfFileFormat plugin interface. By implementing a sub-class of SdfFileFormat and associating it with a unique file extension for USD’s consumption, we can enable direct USD referencing of layers expressed as files of any format whose encoding can reasonably be translated into USD. This is not only how USD supports direct consumption of Alembic (.abc) files, but also how USD’s native text and crate binary representations are provisioned.
SdfLayer既提供了层的“文档模型”，也提供了USD编写层并从中提取数据的接口。SdfLayer接口根据USD prim/property/metadata数据模型提供数据，但由于SdfFileFormat插件接口，备份文件中的数据实际编码非常灵活。通过实现SdfFileFormat的子类并将其与用于USD消费的唯一文件扩展名相关联，我们可以启用直接USD引用层，这些层表示为任何格式的文件，其编码可以合理地转换为USD。这不仅是USD支持直接消费Alembic（.abc）文件的方式，也是USD的原生文本和crate二进制表示的方式。
Data authored to layers by applications or scripts will remain in memory until SdfLayer::Save is called on the layer. If a program is writing more data than fits in the program’s memory allotment, we suggest:
应用程序或脚本编写到图层的数据将保留在内存中，直到对图层调用SdfLayer：：保存。如果一个程序写入的数据超过了程序的内存分配，我们建议：
Using USD’s native binary crate format (which is the default file format for files created with the .usd file extension)
使用USD的原生二进制crate格式（这是使用.usd文件扩展名创建的文件的默认文件格式）Calling layer.Save() periodically: doing so will flush all of the heavy property-value data from memory into the file, while leaving the file open and available for continued writing of data. Only the crate binary format possesses this “flushability” property; USD’s text representation can only be written out sequentially beginning-to-end, and cannot be digested lazily, therefore it cannot be authored incrementally and must always keep all of its data in-memory; other formats do not allow incremental saving because they must translate USD’s encoding into their own format that does not itself allow incremental saving, like the Alembic FileFormatPlugin.
调用层。定期保存（）：这样做会将所有重属性值数据从存储器冲洗到文件中，同时使文件打开并可用于继续写入数据。只有crate二进制格式才具有这种“可刷新性”属性; USD的文本表示只能按顺序从头到尾写出，不能被懒惰地消化，因此它不能被增量创作，必须始终将其所有数据保存在内存中;其他格式不允许增量保存，因为它们必须将USD的编码转换成自己的格式，而这种格式本身不允许增量保存，例如Alembic FileFormatPlugin。
Although layers exist first and foremost to define the persistent storage representation of USD data, one can also create temporary, “in-memory” layers for lightweight (in that there is no filesystem access required) USD data storage, via UsdStage::CreateInMemory.
虽然层首先是用来定义USD数据的持久存储表示，但也可以通过UsdStage：：CreateInMemory为轻量级（不需要文件系统访问）USD数据存储创建临时的“内存中”层。
Layer Offset 图层偏移
Composition arcs such as References and SubLayers can include an offset and scaling of time to be applied during attribute value resolution for all data composed from the target layer. We call this a Layer Offset, embodied in SdfLayerOffset. Layer offsets compose, so that if A references B with a time-scale of 2.0 and B references C with a time-scale of 3.5, then data resolved at A whose source is C will have a total time-scale of 7.0 applied to it.
合成弧（例如“引用”和“子层”）可以包括要在属性值解析期间对从目标层合成的所有数据应用的时间偏移和缩放。我们称之为层偏移，具体体现在SdfLayerOffset中。层偏移合成，使得如果A以2.0的时间尺度引用B并且B以3.5的时间尺度引用C，则在A处解析的数据（其源是C）将具有应用于其的总时间尺度7.0。
When an arc has both an offset and scale applied, the referenced animation is first scaled, then offset as it is brought into the referencing layer. So, in the following example, a timeSample at timeCode 12 in the file someAnimation.usd will appear at ((12 * 0.5) + 10) = 16 as resolved from the referencing layer. Layer offsets cannot themselves vary over time. If a consuming context requires variable retiming of referenced data, it can use the more powerful (and somewhat more costly) Value Clips feature.
当圆弧同时应用了偏移和缩放时，首先缩放被引用的动画，然后在将其引入到引用层时进行偏移。因此，在下面的示例中，文件someAnimation.usd中的timeSample在timeCode 12处将出现在（（12 * 0.5）+ 10）= 16处，这是从参考层解析的。层偏移本身不能随时间变化。如果消费上下文需要对引用数据进行可变的重新定时，则可以使用功能更强大（而且成本更高）的Value Clips特性。
子图层偏移/比例（以USDA计）
#usda 1.0
(
subLayers = [
@./someAnimation.usd@ (offset = 10; scale = 0.5)
]
)
LayerStack LayerStack
LayerStacks are the keystone to understanding composition in USD. The definition of a LayerStack is simply:
LayerStacks是理解USD组合的基石。LayerStack的定义很简单：
The LayerStack is important to understanding composition for two reasons:
LayerStack对于理解组合很重要，原因有两个：
Composition Arcs target LayerStacks, not Layers.
合成弧的目标是LayerStacks，而不是Layers。When a layer references (or payloads or sub-layers) another layer, it is targeting (and therefore composing) not just the data in the single layer, but all the data (in strength-order) in the LayerStack rooted at the targeted layer.
当一个层引用（或有效载荷或子层）另一个层时，它不仅瞄准（并因此组成）单个层中的数据，而且瞄准（以强度顺序）根植于目标层的LayerStack中的所有数据。LayerStacks provide the container through which references can be list-edited.
LayerStacks提供了一个容器，通过该容器可以对引用进行列表编辑。Many of the composition arcs (as well as relationships) describe not just a single target, but an orderable list of targets, that will be processed (in order) according to the type of the arc. References can be list edited among the layers of a LayerStack. This can be a powerful method of non-destructively changing the large-scale structure of a scene as it flows down the pipeline.
许多合成弧（以及关系）描述的不仅仅是单个目标，而是可排序的目标列表，这些目标将根据弧的类型（按顺序）进行处理。可以在LayerStack的层之间对参照进行列表编辑。这可以是一种强大的方法，当场景沿着管道流动时，非破坏性地改变场景的大规模结构。
For example, we might have a generic version of a special effect added into a scene at the sequence level:
例如，我们可能会在序列级别将特效的通用版本添加到场景中：
sequenceFX.usd，它将引用添加到可能从较弱层引用的资产上
#usda 1.0
over "World"
{
over "Props"
{
over "Prop_145" (
prepend references = @sequenceFX/turbulence.usd@
)
{
}
}
}
Now, at the shot-level, we have a shotFX.usd layer that participates in the same LayerStack as sequenceFX.usd (because one of the shot layers SubLayers in the sequence.usd layer, which in turn SubLayers the above sequenceFX.usd layer). In this particular shot, we need to replace the generic turbulence effect with a different one, which may have completely different prims in it. Therefore it is not enough to just “add on” an extra reference, because the prims from turbulence.usd will still “shine through” - we must also remove the weaker reference, which we can do via list editing.
现在，在快照级别，我们有一个shotFX.usd层，它与sequenceFX.usd一起参与同一个LayerStack（因为其中一个快照层是sequence.usd层中的SubLayers，它又是上面的sequenceFX.usd层的SubLayers）。在这个特殊的镜头中，我们需要用一个不同的效果替换一般的湍流效果，其中可能有完全不同的素数。因此，仅仅“添加”一个额外的引用是不够的，因为turbulation.usd的prims仍然会“闪耀”-我们还必须删除较弱的引用，这可以通过列表编辑来完成。
shotFX.usd，它替换序列级引用，同时保留任何其他引用
#usda 1.0
over "World"
{
over "Props"
{
over "Prop_145" (
prepend references = @./fx/shotEffect1.usd@
delete references = @sequenceFX/turbulence.usd@
)
{
}
}
}
When the shot is composed, the references on /World/Props/Prop_145 will be combined using the list editing rules, and will resolve to a list that includes shotEffect1.usd, but not turbulence.usd. In this second example we have also shown that the operand of list-editing operations can be a list that can contain multiple targets.
合成快照时，将使用列表编辑规则组合/World/Props/Prop_145上的引用，并将解析为包含shotEffect1.usd但不包含turburence. usd的列表。在第二个例子中，我们还展示了列表编辑操作的操作数可以是一个包含多个目标的列表。
List Editing 列表编辑
List editing is a feature to which some array-valued data elements in USD can subscribe, that allows the array-type element to be non-destructively, sparsely modified across composition arcs . It would be very expensive and difficult to reason about list editable elements that are also time-varying, so Attributes can never be list editable. Relationships, References, Inherits, Specializes, VariantSets, and integer and string/token array custom metadata can be list edited. When an element is list editable, instead of only being able to assign an explicit value to it, you can also, in any stronger layer:
列表编辑是USD中的一些数组值数据元素可以订阅的一个特性，它允许数组类型元素在组合弧上被非破坏性地、稀疏地修改。对于列表可编辑元素也是随时间变化的，这将是非常昂贵和困难的，所以属性永远不能是列表可编辑的。Relationships、References、Inherits、Specializes、VariantSets以及integer和string/token数组自定义元数据可以列表编辑。当元素可列表编辑时，您不仅可以为其指定显式值，还可以在任何更强的图层中：
append another value or values to the back of the resolved list; if the values already appear in the resolved list, they will be reshuffled to the back. An appended composition arc in a stronger layer of a LayerStack will therefore be weaker than all of the arcs of the same type appended from weaker layers, by default; however, the Usd API’s for adding composition arcs give you some flexibility here.
将另一个或多个值附加到解析列表的后面;如果这些值已经出现在解析列表中，则它们将被重新洗牌到后面。因此，默认情况下，LayerStack的较强层中的附加合成弧将弱于从较弱层附加的相同类型的所有弧;但是，用于添加合成弧的Usd API在这里为您提供了一些灵活性。delete a value or values from the resolved list. A “delete” statement can be speculative, that is, it is not an error to attempt to delete a value that is not present in the resolved list.
从解析列表中删除一个或多个值。“delete”语句可以是推测性的，也就是说，尝试删除解析列表中不存在的值并不是错误。prepend another value or values on the front of the resolved list; if the values already appear in the resolved list, they will be shuffled to the front. A prepended composition arc in a weaker layer of a LayerStack will still be stronger than any arcs of the same type that are appended from stronger layers.
在已解析列表前面添加另一个或多个值;如果这些值已经出现在解析列表中，则它们将被洗牌到前面。LayerStack的较弱层中的前置合成弧将仍然比从较强层附加的相同类型的任何弧更强。reset to explicit , which is an “unqualified” operation, as in references = @myFile.usd@. This causes the resolved list to be reset to the provided value or values, ignoring all list ops from weaker layers.
reset to explicit，这是一个“unqualified”操作，如references = @myFile.usd@。这导致解析列表被重置为所提供的一个或多个值，忽略来自较弱层的所有列表操作。
Although we refer to these operations as “list editing”, and they operate on array-valued data, it should be clear from the description of the operators that list-edited elements always resolve to a set , that is, there will never be any repetition of values in the resolved list, and it is a syntax error for the same value to appear twice in the same operation in a layer. Also, in the usda text syntax, any operation can assign either a single value without the square-bracket list delimiters, or a sequence of values inside square brackets.
尽管我们将这些操作称为“列表编辑”，并且它们对数组值数据进行操作，但从操作符的描述中应该清楚，列表编辑的元素总是解析为集合，也就是说，在解析的列表中永远不会有任何重复的值，并且同一值在层中的同一操作中出现两次是语法错误。此外，在usda文本语法中，任何操作都可以分配不带方括号列表分隔符的单个值，或方括号内的值序列。
See LayerStack for an example of list editing, as applied to references. See also the FAQ on deleting items with list ops: When can you delete a reference (or other deletable thing)?
有关应用于引用的列表编辑示例，请参见LayerStack。另请参阅有关使用列表操作删除项目的常见问题解答：什么时候可以删除引用（或其他可删除的东西）？
LIVRPS Strength Ordering
LIVRPS强度订购
LIVRPS is an acronym for Local, Inherits, VariantSets, References, Payload, Specializes, and is the fundamental rubric for understanding how opinions and namespace compose in USD. LIVRPS describes the strength ordering in which the various composition arcs combine, within each LayerStack. For example, when we are trying to determine the value of an attribute or metadatum on a stage at path that subscribes to the value resolution policy that “strongest opinion wins” (which is all attributes and most metadata), we iterate through PrimSpecs in the following order looking for an opinion for the requested datum:
LIVRPS是Local、Inherits、VariantSets、References、Payload、Specializes的首字母缩写，是理解意见和命名空间如何在USD中组成的基本准则。LIVRPS描述了在每个LayerStack内各种合成弧组合的强度排序。例如，当我们试图确定某个属性或元数据的值在路径上订阅了“最强意见获胜”的值解析策略（即所有属性和大多数元数据）时，我们按以下顺序遍历PrimSpecs，寻找所请求数据的意见：
Local: 当地：
Iterate through all the layers in the local LayerStack looking for opinions on the PrimSpec at path in each layer - recall that according to the definition of LayerStack, this is where the effect of direct opinions in all SubLayers of the root layer of the LayerStack will be consulted. If no opinion is found, then…
遍历本地LayerStack中的所有层，在每个层的路径上寻找PrimSpec上的意见-回想一下，根据LayerStack的定义，这是LayerStack根层的所有子层中的直接意见的效果将被咨询的地方。如果找不到意见，那么...Inherits: 继承：
Resolve the Inherits affecting the prim at path, and iterate through the resulting targets. For each target, recursively apply LIVRP evaluation on the targeted LayerStack - Note that the “S” is not present - we ignore Specializes arcs while recursing . If no opinion is found, then…
解决影响prim at路径的Inherits，并迭代结果目标。对于每个目标，在目标LayerStack上递归地应用LIVRP评估-注意，“S”不存在-我们在递归时忽略Specializes弧。如果找不到意见，那么...VariantSets: 变体集：
Apply the resolved variant selections to all VariantSets that affect the PrimSpec at path in the LayerStack, and iterate through the selected Variants on each VariantSet. For each target, recursively apply LIVRP evaluation on the targeted LayerStack - Note that the “S” is not present - we ignore Specializes arcs while recursing. If no opinion is found, then…
将解析的变量选择应用于影响LayerStack中路径上PrimSpec的所有变量集，并迭代每个变量集上的选定变量。对于每个目标，在目标LayerStack上递归地应用LIVRP评估-注意，“S”不存在-我们在递归时忽略Specializes弧。如果找不到意见，那么...References: 参考文献：
Resolve the References affecting the prim at path, and iterate through the resulting targets. For each target, recursively apply LIVRP evaluation on the targeted LayerStack - Note that the “S” is not present - we ignore Specializes arcs while recursing. If no opinion is found, then…
解析影响prim at路径的References，并迭代结果目标。对于每个目标，在目标LayerStack上递归地应用LIVRP评估-注意，“S”不存在-我们在递归时忽略Specializes弧。如果找不到意见，那么...Payload: 有效载荷：
Resolve the Payload arcs affecting the prim at path; if path has been loaded on the stage, iterate through the resulting targets just as we would references from step 4. If no opinion is found, then…
解决有效载荷弧对初始路径的影响;如果路径已经加载到阶段，就像我们从步骤4中引用的那样，迭代通过得到的目标。如果找不到意见，那么...Specializes: 专长：
Resolve the Specializes affecting the prim at path, and iterate through the resulting targets, recursively applying *full* LIVRPS evaluation on each target prim. If no opinion is found, then…
解决影响路径引物的Specializes，并迭代生成的目标，对每个目标引物递归应用 * 完整 * LIVRPS评估。如果找不到意见，那么...Indicate that we could find no authored opinion
表明我们找不到作者的观点
We have omitted some details, such as how, for any composition arc in the above recipe, we order arcs applied directly on the PrimSpec in relation to the same kind of arc authored on an ancestral PrimSpec in the LayerStack - the short answer is that “ancestral arcs” are weaker than “direct arcs”, and why we ignore the “S” when we recurse for the other arcs, which we discuss more in the entry for Specializes. It may sound like a great deal of work to need to perform for every value lookup, and it absolutely would be if we followed all the steps as described above, during value resolution. This is the reason that we compute and cache an Index for every prim on the Stage: the Index “pre-applies” the above algorithm to find all the PrimSpecs that contribute any opinions to the prim, and caches the list in a recursive data structure that can be very efficiently processed whenever we need to resolve some value on the prim.
我们已经省略了一些细节，例如，对于以上配方中的任何组合弧，我们如何相对于在LayerStack中的祖先PrimSpec上创作的相同种类的弧来对直接应用在PrimSpec上的弧进行排序--简短的答案是“祖先弧”比“直接弧”弱，以及为什么当我们递归其他弧时忽略“S”。我们将在专业化的条目中详细讨论这一点。这听起来像是需要为每个值查找执行大量的工作，如果我们在值解析期间遵循上述所有步骤，那么绝对会如此。这就是我们为舞台上的每个prim计算并缓存索引的原因：索引“预先应用”上述算法以找到对prim贡献任何意见的所有PrimSpecs，并将列表缓存在递归数据结构中，每当我们需要解析prim上的某个值时，该递归数据结构可以被非常有效地处理。
The algorithm for computing the namespace of the stage (i.e. what prims are present and where) are slightly more involved, but still follows the LIVRPS recipe.
用于计算阶段的命名空间的算法（即存在什么素数以及在哪里）稍微更涉及，但仍然遵循LIVRPS配方。
Load / Unload
加载/卸载
The Payload arc provides a “deferred reference” behavior. Wherever a Stage contains at least one Payload (payloads can be list-edited and chained), the client has the ability to Load (compose) all the scene description targeted by the Payload, or to Unload the Payloads and all their scene description, recomposing all prims beneath the payloaded-prim, recursively unloading their payloads, should they possess any. We generally associate payloads with “model assets”, which provides us with payloads, and therefore “load points” at all the leaves of the Model Hierarchy. This organization allows clients to craft “working sets” of a Stage, fully composing only the parts of the scene needed for a given task, saving time and memory for the operation.
Payload弧提供了一种“延迟引用”行为。只要舞台包含至少一个有效载荷（有效载荷可以列表编辑和链接），客户端就能够加载（合成）该有效载荷所针对的所有场景描述，或者卸载有效载荷及其所有场景描述，重新合成有效载荷prim下的所有prim，递归地卸载它们的有效载荷（如果它们拥有的话）。我们通常将有效载荷与“模型资产”相关联，“模型资产”为我们提供有效载荷，因此“加载点”位于模型层次结构的所有叶子上。这种组织允许客户制作舞台的“工作集”，仅完整地组成给定任务所需的场景部分，从而节省操作的时间和内存。
For more information, see Working Set Management in the USD Manual.
有关详细信息，请参阅《USD手册》中的工作集管理。
Localize 本地化
USD allows the construction of highly referenced and layered scenes that assemble files from many different sources, which may resolve differently in different contexts (for example, your asset resolver may apply external state to select between multiple versions of an asset). If one wishes to package up all of the needed files for a given scene so that they are isolated from asset resolution behavior and can be copied or shipped easily to another location, without the drastic transformation that flattening a stage incurs, then one must “localize” all of the scattered layers into a coherent tree of files, which requires not only copying files, but also editing them to retarget all of the references, payloads, and generic asset paths to target the copied files in their new locations. UsdUtilsCreateNewUsdzPackage does this for you, although we have not yet exposed the ability to just localize yet, but we hope to eventually.
USD允许构建高度引用和分层的场景，这些场景组合来自许多不同来源的文件，这些文件在不同的上下文中可能会有不同的解析方式（例如，您的资源解析器可能会应用外部状态来在资源的多个版本之间进行选择）。如果希望打包给定场景的所有所需文件，使得它们与资产解析行为隔离，并且可以容易地复制或运送到另一位置，而没有平坦化阶段所引起的剧烈变换，则必须将所有分散的层“本地化”成文件的连贯树，这不仅需要复制文件，而且需要编辑它们以重新定向所有引用。有效载荷和通用资源路径，以将复制的文件定位在它们的新位置。UsdUtilsCreateNewUsdzPackage为您做到了这一点，尽管我们还没有公开本地化的能力，但我们希望最终能够做到。
Metadata 元数据
Metadata is the lightest-weight form of (name, value) scene description; it is “light” because unlike attributes, metadata cannot be time-varying, and because prims and properties can possess metadata, but metadata cannot itself have metadata. Metadata are extensible, however adding a new, named piece of metadata requires a change to a configuration file to do so, because the software wants to know, definitively, what the datatype of the metadatum should be. USD provides a special, dictionary-valued metadatum called customData that provides a place to put user metadata without needing to touch any configuration files. For more information on the allowed types for metadata and how to add new metadata to the system, please see the discussion of metadata in the API manual.
元数据是（名称、值）场景描述的最轻量级形式;它是“轻的”，因为与属性不同，元数据不能是时变的，并且因为素数和属性可以拥有元数据，但是元数据本身不能拥有元数据。元数据是可扩展的，但是添加新的命名元数据片段需要更改配置文件，因为软件希望明确地知道元数据的数据类型应该是什么。USD提供了一个特殊的字典值元数据，名为customData，它提供了一个放置用户元数据的地方，而不需要接触任何配置文件。有关元数据允许的类型以及如何向系统添加新元数据的更多信息，请参阅API手册中关于元数据的讨论。
Model 型号
Model is a scenegraph annotation ascribable to prims by setting their kind metadata. We label certain prims as models to partition large scenegraphs into more manageable pieces - there is a core “leaf model” kind, component, and two refinements of “models that aggregate other models”, group, and assembly. Core UsdPrim API can cheaply answer questions like UsdPrim::IsModel and UsdPrim::IsGroup, and “model-ness” is one of the criteria that a UsdPrimRange can use to traverse a stage. All model kinds are extensible via site-customization, so that, for example, you can have both “character” and “prop” component model kinds in your pipeline if that is a useful distinction to make. See also Model Hierarchy.
模型是一个场景图注释，可通过设置其类元数据来归属于素数。我们将某些prims标记为模型，将大型场景图划分成更易于管理的部分-有一个核心的“叶模型”的种类，组件，和两个细化的“模型，聚合其他模型”，组和组装。核心UsdPrim API可以廉价地回答像UsdPrim：：IsModel和UsdPrim：：IsGroup这样的问题，“model-ness”是UsdPrimRange可以用来遍历阶段的标准之一。所有的模型类型都可以通过站点定制进行扩展，因此，例如，如果这是一个有用的区别，您可以在管道中同时拥有“字符”和“道具”组件模型类型。另请参见模型层次。
Model Hierarchy 模型层次
Model Hierarchy builds on the concept of model in a scenegraph to tackle the problem of discovering and defining a “table of contents of important subtrees of prims” that can be enumerated and traversed very efficiently. The model hierarchy defines a contiguous set of prims descending from a root prim on a stage, all of which are models. Model hierarchy is an index of the scene that is, strictly, a prefix, of the entire scene. The member prims must adhere to the following three rules:
模型层次结构建立在场景图中的模型的概念上，以解决发现和定义“素的重要子树的内容表”的问题，可以非常有效地枚举和遍历。模型层次结构定义了一组连续的素数，这些素数从一个舞台上的根素数降下来，所有这些素数都是模型。模型层次是场景的索引，严格来说，它是整个场景的前缀。成员prim必须遵守以下三条规则：
Only group model prims can have other model children (assembly is a kind of group)
只有组模型素数才能有其他模型子（装配是组的一种）A prim can only be a model if its parent prim is also a (group) model - except for the root model prim.
一个prim只能是一个模型，如果它的父prim也是一个（组）模型-除了根模型prim。No prim should have the exact kind “model”, because “model” is neither a singular component nor a plural group container - it is just the “abstract” commonality between components and groups.
没有primer应该有确切的种类“model”，因为“model”既不是单个组件，也不是复数组容器--它只是组件和组之间的“抽象”共性。
This implies that component models cannot have model children. It also implies that just because a prim has its kind metadata authored to “component”, its UsdPrim::IsModel query will only return true if its parent UsdPrim::IsGroup also answers affirmatively.
这意味着组件模型不能有子模型。它还意味着，仅仅因为prim将其种类元数据创作为“component”，所以它的UsdPrim：：IsModel查询将仅在其父UsdPrim：：IsGroup也肯定回答时返回true。
We find model hierarchy to be a useful construct because the models in our scenes align very closely with “referenced assets”, and we build complex scenes by referencing many assets together and overriding them. Reasoning about referencing structure can get complicated very quickly and necessitate introducing fragile conventions. However, reasoning about a model hierarchy is much more straightforward, and when assets are published/packaged with model kinds already established, the model hierarchy becomes mostly “self assembling”.
我们发现模型层次结构是一个有用的构造，因为我们的场景中的模型与“引用的资产”非常紧密地对齐，我们通过引用许多资产一起并覆盖它们来构建复杂的场景。关于引用结构的推理可能会很快变得复杂，并且需要引入脆弱的约定。然而，关于模型层次结构的推理要简单得多，当资产与已经建立的模型种类一起发布/打包时，模型层次结构主要变成“自组装”。
Namespace 命名空间
Namespace is simply the term USD uses to describe the set of prim paths that provide the identities for prims on a Stage, or PrimSpecs in a Layer. A Stage’s namespace nominally consists of a “forest” in graph theory, that is, any number of “root prims” that have (possibly empty) trees beneath them. To facilitate traversal and processing of a Stage’s namespace of prims, each Stage possesses a PseudoRoot prim that is the parent of all authored root prims, represented by the path /.
命名空间只是USD用来描述prim路径集的术语，prim路径集为Stage上的prim或Layer中的PrimSpecs提供标识。Stage的命名空间名义上由图论中的“森林”组成，也就是说，任意数量的“根素数”下面有树（可能是空的）。为了便于遍历和处理阶段的素数命名空间，每个阶段拥有一个伪根素数，该伪根素数是所有创作的根素数的父，由路径/表示。
Opinions 意见
Opinions are the atomic elements that participate in Value Resolution in USD. Each time you author a value for a Metadatum, Attribute, or Relationship, you are expressing an opinion for that object in a PrimSpec in a particular Layer. On a composed Stage, any object may be affected by multiple opinions from different layers; the ordering of these opinions is determined by the LIVRPS strength ordering.
意见是参与美元价值解析的原子元素。每次为元数据、属性或关系创建值时，您都是在特定层的PrimSpec中表达该对象的观点。在组合舞台上，任何对象都可能受到来自不同层的多个意见的影响;这些意见的排序由LIVRPS强度排序确定。
Over 过
Over is one of the three possible specifiers a prim (and also a PrimSpec) can possess. An over is the “weakest” of the three specifiers, in that it does not change the resolved specifier of a prim in a LayerStack even when an over appears in a stronger layer than a def or class for the same PrimSpec. Over is short for “override” or “compose over”, and its purpose is just to provide a speculative, neutral prim container for overriding opinions; we use the term “speculative” because if the over composes over a defined prim, its opinions will contribute to the evaluation of the stage, but if all the PrimSpecs contributing to a prim have the over specifier, then the prim will not be visited by UsdPrim::GetChildren or UsdStage::Traverse.
Over是prim（也是PrimSpec）可以拥有的三个可能的说明符之一。over是三个说明符中“最弱的”，因为它不会改变LayerStack中prim的解析说明符，即使over出现在比相同PrimSpec的def或class更强的层中。Over是“override”或“compose over”的缩写，它的目的只是为压倒一切的意见提供一个推测性的、中立的prim容器;我们使用术语“推测性”，因为如果over在定义的prim上组成，则它的意见将有助于阶段的评估，但是如果对prim有贡献的所有PrimSpecs都具有over说明符，则该prim将不会被UsdPrim：：GetChildren或UsdStage：：Traverse访问。
When an application exports sparse overrides into a layer that sits on top of an existing composition, it is common to see deep nesting of overs.
当应用程序将稀疏覆盖导出到位于现有组合之上的层中时，通常会看到覆盖层的深度嵌套。
一个“over”提供了推测性的意见
#usda 1.0
over "World"
{
over "Props"
{
over "LuxoBall"
{
double radius = 10
}
}
}
Path 路径
A path is a location in namespace. In USD text syntax (and documentation), paths are enclosed in angle-brackets, as found in the authored targets for references, payloads, inherits, specializes, and relationships. USD assigns paths to all elements of scene description other than metadata, and the concrete embodiment of a path, SdfPath, serves in the API as a compact, thread-safe, key by which to fetch and store scene description, both within a Layer, and composed on a Stage. The SdfPath syntax allows for recording paths to different kinds of scene description. For example:
路径是命名空间中的位置。在USD文本语法（和文档）中，路径被括在尖括号中，如引用、有效载荷、继承、专门化和关系的创作目标中。USD将路径分配给除元数据之外的场景描述的所有元素，并且路径的具体实施例SdfPath在API中用作紧凑的、线程安全的键，通过该键来获取和存储在层内以及在舞台上合成的场景描述。SdfPath语法允许记录不同类型场景描述的路径。举例来说：
/Root/Child/Grandchild represents an absolute prim path of three nested prims
/Root/Child/Grandchild表示三个嵌套素数的绝对素数路径/Root/Child/Grandchild.visibility names the property visibility on the prim Grandchild.
/Root/Child/Grandchild。visibility命名prim Grandchild上的属性可见性。/Root/Child/Grandchild{modelingVariant=withCargoRack}/GreatGrandchild represents the child prim GreatGrandchild authored inside the Variant “withCargoRack of VariantSet modelingVariant
/Root/Child/Grandchild{modelingVariant=withCargoRack}/GreatGrandchild表示在VariantSet modelingVariant的Variant“withCargoRack”内创作的子prim GreatGrandchild
与示例路径对应的图层中的场景描述
#usda 1.0
def "Root"
{
def "Child"
{
def "GrandChild" ( # Corresponds to path #1 above
add variantSets = [ "modelingVariant" ]
{
variantSet "modelingVariant" = {
"withCargoRack" {
def "GreatGrandchild" # Corresponds to path #3 above
{
}
}
}
token visibility # Corresponds to path #2 above
}
}
}
Path Translation 路径转换
All of USD’s Composition Arcs other than SubLayers allow a “prim name change” as the target prim of the arc gets composed under the prim that added the composition arc. One of a UsdStage’s central responsibilities is applying all of the necessary path translation required to allow its users to deal almost exclusively in the “fully composed namespace” of the stage’s root layer, rather than needing to be concerned about what layer (with its own namespace) provides the data we want to access or author. Path translation is applied during such queries as finding a prim and fetching the targets of a relationship or connection, and inverse path translation is performed by the active Edit Target whenever you author to a stage.
除了子层之外，所有USD的合成弧允许“原名称更改”，因为弧的目标原在添加合成弧的原下合成。UsdStage的核心职责之一是应用所有必要的路径转换，以允许其用户几乎独占地处理stage根层的“完全组合命名空间”，而不需要关心哪个层（具有自己的命名空间）提供了我们想要访问或创作的数据。路径转换应用于诸如查找prim和获取关系或连接的目标等查询期间，并且每当您创作到阶段时，活动的编辑目标执行反向路径转换。
Following is an example of the kind of path translation that happens in response to adding references, demonstrating the effects on not only the stage’s namespace, but also on relationship targets. Given:
下面是响应于添加引用而发生的路径转换类型的示例，演示了不仅对阶段的名称空间的影响，而且对关系目标的影响。鉴于：
#usda 1.0
(
defaultPrim = "MyModel"
)
def Xform "MyModel"
{
rel gprims = [ </MyModel/Cube>, </MyModel/Sphere> ]
def Cube "Cube"
{
}
}
and an aggregating file that references asset.usd:
以及引用asset.usd的聚合文件：
#usda 1.0
(
defaultPrim = "MySet"
)
def Xform "MySet"
{
def Xform "Building_1" (
references = @asset.usd@
)
{
}
def Xform "Building_2" (
references = @asset.usd@
)
{
}
}
Then, if we add the “set” represented by assembly.usd into a shot.usd, USD path translation operates at two levels (recursively), translating /MyModel to either /Building_1 or /Building_2, conextually, and translating /MySet to /WestVillage. So if we query the targets of the relationship /World/WestVillage/Building_1.gprims, we will get back:
然后，如果我们将assembly.usd表示的“set”添加到shot.usd中，USD路径转换将在两个级别（递归地）进行，将/MyModel转换为/Building_1或/Building_2，并将/MySet转换为/WestVillage。因此，如果我们查询关系/World/WestVillage/Building_1.gprims的目标，我们将得到：
[ /World/WestVillage/Building_1/Cube, /World/WestVillage/Building_1/Sphere ]
[ /World/WestVillage/Building_1/Cube，/World/WestVillage/Building_1/Sphere ]
If we note that there is no Sphere prim, and therefore want to eliminate it from consideration at the shot-level using relationship list-editing, we refer to it by its stage-level path , rather than its authored path, which is not even easy to determine using the public Usd API’s. Deleting the target in shot.usd might look like this:
如果我们注意到没有Sphere prim，因此想要使用关系列表编辑在镜头级别将其从考虑中消除，则我们通过其舞台级别路径而不是其创作路径来引用它，这甚至不容易使用公共Usd API来确定。删除shot.usd中的目标可能如下所示：
#usda 1.0
(
defaultPrim = "World"
)
def Xform "World"
{
def "WestVillage" (
references = @assembly.usd@
)
{
over "Building_1"
{
delete rel gprims = </World/WestVillage/Building_1/Sphere>
}
}
}
We mentioned above that path translation also operates in the opposite direction when you use Edit Targets to send your relationship or connection edits across a composition arc, because it follows that every encoded path must be in the namespace of the PrimSpec on which it is recorded. For example, if we were working with the same shot.usd Stage, and specified the same path to delete, /World/WestVillage/Building_1/Sphere, but have set the Stage’s EditTarget to assembly.usd across the reference authored on /World/WestVillage/Building_1, then the act of authoring will transform the path into the target namespace, so the result would be an assembly.usd that looks like:
我们在上面提到，当您使用Edit Targets跨合成弧发送关系或连接编辑时，路径转换也会以相反的方向操作，因为它遵循每个编码路径必须位于记录它的PrimSpec的命名空间中。例如，如果我们正在使用相同的shot.usd舞台，并指定了相同的删除路径/World/WestVillage/Building_1/Sphere，但已将舞台的EditTarget设置为在/World/WestVillage/Building_1上创作的引用中的assembly.usd，则创作操作将路径转换为目标命名空间，因此结果将是如下所示的assembly.usd：
修改了assembly.usd，删除了关系
#usda 1.0
(
defaultPrim = "MySet"
)
def Xform "MySet"
{
def Xform "Building_1" (
references = @asset.usd@
)
{
delete rel gprims = </MySet/Building_1/Sphere>
}
def Xform "Building_2" (
references = @asset.usd@
)
{
}
}
Payload 有效载荷
A Payload is a composition arc that is a special kind of a Reference. It is different from references primarily in two ways:
有效载荷是一个复合弧，它是一种特殊的引用。它与参考文献的不同主要体现在两个方面：
The targets of References are always consumed greedily by the indexing algorithm that is used to open and build a Stage. When a Stage is opened with UsdStage::InitialLoadSet::LoadNone specified, Payload arcs are recorded, but not traversed. This behavior allows clients to manually construct a “working set” that is a subset of the whole scene, by loading just the bits of the scene that they require.
引用的目标总是被用于打开和构建阶段的索引算法贪婪地消耗。在指定了UsdStage：：InitialLoadSet：：LoadNone的情况下打开Stage时，将记录有效负载弧，但不会遍历有效负载弧。此行为允许客户端通过仅加载它们所需的场景位来手动构造作为整个场景的子集的“工作集”。Payloads are weaker than references, so, for a particular prim within any given LayerStack, all direct references will be stronger than all direct payloads.
有效载荷比引用弱，因此，对于任何给定LayerStack中的特定prim，所有直接引用都将比所有直接有效载荷强。
Although payloads can be authored on any prim in any layer, in Pixar’s pipeline we find it very useful to primarily add payloads to the root prims of component-model assets. See the performance note on packaging assets with payloads.
虽然有效载荷可以在任何层的任何prim上创作，但在Pixar的管道中，我们发现主要将有效载荷添加到组件模型资产的根prim非常有用。请参阅有关打包具有有效负载的资产的性能说明。
Prim Prim
A Prim is the primary container object in USD: prims can contain (and order) other prims, creating a “namespace hierarchy” on a Stage, and prims can also contain (and order) properties that hold meaningful data. Prims, along with their associated, computed indices, are the only persistent scenegraph objects that a Stage retains in memory, and the API for interacting with prims is provided by the UsdPrim class. Prims always possess a resolved Specifier that determines the prim’s generic role on a stage, and a prim may possess a schema typeName that dictates what kind of data the prim contains. Prims also provide the granularity at which we apply scene-level instancing, load/unload behavior, and deactivation.
Prim是USD中的主要容器对象：prims可以包含（和排序）其他prims，从而在舞台上创建“命名空间层次结构”，prims还可以包含（和排序）保存有意义数据的属性。Prims沿着关联的计算索引是Stage保留在内存中的唯一持久性场景图对象，用于与prims交互的API由UsdPrim类提供。prim总是拥有一个解析的Specifier，它决定了prim在舞台上的通用角色，prim可能拥有一个schema typeName，它决定了prim包含什么类型的数据。Prims还提供了应用场景级实例化、加载/卸载行为和停用的粒度。
Prim Definition Prim定义
A prim definition is the set of built-in properties and metadata that a prim gains from a combination of the IsA schema determined from its typeName and its applied API schemas. A prim’s prim definition is used to determine what properties and metadata the prim has besides what is authored in its scene description. It also may provide fallback values during property value or metadata value resolution for the prim’s built-in properties and metadata. The API for prim definitions are provided by the UsdPrimDefinition class.
prim定义是一组内置属性和元数据，prim从其typeName和应用的API模式确定的伊萨模式的组合中获得。prim的prim定义用于确定除了在其场景描述中创作的内容之外，prim还具有哪些属性和元数据。它还可以在prim的内置属性和元数据的属性值或元数据值解析期间提供回退值。prim定义的API由UsdPrimDefinition类提供。
PrimSpec PrimSpec
Each composed Prim on a Stage is the result of potentially many PrimSpecs each contributing their own scene description to a composite result. A PrimSpec can be thought of as an “uncomposed prim in a layer”. Similarly to a composed prim, a PrimSpec is a container for property data and nested PrimSpecs. Importantly, composition arcs can only be applied on PrimSpecs, and those arcs that specify targets are targeting other PrimSpecs.
舞台上的每个合成Prim都是潜在的许多PrimSpecs的结果，每个PrimSpecs都将其自己的场景描述贡献给合成结果。PrimSpec可以被认为是“层中未组合的prim”。与组合prim类似，PrimSpec是属性数据和嵌套PrimSpecs的容器。重要的是，组合弧只能应用于PrimSpecs，而那些指定目标的弧则以其他PrimSpecs为目标。
PrimStack PrimStack
A PrimStack is a list of PrimSpecs that contribute opinions for a composed prim’s metadata. This information is condensed from the prim’s index, and made available through UsdPrim::GetPrimStack.
PrimStack是一个PrimSpecs的列表，这些PrimSpecs为组合prim的元数据提供意见。这些信息是从prim的索引中压缩出来的，并通过UsdPrim：：GetPrimStack提供。
Primvar 初级↓
The name primvar comes from RenderMan, and stands for “primitive variable”. A primvar is a special attribute that a renderer associates with a geometric primitive, and can vary (interpolate) the value of the attribute over the surface/volume of the primitive. In USD, you create and retrieve primvars using the UsdGeomImageable schema, and interact with the special primvar encoding using the UsdGeomPrimvar schema.
primvar这个名字来自RenderMan，代表“原始变量”。primvar是渲染器与几何基本体相关联的特殊属性，并且可以在基本体的表面/体积上改变（内插）属性的值。在USD中，您可以使用UsdGeomImageable模式创建和检索primvar，并使用UsdGeomPrimvar模式与特殊的primvar编码进行交互。
There are two key aspects of Primvar identity:
Primvar身份有两个关键方面：
Primvars define a value that can vary across the primitive on which they are defined, via prescribed interpolation rules.
Primvar定义了一个值，该值可以通过规定的插值规则在定义它们的图元上变化。Taken collectively on a prim, its Primvars describe the “per-primitive overrides” to the shader(s) to which the prim is bound. Different renderers may communicate the variables to the shaders using different mechanisms over which Usd has no control; Primvars simply provide the classification that any renderer should use to locate potential overrides.
在prim上，其Primvar描述了对prim绑定到的着色器的“每基本体覆盖”。不同的渲染器可以使用Usd无法控制的不同机制将变量传送到着色器; Primvars只是提供了任何渲染器都应该用来定位潜在覆盖的分类。
Property 房产
Properties are the other kind of namespace object in USD (Prims being the first). Whereas prims provide the organization and indexing for a composed scene, properties contain the “real data”. There are two types of Property: Attribute and Relationship. All properties can be ordered within their containing Prim (and are otherwise enumerated in dictionary order) via UsdPrim::SetPropertyOrder, and can host Metadata.
属性是USD中的另一种名称空间对象（Prims是第一种）。prims为合成场景提供组织和索引，而properties包含“真实的数据”。有两种类型的属性：属性和关系。所有属性都可以通过UsdPrim：：SetPropertyOrder在其包含的Prim中排序（否则按字典顺序枚举），并且可以托管元数据。
Sometimes it is desirable to be able to further group and organize a prim’s properties without introducing new child prim containers, either for locality reasons, or to keep the scene description lightweight to that end, properties in USD can be created inside nested namespaces, and enumerated by namespace. Here are some examples of namespaced properties from usd schemas:
有时，期望能够在不引入新的子prim容器的情况下进一步分组和组织prim的属性，无论是出于局部性原因，还是为了保持场景描述轻量化，USD中的属性可以在嵌套的命名空间内创建，并通过命名空间枚举。以下是一些来自usd模式的命名空间属性的示例：
#usda 1.0
over MyMesh
{
rel material:binding = </ModelRoot/Materials/MetalMaterial>
color3f[] primvars:displayColor = [ (.4, .2, .6) ]
}
PropertySpec 属性规格
Just as PrimSpecs contain data for a prim within a layer, PropertySpecs contain the data for a property within a layer. PropertySpecs are nested inside PrimSpecs; a PropertySpec can be as simple as a statement of a property’s existence (which, for Attributes, includes its typeName), or can contain values for any piece of metadata authorable on properties, including its value. For Relationships, the value a PropertySpec can contain is its targets , which is an SdfListOp<SdfPath> For Attributes, each PropertySpec can contain two independent values: a timeless Default Value, and a freely varying, ordered collection of TimeSamples.
就像PrimSpecs包含层中prim的数据一样，PropertySpecs包含层中属性的数据。PropertySpecs嵌套在PrimSpecs内部; PropertySpec可以像属性存在的声明一样简单（对于Attributes，其包括其typeName），或者可以包含可在属性上授权的任何元数据片段的值，包括其值。对于Relationships，PropertySpec可以包含的值是其目标，即SdfListOpFor Attributes，每个PropertySpec可以包含两个独立的值：一个无时间限制的默认值，以及一个自由变化的、有序的TimeSamples集合。
PropertyStack 属性栈
A PropertyStack is a list of PropertySpecs that contribute a default or timeSample (for Attributes) or target (for relationships), or any piece of metadata, for a given property. The information returned by UsdProperty::GetPropertyStack should only be used for debugging/diagnostic purposes, not for value resolution, because:
PropertyStack是PropertySpecs的列表，其为给定属性提供默认值或timeSample（对于属性）或目标（对于关系）或任何元数据片段。UsdProperty：：GetPropertyStack返回的信息应仅用于调试/诊断目的，而不是用于值解析，因为：
In the presence of Value Clips, an attribute’s PropertyStack may need to be recomputed on each frame, which may be expensive.
在存在值剪辑的情况下，可能需要在每个帧上重新计算属性的PropertyStack，这可能是昂贵的。A PropertyStack does not contain the proper time-offsets that must be applied to the PrimSpecs to retrieve the correct timeSample when there are authored Layer Offsets on references, subLayers, or clips.
PropertyStack不包含正确的时间偏移，当参照、子层或片段上存在编写的层偏移时，必须将该时间偏移应用于PrimSpecs以检索正确的timeSample。
If your goal is to optimize repeated value resolutions on attributes, retain a UsdAttributeQuery instead, which is designed for exactly this purpose.
如果您的目标是优化属性上的重复值解析，请保留UsdAttributeQuery，它正是为此目的而设计的。
Proxy 代理
Proxy is a highly overloaded term in computer graphics… but so were all the alternatives we considered for the same concept in USD. “proxy” is one of the possible purpose values a prim can possess in the UsdGeom schemas. When we talk about “a proxy” for a model or part of a model, we mean a prim (that may have a subtree) that has purpose proxy , and is paired with a prim whose purpose is render. The idea behind this pairing is that the proxy provides a set of gprims that are lightweight to read and draw, and provide an idea of what the full render geometry will look like, at much cheaper cost.
代理在计算机图形学中是一个高度过载的术语......但是我们在USD中考虑的相同概念的所有替代方案也是如此。“proxy”是prim在UsdGeom模式中可以拥有的可能目的值之一。当我们谈论模型或模型的一部分的“代理”时，我们指的是具有目的代理的prim（可能具有子树），并且与目的是渲染的prim配对。这种配对背后的想法是，代理提供了一组gprims，这些gprims对于读取和绘制来说是轻量级的，并且以更便宜的成本提供了完整渲染几何体的外观。
Why not just use a “level of detail” or “standin” VariantSet, rather than creating this special, different kind of visibility setting? The answer is twofold:
为什么不使用“细节级别”或“标准”VariantSet，而不是创建这种特殊的、不同类型的可见性设置呢？答案是双重的：
Most clients of USD in our pipeline place a high value on bringing up a complex scene for inspection and introspection as quickly as possible
大多数客户的美元在我们的管道放置一个高价值的提出一个复杂的现场检查和反省尽快But, they also require access to the actual data that will be used for rendering, at all times.
但是，它们还需要始终访问将用于渲染的实际数据。
Therefore, a VariantSet is not a very attractive option for solving this display problem, because in order to draw the lightweight geometry, we would have removed the possibility of inspecting the “render quality” data, because only one variant of a VariantSet can be composed at any given time, for a particular prim on a Stage. It is a fairly lightweight operation to instruct the renderer to ignore the proxies and image the full render geometry, when that is required.
因此，对于解决此显示问题，VariantSet不是一个非常有吸引力的选项，因为为了绘制轻量几何体，我们将消除检查“渲染质量”数据的可能性，因为对于舞台上的特定prim，在任何给定时间只能合成VariantSet的一个变体。这是一个相当轻量级的操作，指示渲染器忽略代理并在需要时对完整的渲染几何体进行成像。
PseudoRoot 伪根
A Stage’s PseudoRoot Prim is a contrivance that allows every UsdStage to contain a single tree of prims rather than a forest. See Namespace for further details.
Stage的PseudoRoot Prim是一种设计，它允许每个UsdStage包含一个prim树而不是一个森林。有关详细信息，请参见命名空间。
Purpose 目的
Purpose is a builtin attribute of the UsdGeomImageable schema, and is a concept we have found useful in our pipeline for classifying geometry into categories that can each be independently included or excluded from traversals of prims on a stage, such as rendering or bounding-box computation traversals. In essence, it provides client-driven “visibility categories” as gates on a scenegraph traversal.
目的是UsdGeomImageable模式的内置属性，并且是我们发现在我们的流水线中有用的概念，用于将几何体分类为类别，每个类别可以独立地包括或排除在阶段上的素数遍历中，例如渲染或边界框计算遍历。本质上，它提供了客户端驱动的“可见性类别”作为场景图遍历上的门。
The fallback purpose, *default* indicates that a prim has “no special purpose” and should generally be included in all traversals. Subtrees rooted at a prim with purpose *render* should generally only be included when performing a “final quality” render. Subtrees rooted at a prim with purpose *proxy* should generally only be included when performing a lightweight proxy render (such as OpenGL). Finally, subtrees rooted at a prim with purpose *guide* should generally only be included when an interactive application has been explicitly asked to “show guides”.
回退目的 *default* 表示prim“没有特殊目的”，通常应包含在所有遍历中。以prim为根的子树的目的 *render* 通常应该仅在执行“最终质量”渲染时才包括。以prim为根且具有purpose *proxy* 的子树通常应仅在执行轻量级代理渲染（例如OpenGL）时被包括。最后，以具有目的 * 指南 * 的prim为根的子树通常仅应在交互式应用程序已被明确要求“显示指南”时被包括。
For a discussion of the motivation for purpose, see Proxy.
有关目的动机的讨论，请参见代理。
References 参考资料
After SubLayers, References are the next most-basic and most-important composition arc. Because a PrimSpec can apply an entire list of References, References can be used to achieve a similar kind of layering of data, when one knows exactly which prims need to be layered (and with some differences in how the participating opinions will be resolved).
在SubLayers之后，References是下一个最基本和最重要的合成弧。因为PrimSpec可以应用整个References列表，所以当人们确切地知道哪些素数需要分层时，References可以用于实现类似的数据分层（并且在如何解决参与意见方面存在一些差异）。
But the primary use for References is to compose smaller units of scene description into larger aggregates , building up a namespace that includes the “encapsulated” result of composing the scene description targeted by a reference. Following is a simple example of referencing, with overrides.
但References的主要用途是将较小的场景描述单元组合成较大的聚合，构建一个名称空间，其中包括组合引用所针对的场景描述的“封装”结果。下面是一个简单的引用示例，带有覆盖。
We start with a trivial model asset, Marble. Note that, for brevity, we are eliding some of the key data usually found in published assets (such as AssetInfo, shading of any kind, Inherits, a Payload, detailed model substructure).
我们从一个简单的模型资产Marble开始。请注意，为了简洁起见，我们省略了一些通常在发布的资产中找到的关键数据（例如AssetInfo，任何类型的着色，Inherits，Payload，详细的模型子结构）。
marble.usd，定义单个绿色大理石
#usda 1.0
(
defaultPrim = "Marble"
)
def Xform "Marble" (
kind = "component"
)
{
def Sphere "marble_geom"
{
color3f[] primvars:displayColor = [ (0, 1, 0) ]
}
}
Now we want to create a collection of marbles, by referencing the Marble asset multiple times, and overriding some of the referenced properties to make each instance unique.
现在，我们要创建一个大理石集合，方法是多次引用大理石资源，并覆盖一些引用的属性以使每个实例都是唯一的。
MarbleCollection.usd，一个引用的Marble资产的程序集
#usda 1.0
def Xform "MarbleCollection" (
kind = "assembly"
)
{
def "Marble_Green" (
references = @Marble.usd@
)
{
double3 xformOp:translate = (-10, 0, 0)
uniform token[] xformOpOrder = [ "xformOp:translate" ]
}
def "Marble_Red" (
references = @Marble.usd@
)
{
double3 xformOp:translate = (5, 0, 0)
uniform token[] xformOpOrder = [ "xformOp:translate" ]
over "marble_geom"
{
color3f[] primvars:displayColor = [ (1, 0, 0) ]
}
}
}
To understand the results, we’ll examine the result of flattening a Stage opened for MarbleCollection.usd, which provides us with the same namespace and resolved property values that the originating Stage would, with all of the composition arcs “baked out”.
为了理解结果，我们将检查为MarbleCollection.usd打开的Stage的展平结果，它为我们提供了与原始Stage相同的名称空间和解析的属性值，所有的合成弧都“烤出来”。
usd演示了引用如何联合收割机名称空间
#usda 1.0
def Xform "MarbleCollection" (
kind = "assembly"
)
{
def Xform "Marble_Green" (
kind = "component"
)
{
double3 xformOp:translate = (-10, 0, 0)
uniform token[] xformOpOrder = [ "xformOp:translate" ]
def Sphere "marble_geom"
{
color3f[] primvars:displayColor = [ (0, 1, 0) ]
}
}
def Xform "Marble_Red" (
kind = "component"
)
{
double3 xformOp:translate = (5, 0, 0)
uniform token[] xformOpOrder = [ "xformOp:translate" ]
def Sphere "marble_geom"
{
color3f[] primvars:displayColor = [ (1, 0, 0) ]
}
}
}
Things to note: 注意事项：
In the composed namespace, the prim name Marble is gone, since the references allowed us to perform a prim name-change on the prim targeted by the reference. This is a key feature of references, since without it, we would be unable to reference the same asset more than once within any given prim scoping, because sibling prims must be uniquely named to form a proper namespace.
在组合命名空间中，prim名称Marble已经消失，因为引用允许我们对引用所针对的prim执行prim名称更改。这是引用的一个关键特性，因为如果没有它，我们将无法在任何给定的prim范围内多次引用同一资产，因为兄弟prim必须唯一命名以形成适当的命名空间。Even though the asset prim named /Marble/marble_geom shows up twice in the flattened scene, which indicates that there were indeed two distinct prims on the Stage, when we opened a stage for the original MarbleCollection.usd, the file Marble.usd was only opened once and shared by both references. For deeper sharing of referenced assets, in which the prims themselves are also shared, see Instancing .
尽管名为/Marble/marble_geom的资源prim在展平场景中出现两次，这表明舞台上确实有两个不同的prim，但当我们打开原始MarbleCollection.usd的舞台时，文件Marble.usd只打开一次，并被两个引用共享。有关被引用资源的更深层次共享（其中也共享prims本身），请参见实例化。References can apply a Layer Offset to offset and scale the time-varying data contained in the referenced layer(s).
参照可以应用“图层偏移”来偏移和缩放被参照图层中包含的时变数据。References can target any prim in a LayerStack, excepting ancestors of the prim containing the reference, if the reference is an internal reference targeting the same LayerStack in which the reference is authored. When targeting sub-root prims, however, there is the potential for surprising behavior unless you are aware of and understand the ramifications. One such ramification is that if the targeted sub-root prim has an ancestor prim that contains a VariantSet, the referencer will have no ability to express a selection for that VariantSet. For a more complete discussion of the ramifications of referencing sub-root prims, see the UsdReferences class documentation.
如果引用是内部引用，指向创建引用的同一LayerStack，则引用可以指向LayerStack中的任何prim，包含引用的prim的祖先除外。然而，当以子根素数为目标时，除非您意识到并理解其后果，否则可能会出现令人惊讶的行为。一个这样的分支是，如果靶向的亚根引物具有包含VariantSet的祖先引物，则参考子将没有能力表达针对该VariantSet的选择。有关引用子根素数的分支的更完整讨论，请参见UsdReferences类文档。
See List Editing for the rules by which references can be combined within a LayerStack
请参阅列表编辑以了解在LayerStack中组合引用的规则
Relationship 关系
A Relationship is a “namespace pointer” that is robust in the face of composition arcs, which means that when you ask USD for a relationship’s targets, USD will perform all the necessary namespace-manipulations required to translate the authored target value into the scene-level namespace. Relationships are used throughout the USD schemas; perhaps most visibly in the UsdShadeMaterialBindingAPI schema’s binding of gprims to their associated Materials. Relationships can have multiple targets, as, for instance, the relationships in a UsdCollectionAPI target all of the objects that belong to the named collection; therefore, relationships are List Edited. Following is an example that demonstrates how a relationship’s targets must be remapped to provide useful pointers.
Relationship是一个“命名空间指针”，在组合弧面前是健壮的，这意味着当您向USD请求关系的目标时，USD将执行所有必要的命名空间操作，以将创作的目标值转换为场景级命名空间。关系在整个USD模式中使用;也许最明显的是UsdShadeMaterialBindingAPI模式将gprim绑定到其关联的Materials。关系可以有多个目标，例如，UsdCollectionAPI中的关系以属于命名集合的所有对象为目标;因此，关系被列表编辑。下面是一个示例，演示了必须如何重新映射关系的目标以提供有用的指针。
Let’s enhance the asset example from the References entry to have a shading Material and binding:
让我们增强References条目中的资产示例，使其具有着色材质和绑定：
大理石.美元，带装订材料
#usda 1.0
(
defaultPrim = "Marble"
)
def Xform "Marble" (
kind = "component"
)
{
def Sphere "marble_geom"
{
rel material:binding = </Marble/GlassMaterial>
color3f[] primvars:displayColor = [ (0, 1, 0) ]
}
def Material "GlassMaterial"
{
# Interface inputs, shading networks, etc.
}
}
Now, because each marble in the MarbleCollection.usd scene has its own copy of the GlassMaterial prim, we expect that when we:
现在，因为MarbleCollection.usd场景中的每个大理石都有自己的GlassMaterial prim副本，所以我们希望：
解析引用关系
stage = Usd.Stage.Open("MarbleCollection.usd")
greenMarbleGeom = stage.GetPrimAtPath("/Marble_Collection/Marble_Green/marble_geom")
print(UsdShade.MaterialBindingAPI(greenMarbleGeom).GetDirectBindingRel().GetTargets())
we will get: 我们将得到：
/MarbleCollection/Marble_Green/GlassMaterial
/MarbleCollection/大理石_绿色/GlassMaterial
as the result, even though that was not the authored value in Marble.usd.
因此，即使这不是Marble. usd中的创作值。
Root LayerStack 根层堆栈
Every Stage has a “root” LayerStack, comprised of the LayerStack defined by the root Layer on which the Stage was opened, appended to the LayerStack defined by the stage’s Session Layer (the method for enumerating the layers in a Stage’s root LayerStack, UsdStage::GetLayerStack, provides the option of eliding the Session Layer’s contributions). The root LayerStack is special/important for two reasons:
每个阶段都有一个“根”LayerStack，该“根”LayerStack由在其上打开阶段的根层定义的LayerStack组成，附加到由阶段的会话层定义的LayerStack（用于枚举阶段的根LayerStack中的层的方法UsdStage：GetLayerStack提供了省略会话层贡献的选项）。根LayerStack之所以特殊/重要，有两个原因：
The prims declared in root layers are the only ones locatable using the same paths that identify composed prims on the Stage. Currently, an Edit Target can only target PrimSpecs in the root LayerStack, although we hope to relax that restriction eventually.
根层中声明的素数是唯一可使用标识舞台上组合素数的相同路径定位的素数。目前，编辑目标只能针对根LayerStack中的PrimSpecs，尽管我们希望最终放宽这个限制。It is the layers of the root LayerStack that are the most useful in facilitating shared workflows using USD. Cooperating departments and/or artists can each manage their own layer(s) in the root LayerStack of an asset, sequence, or shot, and their work will combine in intuitive ways with that of other artists working in the same context in their own layers.
根LayerStack的层在使用USD促进共享工作流方面最有用。合作的部门和/或艺术家可以各自管理资源、序列或镜头的根LayerStack中的他们自己的层，他们的工作将以直观的方式与其他艺术家在他们自己的层中在相同上下文中工作的工作相联合收割机。
Schema 模式
USD defines a schema as an object whose purpose is to author and retrieve structured data from some UsdObject. Most schemas found in the core are “prim schemas”, which are further refined into IsA Schemas and API Schemas, for which the USD distribution provides tools for code generation to create your own schemas. However, there are several examples of “property schemas”, also, such as UsdGeomPrimvar and UsdShadeInput. Schemas are lightweight objects we create to wrap a UsdObject, as and when needed, to robustly interrogate and author scene description. We also use schema classes to package type/schema-based computations, such as UsdGeomImageable::ComputeVisibility.
USD将模式定义为对象，其目的是从某些UsdObject创建和检索结构化数据。在核心中找到的大多数模式都是“prim模式”，它们被进一步细化为伊萨模式和API模式，USD发行版为此提供了代码生成工具，以创建自己的模式。然而，也有几个“属性模式”的示例，如UsdGeomPrimvar和UsdShadeInput。schema是我们创建的轻量级对象，在需要时包装UsdObject，以健壮地询问和创作场景描述。我们还使用模式类来打包基于类型/模式的计算，例如UsdGeomImagable：：ComputeVisibility。
Session Layer 会话层
Each UsdStage can be created with a session layer that provides for “scratch space” to configure, override, and experiment with the data contained in files backing the stage. If requested or provided at stage creation-time, a session layer participates fully in the stage’s composition, as the strongest layer in the stage’s Root LayerStack, and can possess its own SubLayers. Session layers generally embody “application state”, and, if saved, would be saved as part of application state rather than as part of the data set they modify. usdview creates a sesssion layer, into which are targeted all VariantSet selections, vis/invis opinions, and activation/deactivation operations provided by the GUI. In keeping with the view of session-layer as application state rather than asset data, UsdStage::Save does not save its stage’s session layer(s).
每个UsdStage都可以创建一个会话层，该会话层提供“临时空间”，以配置、覆盖和试验支持该Stage的文件中包含的数据。如果在阶段创建时被请求或提供，会话层作为阶段的根层堆栈中的最强层完全参与阶段的合成，并且可以拥有其自己的子层。会话层通常体现“应用状态”，并且如果被保存，则将被保存为应用状态的一部分，而不是它们修改的数据集的一部分。usdview创建了一个sesssion层，其中针对GUI提供的所有VariantSet选择、维斯/invis意见和激活/去激活操作。为了将会话层视为应用程序状态而不是资产数据，UsdStage：：Save不保存其阶段的会话层。
To edit content in a session layer, get the layer’s edit target using stage->GetEditTargetForLocalLayer(stage->GetSessionLayer()) and set that target in the stage by calling UsdStage::SetEditTarget or creating a UsdEditContext.
要编辑会话层中的内容，请使用stage->GetEditTargetForLocalLayer（stage->GetSessionLayer（））获取层的编辑目标，并通过调用UsdStage：：SetEditTarget或创建UsdEditContext在stage中设置该目标。
Specializes 专业
Specializes is a composition arc that allows a specialized prim to be continuously refined from a base prim, through unlimited levels of referencing. A specialized prim will contain all of the scene description contained in the base prim it specializes (including the entire namespace hierarchy rooted at the base prim), but any opinion expressed directly on the specialized prim will always be stronger than any opinion expressed on the base prim, in any referencing context. In behavior, specializes is very similar to inherits, with the key difference being the relative strength of referenced opinions vs “inherited/specialized” opinions, which leads to very different uses for the two.
Specializes是一个组合弧，允许通过无限的引用级别，从基础prim连续精炼专用prim。一个专门的prime将包含它专门的基础prime中包含的所有场景描述（包括植根于基础prime的整个命名空间层次结构），但是在任何引用上下文中，直接在专门prime上表达的任何观点总是比在基础prime上表达的任何观点更强。在行为上，专业化与继承非常相似，关键的区别在于引用意见与“继承/专业化”意见的相对强度，这导致了两者的使用非常不同。
Let us examine an example inspired by the first uses of the specializes arc at Pixar: specializing materials in our shading schema. We wish to publish an asset that contains several types of metallic materials, all of which should maintain their basic “metalness”, even as the definition of metal may change in referencing contexts. For brevity, we focus on one particular specialization, a corroded metal; we also leave out many of the schema details of how materials and their shaders interact.
让我们来看看一个例子，它的灵感来自于皮克斯第一次使用specialized arc：在我们的着色方案中专门化材质。我们希望发布一个包含几种类型的金属材料的资产，所有这些材料都应该保持其基本的“金属性”，即使金属的定义可能会在引用上下文中发生变化。为简洁起见，我们集中在一个特定的专业化，腐蚀的金属;我们还省略了许多关于材质和它们的着色器如何交互的模式细节。
#usda 1.0
def Xform "Robot"
{
def Scope "Materials"
{
def Material "Metal"
{
# Interface inputs drive shader parameters of the encapsulated
# network. We are not showing the connections, nor how we encode
# that the child Shader "Surface" is the primary output for the
# material.
float inputs:diffuseGain = 0
float inputs:specularRoughness = 0
def Shader "Surface"
{
asset info:id = @PxrSurface@
}
}
def Material "CorrodedMetal" (
specializes = </Robot/Materials/Metal>
)
{
# specialize roughness...
float inputs:specularRoughness = 0.2
# Adding a pattern to drive Surface bump
def Shader "Corrosion"
{
asset info:id = @PxrOSL@
vector3f outputs:disp
}
over "Surface"
{
# Override that would connect specularBump to Corrosion
# pattern's "outputs:disp" attribute
}
}
}
}
Notes: 备注：
The above example is not realistic at all regarding how you would actually design a Metal or CorrodedMetal material!
上面的例子是不现实的，关于你实际上如何设计金属或腐蚀金属材料！Specializes can target any prim on the stage that is neither an ancestor nor descendant of the specializing prim.
特化者可以瞄准舞台上任何既不是特化者祖先也不是其后代的灵长类。In the example above, replacing the specializes with inherits will produce the same composed result - try it!
在上面的例子中，用继承替换specialized将产生相同的组合结果-试试看！
In the sameRobot.usd asset, we might define many more materials, some of which are “siblings” of CorrodedMetal in that they specialize Metal, and some that further specialize CorrodedMetal, since specialization is not limited to any depth. The unique behavior of specializes only becomes evident, however, in a referencing context, so let us try one.
在sameRobot.usd资产中，我们可能定义更多的材质，其中一些是CorrodedMetal的“兄弟”，因为它们专门化Metal，而另一些则进一步专门化CorrodedMetal，因为专门化不限于任何深度。但是，专业化的独特行为只有在引用的上下文中才变得明显，所以让我们尝试一个。
#usda 1.0
def Xform "World"
{
def Xform "Characters"
{
def "Rosie" (
references = @./Robot.usd@</Robot>
)
{
over "Materials"
{
over "Metal"
{
float inputs:diffuseGain = 0.3
float inputs:specularRoughness = 0.1
}
}
}
}
}
If you examine the flattened RobotScene.usd you will see the effect of specializes on the specialized /World/Characters/Rosie/Materials/CorrodedMetal prim: we overrode both diffuseGain and specularRoughness on the base Metal material, but only the diffuseGain propagates onto /World/Characters/Rosie/Materials/CorrodedMetal, because specularRoughness was already refined on the referenced /Robot/Materials/CorrodedMetal prim. This also demonstrates the difference between specializes and inherits: if you change the specializes arc to inherits in Robot.usd and recompose the scene, you will see that both diffuseGain and specularRoughness propagate onto /World/Characters/Rosie/Materials/CorrodedMetal.
如果你检查展平的RobotScene.usd，你会看到specialized在specialized /World/Characters/Rosie/Materials/CorrodedMetal prim上的效果：我们覆盖了基础金属材质上的diffuseGain和spectrularRoughness，但只有diffuseGain传播到/World/Characteristics/Rosie/Materials/CorrodedMetal，因为spectrularRoughness已经在引用的/Robot/Materials/CorrodedMetal底漆上进行了细化。这也说明了特殊化和继承之间的区别：如果你在Robot.usd中将specialized弧更改为继承并重新合成场景，你会看到diffuseGain和spectrularRoughness都传播到/World/Characters/Rosie/Materials/CorrodedMetal上。
The specializes behavior is desirable in this context of building up many unique refinements of something whose base properties we may want to continue to update as assets travel down the pipeline, but without changing anything that makes the refinements unique. What if we do want to broadcast an edit on the Metal material to all of the Materials that specialize it? All we need do is use inherits and specializes together: make each Metal itself and each specialized material (such as CorrodedMaterial) inherit from a /_class_Metal prim. Now any overrides added in /_class_Metal will propagate to each specialized material regardless of whether they have expressed any opinion about it in referenced layers, themselves.
在构建某些事物的许多独特细化的上下文中，特殊化行为是可取的，随着资产的传输，我们可能希望继续更新其基础属性，但不改变任何使细化唯一的东西。如果我们真的想把金属材质的编辑广播给所有专门使用它的材质怎么办？我们需要做的就是一起使用继承和特殊化：使每个Metal本身和每个专用材质（如CorrodedMaterial）继承自/_class_Metal prim。现在，在/_class_Metal中添加的任何覆盖都将传播到每种专用材质，而不管它们是否在引用层中表达了对该材质的任何意见。
Specifier 规格
Every PrimSpec possesses a specifier, which conveys the author’s (authoring tool’s) intent for how the PrimSpec should be consumed and interpreted in a composed scene. There are three possible values for a prim’s specifier in USD, defined by SdfSpecifier:
每个PrimSpec都拥有一个说明符，它传达了作者（创作工具）在合成场景中如何使用和解释PrimSpec的意图。在USD中，由SdfSpecifier定义的prim的说明符有三种可能的值：
A prim’s resolved specifier on a UsdStage determines which kinds of traversals (as defined by “prim flags”) will visit the prim. The most common, default traversals, which are meant to be used for rendering and other common scenegraph processing, will visit only defined, non-abstract prims.
一个prim在UsdStage上的解析说明符确定哪些类型的遍历（由“prim标志”定义）将访问prim。最常见的默认遍历，旨在用于渲染和其他常见场景图处理，将仅访问定义的非抽象素数。
Stage 阶段
A stage is the USD abstraction for a scenegraph derived from a root USD file, and all of the referenced/layered files it composes. A stage always presents the composed view of the scene description that backs it. The UsdStage class embodies a Stage, and caches in memory just enough information about the composed namespace and backing files so that we can rapidly traverse the stage and perform efficient data queries, and allow prim, property, and metadata editing targeted at any layer that contributes to the Stage’s composition. Mutated stage layers can be collectively saved to backing-store using UsdStage::Save.
stage是从根USD文件派生的场景图的USD抽象，以及它组成的所有引用/分层文件。舞台始终呈现支持它的场景描述的合成视图。UsdStage类包含了一个Stage，并在内存中缓存了关于合成的命名空间和支持文件的足够信息，以便我们可以快速遍历Stage并执行高效的数据查询，并允许针对任何有助于Stage合成的层进行prim、property和元数据编辑。使用UsdStage：：Save可以将变异的阶段层集体保存到备份存储。
Stage Traversal 舞台穿越
Most consumption of USD data follows the pattern of traversing an open stage, processing prims one at a time, or several in parallel. A UsdStage allows for both direct and subtree range-based traversals, each with “filtering” according to a number of criteria.
USD数据的大多数消费遵循遍历开放阶段的模式，一次处理一个素数，或者并行处理几个素数。UsdStage允许直接遍历和基于子树范围的遍历，每个遍历都根据许多标准进行“过滤”。
direct 直接
Given a UsdPrim p, one can fetch its direct children on the Stage using p.GetChild() <UsdPrim::GetChild>, p.GetChildren() <UsdPrim::GetChildren>, p.GetAllChildren() <UsdPrim::GetAllChildren>, and p.GetFilteredChildren() <UsdPrim::GetFilteredChildren>.
给定UsdPrim p，可以使用p.GetChild（）、p.GetChildren（）、p.GetAllChildren（）和p.GetFilteredChildren（）在舞台上获取其直接子项。subtree range iteration 子树范围迭代
One can also fetch a UsdPrimSubtreeRange directly from a prim via p.GetDescendants() <UsdPrim::GetDescendants>, p.GetAllDescendants() <UsdPrim::GetAllDescendants>, and p.GetFilteredDescendants() <UsdPrim::GetFilteredDescendants>.
还可以通过p.GetDescendants（）、p.GetAllDescendants（）和p.GetFilteredDescendants（）直接从primer获取UsdPrimSubtreeRange。Note 注记
None of the Get*Descendants() methods are wrapped to Python, pending a refactoring project).
没有Get*Descendants（）方法被包装到Python，等待重构项目）。Additionally, and more commonly used in USD core code, one can traverse the subtree rooted at a prim by creating a UsdPrimRange, which allows for depth-first iteration with the ability to prune subtrees at any point during the iteration. The UsdStage::Traverse method creates and returns a UsdPrimRange that will traverse the entire stage using the “default predicate.”
此外，在USD核心代码中更常用的是，可以通过创建UsdPrimRange来遍历以prim为根的子树，这允许深度优先迭代，并能够在迭代期间的任何点修剪子树。UsdStage：：Traverse方法创建并返回一个UsdPrimRange，该UsdPrimRange将使用“默认谓词”遍历整个阶段。
Traversal Filtering via PrimFlag Predicates
通过PrimFlag谓词的遍历过滤
All of the methods mentioned above that contain “Filtered” in their name, plus UsdPrimRange, allow one to specify a predicate consisting of a boolean combination of “flags” that test against certain (all cached, for fast access) states of prims. Some examples are whether a prim is defined, or active, or loaded, etc. For a full list of the possible prim flags and examples of how they can be logically combined, see prim predicate flags. The remaining methods (e.g. GetChildren()) all use a predefined Default Predicate that serves a common traversal pattern.
上面提到的名称中包含“Filtered”的所有方法，加上UsdPrimRange，允许人们指定一个谓词，该谓词由“flags”的布尔组合组成，用于测试prim的某些（所有缓存，用于快速访问）状态。一些实例是引物是否被定义、或活性或加载等。有关可能的prim标志的完整列表以及如何在逻辑上组合它们的示例，请参见prim谓词标志。其余方法（例如GetChildren（））都使用一个预定义的默认谓词，该谓词服务于一个公共遍历模式。
Subcomponent 子组件
Subcomponent is another kind value like component that can be applied to a prim, but is not a “model kind”, and serves a different purpose. The model-kinds collaborate to form a model hierarchy, whose purpose is to provide a lightweight prefix/index of a complicated scene. By contrast, subcomponents have no strict contiguity rules associated with them; rather, a subcomponent just identifies some prim inside a component that may be “important”. An exporter may choose to identify articulation points in a complicated model by labeling such prims as subcomponents (for example, the DoorAssembly Xform inside an architectural model). Thus subcomponents provide a way of setting up levels of organizational complexity within component models, providing intermediate interfaces/views of a model’s organization that sit in-between “just show me a single prim for the entire model” and “expand all hierarchy down to leaf prims”.
子组件是另一种类型值，类似于组件，可以应用于primer，但不是“模型类型”，并且服务于不同的目的。模型种类协作形成一个模型层次，其目的是提供一个轻量级的前缀/索引的复杂场景。相比之下，子组件没有与它们相关联的严格邻接规则;相反，子组分只是识别组分内部可能是“重要”的一些引物。导出器可以选择通过将这些图元标记为子组件（例如，建筑模型中的DoorAssembly Xform）来标识复杂模型中的接合点。因此，子组件提供了一种在组件模型中建立组织复杂性级别的方法，提供了模型组织的中间接口/视图，它们位于“仅为整个模型显示一个prim”和“将所有层次向下扩展到叶prim”之间。
As another example of how subcomponents may guide interaction behavior, the pxrUsdReferenceAssembly plugin for Maya uses the presence of subcomponent prims to guide the behavior of its “expanded” representation.
作为子组件如何指导交互行为的另一个示例，Maya的pxrUsdReferenceAssembly插件使用子组件的底标来指导其“展开”表示的行为。
SubLayers 子层
SubLayers is the composition arc used to construct LayerStacks. As an example, here is one possible combination of USD layers that could have been the source for the example in the LayerStack entry, and also demonstrate how SubLayers supports nested LayerStacks:
SubLayers是用于构造LayerStacks的合成弧。作为示例，这里是一个可能的USD图层组合，它可能是LayerStack条目中示例的源，并演示子图层如何支持嵌套LayerStacks：
#usda 1.0
(
subLayers = [
@shotFX.usd@,
@shotAnimationBake.usd@,
@sequence.usd@
]
)
#usda 1.0
(
subLayers = [
@sequenceFX.usd@,
@sequenceLayout.usd@,
@sequenceDressing.usd@
]
)
Note that SubLayers can specify Layer Offsets to offset and scale time-varying data contained in the sub-layer(s)
请注意，子图层可以指定图层偏移来偏移和缩放子图层中包含的时变数据
TimeCode 时间代码
TimeCodes are the unit-less time ordinate in USD. A UsdTimeCode can encode the ordinate for a TimeSample in double-precision floating point, but can also encode the ordinate that maps to an attribute’s Default Value. For any given composed scene, defined by its root layer, the TimeCode ordinates of the TimeSamples contained in the scene are scaled to seconds by the root layer’s timeCodesPerSecond metadata, which can be retrieved with UsdStage::GetTimeCodesPerSecond. This allows clients great flexibility to encode their TimeSamples within the range and scale that makes the most sense for their application, while retaining a robust mapping to “real time” for decoding and playback.
时间代码是以美元为单位的无单位时间坐标。UsdTimeCode可以用双精度浮点编码TimeSample的纵坐标，但也可以对映射到属性默认值的纵坐标进行编码。对于由其根层定义的任何给定的合成场景，场景中包含的TimeSamples的TimeCode坐标通过根层的timeCodesPerSecond元数据被缩放到秒，该元数据可以使用UsdStage：：GetTimeCodesPerSecond检索。这使客户端能够灵活地在对应用程序最有意义的范围和尺度内编码TimeSamples，同时保留了一个健壮的映射到“真实的”以进行解码和回放。
TimeSample TimeSample
The term timeSample is used in two related contexts in USD:
术语timeSample在USD的两个相关上下文中使用：
TimeSamples as source for Value Resolution
TimeSamples作为值分辨率源Each PropertySpec for an Attribute can contain a collection called timeSamples that maps TimeCode ordinates to values of the Attribute’s type.
Attribute的每个PropertySpec都可以包含一个名为timeSamples的集合，该集合将TimeCode坐标映射到Attribute类型的值。The time-ordinate for an Attribute
属性的时间坐标USD API sometimes refers to just the ordinate of a time-varying value as a TimeSample; for example, UsdAttribute::GetTimeSamples and UsdAttribute::GetTimeSamplesInInterval return a simple vector of time ordinates at which samples may be resolved on the attribute.
USD API有时只是指时变值的纵坐标作为TimeSample;例如，UsdAttribute：：GetTimeSamples和UsdAttribute：：GetTimeSamplesInInterval返回时间坐标的简单向量，在该向量处样本可以被解析在属性上。
Typed Schema 类型化架构
Synonym for IsA Schema. 伊萨Schema的同义词。
User Properties 用户属性
userProperties: is a property namespace recognized by the majority of DCC plugins as a place to look for “extra custom properties” that are too informal to warrant creating an API Schema, but which you might need access to in the DCC’s, and want to ensure they get round-tripped back to USD. We plan to create a UsdUserPropertiesAPI schema to aid in authoring and enumerating user properties, but creating a property in the userProperties: namespace using UsdPrim::CreateAttribute() (not all importers may handle custom relationships properly) is sufficient.
用户属性：大多数DCC插件都认为它是一个属性命名空间，可以用来寻找“额外的自定义属性”，这些属性过于非正式，以至于无法保证创建API Schema，但您可能需要在DCC中访问这些属性，并希望确保它们能往返返回到USD。我们计划创建一个UsdUserPropertyAPI模式来帮助创建和枚举用户属性，但在userProperties中创建一个属性：使用UsdPrim：：CreateAttribute（）命名空间（并非所有导入程序都能正确处理自定义关系）就足够了。
Value Clips 数值剪辑
Value Clips are a feature that allows one to partition varying attribute timeSample overrides into multiple files, and combine them in a manner similar to how non-linear video editing tools allow one to combine video clips. Clips are especially useful for solving two important problems in computer graphics production pipelines:
Value Clips是一种功能，它允许人们将变化的属性timeSample覆盖划分为多个文件，并以类似于非线性视频编辑工具允许人们组合视频剪辑的方式联合收割机它们。剪辑对于解决计算机图形生产流水线中的两个重要问题特别有用：
Crowd/background animation at scale
按比例缩放的群组/背景动画Crowd animators will often create animation clips that can apply to many background characters, and be sequenced and cycled to generate a large variety of animation. USD clips provide the ability to encode the sequencing and non-uniform time-mapping of baked animation clips that this task requires.
群体动画师通常会创建动画剪辑，这些动画剪辑可以应用于许多背景角色，并被排序和循环以生成各种各样的动画。USD剪辑提供了对此任务所需的烘焙动画剪辑的序列和非均匀时间映射进行编码的能力。File-per-frame “big data”
File—per—Frame大数据The results of some simulations and other types of sequentially-generated special effects generate so much data that it is most practical for the simulator to write out each time-step or frame’s worth of data into a different file. USD Clips make it possible to stitch all of these files together into a continuous (even though the data may itself be topologically varying over time) animation, without needing to move, merge, or perturb the files that the simulator produced. The USD toolset includes a utility usdstitchclips that efficiently assembles a sequence of file-per-frame layers into a Value Clips representation.
一些模拟和其他类型的顺序生成的特效的结果生成了如此多的数据，以至于模拟器最实际的做法是将每个时间步或帧的数据写入不同的文件。USD Clips可以将所有这些文件拼接成连续的动画（即使数据本身可能随着时间的推移而发生拓扑变化），而不需要移动、合并或干扰模拟器生成的文件。USD工具集包括一个实用程序usdstitchclips，它可以有效地将每帧文件层序列组装成Value Clips表示。
The key advantage of the clips feature is that the resulting resolved animation on a UsdStage is indistinguishable from data collected or aggregated into a single layer. In other words, consuming clients can be completely unaware of the existence of clips: there is no special schema or API required to access the data. The disadvantages of using clips are:
剪辑功能的主要优点是，在UsdStage上生成的解析动画与收集或聚合到单个图层中的数据是无法区分的。换句话说，消费客户端可能完全不知道剪辑的存在：不需要特殊的模式或API来访问数据。使用剪辑的缺点是：
Encoding clips on a stage is more complicated than simply recording samples on attributes, or adding references (see UsdClipsAPI for details on encoding)
在舞台上对剪辑进行编码比简单地在属性上记录样本或添加引用要复杂得多（有关编码的详细信息，请参阅UsdClipsAPI）There is some performance overhead associated with the use of clips, both in the number of files that must be opened to play back animation (but that’s what we asked for in using clips!), and also in extra overhead in resolving attribute values in the presence of clips. Clips are the reason that UsdProperty::GetPropertyStack requires a timeCode argument, because the set of layers that contribute to an attribute’s value can change over time when it is affected by clips.
使用剪辑会带来一些性能开销，包括播放动画必须打开的文件数量（但这正是我们使用剪辑时所要求的！），以及在存在剪辑的情况下解析属性值的额外开销。剪辑是UsdProperty：：GetPropertyStack需要timeCode参数的原因，因为当属性值受到剪辑影响时，有助于属性值的图层集可能会随时间变化。
Note 注记
For performance and scalability reasons, a UsdStage will ignore any composition arcs contained in a “clip” USD file, which means that clips can only usefully contain direct (local) opinions about the attributes they wish to modify. For more information on value clip behavior and how clips are encoded, see Sequenceable, Re-timeable Animated Value Clips in the USD Manual.
出于性能和可伸缩性的原因，UsdStage将忽略包含在“剪辑”USD文件中的任何合成弧，这意味着剪辑只能有效地包含关于它们希望修改的属性的直接（本地）意见。有关值剪辑行为和剪辑编码方式的详细信息，请参见USD手册中的可序列、可重计时的动画值剪辑。
Value Resolution 价值分辨率
Value Resolution is the algorithm by which final values for properties or metadata are “composed” from all of the various PropertySpecs or PrimSpecs that contain data for the property or metadatum. Even though value resolution is the act of composing potentially many pieces of data together to produce a single value, we distinguish value resolution from composition because understanding the differences between the two aids in effective construction and use of USD:
值解析是一种算法，通过该算法，属性或元数据的最终值由包含属性或元数据的所有各种PropertySpecs或PrimSpecs“组成”。尽管价值解析是将许多数据组合在一起以产生单个值的行为，但我们将价值解析与组合区分开来，因为理解两者之间的差异有助于有效地构造和使用USD：
Composition is cached, value resolution is not
缓存了合成，不缓存值解析The “indexing” performed by the composition algorithm when a Stage is opened, prims are loaded, or new scene description is authored, is cached at the prim-level for fast access. The USD core does not, however, pre-compute or cache any per-composed-property information, which is a principal design decision aimed at keeping latency low for random-access to composed data, and keeping the minimal memory footprint for USD low. Instead, for attribute value resolution, the USD core provides opt-in facilities such as UsdAttributeQuery and UsdResolveInfo, objects a client can construct and retain themselves that cache information that can make repeated value queries faster.
当打开舞台、加载prim或创作新场景描述时，由合成算法执行的“索引”被缓存在prim级别以用于快速访问。然而，USD核不预计算或缓存任何每组合属性信息，这是主要的设计决策，旨在保持低的延迟以用于随机访问组合数据，并保持低的USD的最小存储器占用。相反，对于属性值解析，USD核心提供了选择性加入工具，如UsdAttributeQuery和UsdResolveInfo，客户端可以构建并保留它们自己的对象，这些对象可以缓存可以使重复值查询更快。Composition is internally multi-threaded, value resolution is meant to be client multi-threaded.
组合是内部多线程的，值解析意味着客户端多线程的。Composition of a large stage can be a big computation, and USD strives to effectively, internally multi-thread the computation; therefore clients should realize they are unlikely to gain performance from opening multiple stages simultaneously in different threads. Value resolution, however, is a much more lightweight process (moreso for attributes than relationships), and USD’s primary guidance for clients wishing to maximize USD’s performance on multi-core systems is to perform as much simultaneous value resolution and data extraction as possible; USD’s design was guided by this access pattern, and we continue to work on eliminating remaining impediments to efficient multi-threaded value resolution.
一个大的阶段的组成可以是一个大的计算，和USD努力有效地，内部多线程的计算;因此，客户端应该意识到它们不太可能从在不同线程中同时打开多个阶段中获得性能。然而，价值解析是一个更轻量级的过程（更多的是属性而不是关系），对于希望最大化USD在多核系统上性能的客户，USD的主要指导是尽可能多地同时执行价值解析和数据提取; USD的设计是以这种访问模式为指导的，我们将继续努力消除对高效多线程值解析的剩余障碍。Composition rules vary by composition arc, value resolution rules vary by metadatum.
组合规则因组合弧而异，值分解规则因元表而异。The composition algorithm is the process of interpreting a collection of composition arcs into an “index” of data-containing sites for each composed prim. Value resolution simply consumes the ordered (strong-to-weak) list of contributing sites, and is otherwise insensitive to the particular set of composition arcs that produced that list; but how the data in those sites is combined depends on the particular metadatum being resolved.
组合算法是将组合弧的集合解释为每个组合引物的含数据位点的“索引”的过程。值解析仅仅消耗贡献站点的有序（强到弱）列表，否则对产生该列表的特定组合弧集不敏感;但是如何组合那些站点中的数据取决于被解析的特定元数据。
Resolving Metadata 解析元数据
The basic rule for the metadata value resolution provided by UsdObject::GetMetadata is: strongest opinion wins. Certain metadata such as prim specifier, attribute typeName, and several others have special resolution rules; the only one we will discuss here is dictionary-valued metadata, because it is user-facing, as, for example, the customData dictionary authorable on any prim or property. Dictionaries are resolved element-wise, so that customData[“keyOne”] authored on a referencing prim will not block, but rather compose into a single dictionary with customData[“keyTwo”] on the referenced prim.
UsdObject：：GetMetadata提供的元数据值解析的基本规则是：最强的意见获胜。某些元数据，如prim说明符、属性typeName和其他一些元数据具有特殊的解析规则;我们在这里讨论的唯一一个是字典值元数据，因为它是面向用户的，例如，customData字典可在任何prim或属性上授权。字典是按元素解析的，这样在引用prim上编写的customData[“keyOne”]不会阻塞，而是在引用prim上使用customData[“keyTwo”]组成单个字典。
Resolving Relationships 解决关系
Because relationship targets are list edited, we must, in general, combine all of the opinions about the relationship’s targets, not just the strongest. The rules for how the opinions combine (in weak-to-strong order) are contained inside SdfListOp::ApplyOperations.
因为关系目标是列表编辑的，所以一般来说，我们必须联合收割机所有关于关系目标的意见，而不仅仅是最强的意见。意见如何联合收割机的规则（以弱到强的顺序）包含在SdfListOp：：ApplyOperations中。
Resolving Attributes 解析属性
Value resolution for attributes, as performed by UsdAttribute::Get, is unique in three ways:
UsdAttribute：：Get执行的属性值解析在三个方面是唯一的：
Time Offsets 时间偏移
UsdAttribute::Get is a function of time, so all queries except those evaluated at UsdTimeCode::Default are affected by time-scaling operators such as Layer Offsets.
UsdAttribute：：Get是时间的函数，因此除了在UsdTimeCode：：Default下计算的查询外，所有查询都受到时间缩放运算符（如图层偏移）的影响。Interpolation 插值
If the requested time ordinate falls between two samples, and the stage is configured for linear interpolation (which it is by default), then we will attempt to apply linear interpolation of the bracketing timeSamples, before falling back to holding the earlier of the two timeSamples.
如果请求的时间坐标福尔斯在两个样本之间，并且级被配置为线性插值（默认情况下是这样），那么我们将尝试应用包围时间样本的线性插值，然后回落到保持两个时间样本中较早的一个。Three value sources for each site
每个站点有三个价值来源For each site in a prim’s Index that may affect a metadatum or relationship, there is just a single place to look for a value - if none is found, we move on to the next site looking for values. For attributes, however, we must examine three possible sources for a value for each site, before moving on to the next site in strong-to-weak order:
对于prim的索引中可能影响元数据或关系的每个站点，只有一个地方可以查找值-如果没有找到，我们就转到下一个站点查找值。然而，对于属性，我们必须检查每个站点的值的三个可能的来源，然后按强到弱的顺序移动到下一个站点：
Value Clips that are anchored at the site or an ancestor site in namespace. If no clips are found, or if clips do not provide a value for the attribute, then…
锚定在命名空间中的站点或祖先站点的值剪辑。如果未找到剪辑，或者剪辑未提供属性值，则...TimeSamples authored directly at the site. If there are no TimeSamples, then…
直接在研究中心创作的TimeSamples。如果没有TimeSamples，则...Default Value authored directly at the site
直接在研究中心编写的默认值
Effective use of UsdAttribute::Get()
有效使用UsdAttribute：：Get（）
The default UsdTimeCode value for UsdAttribute::Get() is UsdTimeCode::Default(), which is almost always a poor choice when resolving values on a stage that contains animation. When writing code that extracts attribute values from a stage, if the codesite is not provided an explicit querying time, you should use UsdTimeCode::EarliestTime(), which will ensure that if there is any timeSample authored for the attribute, it will provide the value, rather than the default, which is all that is consulted when UsdTimeCode::Default() is the given time ordinate.
UsdAttribute：：Get（）的默认UsdTimeCode值为UsdTimeCode：：Default（），在解析包含动画的舞台上的值时，这几乎总是一个糟糕的选择。当编写代码从阶段提取属性值时，如果没有为codesite提供显式查询时间，您应该使用UsdTimeCode：：EarliestTime（），这将确保如果有任何timeSample为该属性创作，它将提供值，而不是默认值，当UsdTimeCode：：Default（）是给定的时间坐标时，这是所有要参考的。
Variability 变异性
Attributes possess a special piece of metadata called variability that serves as a statement of intent (typically by a schema) of whether the attribute’s value should have timeSamples that can vary its value over time, or whether it should be restricted to having only a default value. Variability can have two values: varying and uniform; by default, a newly created attribute is varying (unless you explicitly specify otherwise), and varying attributes appear “unadorned” in the usda text format. Attributes that are uniform, however, will appear with the “uniform” modifier in any layer that contains a properly-authored opinion for the attribute.
属性拥有称为可变性的特殊元数据块，用作意图声明（通常通过模式），说明属性的值是否应该具有随时间变化的timeSamples，或者是否应该限制为仅具有默认值。可变性可以有两个值：变化均匀;默认情况下，新创建的属性是变化的（除非您明确指定其他），并且变化的属性在USDA文本格式中显示为“不加修饰”。但是，统一的属性将与“统一”修饰符一起出现在包含属性正确创作意见的任何图层中。
Variability is not consulted or consumed by the core during authoring or value resolution, in order to keep those operations fast. It appears in schema-generated documentation, and can be used for validation by higher-level authoring code, and as a hint to clients that the value is not expected to change over time. See also UsdAttribute::GetVariability
在创作或值解析期间，核心不咨询或消费可变性，以便保持这些操作快速。它出现在模式生成的文档中，可以用于更高级别的创作代码的验证，并作为一个提示，提示客户端的值不会随着时间而改变。另请参见UsdAttribute：：GetVariability
Mesh模式中统一属性“subdivisionScheme”的usda
def Mesh "SimulatableGarment"
{
uniform token subdivisionScheme = "loop"
}
Variant 变体
A variant represents a single, named variation of a VariantSet; each VariantSet can have zero or a single variant selection expressed in scene description or as a fallback in a plugin or specified by an application, if no selection was authored. “variants” is also the keyword in the usda text syntax for expressing variant selections, as strings. The following valid usda expresses a selection of “High” for the variantSet named “lodVariant”. Variant selections are always strings that refer to variant names, which can be USD identifiers with the addition of allowing the “-” character, and an optional leading “.”.
变体表示VariantSet的单个命名变体;如果没有创作选择，则每个VariantSet可以具有零个或单个变体选择，所述变体选择在场景描述中表达，或者作为插件中的后备，或者由应用程序指定。“变体”也是USDA文本语法中的关键字，用于将变体选择表达为字符串。以下有效的usda表示名为“lodVariant”的variantSet的“High”选择。变量选择始终是引用变量名称的字符串，变量名称可以是USD标识符，并允许添加“-”字符和可选的前导“.”。
用于表达变体选择的最小场景描述
#usda 1.0
over "Model" (
variants = {
string lodVariant = "High"
}
)
{
}
A variant can contain overriding opinions (for properties, metadata, and more), as well as any arbitrary scene description (entire child prim subtrees, etc). Variants can also include additional composition arcs. This gives us great flexibility in building up variations out of existing, modular pieces that can be referenced, inherited, etc. In the following example snippet, the “referenceVariantSet” VariantSet contains two variants that reference different USD assets. Changing the variant selection controls which asset is referenced in the scene.
一个变量可以包含覆盖的意见（属性，元数据等），以及任何任意的场景描述（整个子prim子树等）。变体还可以包括另外的合成弧。这给了我们很大的灵活性，可以从现有的模块化部分中构建变体，这些模块化部分可以被引用、继承等。在以下示例代码段中，“referenceVariantSet”VariantSet包含引用不同USD资产的两个变量。更改变体选择可控制在场景中引用的资源。
带引用的VariantSet
over "Model" (
prepend variantSets = "referenceVariantSet"
variants = {
string referenceVariantSet = "asset1"
}
)
{
variantSet "referenceVariantSet" = {
"asset1" (
prepend references = @Asset1.usda@
) {
}
"asset2" (
prepend references = @Asset2.usda@
) {
}
}
}
VariantSet 变量
A VariantSet is a composition arc that allows a content creator to package a discrete set of alternatives, between which a downstream consumer is able to non-destructively switch, or augment. A reasonable way to think about VariantSets is as a “switchable reference”. Each Variant of a VariantSet encapsulates a tree of scene description that will be composed onto the prim on which the VariantSet is defined, when the Variant is selected. VariantSet names must be legal USD identifiers. Here is an example of a very simple VariantSet:
VariantSet是允许内容创建者打包离散的备选集合的合成弧，下游消费者能够在其之间非破坏性地切换或增强。考虑VariantSets的一个合理方式是作为一个“可切换的参考”。VariantSet的每个Variant封装了场景描述树，当选择VariantSet时，该树将被合成到定义VariantSet的primer上。VariantSet名称必须是法律的的USD标识符。下面是一个非常简单的VariantSet示例：
#usda 1.0
def Xform "Implicits" (
append variantSets = "shapeVariant"
)
{
variantSet "shapeVariant" = {
"Capsule" {
def Capsule "Pill"
{
}
}
"Cone" {
def Cone "PartyHat"
{
}
}
"Cube" {
def Cube "Box"
{
}
}
"Cylinder" {
def Cylinder "Tube"
{
}
}
"Sphere" {
def Sphere "Ball"
{
}
}
}
}
Things to note about simpleVariantSet.usd
关于simpleVariantSet.usd的注意事项
Variant selections are not required.
不需要选择变量。If you copy/paste, then open simpleVariantSet.usd in usdview, nothing will be drawn! This is because we have not specified a selection for shapeVariant (see Variant for what a selection looks like), which is always a valid thing to do, and simply means none of the variants contained in the VariantSet will be applied. If you select the prim /Implicits in usdview's browser, and open the “Metadata” tab of the inspector in the lower-right-hand corner, you will find a drop-down selection box for shapeVariant, from which you can select any of the variations and see the viewport update in response. Each time you make a selection, usdview is authoring a variant selection on /Implicits in the opened stage’s session layer.
如果您复制/粘贴，然后在usdview中打开simpleVariantSet.usd，则不会绘制任何内容！这是因为我们没有为shapeVariant指定一个选择（请参阅Variant了解选择的样子），这总是一个有效的做法，这意味着VariantSet中包含的任何变量都不会被应用。如果您在usdview的浏览器中选择prim /Implicates，并打开右下角检查器的“元数据”选项卡，您将找到shapeVariant的下拉选择框，您可以从中选择任何变体并查看视口更新。每次进行选择时，usdview都会在打开的stage会话层中的/Implicates上创作一个变体选择。Variants can contain *any* scene description.
变体可以包含 * 任何 * 场景描述。Variants are not just about overrides! In simpleVariantSet.usd, we are creating a differently-named-and-typed child prim in each variant. Each variant can in fact create an entire subtree of prims (that will be combined on top of any referenced scene description), as well as apply overrides.
变体不仅仅是覆盖！在simpleVariantSet.usd中，我们在每个变体中创建一个不同名称和类型的子prim。实际上，每个变体都可以创建一个完整的prims子树（将在任何引用的场景描述之上组合），并应用覆盖。VariantSets are “inlined” in usda.
VariantSet在usda中是“内联”的。Although VariantSets, in composition terms, behave very much like references and other arcs that target “remote” scene description, VariantSets are presented as “inlined scene description” inside the prim they modify (or rather, inside the prim, the root of whose subtree the VariantSet modifies).
虽然VariantSet在合成术语中表现得非常像引用和其他以“远程”场景描述为目标的弧，但VariantSet在它们修改的prim内部（或者更确切地说，在prim内部，VariantSet修改其子树的根）呈现为“内联场景描述”。
Characteristics of VariantSets
VariantSets的特征
A prim can have an unlimited number of VariantSets declared directly on itself; the VariantSets can be ordered (initial order is authored order) as part of their List Editing nature, and the final order of the VariantSets provides their relative strength with respect to each other, should their opinions overlap.
一个prim可以有无限数量的VariantSet直接在它自己上声明;可以将变量集排序（初始顺序是创作顺序）作为它们的列表编辑性质的一部分，并且如果它们的意见重叠，则变量集的最终顺序提供它们相对于彼此的相对强度。Because VariantSets are just composition arcs, this implies that VariantSets can be directly nested inside each other, by allowing a Variant of a VariantSet to introduce a new VariantSet. This allows a concise encoding for dependent VariantSets, wherein the options/variants available for the inner/nested VariantSet depends on the selection of the outer VariantSet; see below for an example.
因为VariantSet只是复合弧，这意味着通过允许VariantSet的变体引入新的VariantSet，VariantSet可以直接嵌套在彼此内部。这允许对依赖的VariantSet进行简明编码，其中可用于内部/嵌套的VariantSet的选项/变体取决于外部VariantSet的选择;参见下面的示例。Higher-level/downstream contexts can dynamically add new Variants to existing VariantSets. This ability facilitates the use of VariantSets to provide as-you-go asset version control, which can be especially useful, for example, in refining simulations or special effects. We might reference in a low-res water simulation in a weak “sequence layer” that is shared by a number of shots in a sequence. One shot , however, requires a closeup, necessitating a higher resolution simulation. If the sequence-level simulation was placed inside a version VariantSet, in a SequenceBase Variant, then the special shot can, in a layer stronger, simply introduce a new CloseupShot Variant to the version VariantSet. In that shot, both variants will be available and selectable. In other shots, only the SequenceBase Variant will be available.
较高级/下游上下文可以动态地将新的变体添加到现有的变体集合。此功能有助于使用VariantSets来提供随需应变的资源版本控制，这在优化模拟或特殊效果等方面尤其有用。我们可以在低分辨率水模拟中引用弱“序列层”，该“序列层”由序列中的多个镜头共享。然而，一个镜头需要特写，需要更高分辨率的模拟。如果序列级模拟被放置在SequenceBase Variant中的版本VariantSet内，则特殊镜头可以在更强的层中简单地将新的CloseupShot Variant引入到版本VariantSet。在该镜头中，两种变体都可用并可选择。在其他快照中，只有SequenceBase变体可用。VariantSets allow optimal scattering of instancing variation, because for any given instanceable prim, its instancing key, which is what we use to decide which scene-level instances will share the same prototype, takes the variant selections on the prim into account. So, if you build and publish an asset with one-or-more VariantSets on its root prim, an environment-building tool can confidently add many instances of the asset to a scene, scattering variation by scattering variant-selections, and the USD core will ensure only as many unique prototypes are compose as there are unique combinations of variant-selections.
VariantSets允许实例化变化的最佳分散，因为对于任何给定的可实例化prim，其实例化键（我们用来决定哪些场景级实例将共享相同的原型）考虑了prim上的变体选择。因此，如果您构建并发布在其根prim上具有一个或多个VariantSet的资源，则环境构建工具可以自信地将资源的许多实例添加到场景中，通过分散变体选择来分散变化，并且USD核心将确保仅组成与变体选择的独特组合一样多的独特原型。
Nested VariantSets 嵌套变量集
As mentioned above, VariantSets can be nested directly inside each other, on the same prim. VariantSet nesting in USD can be accomplished straightforwardly by nesting the use of UsdEditContext objects in code. Following is a small python program that nests two VariantSets, demonstrating that the contents of the inner VariantSet can vary from Variant to Variant of the outer VariantSet.
如上所述，VariantSets可以直接嵌套在同一个prim上。USD中的VariantSet嵌套可以通过在代码中嵌套UsdEditContext对象的使用来直接完成。下面是一个嵌套两个VariantSet的小Python程序，演示了内部VariantSet的内容可以从外部VariantSet的Variant变化到Variant。
from pxr import Sdf, Usd
stage = Usd.Stage.CreateNew("nestedVariants.usd")
prim = stage.DefinePrim("/Employee")
title = prim.CreateAttribute("title", Sdf.ValueTypeNames.String)
variantSets = prim.GetVariantSets()
critters = [ "Bug", "Bear", "Dragon" ]
jobs = [ "Squasher", "Rider", "Trainer" ]
critterVS = variantSets.AppendVariantSet("critterVariant")
for critter in critters:
critterVS.AppendVariant(critter)
critterVS.SetVariantSelection(critter)
with critterVS.GetVariantEditContext():
# All edits now go "inside" the selected critter variant
jobVS = variantSets.AppendVariantSet("jobVariant")
for job in jobs:
if (job != "Squasher" or critter == "Bug") and \
(job != "Rider" or critter != "Bug") :
jobVS.AppendVariant(job)
jobVS.SetVariantSelection(job)
with jobVS.GetVariantEditContext():
# Now edits *additionally* go inside the selected job variant
title.Set(critter + job)
stage.GetRootLayer().Save()
Try loading the resulting nestedVariants.usd in usdview. Note that as you select different critterVariants, the contents of jobVariant will change, as will of course, the resolved value of the title attribute on the /Employee prim. If you select “Bug” and “Squasher”, respectively, and then change critterVariant to Bear or Dragon” the jobVariant selection will become empty, because the selected variant is not a valid selection for the jobVariant VariantSet defined inside those critter variants. This is not an error condition, and the result is simply that no jobVariant is applied.
尝试在usdview中加载结果nestedVariants.usd。请注意，当您选择不同的critterVariants时，jobVariant的内容将发生变化，当然，/Employee prim上的title属性的解析值也会发生变化。如果分别选择“Bug”和“Squasher”，然后将critterVariant更改为“Bear”或“Dragon”，则jobVariant选择将变为空，因为所选变体不是在这些critter变体中定义的jobVariant VariantSet的有效选择。这不是一个错误条件，结果只是没有应用jobVariant。
Visibility 能见度
Visibility is a builtin attribute of the UsdGeomImageable base schema, and models the simplest form of “pruning” invisibility that is supported by most DCC apps. Visibility can take on two possible token string values:
可见性是UsdGeomImageable基本模式的内置属性，它对大多数DCC应用程序支持的最简单形式的“修剪”不可见性进行建模。可见性可以采用两种可能的令牌字符串值：
inherited (the fallback value if the attribute is not authored)
inherited（如果未创作属性，则为回退值）invisible 不可见的
If the resolved value is invisible, then neither the prim itself nor any prims in the subtree rooted at the prim should be rendered - this is what we mean by “pruning invisibility”, since invisible subtrees are definitively pruned in their entirety. If the resolve value is inherited, it means that the computed visibility (as provided by UsdGeomImageable::ComputeVisibility) of the prim will be whatever the computed value of the prim’s namespace parent is.
如果解析的值是不可见的，那么prim本身或以prim为根的子树中的任何prim都不应该被渲染-这就是我们所说的“修剪不可见性”，因为不可见的子树被明确地整体修剪。如果resolve值是继承的，这意味着prim的计算可见性（由UsdGeomImageable：：ComputeVisibility提供）将是prim的命名空间父级的计算值。
Visibility may be animated, allowing a sub-tree of geometry to be renderable for some segment of a shot, and absent from others; unlike the action of deactivating geometry prims, invisible geometry is still available for inspection, for positioning, for defining volumes, etc.
可见性可以是动画的，从而允许几何结构的子树对于镜头的一些片段是可渲染的，并且不存在于其他片段;与去激活几何图元的动作不同，不可见的几何图元仍然可用于检查、定位、定义体积等。
扫一扫
2373
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
