本文内容
调试资产处理器问题
如果您在使用资产处理器时遇到问题,本页将介绍常见问题、解决方案和调试技巧。
资产处理器最常见的问题包括:
- 更改源资产后,资产处理时间过长。
- 产品资产与预期不符。它们可能有不正确的信息、缺少信息或完全丢失。
- 意外警告或错误。
- 资产打包与预期不符。内容丢失或捆绑包中包含了预期之外的内容。
- 团队中的不同成员从资产处理中获得不同的结果,影响团队的合作能力。
非确定性产品资产
在不更改生成器代码和不更改源资产的情况下,当多次运行该作业时,产品资产的内容最终会与前一次运行时不同。这表明根据用于处理资产的输入,生成器是非确定的。
效果
在尝试生成 Delta Asset Bundles 以创建游戏内容补丁时,会出现比预期更多的资产,导致玩家下载的内容超出需要。
常见原因
- 产品资产中包含无关信息,如时间戳。保证每次构建的信息都会不同,这也是可能的原因。
- 生成器中的逻辑是非确定性的。确保资产构建尽可能具有确定性,且不会产生副作用。
解决方案
在大多数情况下,这需要工程师对内部生成器逻辑进行修改,以稳定产品输出。
调试
您的团队最有可能在生成 Asset Bundles时遇到这个问题,这是非确定性产品资产影响的主要系统。如果由于源资产和关联的资产生成器没有发生变化,而在捆绑包中出现了您没有预料到的产品资产,那么调试往往会从这里开始向后进行。
产品资产中的非确定性行为将由创建该产品资产的资产创建器引入,因此要查明原因,您需要在资产处理器的资产选项卡中查找该产品资产,或使用外部数据库浏览工具直接在资产数据库中查找。在那里,你可以找到创建该产品资产的工作。确定创建该产品资产的任务后,就可以找到生成该任务的生成器,并进入该生成器的 “处理任务 ”功能,找到输出该产品资产的位置。从这里往回推,你应该可以通过探索代码找到产品资产发生变化的原因。你还可以尝试 调试资产创建器处理该作业,逐步完成。
为帮助识别产品资产中每次处理时都在变化的逻辑块,您可以使用标准文件差异工具,使用两个已生成的产品资产。在 “资产处理器 ”的 “asset ”选项卡中右击产品资产,选择 “重新处理源资产reprocess source asset”,即可快速重新生成产品资产。
另一种调试方法是设置自动化,以便及早发现问题。如果您有一个为项目处理资产的自动化系统,您可以扩展该自动化系统,将迭代资产处理与干净的缓存资产处理和前一天的资产进行比较。这样做可以比较产品资产的哈希值,并找出哈希值发生变化而不应该发生变化的地方。
同一产品资产生成了不同的子 ID
情况
产品资产的子 ID 在预期不会发生变化的情况下发生变化。在最坏的情况下,当源资产或创建产品资产的构建程序未发生任何更改时,子 ID 却发生了更改。在其他情况下,源资产的更改会导致产品资产的子 ID 与之前的不同。
效果
资产大多通过资产 ID(源资产的 UUID 和该产品资产的子 ID)进行引用。如果这一点不一致,产品资产的子 ID 在不应更改的情况下发生了更改,那么对该资产的外部引用可能会出现错误,在重建后指向不同的资产,或者在没有其他产品使用该子 ID 的情况下指向任何资产。
示例
下面是一个包含场景文件和Prefab的示例:
- 新建一个名为
shapes_1.fbx
的 FBX 文件,其中包含两个网格,一个立方体和一个圆柱体。将立方体命名为Mesh_A
,圆柱体命名为Mesh_B
。 - 将这两个网格的名称对调,立方体命名为
Mesh_B
,圆柱体命名为Mesh_A
。将其保存为第二个 FBX,命名为shapes_2.fbx
。 - 将
shapes_1.fbx
放到您的项目中,并将其重命名为shapes.fbx
。 - 创建一个新的Prefab,其中包含一个带有网格组件的实体。
- 将
shapes.fbx
中的立方体Mesh_A
分配给此组件。 - 保存并退出编辑器。
- 用之前创建的
shapes_2.fbx
文件替换项目中的shapes.fbx
文件。 - 加载编辑器。
- 加载之前保存的预置。
- 请注意,实体组件上的网格仍然是
Mesh_A
,但现在在视觉上看起来像圆柱体。
出现这种情况是因为场景处理会根据节点名称生成子 ID。预制板通过此 ID 跟踪传出的资产引用,因此节点名称在功能上是用来跟踪从源 FBX 生成的单个 “产品资产 ”的引用。
请注意,在本例中,这种行为是 100% 故意的。本例中不存在代码问题。在这种情况下,如果这种更改不是 FBX 作者有意为之,那就是内容错误。以下章节将介绍如何识别和纠正类似问题。
常见原因
源资产发生变化导致子标识符发生变化
子 ID 发生变化的最常见原因是,子 ID 是根据源资产中的数据生成的,而这些数据可能会发生变化。例如,如果一个节点名称是通过散列生成产品资产的子 ID,那么内容创建者在源资产中重命名该节点将导致相关产品资产生成一个新的子 ID。
从生成器生成非确定性子 ID
有时,生成器的逻辑可能不是完全确定的。例如,如果生成器只是递增一个整数,将其用作生成的每个产品的子 ID,那么源资产更改导致产品更改以移除一个产品时,将导致移除产品资产后的所有产品资产的子 ID 发生更改。
生成器逻辑的更改会改变子 ID 的生成
有时,生成器作者需要更改生成器为产品资产生成 Sub ID 的方式,导致该生成器输出的所有产品资产在下一次处理时改变 Sub ID。
解决方案
在创建创建器时稳定子 ID
创建创建器的人员有责任定义该创建器如何生成子 ID 的规则。在此过程中,我们建议尽量稳定子标识符的生成: 考虑如何修改源资产,以及如何根据这些修改保持产品资产子标识生成的连续性。
资产管道支持遗留子 ID,当创建程序作者需要更改子 ID 时,可以用它将旧的子 ID 重新映射到新的子 ID 上。
为产品资产创建生成器稳定子 ID 的提示:
- 随机生成的子 ID 通常会导致子 ID 在意想不到的情况下发生变化,即使生成是半随机的。应避免随机生成子 ID。
- 有时,创建者会根据源资产中该信息的有序索引为产品资产分配子 ID。这可能导致子 ID 不稳定,因为源资产中的变化可能导致有序列表发生变化。
- 例如,如果内容创建者删除了一个条目,并导致其他所有内容都向下移动索引。
- 只要内容创建者不希望重命名这些对象,以保持子 ID 的稳定,那么将对象名称散列作为引用也是可行的。
- 对对象名称进行散列以用作子 ID 对内容创建者也有好处,因为这样可以通过创建具有相同名称的新数据来替换内容,从而生成具有相同 ID 的产品资产。
- 有时,您可以使用一个稳定的内部 ID,但内容创建者无法直接控制它。例如,可能有一种内部节点结构,会为内容创建者无法更改的节点生成唯一的内部 ID。用它来生成子 ID 在某些方面可能更稳定,但在使用它来生成子 ID 之前,请考虑一下内容创建者的工作流程。有时,内容创建者可能会特别想制作一个新的东西来替代某个东西,并让新的产品资产无缝地用于旧的产品资产的任何地方。请参阅前面关于使用对象名称的例子。
了解如何为处理您所创作内容的构建器生成子 ID
作为内容创建者,了解如何为从您所处理的源资产创建的产品资产生成子 ID,可以从根本上避免这些问题。
当产品资产的子 ID 发生变化时,会导致对该产品资产的所有引用中断,因为资产 ID 将不再解析到该资产。
在创建初始内容时,尤其是创建 FBX 等场景文件时,考虑清楚如何在其他地方引用该内容有助于保持产品资产子 ID 的稳定。
如果您需要更改源资产,请记住您的更改将如何影响产品资产的子 ID。如果确实需要更改 “产品资产”,可遵循的良好模式是
- 创建新产品资产的存根,或为旧产品资产保留存根。
- 查找旧产品资产的所有引用。
- 与团队其他成员合作,根据需要更新这些引用。
- 确定没有任何内容引用旧产品资产后,进行最后修改,将其从源资产中删除。
修复断开的引用 - 更新源资产
更新源资产,使其能输出具有相同子 ID 的产品资产,这样就能修复任何断开的连接。当产品资产被无意删除时,这种方法最有效,因为内容创建者不知道产品资产正在使用中,或者他们对源资产进行了更改,但没有意识到这会导致这一问题。
修复损坏的引用 - 更新引用丢失产品资产的内容
如果产品资产的删除是故意的,或者源资产无法安全地更新以恢复产品资产,那么可能需要更新所有引用已损坏产品资产的内容。在这种情况下,您需要搜索所有已损坏的引用,并针对引用缺失产品资产的每种类型、内容或代码,在相关系统中进行更新,以处理该产品资产的移除或子 ID 的更改。
例如,如果 FBX 文件更新后不再生成产品资产,而 O3DE Prefab通过实体上的网格组件引用了该产品资产,您可以使用Prefab编辑工作流程来修复这个问题。
- 加载要编辑的Prefab。
- 查找引用中断的组件
- 要么将其更改为引用其他内容,要么删除该组件/实体。
调试
如果内容出现丢失或损坏,请尝试在文本编辑器或其他编辑器中打开引用损坏内容的文件,这样可能会显示更多细节。搜索破损的引用,它要么是资产 ID(UUID 和子 ID 的组合),要么是通过相对路径的引用。
如果你能找到丢失的引用,而且它是一个资产 ID 引用,那么你就可以使用 UUID 来确定源资产。在此基础上,您可以查看源控制中该源资产的历史记录,以了解可能发生了哪些变更,以及这些变更的作者是谁。您可以在本地回滚文件,看看丢失的产品资产是否会再次出现。
如果您认为问题出在生成器本身,而不是内容问题,那么您可以尝试 调试资产生成器来调查产品子 ID 是如何生成的,以及子 ID 的变化来自何处。
如果生成器是 O3DE 生成器,而不是您的团队创建的生成器,您可以 在此 创建一个票单来查看此问题。
在不更改版本的情况下更改生成器中的逻辑
情况
工程师更改了资产创建器的逻辑,但没有更改创建器的指纹或版本。
常见问题
使用此构建器处理的源资产不会自动根据最新更改重新处理。
如果资产因构建器更改而无法处理,进行更改的工程师可能不会注意到,直到构建器更改被推送给团队其他成员,导致其他人被失败的资产干扰。
如果其他内容或逻辑在处理资产时需要更改,其他团队成员在使用旧版生成器输出的产品资产和其他更新逻辑时可能会遇到问题。
立即解决方案
更改生成器的 AssetBuilderSDK::AssetBuilderDesc
中报告的生成器版本号。这样做并重建资产处理器后,所有使用该生成器的资产都将被重新处理。
长期解决方案
一种能发现问题的配置是
- 迭代任务 - 代码重建后处理资产。
- 清理任务 - 代码构建后清理并处理所有资产。
- 在这些任务的构建和运行之间比较每个产品资产的哈希值。如果任何资产在两个背靠背的清理任务中出现差异,但在迭代任务中没有处理,这通常意味着资产生成器被修改,但没有更改其版本。
调试
调试这个问题的重点通常是首先发现问题。一旦发现问题,确定哪个构建程序需要更改版本并进行更改通常是小事一桩。
如果一些团队成员遇到了内容问题,但并非团队中的每个人都遇到了问题,但该内容最近没有更改,这通常就是原因所在。检查最近是否在源控制中修改了该内容的生成器,如果是,检查版本是否已更改。如果没有,那么很可能是生成器更改而版本号没有更改导致的问题。
通过资产处理器用户界面,您可以右键单击资产选项卡中的源资产,并重新运行该资产上的所有作业。如果这样做会导致 “产品资产 ”发生变化,这很可能意味着在未更新版本的情况下更改了构建程序。如果要来回调试,建议先备份旧的产品资产,然后再重新处理源资产。
资产生成器中的逻辑在构建资产之间持续存在
###情况
在某些情况下,由于信息在资产处理过程中持续存在,您可能会根据源资产的处理顺序从作业中获得不同的产品资产输出。这通常是由于处理此内容的资产生成器中的错误造成的。
资产处理器根据配置设置启动一个或多个资产生成器可执行程序,并使用这些程序处理资产,将作业发送到这些资产生成器可执行程序,与各个资产生成器一起运行。资产生成器可执行文件中没有完全关闭和清除所有资产生成器的系统,因此资产生成器有可能在处理单个资产生成器可执行文件作业的多个会话中持续存在信息。
效果
资产生成器可执行文件中的陈旧数据或逻辑可能导致资产处理错误。
原因
导致此问题的原因是在处理过程中的一个步骤中缓存了信息,以便在以后的步骤中更容易访问。
示例
本例介绍了遇到此问题的一种情况:
- 场景生成器可将 FBX 文件等场景文件处理为产品资产集合。
- 每个场景文件都有一个包含附加处理规则的场景清单。
- 在场景清单中,可以标记一个 Python 脚本文件,以便在场景处理过程中运行。
- 初始启动时,每个 Asset Builder 可执行文件中的场景生成器启动时没有设置 Python 脚本。
- 当遇到一个场景文件,其中有一个要运行的 Python 脚本的场景清单时,场景生成器会存储这个 Python 脚本,以便以后使用。
- 场景生成器无意中以跨任务持久化的方式存储了这些数据。
- 在本例中,FBX 文件
NoPython.fbx
的Scene Manifest中没有设置要运行的 Python 脚本,但 FBX 文件WithPython.fbx
的 “场景任务说明 ”中确实设置了要运行的 Python 脚本。 - 如果两个作业最终都在同一个 Asset Builder 可执行文件上运行,那么如果场景生成器在该 Asset Builder 上先于
NoPython.fbx
处理了WithPython.fbx
,要运行的 Python 脚本就会以在NoPython.fbx
上运行的方式被持久化。 - 最终的结果是,在与
WithPython.fbx
相同的 Asset Builder 可执行文件上,如果在WithPython.fbx
之后运行NoPython.fbx
会产生不同的输出: 在WithPython.fbx
之前运行,在不同的 Asset Builder 可执行文件上运行。
解决方案
解决这个问题的主要办法是更新生成器,使其不在不同作业中持续缓存信息。
自动测试有助于防止出现这种情况。您可以查看涵盖上述示例案例的测试 此处 。该测试注释了设置方式和原因。
调试
如前所述,这个问题很难识别,因为它需要非常特殊的设置。这个问题是通过对 O3DE Jenkins 服务器上自动资产处理作业的间歇性问题进行逆向分析发现的。
如果您的团队中出现某些人遇到的资产处理结果与其他团队成员不同的情况,并且您已经排除了 无版本更改的构建程序更改 作为问题来源的可能性,那么请记住这一点。检查显示问题的资产的资产处理日志,检查出现问题时的资产处理顺序与未出现问题时的资产处理顺序。特别是查找在同一资产生成器可执行文件上运行的其他作业,在该可执行文件上使用相同的资产生成器。
Asset Processor 的命令行和图形界面都支持一个有助于调查的命令行标志。标志--sortJobsByDBSourceName
将稳定作业的运行顺序。在调试时使用该标志,可以通过重命名资产来控制作业的运行顺序,从而测试不同的作业处理顺序。资产处理器还允许通过命令行控制 regset 值,使用--regset
标志和要设置的设置。具体来说,将 regset 值/Amazon/AssetProcessor/Settings/Jobs/maxJobs
设置为 1
将限制资产处理器只能启动单个资产生成器可执行文件。请注意,如果您有许多资产要处理,这会导致资产处理时间过长,因此建议您在使用更多最大作业的上一次资产处理器运行中处理完所有作业后再设置此值。使用一个最大作业运行资产处理器后,所有资产都将在同一生成器上的会话中处理,让您可以按照自己选择的顺序具体处理资产。
将 Visual Studio 附加到运行中的资产创建器还有助于调试。按照 这些说明 将使用单个生成器运行资产处理器,这样您就可以在 Visual Studio 连接到资产生成器可执行文件的情况下按顺序处理多个资产。此时,您可以尝试使用 “资产 ”选项卡的右键菜单手动重新处理资产,并跟踪同一资产生成器可执行文件上的同一资产生成器的多个作业中持续存在哪些数据。
修复警告、错误和故障
情况
资产处理完毕后,如果作业已完成,可能仍有一些警告或错误需要处理。在其他情况下,任务可能无法完成,反而会失败。
您可以在资产处理器中查看有关资产任务状态的信息 此处。
效果
资产任务中的警告或错误是资产创建器作者通知内容作者的一种方式,即他们在处理您的资产时遇到了问题,可能没有生成内容作者预期的产品资产。
失败是资产创建器作者通知内容作者的一种方式,即他们在处理您的资产时遇到了问题,可能没有生成内容作者预期的产品资产。
生成器作者可根据具体情况决定什么是警告、错误或失败。 此处提供了指导,并建议了可遵循的模式。
示例 - 警告
> The name of the node 'Material.003' was invalid or conflicting and was updated to 'Material_003'.
当 FBX 文件包含名称中含有非法字符“. ”的素材时,会出现此警告。这是一个警告,因为系统能够安全地将该字符替换为另一个合法字符。无需采取任何措施,但如果内容创建者希望清除此警告,他们可以重新命名 FBX 文件中的素材。在本例中,如果您决定重新命名素材以清除警告,请注意不要导致 产品资产的子 ID发生变化,从而引发其他问题。
示例 - 错误
> Element with class ID '{4C19E257-F929-524E-80E3-C910C5F3E2D9}' is not registered with the serializer!
当 prefab 文件引用的类已不再在序列化器中注册时,会出现此错误。这是一个错误,因为该 prefab 的行为方式不再与编写时相同,不再有与该序列化信息相匹配的 C++ 类。这是一个错误而不是警告,因为缺少的信息可能会产生副作用,影响该 prefab 的功能。该Prefab在某种程度上仍可被处理,因此它是一个错误而不是失败。在这种情况下,通常希望有一个损坏的产品资产,而不是没有产品资产,因为它提供了更多的调试和纠正选项。
示例 - 失败
> Failed to import Asset Importer Scene. Error returned: FBX-Parser unexpected end of file
出现故障的原因是处理的文件是带有 FBX 扩展名的空白文件。场景生成器没有任何信息可用于创建产品资产,因此它失败了,什么也没有输出。
解决方案
大多数 “警告”、“错误 ”和 “失败 ”消息都包含足够的信息,可帮助指导解决问题的步骤。如果这些信息还不够,下一步就是查看该作业的其他日志信息,看看它们是否包含相关信息。
通常,要清除这些问题,需要更改源资产。您正在调查的特定资产的资产处理日志可能包含更多详细信息,可以帮助您通过更改源资产来解决问题。
在某些情况下,更改资产生成器以更正确地处理这些数据可能更有意义。如果你是内容创建者,但你看不到解决该问题的途径,请与工程团队的人员讨论,看看是否可以更新 “资产生成器”,以便更好地处理源资产。
调试
调试资产作业警告、错误和失败的第一步是资产处理器用户界面的 作业选项卡或资产处理器批处理的日志输出。处理作业时的日志一般会提供指导,说明为什么会出现这种情况,在很多情况下还包括纠正问题的步骤。
下一个调试选项是查看特定生成器的文档,这可能会为创建可干净处理的资产提供指导。例如,如果您遇到 FBX 文件的问题,不知道该采取什么步骤, 3D 场景格式支持文档可能会提供一些信息来帮助解决问题。
另一种方法是检查生成器本身的源代码,尤其是生成这些信息的位置。逐步了解生成器在处理数据时出现问题的原因,看看是否有办法更改源资产以清除问题,或者是否有办法更改生成器本身以更好地处理源资产。
为了帮助解决这个问题, 更直接地调试资产生成器能会有所帮助。
缓慢的资产处理时间
资产处理时间过长会影响团队快速迭代项目的能力。
常见原因
- 源资产数量多 - 一个项目的内容多,处理时间就长。
- 大型或难以处理的源资产 - 在某些情况下,单个源资产可能是一个异常值,其处理时间比大多数其他内容要长得多。
- 深层作业依赖网 - 一个大型作业依赖网可能会导致一个文件的更改导致许多其他文件需要重新处理。请阅读 资产依赖性和标识符 主题了解更多信息。
解决方案
- 从项目中删除未使用的内容可节省整体资产处理时间。
- 有针对性地改进资产生成器的性能,可帮助节省资产处理的总体时间。
调试场景管道
场景管道将源场景资产导入包含网格和材质等场景节点的场景图中。场景清单中添加了处理规则,场景构建者可利用这些规则输出模型、碰撞网格和动画等场景产品资产。场景流程是一个复杂的框架,它将源资产场景文件导入场景图,更新清单,根据清单中的场景规则构建产品,并根据这些规则生成产品资产。这种挫败感可能会导致场景作者调整原始源场景(即 Blender 文件)中的次要数据,并重新导出以尝试解决来自 O3DE 场景管道的奇怪错误。场景流水线有许多处理步骤,因此在确定哪些场景节点数据(如变换数据、网格数据)被发现以及导入场景节点所使用的规则时可能会比较混乱。场景管道事件可以通过 Python 脚本或 C++ 代码修改场景清单规则来覆盖。这可能会导致混淆生成产品资产所使用的规则。
随着源场景资产变得越来越复杂,开发人员最终需要调试场景流水线的输出来排除故障。
团队可能会遇到:
- 渲染模型无法与碰撞网格对齐
- 材质最终出现意外设置或纹理
- 在场景中找到额外的模型
- 用户定义的属性没有显示正确的值
- 渲染模型中存储的网格节点出现意外分组
常见原因
AssImp 问题
场景管道使用 AssImp 库将源代码场景文件导入场景图。场景图是源场景文件在管道中的内存表示。由于 AssImp 库导入文件的方式不同,源场景文件在场景图中可能看起来不一样。
缺少用户定义的属性
源场景文件中的用户自定义属性在导入时可能会出现意外结果,例如键丢失或值发生变化。AssImp 库将导入的内容可能不匹配,导出自定义属性的选项可能被遗漏,或者场景流水线可能期望从源场景文件中获得精确的值类型。
有关更多信息,请参阅 场景 API:用户定义的属性。
使用了错误的场景清单规则
正在编写或调试脚本的技术内容创建者(如技术美术师)可能会发现某些源场景资产出现了一些意想不到的结果。Python 脚本可以使用 print()
在资产的日志文件中添加输出命令,但这可能不足以确定脚本正在影响什么。调试输出标记是确定受影响的脚本管道中发生了什么的另一个好方法。
解决方案
启用调试输出功能
调试输出 “标志是一个功能标志,可用于查看场景管道生成的场景图和场景清单。从 AssImp 库导入源场景后,场景图被认为是不可变的。场景清单可在场景管道事件中更新。
注意:启用后,支持调试输出的 AssetBuilder 将以产品资产的形式提供调试信息。这主要用于场景文件。
该标志可在命令行或资产处理器图形用户界面应用程序中设置。要使用命令行选项:
<path to asset processor>/AssetProcessor.exe --debugOutput
命令行标志也可应用于批处理版本的资产处理器。
<path to asset processor>/AssetProcessorBatch.exe --debugOutput
For example:
D:\o3de\build\bin\profile\AssetProcessor.exe --debugOutput
调试输出标志可在 Asset Processor GUI 中使用 Tools | Debug Output 复选框进行设置。激活该复选框后,调试输出文件将出现在场景文件的缓存文件夹中。
注意:打开调试输出标记后,需要重新处理资产以输出调试文件。
Debug output: scene graph
场景图调试输出文件存储在默认的 .azmodel
文件旁边。例如,对于 PC 平台的源文件D:\o3de\my_project\assets\test.fbx
,缓存文件夹中应(至少)有这些文件:
D:\o3de\my_project\Cache\pc\assets\test.azmodel
D:\o3de\my_project\Cache\pc\assets\test.dbgsg
D:\o3de\my_project\Cache\pc\assets\test.dbgsg.xml
.dbgsg
和 .dbgsg.xml
f文件是调试场景图文件,前者是每个节点调试信息的平面列表,后者是文件中节点调试信息的 XML 表示。
调试输出会列出节点名称、节点路径和节点类型。名称是作者为节点指定的文本标签。节点路径是从根节点指向该节点的点号。节点类型存储该节点的特定数据,如网格数据、变换数据或自定义属性数据。
网格数据存储网格的相关信息,如位置数、法线、面列表和面材质 ID。变换数据(Transform Data)存储有关矩阵平移、缩放和旋转的信息。材质数据存储了材质名称和物理基础渲染属性等信息。自定义属性数据以键值对的形式存储用户定义的属性。
调试输出:场景清单
可以使用 Python 脚本或 C++ 代码更改场景管道逻辑,以更新场景清单。要确定逻辑如何影响场景清单规则,团队可以打开调试输出标志,并在缓存文件夹中找到.assetinfo.dbg
文件。
For example:
D:\o3de\my_project\Cache\pc\assets\test.azmodel
D:\o3de\my_project\Cache\pc\assets\test.assetinfo.dbg
.assetinfo.dbg
文件是场景生成器处理场景图时内存中场景清单的文件表示。每个规则都以 “$type”
键开头,并按 GUID 和名称列出规则,如 “{07B356B7-3635-40B5-878A-FAC4EFD5AD86}”。MeshGroup"
。
MeshGroup 是规则的一个示例,它会创建一个 .azmodel
产品文件,该文件使用 “name”
字段命名,在 “selectedNodes”
数组中包含网格节点路径,并在 “unselectedNodes”
数组中排除节点路径。
查看资产处理器日志
如果资产处理器未按预期运行,可使用 Logs 标签中的信息来调试问题。Logs选项卡包含资产处理器的日志信息,而不是单个流程作业的日志信息。要查看单个流程作业的日志,请参阅资产处理器Jobs选项卡中的Event Log Details窗格。
在Asset Processor中,选择Logs。
在Logs部分中,你可以看到以下内容:
- Status - 日志的日期和时间戳。
- Source - 生成日志的内容(例如,资产处理器)。
- Message - 日志描述。
要创建另一个日志报告,点击Add。
在Create New Logging Tab中,你可以指定以下设置:
- Filter name - 筛选器的名称 (例如,
All logs
). - Text filter (optional) - 用于过滤日志结果的文本。
- Show messages - 显示每个日志的相关信息。
- Show warnings - 显示有警告的日志。
- Show errors - 显示有错误的日志。
- Show debug - 显示有调试问题的日志。
- Filter name - 筛选器的名称 (例如,
选择 OK。日志报告将作为另一个选项卡出现在资产处理器中。
您可以选择Copy all,将原始日志粘贴到文本文件中。您还可以选择Open log files,打开操作系统中包含日志文件的目录。
重启资产处理器
您可以重新启动 Open 3D Engine (O3DE) Editor 和 Asset Processor。确认同一时间只有一个 Asset Processor 实例在运行。
关闭O3DE编辑器。
在Windows任务栏,右击 Asset Processor,选择Quit 或按下 Ctrl+Q。
重新启动 O3DE 编辑器。资产处理器自动启动。
使用资产生成器调试
您可以使用 AssetBuilder 调试资产处理器。这是一个独立的 AzToolsFramework
应用程序,可让你单独运行 BuilderSDK 模块。你可以在调试模式下运行 AssetBuilder,为资产生成器开发新功能。在调试模式下,AssetBuilder 会创建测试作业或处理指定文件的作业。
注意:必须先启动资产处理器,然后才能输入-debug
命令。
在终端中,导航到
<build>/bin/<config>/
。输入以下命令可获得可能的选项列表。更多信息请参阅 资产生成器设置。
AssetBuilder.exe -help
您可以使用以下调试选项:
要调试指定文件,请运行以下命令。
```cmd AssetBuilder.exe -debug <path_to_scan_directory>\<source_asset.ext> ```
要创建不处理指定文件的作业,请运行以下命令。
AssetBuilder.exe -debug_create "<path_to_scan_directory>\<source_asset.ext>" -module "<path_to_debug_build_directory>\Builders\ExampleBuilder.dll" -output "<path_to_log_directory>"
要在不为指定文件创建任务的情况下进行处理,请运行以下命令。
AssetBuilder.exe -debug_process "<path_to_scan_directory>\<source_asset.ext>"
使用 Microsoft 子进程调试强大工具
使用该工具可将调试器自动附加到生成的子进程上。
进入 下载 页面,选择 Download。
为 Visual Studio 安装工具。
在 Visual Studio 中,启动
AssetProcessor.exe
。Asset Builders 中的断点工作正常。
从资产处理器调试资产构建器
使用以下步骤调试以下任一情况:
- 使用
debug
选项在 Asset Builder 的单次运行中难以重现的间歇性故障。 - 仅在多个进程任务请求中出现的故障。
在文本编辑器中打开
Registry/AssetProcessorPlatformConfig.setreg
文件,设置maxjobs=1
。这将限制 Asset Processor 一次只能运行一个作业。运行 Asset Processor,使其生成 Asset Builder 进程。
要调试,请在 Visual Studio 中附加
AssetBuilder.exe
。资产生成器只有一个。
下一次修改源文件时,AssetBuilder.exe
将生成该资产。
提示:您可以生成多个AssetBuilder.exe
实例,并将它们附加到 Visual Studio。
清除缓存
如果你是一名游戏美术师,在运行 Asset Processor 时遇到问题,可能是因为缓存损坏。你可以通过删除项目的Cache
目录来解决问题。重新启动 Asset Processor,重新处理源资产并重建资产缓存。
注意:如果你是一名工程师,正在制作基于 BuilderSDK 的新构建器,我们建议你不要删除缓存。