툴킷 개요

Shotgun Pipeline Toolkit의 다양한 개념에 대한 개요입니다.

여기에서는 앱 및 엔진의 작동 방식, 툴킷의 시작 방법 및 현재 컨텍스트(작업 영역) 관리, 디스크에서 폴더를 만드는 방법 등의 주요 개념에 대해 자세히 설명합니다. 구성 또는 개발에 관련된 사람은 여기에서 시작하는 것이 좋습니다.
이 문서에서는 툴킷 구성에 대한 제어 권한을 갖고 있는 경우에만 사용할 수 있는 기능에 대해 설명합니다. 자세한 정보는 Shotgun 통합 관리자 안내서를 참조하십시오.

목차:

소개

프로젝트 및 구성

      스튜디오 구성 개선

      각 프로젝트의 파이프라인 구성

      업데이트 확인

      Core API 업데이트 확인

디스크에 폴더 만들기

현재 컨텍스트

파일 시스템 템플릿

실행할 엔진 및 앱 선택

      기본 구성의 환경

      Shotgun의 환경 - 상황에 맞는 메뉴 채우기

앱 구성

      후크

Shotgun 및 셸에서 실행

Shotgun에 게시

재사용 가능한 앱 빌드

보안 및 인증

      Core v0.16으로 업그레이드

      인증 및 프롬프트

            전역 스크립트 키 사용

            Shogun에 로그인

            비대화식 환경에서 실행

      기술적 상세 정보

            Shotgun 인증 라이브러리

            Shotgun 인증 및 권한

            툴킷 직렬화

            파일 위치

            다중 스레드 환경

툴킷 기술 상세 정보 및 추가 정보

소개

Shotgun Pipeline Toolkit에 대해 자세히 알고 싶으십니까? 여기에서 궁금증을 해결할 수 있습니다. 이 문서에서는 몇 가지 핵심 기능에 대해 자세히 설명합니다. 설명, 예제 및 간단한 데모를 통해 Shotgun 툴킷에 대한 모든 것을 보여 줍니다. 이 문서는 툴킷을 익히거나 툴킷을 통해 스튜디오의 가치를 높일 수 있는 방법을 알고 싶은 경우에 좋은 시작점입니다. 이 문서를 읽고 나면 주요 개념과 실제로 어떻게 작동하는지 이해할 수 있게 됩니다.

아래는 Shotgun Pipeline Toolkit(Sgtk)에 대한 간략한 설명입니다.

  • Sgtk는 Shotgun 플랫폼 기반의 파이프라인 툴킷입니다. 이 툴킷을 사용하면 스튜디오용 도구를 쉽게 작성하고 설치할 수 있습니다.
  • Sgtk는 파일 시스템을 기반으로 합니다. 디스크에서 항목의 저장 위치를 정리하여 디스크에 있는 항목을 깔끔하게 구성할 수 있습니다.
  • Sgtk는 보조적인 역할을 합니다. 파이프라인에서 데이터를 인수하거나 추상화하지는 않지만, 아티스트에게 정보를 쉽게 찾고 오류를 방지할 수 있는 강력한 도구를 제공합니다.
  • Sgtk는 공유를 도와줍니다. 모든 게시를 Shotgun에 저장함으로써 툴킷을 통해 프로덕션 전반에 걸쳐 업데이트 및 작업을 쉽게 공유할 수 있습니다.

다음 섹션에서는 Shotgun Pipeline Toolkit과 그 작동 방식을 자세히 살펴보겠습니다.

프로젝트 및 구성

Shotgun Pipeline Toolkit에서는 모든 항목이 프로젝트 중심입니다. 일반적으로 프로젝트는 Shotgun 내부에서 수명 주기를 시작하고 입찰 및 사전 프로덕션 진행단계를 거칩니다. 프로젝트가 컨텐츠 생성 진행단계를 위해 준비되면 해당 프로젝트에 대해 툴킷을 설정할 수 있습니다.

새 프로젝트를 설정할 때 템플릿 구성을 사용합니다. 템플릿 구성은 엔진 및 앱, 파일 시스템 구성 및 기타 설정을 포함하는 미리 정의된 구성입니다. 툴킷으로 시작하는 경우 예제 구성을 탐색의 시작점으로 사용할 수 있습니다. 다른 프로젝트에서 툴킷을 사용하고 있는 경우, 해당 구성을 새 프로젝트의 시작점으로 사용하는 것이 좋습니다. 그렇게 하면 스튜디오 구성을 개선시켜 각각의 새로운 프로젝트에 맞게 조정할 수 있습니다. 물론 스튜디오 구성을 개별적으로 유지 관리하고 이를 모든 새 프로젝트의 템플릿으로 사용할 수도 있습니다.

각 구성은 여러 저장 지점을 정의합니다. 표준 샘플 구성인 tk-config-default의 경우 기본이라는 단일 저장소 지점을 정의합니다. 즉, 모든 프로덕션 데이터가 단일 파일 시스템 프로젝트 루트 아래에 있음을 의미합니다. 두 개 이상의 파일 시스템 루트를 사용하여 구성을 설정할 수도 있습니다. 이를 다중 루트 구성이라고 합니다. 다중 루트 구성이 필요한 경우에는 렌더링과 편집을 위해 별도의 저장소가 있어야 할 경우 등이 있습니다. 이러한 저장 지점은 각각 Shotgun의 로컬 파일 저장소여야 하며 사이트 기본 설정(Site Preferences)의 파일 관리(File Management) 탭 아래에서 설정할 수 있습니다.

Shotgun 툴킷은 원하는 위치에 실제 프로젝트 구성을 설치합니다. 일반적으로 프로젝트 데이터 영역 자체가 아닌 디스크의 소프트웨어 설치 영역이 됩니다. 위치가 만족스럽지 않으면 언제든지 나중에 이동할 수 있습니다.

스튜디오 구성 개선

새 프로젝트를 설정할 때 기존 프로젝트를 기반으로 시작할 수 있습니다. Shotgun 툴킷은 해당 프로젝트의 구성 폴더를 새 프로젝트로 복사합니다. 즉, 새 프로젝트는 기반이 되는 프로젝트와 동일한 버전의 앱과 엔진, 동일한 설정 및 동일한 커스터마이제이션을 가져옵니다. 이 기능은 파이프라인을 개선시키고 기존 프로덕션의 개선 및 조정 사항을 활용하려는 경우 유용할 수 있습니다.

또는 해당 프로젝트 설정에 만족하는 경우 프로젝트의 구성 폴더를 가져와서 중앙 위치에 저장할 수 있습니다. 그러면 이 구성을 스튜디오 템플릿으로 사용할 수 있으며 새 프로젝트를 만들 때마다 이 구성을 기반으로 설정할 수 있습니다. 원하는 경우, git 등을 사용하여 이 스튜디오 템플릿 구성을 소스 제어할 수도 있으며, 파이프라인 구성 템플릿이 시간이 지남에 따라 어떻게 개선되는지를 간단하고 투명하게 트래킹할 수 있습니다. 업데이트할 때마다 프로젝트 중 하나에서 구성을 복사하고 변경 사항을 커밋합니다.

구성 관리에 대한 자세한 정보는 다음 상세 문서를 확인하십시오.

각 프로젝트의 파이프라인 구성

프로젝트에 대한 Shotgun 툴킷을 설정할 때마다 파이프라인 구성이 만들어집니다. 이 구성에는 프로젝트에 필요한 모든 설정과 파일이 포함됩니다. 구성에는 프로젝트를 직접 지정하려는 경우 셸에서 실행할 수 있는 전용 tank 명령이 있습니다(모든 프로젝트에서 작동하는 전역 tank 명령도 있음). Shotgun에서는 프로젝트 구성이 디스크에 상주하는 위치를 쉽게 트래킹할 수 있도록 파이프라인 구성이 특수 파이프라인 구성 엔티티로 등록되었습니다.

