툴킷의 새 기본 구성 개요

소개

툴킷 레거시 구성이 개선되어 tk-config-default2로 릴리즈되었습니다. 이 구성은 이제 Shotgun 데스크톱에서 고급 프로젝트 설정을 수행할 때의 기본 구성입니다. 이 문서의 목표는 새로운 구성의 구조에 대한 개요를 제공하고 레거시 툴킷 구성에 익숙한 사람들이 많이 하는 질문에 대한 답을 제공하는 것입니다. 기존 구성을 새 구조로 업데이트하는 방법에 대한 개요와 함께 레거시 Publish 앱에서 새 툴킷 게시자로 마이그레이션하는 방법, 새로운 소프트웨어 엔티티 사용 및 Shotgun 웹의 메뉴를 채우는 새로운 설정 지원에 대한 몇 가지 지침이 포함되어 있습니다.

기본 구성은 무엇입니까?

기본 구성은 Shotgun 데스크톱에서 해당 프로젝트에 대한 고급 프로젝트 설정을 실행하는 방법으로 프로젝트에 설치합니다.


고급 프로젝트 설정 중 기본 구성 선택

스튜디오 전용 워크플로우를 커스터마이즈하고 조정하기 위한 템플릿을 제공합니다. 기본 구성에는 프로젝트의 디스크에 파일이 있는 위치를 나타내는 기본 파일 시스템 스키마 및 템플릿이 함께 제공됩니다. 또한 기본 구성에는 3dsMax, Houdini, Mari, Maya, Motionbuilder, Nuke 및 Photoshop을 포함하여 지원되는 모든 통합이 포함됩니다. 이러한 통합은 각 DCC에 대해 파일 관리, 게시 및 워크플로우 로드를 허용하도록 구성됩니다. 기본 구성은 툴킷 관리자를 위한 참조 정보를 제공하며 완벽한 스튜디오 파이프라인을 빌드하기 위한 훌륭한 시작점입니다.

기본 구성 구조를 사용해야 하는 이유는 무엇입니까?

새로운 기본 구성은 프로덕션 환경을 수동으로 조정해야 할 때 효율성을 최대화할 수 있도록 고객 피드백 및 관찰된 내용을 기반으로 재구성되었습니다. 레거시 구성의 많은 중복성을 제거하여 일반 엔진 및 앱 설정 변경 사항을 단일 파일로 격리할 수 있는 포함 기반 구조를 채택했습니다. 

변경 사항 이해

새로운 환경 파일의 구조에 대한 개요는 여기를 참조하십시오.

새로운 구성의 몇 가지 구조적 구성요소를 통해 관리자가 변경된 사항을 쉽게 이해할 수 있습니다.

  • 이제 앱, 엔진 및 프레임워크의 위치 설명자가 구성의 한 위치에만 존재합니다. 레거시 구성에서는 앱 또는 엔진의 버전을 업데이트할 때 각 최상위 환경 파일을 변경해야 했습니다. 모든 앱 및 엔진 정의에는 이제 단일 위치의 위치 설명자가 포함됩니다. 다음 번들 설명자 파일은 env/includes에서 찾을 수 있습니다.



    • app_locations.yml      # 모든 앱 위치 설명자가 여기에 정의됩니다.
    • engine_locations.yml   # 모든 엔진 위치 설명자가 여기에 정의됩니다.
    • frameworks.yml         # 모든 프레임워크가 여기에 정의됩니다.
  • 모든 엔진별 및 앱별 설정은 해당 앱 또는 엔진 전용 파일에 정의되어 있습니다. 레거시 구성에서는 각 최상위 환경 파일이 모든 엔진 및 앱에 대한 설정을 정의했습니다. 새로운 구조에서는 환경 파일에 엔진별 설정 파일의 엔진 구성이 포함됩니다. 그런 다음 엔진 설정 파일에 앱별 설정이 포함됩니다. 이렇게 하면 다양한 엔진과 앱 설정이 모두 격리되어 엔진이나 앱을 업데이트할 위치를 쉽게 결정할 수 있습니다(예: 엔진 또는 앱 설정 파일로 이동). 예를 들어 모든 환경에서 Maya가 구성되는 방식을 변경하려면 env/includes/settings/tk-maya.yml을 편집합니다. 모든 프로덕션 환경에서 게시자가 구성되는 방식을 변경하려면 env/includes/settings/tk-multi-publish2.yml을 수정합니다. 

  • 이 앱/엔진 설정 파일 내에는 해당 앱/엔진에 대한 여러 구성이 있습니다. 설정의 각 변형은 서로 다른 환경에 포함되어 있으며 어떤 설정 컬렉션이 어떤 환경에 해당하는지 쉽게 알 수 있도록 명명되었습니다. 예를 들어 tk-maya.yml의 settings.tk-maya.asset_step 설정은 asset_step 환경에 대한 maya 엔진 설정을 정의합니다.



    마찬가지로, tk-multi-publish2.yml의 settings.tk-multi-publish2.nuke.shot_step 설정은 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로 바뀌었습니다. 이러한 파일의 구조는 동일하지만 새로운 구성에서는 소프트웨어 경로가 훨씬 적습니다. 이는 툴킷을 사용하여 소프트웨어 경로를 변환하기 위해 선호되는 방법이 Shotgun에서 소프트웨어 엔티티를 사용하는 것이기 때문입니다.


