Toolkit 的新默认配置概述

简介

Toolkit 的旧配置已更新,并以 tk-config-default2 发布。此配置现在是在 Shotgun Desktop 中执行高级项目设置时的默认配置。本文的目的是概述新配置结构,并帮助回答熟悉旧 Toolkit 配置的用户提出的常见问题。其中概述了如何将现有配置更新到新结构,以及如何从旧版发布应用迁移到新的 Toolkit 发布器,从而使用新软件实体,并支持用于在 Shotgun Web 中填充菜单的新设置。

默认配置是什么?

在 Shotgun Desktop 中对项目运行高级项目设置时,将为项目安装默认配置。


在高级项目设置期间选择默认配置

它提供用于自定义和管理工作室特定工作流的模板。默认配置附带一个默认文件系统数据结构和多个用于确定存放项目文件的磁盘位置的模板。默认配置还附带所有支持的集成,包括 3ds Max、Houdini、Mari、Maya、Motionbuilder、Nuke 和 Photoshop。这些集成配置为允许对其中每个 DCC 执行文件管理、发布和加载工作流。默认配置为 Toolkit 管理员提供了参考,可以基于它构建完整的工作室工作流。

我为什么要使用默认配置结构?

我们根据客户反馈和观察结果重新组织了新默认配置,以帮助在需要手动管理制作环境时最大限度地提高效率。移除了旧配置的大量冗余内容,以支持基于包含的结构,从而允许通用插件和应用设置更改隔离到单个文件中。 

了解更改内容

有关新环境文件的结构的概述,请参见此处

新配置的几个结构化组成部分应该可以帮助管理员了解更改内容:

  • 应用、插件和框架的位置描述符现在都位于配置中的一处。在旧配置中,更新应用或插件的版本需要在每个顶层环境文件中进行更改。所有应用和插件定义现在均包含来自某一处的位置描述符。这些捆绑包描述符文件位于 env/includes



    • app_locations.yml      # 此处定义了所有应用位置描述符
    • engine_locations.yml   # 此处定义了所有插件位置描述符
    • frameworks.yml         # 此处定义了所有框架
  • 所有插件特定和应用特定的设置均在相应应用或插件的专用文件中定义。在旧配置中,每个顶层环境文件定义所有插件和应用的设置。采用了新结构后,环境文件包含插件特定的设置文件中的插件配置。插件设置文件则包含应用特定的设置。这就隔离了各种插件和应用设置,因此确定在何处更新插件或应用变得非常简单(即,转到插件或应用设置文件!)。例如,要更改 Maya 在所有环境中的配置方式,则编辑 env/includes/settings/tk-maya.yml。要更改发布器在所有制作环境中的配置方式,则修改 env/includes/settings/tk-multi-publish2.yml。 

  • 在这些应用/插件设置文件中,相应应用/插件存在多个配置。这些设置的每个版本对应于一个不同的环境,所采用的命名方式有助于了解哪些设置集合对应于哪个环境。例如,settings.tk-maya.asset_step 设置(在 tk-maya.yml 中)定义 asset_step 环境的 Maya 插件设置。 



    同样,settings.tk-multi-publish2.nuke.shot_step 设置(在 tk-multi-publish2.yml 中)定义 shot_step 环境中 Nuke 的发布器设置

  • 除了环境重构,配置的另一个主要更改是从旧版 tk-multi-publish 应用升级到新版 tk-multi-publish2 应用。新发布器支持独立发布工作流,已与新配置一起更新以支持基于模板的经典工作流。有关新发布器的详细信息,请参见集成用户手册集成开发人员手册


    Shotgun 发布器

需要注意的是,在此新配置中,对于大多数部分,核心数据结构和模板基本保持不变。所做的多数更改涉及环境文件的结构和组织及其包含的设置。

插件设置

插件设置现在隔离在一个设置文件中,该文件定义相应插件在所有环境中的配置。例如,文件 env/includes/settings/tk-maya.yml 定义所有环境使用的所有 Maya 配置。下图显示了项目环境的 Maya 设置:

在此处您可以看到在哪里更改插件级别设置,例如 menu_favourites。您还可以在此处添加应用引用。默认情况下,所有应用都是从应用特定的文件中包含进来的。此结构让管理员可以查看如何在一个文件中为所有环境配置某个插件。

应用设置

与插件设置一样,应用设置现在隔离在一个设置文件中,该文件定义相应应用在所有环境中的配置。例如,文件 env/includes/settings/tk-multi-publish2.yml 定义所有环境使用的所有 Publish2 配置。下面的代码片段显示了 shot_step 环境中 Maya 的 Publish2 设置:

在此处您可以看到如何针对目标环境修改应用特定的设置(与插件设置文件中所包含的内容一样)。此结构让管理员可以查看如何在一个文件中为所有环境配置某个应用。

软件路径

env/includes/paths.yml 文件(位于旧配置中)已重命名为 env/includes/software_paths.yml。这些文件的结构相同,但新配置定义的软件路径少很多。这是因为使用 Toolkit 时解析软件路径的首选方法是使用 Shotgun 中的软件实体。 


在 Shotgun 中看到的软件实体条目

有关软件实体以及如何根据工作室需要自定义软件实体的详细信息,请参见此处的文档。

移除 shotgun_*.yml 环境文件

shotgun_*.yml 环境文件以前用于配置 Shotgun Web 应用的 Toolkit 动作菜单中可用的 Toolkit 动作。我们现在弃用了这些额外的环境文件,改为采用与配置所有其他插件相同的方式配置 tk-shotgun 插件。现在,不是我们希望对其执行 Toolkit 动作的每种类型的实体都有一个 shotgun_xxx.yml 文件,而是在更多典型环境中提供 Shotgun 插件的配置,例如 project.yml、shot_step.yml 等;以及手动控制向核心 pick_environment 挂钩选取环境。目标是移除与 Toolkit 浏览器集成有关的特殊行为,以支持更加标准化的配置。对浏览器集成配置的这些更改是向后兼容的,因此现有配置像以前一样继续有效。

移除 app_launchers.yml

应用启动器定义已移到 env/includes/settings/tk-multi-launchapp.yml 文件。这使得各种环境中的应用启动设置与配置的新结构一致(每个应用/插件都有自己的设置文件)。另外还需要注意的是,许多应用启动配置已移除,改用可通过软件实体自动发现的应用启动。有关此方面的详细信息,请参见软件实体文档

使用旧默认配置

仍可通过 Shotgun Desktop 中的高级项目设置使用旧默认配置。Github 库也将保持可见且可供下载。此外,还通过最新应用、插件和框架对旧默认配置进行了更新,使其与新默认配置一致且可区分版本。

迁移现有配置

提供了最新版本的 tk-config-default2 后,好几个客户表示有意将其现有配置转换为新的组织结构。以下各节旨在提供用于实现此过渡的方法。

需要注意的是,此过程完全是可选的。现有的可运行配置应该可以继续使用,而无需任何更改。 

另外还需要注意的是,将现有配置迁移到新结构是一个高级手动过程,需要全面了解旧 Toolkit 配置结构、Git 和 tank Shell 命令。请小心操作。我们此时不提供任何保证。

开始使用 tk-config-default2

建议在迁移现有配置时,先在 Shotgun 中创建一个新的测试项目,在 Desktop 中使用高级项目设置,然后在系统提示时选择新默认配置。这将为您提供一个干净且有效的配置,我们可以开始修改。

接下来,请务必熟悉新配置结构,尤其是环境文件。有关新结构的详细信息,请参见此自述文件以及上面各部分。

清理未使用的应用和插件

全面了解新结构后,应该移除您的工作室不使用的任何插件和应用。为此,您需要从 env/includes/settings 文件夹中移除您不需要的任何应用和插件设置文件。此外,您还需要从其余插件设置文件中移除对未使用的应用的任何引用,以及从顶层环境文件中移除对未使用的插件的任何引用。

例如,如果您的工作室不使用 tk-nuke-quickdailies 应用,则从 Nuke 插件设置文件中移除上面高亮显示的行。