프로젝트가 설정될 때 생성되는 마스터 구성 외에도 프로젝트에 대한 추가 구성을 만들 수 있습니다. 이 기능은 프로젝트의 다른 사람들에게 영향을 주지 않고 구성을 변경하려는 경우에 유용합니다. 이 작업을 수행하려면 Shotgun의 파이프라인 구성으로 이동하고 이를 마우스 오른쪽 버튼으로 클릭하여 복제하도록 선택할 수 있습니다. 이렇게 하면 다른 프로젝트를 기반으로 한 프로젝트의 새로운 파이프라인 구성이 만들어지며 새로운 구성을 사용하여 다른 사용자에게 영향을 주지 않고 새로운 앱 등을 안전하게 테스트할 수 있습니다.

프로젝트의 기본 구성의 이름을 Primary로 지정해야 합니다. 이름을 바꾸거나 수정하거나 삭제하면 예상대로 작동하지 않을 수 있습니다. Shotgun에 저장된 파이프라인 구성은 수동이 아닌 다양한 tank 관리 명령을 통해 조작되므로 기본적으로 읽기 전용입니다.

예: 구성 복제 방법

업데이트 확인

다른 App Store와 마찬가지로, Shotgun 툴킷 App Store는 앱과 엔진을 위한 새로운 버전을 지속적으로 제공합니다. 이러한 새 버전에는 중요한 버그 수정이나 흥미로운 새 기능이 포함될 수 있습니다. 앱과 엔진을 업그레이드하는 것은 전적으로 선택 사항입니다. 일반적으로 빠른 프로세스이며 업그레이드 스크립트는 변경하기 전에 항상 메시지를 표시합니다. 마찬가지로, 실수로 설치한 버전이 만족스럽지 않은 경우 간단히 롤백할 수 있습니다.

단일 명령으로 업그레이드 프로세스를 처리합니다. 프로젝트 구성 폴더에 있는 tank 명령을 실행하고 updates 매개변수를 추가하기만 하면 됩니다.

> /software/shotgun/bug_buck_bunny/tank updates

매개변수 없이 이 명령을 실행하면 모든 환경, 엔진 및 앱이 검사되므로 시간이 오래 걸릴 수 있습니다. 설치된 앱 및 엔진의 하위 집합에 대해 업데이트 프로그램을 실행할 수도 있습니다.

일반 구문:

> tank updates [environment_name] [engine_name] [app_name]

특수 키워드 ALL을 사용하여 한 범주의 모든 항목을 나타낼 수 있습니다. 예:

  • 모든 항목 검사: tank updates
  • 샷 환경 검사: tank updates Shot
  • 모든 환경의 모든 Maya 앱 검사: tank updates ALL tk-maya
  • 샷 환경의 모든 Maya 앱 검사: tank updates Shot tk-maya
  • 모든 위치에서 Loader 앱이 최신 버전인지 확인: tank updates ALL ALL tk-multi-loader
  • Maya에서 Loader 앱이 최신 버전인지 확인: tank updates ALL tk-maya tk-multi-loader

이 스크립트는 App Store를 확인하는 것 외에도 등록된 다른 위치를 모두 확인하므로 앱을 배포한 위치에 따라 로컬 git, Github 리포지토리, 디스크의 파일 및 App Store를 쿼리할 수 있습니다.

새 버전의 앱이 앱 구성을 변경할 수 있습니다. 예를 들어 새 기능에 새로운 구성 매개변수가 필요할 수 있습니다. 이 경우 tank 업그레이드 스크립트는 이러한 매개변수의 값을 입력하라는 메시지를 표시합니다.

Core API에 대한 업데이트 확인

Toolkit Core API의 새 버전이 릴리즈될 때가 있습니다. Core API를 업데이트하는 데는 별도의 명령이 사용됩니다. 이 경우 명령은 tank core입니다.

디스크에 폴더 만들기

프로젝트에 Shotgun Pipeline Toolkit이 설정되면 툴킷을 사용하여 일관된 폴더 구조를 만들 수 있습니다. 이 폴더 구조는 디스크에 있는 파이프라인 구성의 일부로 파일 시스템 템플릿을 작성하여 구성됩니다. 이 폴더 구조에서 일부 경로는 동적입니다. 예를 들어 Shotgun 에셋을 나타내는 asset이라는 폴더가 있을 수 있습니다. 이러한 동적 폴더는 Shotgun 쿼리 및 기타 여러 항목에 연결할 수 있습니다.

Shotgun 툴킷은 다양한 설정과 시나리오를 처리하는 다양한 동적 폴더 유형을 제공합니다. 폴더 생성을 설정할 때 표준 Shotgun API 쿼리 구문을 사용할 수 있습니다. 따라서 예를 들어 파일 시스템을 구성하여 에셋이 유형별로 파일 시스템의 다른 폴더에 저장되도록 할 수 있습니다. 이러한 작업 방법에 대한 자세한 정보는 관리자 안내서를 참조하십시오.

Shotgun Pipeline Toolkit 폴더 생성은 두 가지 패스로 진행됩니다. 즉, 언제든지 다른 사람이 실행할 수 있는 직접 패스와 일반적으로 응용프로그램 시작 직전에 아티스트가 실행하는 유예 패스입니다. 이 유예 패스는 완전히 자동으로 이루어지며 응용프로그램별 폴더 및 사용자 샌드박스를 설정하는 데 사용할 수 있습니다.

현재 컨텍스트

파일 시스템 구조가 만들어지면 Shotgun 툴킷은 디스크상의 폴더와 폴더를 가져온 Shotgun 객체 사이의 관계를 인식합니다. 이는 경로를 게시, 로드 또는 확인할 때 툴킷이 Shotgun의 객체를 폴더, 디스크 또는 파일과 쉽게 연관시킬 수 있기 때문에 중요합니다. 또한 컨텍스트 또는 현재 작업 영역과도 연관됩니다. 컨텍스트 객체는 Toolkit Core의 일부이며 작업 중인 현재 항목을 트래킹합니다. 이는 툴킷이 파일 시스템 경로를 확인할 때의 핵심 메커니즘입니다. 이 문서에서 자세히 설명하겠습니다.

컨텍스트는 태스크, 에셋 또는 샷과 같은 Shotgun 객체 또는 디스크의 경로에서 만들 수 있습니다. 앱이 실행 중일 때 항상 컨텍스트에 액세스할 수 있으므로 파일 시스템 명명 규칙이나 앱이 에셋 또는 샷 파이프라인에서 사용되는지 여부를 몰라도 앱을 쉽게 만들 수 있습니다. 이러한 사항은 모두 Toolkit Core API와 컨텍스트에 의해 처리됩니다.

파일 시스템 템플릿

Toolkit Core에는 파일 경로를 처리하는 시스템이 있습니다. 이를 템플릿 시스템이라고 합니다. Shotgun 툴킷은 파일 시스템 기반이므로, 앱에서 디스크의 데이터를 읽거나 쓸 필요가 있을 때마다 파일 경로를 확인해야 합니다. 앱은 파일 시스템 구조에 독립적입니다. 즉, 파일 시스템이 어떻게 구성되어 있는지 모릅니다. 이러한 사항은 템플릿 시스템에서 처리합니다.

템플릿 시스템의 핵심에는 템플릿 구성 파일이 있습니다. 이 파일에는 프로젝트의 중요한 파일 시스템 위치가 모두 들어 있습니다. 템플릿의 모양은 다음과 같습니다.

maya_shot_publish: 'shots/{Shot}/{Step}/pub/{name}.v{version}.ma'