Shotgun에서 볼 수 있는 소프트웨어 엔티티 항목

소프트웨어 엔티티 및 스튜디오에서 작동하도록 커스터마이즈하는 방법에 대한 자세한 정보는 여기에 있는 설명서를 참조하십시오.

shotgun_*.yml 환경 파일 제거

shotgun_*.yml 환경 파일은 이전에 Shotgun 웹 앱의 툴킷 액션 메뉴에서 사용할 수 있는 툴킷 액션을 구성하는 데 사용되었습니다. 저희는 다른 모든 엔진이 구성되는 것과 동일한 방법으로 tk-shotgun 엔진을 구성하기 위해 이러한 추가 환경 파일을 제거했습니다. 툴킷 액션을 원하는 엔티티의 각 유형에 대해 shotgun_xxx.yml 파일을 사용하는 대신 project.yml, shot_step.yml 등 보다 일반적인 환경에서 Shotgun 엔진의 구성을 볼 수 있으며 환경을 코어 pick_environment 후크로 선택하도록 수동 제어할 수 있습니다. 목표는 보다 표준화된 구성을 위해 툴킷의 브라우저 통합을 둘러싼 특수한 동작을 제거하는 것입니다. 브라우저 통합 구성에 대한 이러한 변경 사항은 이전 버전과 호환되므로 기존 구성은 항상 그대로 작동합니다.

app_launchers.yml 제거

앱 시작 관리자 정의가 env/includes/settings/tk-multi-launchapp.yml 파일로 이동되었습니다. 따라서 다양한 환경의 앱 시작 설정이 구성의 새로운 구조와 긴밀히 연결됩니다(각 앱/엔진에는 고유한 설정 파일이 있음). 또한 소프트웨어 엔티티가 앱 시작을 자동으로 검색할 수 있도록 앱 시작 구성 중 많은 부분이 제거되었습니다. 자세한 정보는 소프트웨어 엔티티 설명서를 참조하십시오. 

레거시 기본 구성 사용

Shotgun 데스크톱에서는 고급 프로젝트 설정을 통해 레거시 기본 구성을 계속 사용할 수 있습니다. Github 리포지토리도 계속 표시되며 다운로드할 수 있습니다. 레거시 기본 구성은 새로운 기본 구성으로 버전별로 인라인으로 가져오기 위해 최신 앱, 엔진 및 프레임워크로 업데이트되었습니다. 

기존 구성 마이그레이션

tk-config-default2의 최신 릴리즈에서, 일부 고객은 기존 구성을 이 새로운 조직 구조로 변환하는 것에 관심을 표명했습니다. 다음 섹션에서는 이러한 변환을 위한 방법을 제시하고자 합니다.

이 프로세스는 선택 사항입니다. 기존의 운영 구성은 변경할 필요가 없습니다. 