同样,如果您的工作室不使用 Motionbuilder,则移除上面高亮显示的行并不再包含 tk-motionbuilder.yml。上图显示了 project.yml 文件的一部分。您可能需要从多个顶层环境文件中移除未使用的插件。

您还应该从 env/includes/*_locations.yml 文件中的位置文件中移除未使用的插件和应用描述符。

要移除 Motionbuilder 插件,您需要移除 engine_locations.yml 文件中定义的位置描述符。未使用的应用位置描述符需要从 app_locations.yml 中移除。

更新随附集成的设置

这将使配置处于仅有您工作室使用的随附集成的状态。您将需要更新其余的应用和插件设置以匹配现有配置。

上图显示了资产上下文的 tk-nuke-writenode 设置。您的现有配置可能使用了不同的/自定义模板,或添加了其他 write_nodes。您将需要检查您的所有现有应用配置以确定哪些设置不同或缺少哪些设置,并相应地对其进行更新。您可能会发现还需要更精细的配置,因此您可能需要添加要由插件设置文件包含的其他设置块。

注意:新默认配置结构是使用稀疏设置构建而成的,因此,新结构中并不包含所有设置。您可以根据需要添加您的配置中使用的设置。

更新为使用软件实体

采用新配置后,在 Shotgun 中几乎所有软件都通过软件实体启动。更新随附集成后,您可能看到 env/includes/settings/tk-multi-launchapp.yml 文件。

此文件用于定义配置中的所有软件启动器:

Screen_Shot_2017-12-04_at_2.49.50_PM.png

上图的顶部区域内容是使用启动应用的软件实体配置的设置。底部区域包含其余的手动软件启动器配置。我们建议尽可能使用软件实体设置。您需要将现有配置中的任何自定义软件启动迁移到此文件,并在相应的插件设置文件中引用它。 

使用软件实体启动器时引入的一个更改是需要 tk-multi-launchapp 来访问关联的插件。在本地计算机上扫描软件安装的逻辑位于各种插件中(例如,tk-maya 知道如何查找 Maya 安装)。因此,当 tk-desktop 和/或 tk-shotgun 配置为使用软件实体启动器时,需要在同一环境中提供所有必要的插件实例。

上图显示了为项目环境配置的插件。高亮显示的行中包含的是 Shotgun Desktop。应通过软件实体启动器从 Desktop 启动的任何软件也应在此处配置关联的插件。此处配置了支持基于软件实体的启动的其他 DCC 插件,例如 Maya、Nuke 和 Photoshop。在旧默认配置的旧 shotgun_xxx.yml 文件中,只需要配置 tk-shotgun 插件。

验证配置

您可以随时在 Shell 中运行验证命令来测试配置,以确保环境文件有效。

./tank validate

./tank validate asset_step

添加自定义应用和插件

接下来,您想要向环境文件中添加您的工作室使用但不属于随附的默认配置的任何插件或应用。首先,在 app_locations.ymlengine_locations.yml 文件中添加位置描述符。然后,将现有应用和插件设置文件作为引用,为新应用和插件插入您的配置。请务必在顶层环境文件中引用添加的任何插件。

复制模板和数据结构

您将需要复制您的现有配置的 templates.ymlschema 文件夹,然后在新配置中替换相应项。


配置中的 schema 文件夹和 templates.yml 文件

您可能希望保留新配置中的默认 templates.yml 的副本,以防您需要更新您工作室的 template.yml。这样,您可以检索并评估由您从随附配置中保留的应用/插件指定的任何新模板,以了解是应使用它们还是对其进行修改以适用于您的工作室。

更新顶层环境

如果您的工作室使用自定义环境(例如“剧集”或“播放列表”),请务必还要在环境文件夹中创建相应的环境文件。

上图显示了顶层环境文件。该 publishedfile_version.yml 是 default2 配置的新文件示例。它有双重作用:在 Shotgun 中提供已发布的文件和版本实体菜单的菜单项。您可以在过渡您的自定义环境时将此文件和其他顶层环境作为引用。

您还需要修改 pick_environment 挂钩,以考虑您的自定义环境。如果您有自定义 pick_environment 挂钩,您或许可以从现有配置中复制它,但您应将其与新默认配置附带的挂钩进行比较,以确保您考虑到定义的所有环境。

上图显示了 default2 挂钩中的一个子句,它考虑了使用前一个图中所示的 publishedfile_version.yml 文件。

更新框架

接下来,更新 frameworks.yml 文件以包含您的工作室所需的任何自定义框架。


  frameworks.yml 文件(位于 env/includes 文件夹)。

此文件始终包含在顶层环境文件中,因此添加适当的描述符应该就可以了。

上图显示了包含在顶层 shot.yml 文件中的框架。包含的任何框架都将可用于相应环境中的所有插件/应用。 

这是再次运行验证的好时机,以确保没有任何拼写错误,也没有遗漏某个设置。

更新挂钩

最后,您需要复制旧配置中定义的任何自定义挂钩。这包括核心挂钩以及应用和插件的挂钩。这些挂钩应该可以继续使用,但会有一些例外。


将现有挂钩复制新配置中的 hooks 文件夹中

如果您是首次使用软件实体,且定义了现有 tk-multi-launchapp 挂钩,您将需要仔细检查您的自定义项是否按预期工作。主要区别在于,旧挂钩需要检查启动应用的设置,以确定将要启动的软件的插件名称。采用基于软件实体的新启动后,不再配置此值。依赖该功能的任何挂钩都需要更新。启动应用挂钩现在以一个额外的参数形式向挂钩提供插件名称(这样,更新就不是很重要了)。

同样,tk-multi-launchapp 的 defer_keyword 设置不用于软件实体配置。如果您依赖此设置来创建自定义的延迟文件夹,则可能需要继续使用手动启动方法。

任何自定义 tk-multi-publish (publish1) 挂钩都不适用于 tk-multi-publish2 (publish2)。如果您在上述步骤中手动将旧版发布器包含到新配置中,则您的挂钩应该可以正常工作。但是,如果您计划升级到 publish2,则需要完成额外的工作以迁移到新 publish2 插件系统。我们建议您将该迁移作为单独的任务处理(迁移配置是一个相当大的任务)。当您准备好继续执行后续操作时,请参见下一节了解一些提示。

此时,您即将完成一个使用新结构的有效配置。建议运行验证并进行调整,直到不再出现任何错误。然后,您可以使用新项目来测试配置,并确保一切符合您的需要。 

从 publish1 迁移到 publish2

显然,将代码和配置迁移到新范例是一个手动过程,而且对每个工作室来说都是不同的。下文的目标是针对预期事项以及如何从 publish1 概念转换到 publish2 概念提供一些提示。

注意:从 publish1 迁移到 publish2 不需要使用新配置结构。您可以结合使用任一发布器与任何有效的 Toolkit 配置。

熟悉 publish2 概念

假定您熟悉 publish1 定义的概念,当您准备好迁移现有 publish1 挂钩以使用 publish2 时,您需要熟悉新发布器及其 API 的概念。有关完整信息,请参见集成开发人员手册。具体来说,务必要了解 publish2 阶段(尤其是接受阶段)、收集器挂钩和发布插件。假定您了解 publish1 挂钩结构,阅读完该手册后,转换过程就明朗了。

publish1 和 publish2 之间的主要差异如下图所示。

publish1.png
publish1 挂钩和内容项关系图表


publish2.png

publish2 插件和内容项关系图表

下面列出的一些高级要点可以帮助说明这些差异。在迁移自定义挂钩之前,请考虑这些要点:

  • 要在 publish2 中发布的内容项由 collector 挂钩创建。这对应于 publish1 中的 scan_scene 挂钩。请参见上图中的绿色框。
  • publish2 中没有主要发布与次要发布的概念。只有要发布的内容项。请参见上图中的蓝色框。
  • 在 publish1 中,pre_publishpublishsecondary_publish 挂钩操作都是静态的、预定义的。在 publish2 中,可以对内容项操作任意数量的发布插件,发布的各个阶段由插件中的方法定义(validatepublishfinalize)。请参见上面的棕黄色框。
  • Publish2 使用新式挂钩,这意味着挂钩可以使用继承性。当您查看随附的 publish2 挂钩时,您可以看到应用中定义的单个基类插件中存在多少核心发布逻辑。

其他注意事项:

  • 一个或多个发布插件可以接受收集的内容项对其执行操作
  • publish2 中的收集器挂钩和发布插件都具有设置的概念,这些设置可以用于定义驱动其行为的每个挂钩值。例如,定义插件的发布模板,以便在发布时知道在何处复制文件。
  • 插件自身附带插件特定的 publish2 收集器和插件。这可以通过在 tk-multi-publish2.yml 设置文件中搜索 {engine} 令牌看到。
  • tk-multi-publish2 应用附带可重用的基础收集器/发布插件。
  • 基础文件发布器旨在处理用于在磁盘上发布文件的所有常见逻辑。它可以处理原位发布或基于模板的发布。 
  • 随附集成继承自基础收集器和文件发布插件,以避免重复使用常用的发布逻辑。

将设置从 publish1 转换到 publish2

下面列出了 publish1 的设置,并提供了有关如何将它们转换到 publish2 的一些说明:

  • display_name:当前未在 publish2 中提供(尽管我们正在着手进行此事)
  • hook_thumbnail:DCC 特定的缩略图生成可以由某个会话收集器插件定义,但在 publish2 中没有相应的挂钩
  • hook_copy_file:默认情况下,文件复制是由基础发布文件插件处理。可以编写任何自定义发布插件以执行文件复制,但在 publish2 中没有相应的挂钩。
  • primary/secondary 挂钩:如前所述,在 publish2 中主要发布与次要发布之间存在差异。您需要将任何自定义扫描场景逻辑迁移到收集器挂钩中。任何自定义发布前/发布/发布后逻辑都需要在发布插件中执行。
  • primary_*:主要的 scene_item_typedisplay_namedescriptionicon 设置都是由 publish2 中的内容项概念定义。收集器创建内容项时会提供值,并且这些值将显示在 UI 中。
  • secondary_outputs:次要输出只是在 publish2 中收集阶段创建的其他内容项。可以将它们作为传统“主”内容项的同级项列出(例如当前 Maya 会话),也可以将它们设为层次结构中传统“主”内容项的父项以推断您需要的关系类型。
  • expand_single_items:收集器挂钩可以定义内容项在 UI 中的定义方式。
  • allow_taskless_publishes:内容项可以具有在发布时关联的定义上下文。可以在收集时确定上下文,也可以由用户手动定义上下文。发布插件可以确定是否允许没有任务的内容项在验证方法中发布。
  • templates:可以在收集器或插件设置中定义模板。由收集器和插件定义模板的使用方式。

publish2 插件的其他参考

下面提供了一些其他资源,可帮助您完成从 publish1 挂钩到 publish2 插件的过渡:

  • 可以从 tk-config-default2 publish2 设置文件清楚了解新发布器的配置方法。您可以了解如何为独立发布器配置基础收集器和文件发布插件,以及 DCC 特定的配置如何继承和使用相同的挂钩。
  • 基础收集器定义如何将拖/放的文件转换为内容项以进行发布,以及从文件扩展到内容项类型的转换逻辑。
  • 基础文件发布插件定义用于在磁盘上发布文件的大部分逻辑,包括如何处理模板、如何向 Shotgun 注册发布以及如何定义发布类型。
  • Maya 特定的 publish2 挂钩也是用于了解如何处理 DCC 特定的集合和发布的很好资源。这些挂钩位于 Maya 插件库中,具有用于收集和发布以下内容的逻辑:当前会话、以前导出的播放预览和 Alembic 缓存以及所有会话几何体。

总结

希望上述步骤能够帮助您了解新配置结构以及如何从您的现有配置过渡到新配置。如果您对新配置有任何疑问,或如果您要完成迁移过程并需要其他说明,请联系我们:support@shotgunsoftware.com

关注

0 评论

登录写评论。