기본적으로 특정 동적 필드를 포함하는 경로를 정의합니다. 각 필드는 유효성 확인 및 입력을 통해 구성될 수 있습니다. 예를 들어 위 템플릿의 {version} 필드를 3개의 0으로 채워진 정수(예: 001, 012, 132)로 정의합니다. 앱이 디스크에서 쓰거나 읽을 필요가 있을 때마다 해당 위치를 설명하기 위해 템플릿 파일에 템플릿이 추가됩니다. 앱은 종종 파이프라인을 형성하도록 설정되기 때문에 한 앱(예: 게시 앱)의 출력 템플릿은 종종 다른 앱(예: 로딩 앱)의 입력 템플릿이 됩니다. 이것이 모든 파일 시스템 위치가 단일 파일에 보관되는 이유입니다.

템플릿 API를 사용하면 경로와 필드 값 목록 사이를 이동할 수 있습니다.

# get a template object from the API
>>> template_obj = sgtk.templates["maya_shot_publish"]
<Sgtk Template maya_asset_project: shots/{Shot}/{Step}/pub/{name}.v{version}.ma>

# we can use the template object to turn a path into a set of fields...
>>> path = '/projects/bbb/shots/001_002/comp/pub/main_scene.v003.ma'
>>> fields = template_obj.get_fields(path)

{'Shot': '001_002',
 'Step': 'comp',
 'name': 'main_scene',
 'version': 3}

# alternatively, we can take a fields dictionary and make a path
>>> template_obj.apply_fields(fields)
'/projects/bbb/shots/001_002/comp/pub/main_scene.v003.ma'

위의 경로와 템플릿에는 두 가지 유형의 필드가 있습니다. ShotStep 필드는 Shotgun에서 이와 동등한 객체(Shot 및 Pipeline Step)를 가진 고급 필드입니다. 여기서 name 필드와 version 필드는 이 특정 유형의 템플릿(이 경우 게시 경로)과 밀접하게 관련됩니다. 샷이 아닌 에셋의 게시 경로를 설명하려면 nameversion 필드가 있어야 합니다. 이는 데이터 유형에 상관없이 모든 게시에 필요하기 때문입니다. 그러나 우리는 ShotStep 필드가 없습니다. 대신 AssetStep 필드가 있을 수 있습니다. Asset 필드는 Shotgun의 에셋과 연결됩니다.

게시를 수행하는 앱을 개발하는 경우 샷 게시 앱과 에셋 게시 앱을 별도로 개발하는 것보다 단일 게시 앱에서 시퀀스, 샷, 에셋 등 모든 항목에 대한 게시 시나리오를 처리하는 것이 좋습니다.

이를 위해 툴킷 컨텍스트가 필요합니다. 기본적으로 툴킷 컨텍스트를 사용하면 위에서 언급한 것처럼 템플릿 필드를 두 개의 개별 그룹으로 나눌 수 있습니다. 컨텍스트 필드(Shot, Step, Asset 등)는 앱 코드가 샷 및 에셋과 같은 개념을 특별히 처리하는 코드를 가질 필요가 없도록 앱 밖에서 확인되는 필드입니다. 대신 앱은 앱의 특정 비즈니스 로직과 직접 연관된 필드에 정보를 입력해야 합니다. Publish 앱을 사용한 이 예에서는 비즈니스 로직이 nameversion 필드로 구성됩니다. 위의 그림에서 알 수 있듯이 Shotgun 툴킷은 필드 확인을 두 개의 진행단계로 나눕니다. 일부 필드는 컨텍스트에 의해 입력되고 일부 필드는 앱 내부의 비즈니스 로직에 의해 입력됩니다. 이렇게 하면 특정 파일 시스템 레이아웃에 연결되지 않은 앱을 설계할 수 있습니다. 이는 좋은 파이프라인 도구를 만드는 중요한 요소입니다.

경로 확인을 처리하는 앱 코드는 일반적으로 다음과 같습니다.

# start with an empty fields dictionary
fields = {}

# first let the context populate all its fields
fields.update( self.context.as_template_fields( publish_template_obj ) )
# fields is now {'Shot': '001_002', 'Step': 'comp' }

# now the app can add its business logic
fields["name"] = "main_scene"
fields["version"] = 234

# and finally the app can produce the path it needs in
# order to save out the file
path = publish_template_obj.apply_fields(fields)

템플릿 API를 구성하고 사용하는 방법에 대한 자세한 정보는 다음을 참조하십시오.

실행할 엔진 및 앱 선택

Toolkit Core의 또 다른 중요한 역할은 사용자에게 어떤 앱을 제공할지 결정하는 것입니다. 캐릭터 리깅 작업을 하고 Maya를 시작하는 경우 한 샷에 집중할 때보다 다른 앱 컬렉션을 원할 것입니다. 또한 앱 작동 방법에 따라 앱을 다르게 구성할 수 있습니다. 즉, 리깅을 위한 리뷰 앱은 턴테이블을 생성하고 동일한 리뷰 앱을 애니메이터가 실행할 경우 해당 앱이 샷 카메라를 사용하여 playblast를 만들 수 있습니다.

이러한 유연성을 고려하여 Shotgun 툴킷 프로젝트 구성에는 여러 환경 컬렉션이 포함되어 있습니다. 환경은 앱 및 엔진 컬렉션과 모든 구성 매개변수를 정의하는 구성 파일입니다.

예: 환경 파일은 어떤 모양입니까?

환경 파일은 엔진 및 앱 컬렉션을 정의하는 yaml 파일입니다.

description: Example environment file

engines:

  tk-maya:
    debug_logging: false
    location: {name: tk-maya, type: app_store, version: v0.2.10}

    apps:

      tk-maya-breakdown:
        hook_multi_update: default
        hook_scan_scene: default
        location: {name: tk-maya-breakdown, type: app_store, version: v0.2.7}

      tk-multi-about:
        location: {name: tk-multi-about, type: app_store, version: v0.1.8}

      tk-multi-loader-1:
        dependency_mode: false
        hook_add_file_to_scene: default
        location: {name: tk-multi-loader, type: app_store, version: v0.2.6}
        menu_name: Load Assets...
        publish_filters: []
        sg_entity_types:
          Asset: []
        single_select: true
        tank_types: [Maya Model, Maya Rig]

  tk-nuke:
    debug_logging: false
    location: {name: tk-nuke, type: app_store, version: v0.2.10}

    apps:

      tk-multi-setframerange:
        location: {name: tk-multi-setframerange, type: app_store, version: v0.1.2}
        sg_in_frame_field: sg_cut_in
        sg_out_frame_field: sg_cut_out

      tk-multi-snapshot:
        hook_copy_file: default
        hook_scene_operation: default
        hook_thumbnail: default
        location: {name: tk-multi-snapshot, type: app_store, version: v0.1.15}
        template_snapshot: nuke_shot_snapshot
        template_work: nuke_shot_work

표시된 것처럼 각 앱과 엔진에는 location 매개변수가 있습니다. 이는 코드의 위치와 현재 사용 중인 버전을 정의합니다. 이 매개변수는 Toolkit Core에서 앱 업데이트 검사를 관리하는 데 사용됩니다. 위의 예는 app_store 유형의 위치를 보여 줍니다. 즉, 승인 및 조정된 앱의 중앙 저장소에서 제공하지만 git와 같은 다른 위치도 지원합니다. 따라서 Shotgun Pipeline Toolkit과 함께 제공되는 업그레이드 시스템을 사용하여 내부 도구를 쉽게 관리하고 업그레이드할 수 있습니다.