또한 기존 구성을 새 구조로 마이그레이션하는 것은 고급 수동 프로세스이므로 레거시 툴킷 구성 구조, git 및 tank 셸 명령에 대한 완벽한 이해가 필요합니다. 신중하게 진행하십시오. 별도의 보호 방법은 없습니다.

tk-config-default2로 시작

기존 구성을 마이그레이션하려면 Shotgun에서 새 테스트 프로젝트를 만들고 데스크톱의 고급 프로젝트 설정을 사용하여 메시지가 표시될 때 새로운 기본 구성을 선택하여 시작하는 것이 좋습니다. 이렇게 하면 수정 작업을 시작할 수 있도록 작동 가능하고 깨끗한 구성이 제공됩니다.

그런 다음 새로운 구성 구조, 특히 환경 파일을 숙지하십시오. 이 읽어보기와 위 섹션에서 새로운 구조에 대한 자세한 정보를 볼 수 있습니다.

사용하지 않는 앱과 엔진 정리

새로운 구조를 완벽히 이해했으면 스튜디오에서 사용하지 않는 엔진과 앱을 제거해야 합니다. 이렇게 하려면 필요하지 않은 앱 및 엔진 설정 파일을 env/includes/settings 폴더에서 제거해야 합니다. 또한 나머지 엔진 설정 파일에서 사용하지 않는 앱에 대한 참조를 제거하고 최상위 env 파일에서 사용하지 않는 엔진에 대한 모든 참조를 제거해야 합니다.

예를 들어 스튜디오에서 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_node를 추가할 수 있습니다. 기존 앱 구성을 모두 검사하여 어떤 설정이 다르거나 누락되었는지 확인하고 적절하게 업데이트해야 합니다. 더 세분화된 구성이 필요할 수도 있으므로 엔진 설정 파일에 포함될 설정 블록을 더 추가해야 할 수도 있습니다.

참고: 새 기본 구성 구조는 스파스 설정을 사용하여 빌드되었으므로 모든 설정이 새 구조 내에 존재하지는 않습니다. 필요에 따라 구성에 사용되는 설정을 추가할 수 있습니다.

소프트웨어 엔티티 사용을 위한 업데이트

새 구성을 사용하면 거의 모든 소프트웨어가 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 데스크톱이 강조 표시된 줄에 포함되어 있음을 볼 수 있습니다. 소프트웨어 엔티티 시작 관리자를 통해 데스크톱에서 시작되어야 하는 모든 소프트웨어 또한 여기에 관련 엔진이 구성되어 있어야 합니다. 여기에서 Maya, Nuke 및 Photoshop과 같은 소프트웨어 엔티티 기반 시작을 지원하도록 구성된 다른 DCC 엔진을 볼 수 있습니다. 레거시 기본 구성에서 이전 shotgun_xxx.yml 파일을 사용할 때는 tk-shotgun 엔진만 구성해야 했습니다. 

구성 유효성 확인

셸에서 언제든지 validate 명령을 통해 구성을 테스트하여 환경 파일이 유효한지 확인할 수 있습니다.

./tank validate

또는

./tank validate asset_step

커스텀 앱 및 엔진 추가

다음으로, 제공된 기본 구성에는 없지만 스튜디오에서 사용하는 모든 엔진이나 앱을 환경 파일에 추가하려고 합니다. 먼저 위치 설명자를 app_locations.ymlengine_locations.yml 파일에 추가합니다. 그런 다음 기존 앱 및 엔진 설정 파일을 참조로 사용하여 새 앱 및 엔진에 대한 구성을 삽입합니다. 최상위 환경 파일에 추가된 엔진을 참조해야 합니다.

템플릿 및 스키마 복사

기존 구성의 templates.ymlschema 폴더를 복사하여 새 구성의 폴더를 대체해야 합니다.


구성 내의 스키마 폴더 및 templates.yml 파일

스튜디오의 templates.yml을 업데이트해야 하는 경우에 대비하여 새 구성의 기본 template.yml의 복사본을 보관할 수 있습니다. 이렇게 하면 제공된 구성에서 보관한 앱/엔진으로 지정된 새 템플릿을 검색하고 평가하여 스튜디오에서 작동하도록 사용 또는 수정해야 하는지 확인할 수 있습니다.

최상위 환경 업데이트