툴킷이 시작되면 어떤 환경을 초기화할지 결정해야 합니다. 이 과정은 고유한 비즈니스 로직을 추가할 수 있는 Python 코드 조각, 즉 후크를 통해 수행됩니다. 컨텍스트 객체(현재 작업 영역)는 이 코드 조각에 전달되며 이는 종종 사용할 환경을 결정하는 데 사용됩니다.

이렇게 하면 파이프라인의 다른 부분에 대해 별도의 앱 컬렉션을 구성할 수 있습니다. 또한 이들을 독립적으로 업데이트할 수 있으며 각기 다른 감독이 별도로 관리할 수도 있습니다.

예: 환경 선택 후크는 어떤 모양입니까?

환경 선택 후크는 프로젝트별로 커스터마이즈할 수 있으며 예를 들어 다음과 같이 표시될 수 있습니다. 환경 선택 후크는 PIPELINE_CONFIG/core/hooks/pick_environment.py에 있습니다.

from tank import Hook

class PickEnvironment(Hook):

    def execute(self, context, **kwargs):
        """
        Example Pick Environment Hook!
        """

        if context.project is None:
            # our context is completely empty!
            # don't know how to handle this case.
            return None

        if context.entity is None:
            # we have a project but not an entity
            return "project"

        if context.entity and context.step:
            # we have a step and an entity
            if context.entity["type"] == "Shot":
                return "shot_step"
            if context.entity["type"] == "Asset":
                return "asset_step"

        return None

기본 구성의 환경

환경의 작동 방법과 구조에 대한 실질적 예제를 제공하기 위해 기본 구성과 함께 제공되는 환경을 살펴보겠습니다.

기본 구성은 다음 환경과 함께 제공됩니다.

  • project.yml - 컨텍스트에 프로젝트만 포함된 경우 실행할 앱 및 엔진
  • shot_and_asset.yml - 컨텍스트에 샷 또는 에셋이 포함된 경우 실행할 앱 및 엔진
  • shot_step.yml - 컨텍스트에 샷 및 파이프라인 단계가 포함된 경우 실행할 앱 및 엔진
  • asset_step.yml - 컨텍스트에 에셋 및 파이프라인 단계가 포함된 경우 실행할 앱 및 엔진

기본 구성은 파이프라인 단계를 기반으로 해당 파일 시스템을 구성했습니다. 즉, 예를 들어 샷 위치에서 Modeling, Rigging 등의 폴더를 찾을 수 있습니다. 기본적으로 작업 중인 각 파이프라인 단계마다 하나의 폴더가 있습니다. 디스크의 이러한 각 폴더에는 자체 작업 영역과 게시 영역이 있습니다. 예를 들어 게시 템플릿은 다음과 같이 표시될 수 있습니다.

maya_shot_publish: 'sequences/{Sequence}/{Shot}/{Step}/pub/{name}.v{version}.ma'

이 템플릿을 사용하려면 컨텍스트에 엔티티(이 경우 샷)와 파이프라인 단계가 모두 포함되어야 합니다. 시퀀스 ABC의 하위인 샷 1122와 파이프라인 단계 Modeling의 경우 위의 템플릿은 sequences/ABC/1122/Modeling/...으로 해석됩니다. 즉, 예를 들어 샷은 있지만 파이프라인 단계는 포함하지 않은 컨텍스트는 위의 템플릿을 채우기에 충분하지 않습니다. 샷만 있는 컨텍스트에서 위의 템플릿을 사용하여 Maya를 시작할 수는 없습니다. 템플릿이 작동하려면 단계가 필요합니다.

그 결과 위와 같이 환경이 분석됩니다. 기본 구성에 정의된 파일 시스템 구조는 단계를 중심으로 하므로 모든 기본 앱은 단계가 정의된 컨텍스트에서 실행해야 합니다. 이러한 두 환경은 기본 구성인 asset_step.yml 파일과 shot_step.yml 파일에서 정의합니다. 이러한 각 파일에는 Maya, Nuke, 3dsmax, Motionbuilder, Photoshop 등 여러 DCC 엔진이 포함되어 있습니다. 예를 들어 Shotgun 내부의 샷 태스크에서 Maya를 시작하면 환경 선택 후크는 shot_step 환경을 선택하고 Maya를 시작한 다음 Maya 앱 구성을 로드합니다.

Shotgun 내부의 샷 객체에서 직접 Maya를 시작하는 것도 유용할 수 있습니다. 특히 콘솔 tank Shot 1122 launch_maya에 입력할 수 있는 것이 매우 유용합니다. 이를 위해 shot_and_asset 환경이 필요합니다. 샷(또는 에셋)은 있지만 파이프라인 단계가 없는 컨텍스트로 Maya를 로드하면 이 환경이 로드됩니다. 그러나 파일 시스템 구조는 파이프라인 단계별로 모두 구성되기 때문에 샷만 있는 경우 로드 또는 게시를 수행할 수 없습니다. Maya는 대신 Work Files 앱만 포함하는 기본 구성으로 시작됩니다. 이 앱을 사용하면 작업할 태스크를 선택한 다음 컨텍스트를 이 태스크로 전환할 수 있습니다. 일단 태스크를 선택하면 툴킷이 컨텍스트를 전환하고 엔진을 다시 시작하며 모든 범위의 앱으로 shot_step 환경을 로드합니다.

마찬가지로, project 환경은 다목적 폴백이며 Work Files 앱만 포함합니다. 이렇게 하면 프로젝트 내부의 거의 모든 곳에서 Maya(또는 다른 앱)를 시작할 수 있으며 툴킷이 최소 상태로 초기화되므로 Work Files 앱을 사용하여 유효한 작업 영역으로 바로 이동할 수 있습니다.

Shotgun의 환경 - 상황에 맞는 메뉴 채우기

컨텍스트에 따라 Shotgun Pipeline Toolkit에 의해 자동으로 선택되는, 위에 설명된 동적 환경 외에도 툴킷에는 특별한 Shotgun 환경 세트가 함께 제공됩니다. 이러한 환경은 Shotgun 내부의 상황에 맞는 메뉴에 표시되는 앱을 제어합니다. 이러한 환경 파일은 모두 shotgun_entitytype.yml 형식으로 이름이 지정됩니다(예: shotgun_shot.yml, shotgun_asset.yml). 이러한 환경에서 정의한 앱은 모두 Shotgun의 해당 엔티티 유형에 대한 상황에 맞는 메뉴에 표시됩니다.

앱 구성

각 앱에는 지정해야 하는 여러 구성 매개변수가 있습니다. 앱을 설치하거나 업그레이드할 때 툴킷은 필요한 모든 설정을 지정했는지 확인합니다. 설정은 일반적으로 자동으로 문서화됩니다. 설명서의 앱 목록 섹션에서 몇 가지 예를 확인하십시오.

문자열 등의 간단한 설정 값은 환경 구성에서 직접 지정됩니다. 템플릿은 다릅니다. Shotgun 툴킷에서는 모든 템플릿을 한 곳에 보관하려고 하므로 환경 파일은 템플릿 파일에 정의된 템플릿을 가리키기만 하면 됩니다. 각 앱은 해당 구성에서 사용하는 템플릿에 다른 필드가 있어야 합니다. 예를 들어 앞의 예제 Publish 앱에서는 디스크에 출력 파일을 만들 때 nameversion 필드가 있는 템플릿을 사용했습니다. 따라서 이 앱에는 nameversion 필드가 포함된 템플릿이 필요한 구성 설정이 필요합니다.

컨텍스트 필드, nameversion 외의 필드가 있는 템플릿을 사용하여 앱을 구성하려는 경우 앱 코드에서 이러한 추가 필드를 채우는 방법을 모르기 때문에 해당 템플릿에서 경로를 생성할 수 없습니다. 마찬가지로, 필드 중 하나(예: version)가 누락된 템플릿을 제공한 경우 혼란스러운 결과가 발생할 수 있습니다. 이 경우 앱에서 버전 번호가 작성되지 않습니다. 따라서 툴킷은 시작할 때 구성을 확인하여 모든 템플릿에 필요한 필드가 제공되었는지 확인합니다. 또한 Shotgun 툴킷은 기본값과 선택적 필드를 사용하는 몇 가지 방법을 지원합니다. 전체 참조를 보려면 다음 링크를 확인하십시오.

후크

Shotgun Pipeline Toolkit은 템플릿을 사용하는 앱 설정 외에도 후크라는 개념을 지원합니다. 후크는 Python 코드의 작은 조각이므로 구성의 일부로 앱 코드 일부를 효과적으로 커스터마이즈할 수 있습니다. 다음은 작동 방식과 유용성에 대한 설명입니다.

앱은 여러 엔진과 프로젝트에서 재사용할 수 있기 때문에 강력합니다. 그러나 앱에 작은 조각의 일부 엔진별 코드가 필요할 수 있습니다. 예를 들어 Nuke와 Maya에서 모두 작동하는 Loader 앱을 빌드하는 경우 실제 파일 로드를 처리하는 코드가 있어야 합니다. 이 코드는 Nuke와 Maya의 API가 완전히 다르므로 각각 달라야 합니다. 모든 엔진과 함께 이 앱을 사용할 수 있다면 더욱 좋을 것입니다. 또한 스튜디오마다 씬에 항목을 로드하는 방법이 다를 수 있습니다. 어떤 스튜디오에서는 커스텀 Maya 참조 노드를 지원해야 하고 어떤 스튜디오에서는 가져오기만 수행할 수도 있습니다.

이 상황은 툴킷에서 후크를 사용하여 처리됩니다. 후크는 커스터마이즈 가능한 코드 조각입니다. 앱은 기본 레벨의 구현을 포함하는 기본 후크와 함께 제공됩니다. 즉, 앱은 즉시 사용이 가능합니다. 그러나 동작을 커스터마이즈하려는 경우 해당 후크 파일을 구성에 복사하면 툴킷이 해당 코드를 대신 사용합니다.

Shotgun 및 셸에서 실행

Shotgun 툴킷이 설치되면 몇 가지 기본 진입점에서 액세스할 수 있습니다.

  • Shotgun 액션은 Shotgun의 마우스 오른쪽 버튼 클릭 메뉴에 나타납니다.
  • 시작 아이콘은 Shotgun 데스크톱 앱의 프로젝트에 대해 나타납니다.
  • 콘솔에서 tank 명령을 사용할 수 있습니다.
  • 툴킷 Python API는 응용프로그램과 셸 모두에서 사용할 수 있습니다.

일반적으로 응용프로그램을 시작하고 태스크를 수행하려면 Shotgun에서 툴킷을 실행합니다. Shotgun 툴킷은 Shotgun 브라우저 플러그인을 사용하여 컴퓨터의 로컬 툴킷 설치와 통신하고 로컬 Python을 사용하여 Shotgun 엔진 및 앱을 실행합니다. 즉, Shotgun 내부에서 바로 폴더 생성과 같은 로컬 작업을 실행할 수 있습니다. Shotgun 내부에서 QT UI 기반 앱을 실행할 수도 있습니다.

또한 명령 셸에서 Shotgun 툴킷에 액세스할 수 있습니다. 각 프로젝트 구성은 자체 tank 명령과 함께 제공됩니다. 프로젝트 구성 루트로 이동하여 ./tank 명령을 실행하기만 하면 됩니다.

마지막으로 PYTHONPATH에 툴킷 API를 추가하고 가져올 수 있습니다. API 사용은 간단합니다. 예를 들어 Maya 내부에서 Shotgun Pipeline Toolkit을 수동으로 시작하거나, 시작 앱 기능을 사용하지 않고 기존 스튜디오 시작 시스템의 일부로 몇 가지 간단한 명령을 실행하기만 하면 됩니다.

Shotgun에 게시

다른 사람들과 작업 중인 파일을 공유하려면 해당 파일을 게시하면 됩니다. 이는 Shotgun 내부에 게시 레코드가 생성된다는 의미입니다.

데이터 관리 측면에서 이러한 의미에 대한 자세한 내용(디스크 항목이 저장된 위치, 파일에 포함된 내용 등)은 실제 작업을 수행하는 앱에 따라 달라집니다. 툴킷 API는 앱 개발자에게 Shotgun 내부에 쉽게 게시를 생성하고 이러한 게시를 올바른 객체에 링크하는 메서드를 제공하여 Shotgun이 모든 올바른 작업자에게 알림을 전달할 수 있도록 합니다. 다용도로 구성할 수 있는 기본 Publish 앱도 제공하지만 이 앱이 Shotgun 툴킷을 사용하여 버전 제어를 구현하는 유일한 방법은 아닙니다. Sgtk는 파이프라인 툴킷이므로 원하는 경우 툴킷을 사용하여 자체 커스텀 버전 제어 및 게시 시스템을 빌드할 수 있습니다. 그러나 시작점으로 아래 Publish 앱을 권장합니다.

재사용 가능한 앱 빌드

Shotgun Pipeline Toolkit은 단순히 앱 및 엔진의 컬렉션이 아닙니다. 자체 도구 및 기술을 개발하는 데 사용할 수 있는 프레임워크이기도 합니다. Shotgun 툴킷에는 유용한 스튜디오 개발 플랫폼으로 사용할 수 있도록 많은 기능이 포함되었습니다. 기본 파이프라인 스택을 빌드하는 대신 툴킷을 기반으로 당면한 문제에 집중할 수 있습니다. 개발자는 아티스트의 파이프라인에 영향을 주지 않고 소프트웨어를 빌드, 평가 및 릴리즈할 수 있습니다.

  • 엔진을 사용하면 기본 기반에 관계없이 Python 및 QT(PySide/PyQt)로 앱을 작성할 수 있습니다. 이는 일부 엔진은 매우 간단하고(Nuke의 경우 이미 PySide와 Python이 포함되어 있음) 일부 엔진은 더 복잡하다(Photoshop의 경우 Python을 지원하지 않음)는 의미입니다. 즉, 간단하고 일관된 방법으로 스튜디오용 도구를 개발할 수 있습니다. 경험에 따르면 Python과 PyQt/PySide는 개발 환경 스튜디오에서 사용되는 경우가 많으며 많은 TD가 이에 익숙합니다.

  • 엔진 레이어는 또한 앱을 한 번 작성한 다음 여러 환경에 배포할 수 있음을 의미합니다. 당사는 표준 앱 제품군을 다중 앱으로 개발했습니다. 이는 동일한 앱이 모든 엔진에서 사용된다는 것을 의미합니다. 특정 코드는 반드시 각 DCC 응용프로그램이 노출하는 특정 API로 작업하도록 작성되어야 하지만 일반적으로 하나 이상의 후크에 포함되어 있기 때문에 앱을 쉽게 재활용할 수 있습니다. 이와 같은 다중 앱을 만들 수 있기 때문에 생기는 또 다른 결과는 새로운 엔진이 개발될 때 모든 표준 앱이 새로운 엔진과 작동하도록 쉽게 구성할 수 있다는 것입니다.

  • 파이프라인 구성 및 복제를 통해 개발 샌드박스를 쉽게 만들 수 있기 때문에 개발자는 일상적인 프로덕션 액티비티를 방해하지 않고 프로덕션에서 개발 작업을 수행할 수 있습니다. 도구를 배포할 준비가 되면 기본 프로젝트 구성을 쉽게 업데이트하고 도구를 모든 아티스트에게 롤아웃할 수 있습니다.

  • 앱은 엔진 내부에서 실행되므로 쉽게 다시 로드할 수 있습니다. 새 코드 변경을 테스트할 때마다 Nuke 또는 Maya를 다시 시작하지 않고 툴킷에서 다시 로드 버튼을 누르기만 하면 최신 코드가 로드됩니다.