스튜디오에서 "에피소드" 또는 "재생 목록"과 같은 커스텀 환경을 사용하는 경우 env 폴더에도 해당 환경 파일을 만들어야 합니다.

위의 이미지는 최상위 환경 파일을 보여 줍니다. publishedfile_version.yml은 default2 구성에 새롭게 추가된 파일의 예입니다. 이 파일은 Shotgun의 PublishedFile 및 Version 엔티티 메뉴에 메뉴 항목을 제공합니다. 커스텀 환경을 변환할 때 이 파일과 다른 최상위 환경을 참조로 사용할 수 있습니다.

또한 커스텀 환경을 고려하여 pick_environment 후크를 수정해야 합니다. 커스텀 pick_environment 후크가 이미 있는 경우 기존 구성에서 복사할 수는 있지만 새 기본 구성에서 제공되는 해당 후크와 비교하여 정의된 모든 환경을 고려해야 합니다.

위의 이미지는 이전 이미지에 표시된 publishedfile_version.yml 파일 사용을 처리하는 default2 후크의 절을 보여 줍니다.

프레임워크 업데이트

다음으로, 스튜디오에 필요한 모든 커스텀 프레임워크가 포함되도록 frameworks.yml 파일을 업데이트합니다.


env/includes 폴더의 frameworks.yml 파일

이 파일은 항상 최상위 환경 파일에 포함되어 있으므로 적절한 설명자를 추가하는 것으로 충분합니다.

위의 이미지는 최상위 레벨 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로 마이그레이션할 때는 새로운 구성 구조를 사용하지 않습니다. 작동 중인 툴킷 구성이 있는 게시자를 사용할 수 있습니다.  

publish2 개념 익히기

publish1에서 정의한 개념에 익숙하고 기존 publish1 후크를 publish2에서 사용할 수 있도록 마이그레이션할 준비가 되면 새로운 게시자 및 해당 API의 개념을 숙지해야 합니다. 통합 개발자 안내서에서 전체 내용을 확인할 수 있습니다. 특히, publish2 진행단계(특히 수락 진행단계), 컬렉터 후크 및 게시 플러그인을 이해하는 것이 중요합니다. 안내서를 읽고 publish1 후크 구조에 대해 이해했다면 전환 경로에 대해 명확하게 이해할 수 있을 것입니다.

publish1과 publish2의 주요 차이점은 아래 다이어그램에서 볼 수 있습니다.

publish1.png
publish1 후크 및 항목 관계 다이어그램

publish2.ko.png

publish2 플러그인 및 항목 관계 다이어그램

다음은 차이점을 명확히 이해하는 데 도움이 되는 몇 가지 설명입니다. 커스텀 후크를 마이그레이션하기 전에 다음을 고려하십시오.

  • publish2에 게시할 항목은 collector 후크에 의해 생성됩니다. 이는 publish1의 scan_scene 후크에 해당합니다. 위의 이미지에서 녹색 상자를 참조하십시오. 
  • publish2에는 기본 및 보조 게시의 개념이 없습니다. 게시할 항목만 있습니다. 위의 이미지에서 파란색 상자를 참조하십시오.
  • publish1에서 pre_publish, publishsecondary_publish 후크 작업은 정적이며 사전 정의되어 있습니다. publish2에서 게시 플러그인은 개수에 제한 없이 항목에 대해 작동할 수 있으며 게시 진행단계는 플러그인의 메서드에 의해 정의됩니다(validate, publish, finalize). 위의 노란색 상자를 참조하십시오.
  • 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_type, display_name, descriptionicon 설정은 모두 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 엔진 리포지토리에 있으며 여기에는 현재 세션, 이전에 내보낸 playblast 및 alembic 캐시뿐만 아니라 모든 세션 지오메트리를 수집하고 게시하기 위한 로직이 있습니다. 

결론

위의 단계를 따르면 새로운 구성 구조와 기존 구성에서 이 구성 구조로 전환하는 방법을 이해할 수 있습니다. 새 구성에 대해 문의 사항이 있거나 마이그레이션 프로세스를 진행하면서 추가 설명이 필요한 경우 support@shotgunsoftware.com으로 문의해 주십시오. 

팔로우