앱 개발에 대한 더 자세한 소개는 다음 문서를 참조하십시오.

보안 및 인증

Shotgun Pipeline Toolkit을 실행하면 특정 작업을 수행하기 위해 정기적으로 Shotgun에 연결됩니다. 이러한 작업의 예로는 새 렌더링 게시 또는 씬에 로드할 항목 찾아보기를 들 수 있습니다. 이 시점에서 툴킷은 데이터를 읽거나 쓰기 위해 Shotgun에 로그인해야 합니다. 즉, 현재 사용자가 Shotgun 서버와의 커넥션을 설정할 수 있도록 인증되어야 합니다.

v0.16 이전의 Toolkit Core 버전에서는 모든 툴킷 작업을 처리하는 데 단일 Shotgun API 스크립트 사용자를 사용하여 인증이 자동으로 처리되었습니다. Toolkit Core v0.16에서는 Shotgun의 다른 작동 방식과 마찬가지로, 각 사용자의 로그인과 암호를 요구하는 모드로 기본 설정됩니다.

툴킷은 인증을 위해 세션 토큰을 사용합니다. 이러한 세션 토큰은 Shotgun 서버에서 생성되는 고유 식별자입니다. Shotgun API 요청이 툴킷에서 들어올 때마다 서버가 이를 확인하고 요청에 대한 액세스 권한을 부여할 수 있도록 이 세션 토큰이 함께 전달됩니다. 이러한 세션 토큰은 비활성 상태가 일정 기간(보통 24시간) 동안 지속되면 시간 초과되며, 이 경우 일반적으로 툴킷이 새 세션 토큰을 검색하도록 암호를 다시 입력하라는 메시지가 표시됩니다.

파이프라인에서는 사용자에게 암호를 묻기가 어렵거나 불가능한 상황이 종종 발생합니다. 이러한 경우 툴킷은 완전히 "헤드리스"로 실행하거나 인증 관련 프로세스를 완전히 커스터마이즈는 여러 가지 방법을 제공합니다. 다음 섹션에서는 툴킷 보안 모델의 작동 방식과 커스터마이즈 방식에 대해 설명합니다.

Core v0.16으로 업그레이드

v0.16 이전에는 모든 인증이 shotgun.yml이라는 구성 파일을 통해 처리되었습니다. 이 파일에는 Shotgun 스크립트 자격 증명이 포함되어 있어 모든 사용자가 로그인할 필요 없이 동일한 방식으로 Shotgun에 액세스할 수 있었습니다. Core v0.16에서 여전히 이 동작을 지원하지만 사용자에게 사용자 이름과 암호를 묻도록 기본 설정되어 있으므로 툴킷에서 사용자를 보다 세밀하게 제어할 수 있고 전역 위치에 스크립트 자격 증명을 저장할 필요가 없습니다.

Core v0.16은 이전 버전과 완벽하게 호환되며 shotgun.yml 파일에 지정된 스크립트 자격 증명을 사용하는 툴킷 프로젝트에서는 이러한 자격 증명을 인증 용도로 사용합니다. 이는 Toolkit Core v0.16으로 업데이트할 때 기존 프로젝트가 새 인증 기능의 영향을 받지 않음을 의미합니다.

기존 shotgun.yml 파일의 모양은 일반적으로 다음과 같습니다.

# Shotgun Pipeline Toolkit configuration file
# this file was automatically created

host: https://mysite.shotgunstudio.com
api_key: abcdefghijklmnopqrstuvwxyz01234567890ABCDE
api_script: Toolkit
http_proxy: null

# End of file.

api_scriptapi_key 줄이 제거되면 툴킷에서 사용자에게 로그인 및 암호를 묻는 메시지를 표시합니다. 새 프로젝트가 v0.16에서 설정되면 자동으로 다음 양식이 사용됩니다.

# Core v0.16 example which doesn't store script
# credentials in a file but instead prompts each
# user to individually log in

host: https://mysite.shotgunstudio.com
http_proxy: null

# End of file.
  • Core v0.16에 도입된 새로운 인증 기능을 사용하여 기존 프로젝트를 실행할 수 있게 하려면 해당 shotgun.yml 파일(일반적으로 구성 폴더의 config/core에 있음)에서 api_keyapi_script 키를 주석 처리합니다.

  • 반대로 새 프로젝트를 만들고 툴킷에서 이전에 사용된 자동 인증 모델을 사용하려면 유효한 스크립트 자격 증명으로 shotgun.yml을 업데이트합니다.

  • 기존 프로젝트의 api_keyapi_script 필드를 주석 처리하면 v0.16 이전의 Core에서 해당 구성이 더 이상 작동하지 않습니다. 주석 처리하기 전에 해당 프로젝트에서 작업하는 모든 사용자가 Core v0.16으로 업그레이드했는지 확인하십시오.

  • 고급 사용자 및 위와 같은 상황을 위한 참고 사항: Shotgun 데스크톱 v1.0.x를 실행 중인 경우 Shotgun 데스크톱에서 사용하는 로컬 사이트 구성에서 api_keyapi_script 필드를 수동으로 제거하지 마십시오. Shotgun 데스크톱의 v1.0.x 이전 버전에서는 shotgun.yml 파일에 저장된 스크립트 자격 증명이 없는 프로젝트를 처리할 수 있지만 사이트 구성 파일에 해당 필드가 있어야 합니다. 파이프라인에서 하드 코딩된 자격 증명을 완전히 없애려면 최신 버전의 Shotgun 데스크톱으로 업데이트해야 합니다.

  • 프로젝트에 공유 코어를 사용하는 경우 shotgun.yml 파일은 프로젝트 구성이 아닌 코어 구성 위치에 있습니다. 이 경우 변경 사항은 해당 코어를 사용하는 모든 프로젝트에 적용됩니다.

  • 일치하는 사용자 로그인 없음 - 이전에는 모든 사용자가 동일한 스크립트 사용자를 사용하여 Shotgun에 연결했습니다. 즉, Shotgun 커넥션에 실제로 어떤 사용자가 연결 중인지에 대한 개념이 별로 없었습니다. 툴킷은 현재 사용자의 운영 체제 로그인을 가져오고(후크 사용) 이를 Shotgun의 사용자와 대조하여 실제 현재 사용자를 식별하려고 했습니다. 이 동작은 v0.16에도 폴백 메커니즘으로 여전히 남아 있지만 사용자별 인증이 활성화된 모든 새 프로젝트에서는 이 시스템 로그인 일치 로직이 더 이상 필요하지 않으며 사용되지 않습니다.

  • 새 권한 - 이전에 툴킷에서 단일 Toolkit 스크립트 사용자를 사용하여 연결할 때는 이 스크립트 사용자와 관련된 Shotgun 권한이 Shotgun 내에서 수행할 수 있는 작업에 대한 제한 요소였습니다. 사용자가 툴킷에 로그인을 시작하는 새 프로젝트에서는 사용자의 Shotgun 권한이 수행할 수 있는 작업을 결정합니다. 이전에는 Toolkit 스크립트 사용자가 아티스트를 대신하여 Shotgun 작업을 수행하는 작업(사내 도구 및 커스터마이제이션)의 동작에 영향을 줄 수 있었지만, 지금은 아티스트가 자신의 자격 증명으로 동일한 작업을 실행합니다. 일반적으로 잠재적인 문제는 사용자가 필요한 모든 파이프라인 작업을 수행할 수 있는 권한을 갖도록 해당 사용자의 Shotgun 권한을 조정하여 신속하게 해결할 수 있습니다.

인증 및 프롬프트

Toolkit Core v0.16부터 아래 설명된 몇 가지 보안 모드가 지원됩니다.

전역 스크립트 키 사용

로그인 및 암호를 입력하라는 메시지가 표시되지 않게 하려면 shotgun.yml 파일에 전역 Shotgun 스크립트 키를 지정하면 됩니다. 툴킷은 모든 Shotgun 작업에 이 키를 사용합니다. 이 모드는 Toolkit Core v0.16 이전의 모든 프로젝트에서 사용된 보안 모드입니다. 기본적으로 새 프로젝트는 이 전역 스크립트 키 없이 생성되지만 shotgun.ymlapi_scriptapi_key 옵션을 추가하여 활성화할 수 있습니다. 예를 보려면 이전 문서 섹션을 참조하십시오.

Shogun에 로그인

사용자별 보안 실행이 활성화된 경우 Shotgun은 사용자를 인증하기 위해 로그인과 암호를 요구합니다. 이러한 로그인과 암호는 세션 간에 기억되지만 입력하라는 요청이 다시 표시될 수도 있습니다.

툴킷에 로그온하면 암호가 Shotgun 서버로 안전하게 전송되고 세션 토큰이 반환됩니다. 그러면 툴킷에서 이 토큰을 사용하여 연결하고 토큰이 유효한 동안 다시 암호를 묻지 않습니다. 토큰이 일정 시간(일반적으로 24시간 동안 비활성화 상태인 경우) 후에 만료되면 툴킷에서 다시 암호를 묻습니다. 로그인 및/또는 암호를 묻는 메시지는 다음과 같은 경우 표시될 수 있습니다.

  • Shotgun 데스크톱을 시작할 때

  • 터미널에서 tank 명령을 실행할 때. 몇 가지 방법으로 메시지가 표시되지 않도록 할 수 있습니다. 여기에 대해서는 다음 섹션에서 설명합니다.

  • Shotgun 웹 응용프로그램에서 툴킷 액션 메뉴 항목을 클릭할 때

  • 일반적으로 Maya, Nuke 또는 다른 DCC를 시작하면 암호를 입력하라는 메시지가 표시되지 않습니다. 이는 Shotgun 데스크톱, Shotgun 웹 응용프로그램 또는 tank 명령이 이미 사용자의 인증을 새로 고쳤기 때문입니다. 그러나 Maya 또는 Nuke를 24시간 이상 비활성 상태로 열어 두면 암호를 갱신하라는 대화상자가 표시될 수 있습니다. 이러한 메시지는 툴킷에서 Shotgun에 액세스하기 직전에 표시됩니다.

비대화식 환경에서 실행

파이프라인 코드를 UI나 사용자가 없는 환경에서 실행해야 할 경우가 많습니다. 일반적인 예로는 렌더 팜에서의 코드 실행을 들 수 있습니다. 이러한 경우 툴킷은 API 및 명령줄을 통해 자격 증명을 제공하는 여러 가지 방법을 제공합니다.

tank 명령을 사용하는 경우 몇 가지 옵션을 사용할 수 있습니다. --script-name--script-key 명령줄 인수를 통해 인증을 위한 스크립트 이름과 스크립트 키를 직접 제공할 수 있습니다.

# never prompt for a username or password
> tank --script-name=headless_launcher --script-key=xxx Shot ABC123 launch_maya

명령줄에서 직접 상세 정보를 제공하지 않으려는 경우 해당 정보를 파일에 저장하고 tank 명령에서 --credentials-file 인수를 사용하여 이 파일을 지정할 수도 있습니다.

# never prompt for a username or password
> tank --credentials-file=/path/to/script_credentials.yml Shot ABC123 launch_maya

이 파일의 형식은 다음과 같습니다.

script-name: Toolkit
script-key: abcdefghijklmnopqrstuvwxyz01234567890ABCDE

이 방법을 사용하면 다양한 파이프라인 서비스에 맞게 각기 다른 권한 설정이 있는 여러 Shotgun 스크립트 사용자를 유지 관리할 수 있으므로 프로세스에 필요한 Shotgun 데이터에만 액세스할 수 있도록 제한됩니다.

툴킷 API를 직접 사용하는 경우 툴킷이 인증 받으려면 현재는 일부 코드를 작성해야 합니다. Sgtk API의 기본 보안 API 메서드는 sgtk.set_authenticated_user(user)입니다. 이 메서드를 사용하여 특정 사용자를 Toolkit Core 세션과 연관시킬 수 있습니다. 이 메서드에 전달한 사용자 객체는 인증에 대한 로직을 추상화하는 Shotgun 인증 API에 의해 생성됩니다. 아래 샘플 코드는 Shotgun 스크립트를 사용하여 인증하는 Toolkit Core API 세션을 설정하는 방법을 보여 줍니다.

import sgtk
from tank_vendor.shotgun_authentication import ShotgunAuthenticator

# create an authenticator object. This is the main object which
# handles all authentication
sa = ShotgunAuthenticator()

# Use the authenticator to create a user object. This object
# identifies a Shotgun user or script and also wraps around
# a Shotgun API instance which is associated with that user.
user = sa.create_script_user(api_script="myscript",
                             api_key="xxxxx",
                             host="https://myhost.shotgunstudio.com")

# tell the Toolkit Core API which user to use
sgtk.set_authenticated_user(user)

인증된 사용자가 툴킷에 설정되면 사용자 객체가 기본 제공된 context 직렬화 메서드의 일부로 자동으로 직렬화됩니다. 즉, 예를 들어 Maya, Nuke 또는 다른 DCC를 시작하면 시작 프로세스(일반적으로 tank 명령, Shotgun 데스크톱 또는 Shotgun 웹 응용프로그램)에서 시작된 DCC로 자격 증명이 전달됩니다. 따라서 한 프로세스에서 다른 프로세스로 유효한 자격 증명을 쉽게 전달할 수 있습니다.

Shotgun Authenticator API에 대한 자세한 정보는 인라인 코드 문서를 참조하십시오.

기술적 상세 정보

Shotgun 인증 라이브러리

모든 Shotgun 관련 인증 로직은 Toolkit Core 및 Shotgun 데스크톱에서 사용되는 독립 실행형 Python 라이브러리로 개발되었습니다. 또한 사용자가 Shotgun에 로그인해야 하는 시나리오를 처리해야 하는 다른(툴킷이 아닌) 응용프로그램에서도 사용할 수 있습니다. 라이브러리는 Shotgun API를 래핑하고 사용자가 인증해야 할 때 표시되는 표준 QT 기반 Shotgun 로그인 대화상자를 포함합니다. Shotgun 인증 모듈은 Shotgun 인증과 관련된 여러 가지 일반적인 시나리오를 처리하고 사용자가 안전하고 편안하게 느끼도록 표준화된 사용자 환경을 유지 관리하는 데 도움을 줍니다. 기능 집합은 다음과 같이 요약할 수 있습니다.

  • 사용자 이름과 암호를 묻는 메시지와 관련된 표준화된 QT 및 명령줄 기반 사용자 환경

  • API가 사용자 중단을 최소화할 수 있도록 API 인스턴스에서 Shotgun 세션 토큰을 유지하기 위한 기본 메커니즘

  • API의 클라이언트가 기본값을 기준으로 동작을 구성할 수 있도록 구성 및 재정의 가능한 기본 매니저

  • API의 중앙에서 Shotgun 사용자 객체의 팩토리 역할을 하는 Shotgun Authenticator 인스턴스. 이러한 객체는 Shotgun의 사용자 또는 스크립트를 나타냅니다.

  • 인증 라이브러리에서 반환된 Shotgun 사용자 객체에는 해당 사용자와 관련된 Shotgun API 인스턴스를 만드는 create_sg_connection() 메서드가 있습니다. 스크립트 사용자가 아닌 경우 일반적으로 24시간 동안 비활성 상태이면 Shotgun API 인스턴스에서 사용하는 세션 토큰이 무효화될 수 있습니다. 이 경우 Shotgun API 인스턴스는 이 오류를 트랩하여 사용자에게 암호를 입력하라는 메시지를 자동으로 표시합니다.

자세한 정보는 Shotgun 인증 모듈의 인라인 코드 문서를 참조하십시오.

Shotgun 인증 및 권한

사용자가 툴킷에서 로그인 및 암호로 인증할 때마다 Shotgun 인증 라이브러리는 Shotgun 서버에 연결하고 이 정보를 이후 요청에 사용할 세션 토큰으로 교환합니다. 암호는 저장되지 않으며 세션 토큰은 디스크의 파일 권한이 제한된 파일에 저장되고 인증이 필요할 때마다 사용됩니다. 툴킷은 가능할 때마다 이 저장된 세션 토큰을 사용하려고 시도하며 토큰이 더 이상 유효하지 않은 경우에만 사용자에게 메시지를 표시합니다. 이는 일반적으로 비활성 상태가 24시간 동안 지속된 경우 발생합니다.

툴킷이 이러한 방식으로 Shotgun과 통신하는 경우 API 세션은 사용자가 Shotgun 웹 응용프로그램에 로그인할 때 일반적으로 사용하는 것과 동일한 Shotgun 권한 규칙을 사용합니다. 이러한 권한은 기본 Shotgun API 스크립트 권한과 다를 수 있으며 종종 제한적일 수 있습니다. 즉, 스크립트 사용자로 로그인할 때 수행할 수 있는 작업을 사용자로 로그인할 때 실패할 수 있으며 그 반대의 경우도 마찬가지입니다. 권한 오류가 발생하면 Shotgun 권한 편집기에서 사용자 및 API 스크립트에 대한 권한을 다시 확인하십시오. 이 권한은 Shotgun 웹 응용프로그램의 관리자 메뉴에서 찾을 수 있습니다.

툴킷 직렬화

툴킷에서 Maya 또는 Nuke와 같은 DCC가 시작되면(tk-multi-launchapp 사용), 현재 context는 일반적으로 문자열 기반 형식으로 직렬화됩니다. DCC 프로세스가 시작되고 일반적으로 툴킷에서 제공하는 시작 또는 부트스트랩 스크립트를 실행하도록 요청됩니다. 이 스크립트는 컨텍스트 문자열을 객체로 역직렬화하여 새 tk 인스턴스를 만들고 마지막으로 엔진을 시작합니다.

이 과정에서 사용자 객체도 직렬화됩니다. 즉 새 프로세스가 상위 프로세스와 동일한 자격 증명 설정으로 실행됩니다. 이렇게 하면 예를 들어 여러 사용자가 서로 다른 프로세스를 시작하거나 한 시스템에서 컨텍스트를 캡처한 다음 다른 시스템에서 컨텍스트를 실행할 수 있습니다.

파일 위치

세션 토큰은 다음 파일에 저장됩니다.

  • macosx: ~/Library/Caches/Shotgun/SITENAME/authentication.yml
  • Linux: ~/.Shotgun/SITENAME/authentication.yml
  • Windows: %APPDATA%/Shotgun/SITENAME/authentication.yml

툴킷 인증 라이브러리는 현재 사이트와 현재 사용자의 컨셉을 유지 관리합니다. 즉, 라이브러리를 사용하여 모든 응용프로그램과 세션에 동일한 로그인 자격 증명에 대한 액세스 권한이 있는 단일 로그온을 유지 관리할 수 있습니다.

다중 스레드 환경

비활성 상태가 일정 시간 동안 지속되어 세션 토큰이 만료되면 Shotgun 인증 라이브러리가 사용자에게 암호를 묻는 메시지를 표시합니다. 로그인할 때와 마찬가지로, 이 암호는 Shotgun 서버에 전송되고 유효한 새 세션 토큰으로 교환됩니다.

실제로 Shotgun 인증 라이브러리 user_object.create_sg_connection() 메서드에 의해 반환된 Shotgun API 핸들에는 세션 만료를 확인하는 래퍼 코드가 포함되어 있습니다. 세션 만료가 탐지될 때마다 사용자에게 다시 인증 후 작업을 다시 시도하라는 메시지가 표시됩니다.

다중 스레드 시나리오에서 여러 작업자 스레드가 Shotgun API 인스턴스를 유지하고 동시에 여러 스레드에서 세션 만료가 발생하는 경우 Shotgun 인증 라이브러리는 첫 번째 세션을 제외한 모든 스레드를 일시 중지하고 사용자에게 새 암호를 묻는 메시지를 표시합니다. 이 방법을 통해 사용자에게 메시지가 계속 표시되는 것을 방지할 수 있습니다. 사용자에게 메시지가 표시될 때마다 QT UI 코드는 항상 기본 스레드에서 실행됩니다.

툴킷 기술 상세 정보 및 추가 정보

Shotgun Pipeline Toolkit은 Python으로 작성되었으며(v2.6 이상, 3.x 제외) 본질적으로 클라이언트 컴퓨터에서 실행되는 일련의 스크립트입니다. 이 툴킷은 Linux, Windows 및 Macosx에서 작동합니다.

대부분의 에셋 관리 시스템에는 메타데이터 저장을 위한 데이터베이스가 있습니다. 툴킷에는 자체 데이터베이스가 없으며 저장 및 컨텍스트 관리에 Shotgun 데이터베이스가 사용됩니다. Core API에서 대부분의 작업은 Shotgun과 통신하는 대신 파일 시스템을 사용하여 경로와 데이터를 확인합니다.

Core API는 "주도적인 작업"을 시도하지 않으며 "양자택일"의 거래가 아닙니다. 대신, 스크립트와 아티스트에게 도움이 되는 보조적인 역할을 합니다. 에셋 관리에 대한 한 가지 일반적인 접근 방식은 파이프라인에서 파일 시스템과 데이터 흐름을 완전히 제어하는 것입니다. 파이프라인에서 진행되는 모든 작업을 파악함으로써 시스템은 매우 정확한 방식으로 컨텐츠 생성 및 처리를 트래킹할 수 있습니다. 그러나 이러한 접근 방식은 비용이 발생합니다. 완전한 소유권을 얻으려면 종종 기존 도구를 다시 작성해야 하며 여기에는 모든 데이터가 통과해야 하는 중심점이 필요합니다. 이 방식이 적절할 수도 있지만 툴킷은 소유권을 얻으려고 하지 않습니다. 대신, 툴킷은 데이터를 이해하고 보조적인 역할을 수행합니다. Shotgun 툴킷은 항목이 저장되는 디스크 위치를 알고 있으므로 아티스트와 개발자가 프로덕션 프로세스 전반에 걸쳐 공동 작업하고 구성하는 데 도움이 됩니다.

Shotgun 툴킷은 기존 파이프라인 설정 및 컨텐츠 트래킹 시스템과 함께 실행할 수 있습니다. 항목이 저장되는 디스크 위치를 공유하는 경우 툴킷에서 데이터를 교환할 수 있어야 합니다.

자세한 정보는 다음 문서를 확인하십시오.

Big Buck Bunny - footage 제공: (CC) Blender Foundation, www.blender.org
팔로우

0 댓글

댓글을 남기려면 로그인하세요.