본문 바로가기
Nuke/NDK

NDK - Versioning

by 르면가게 2024. 12. 7.

Plug-in Versioning

NDK (NUKE Developer Kit)에는 플러그인 버전 관리를 위한 명시적인 기능이 제공되지 않습니다. 따라서 여러 버전의 플러그인을 호환성 문제 없이 사용하는 방법에 대해 몇 가지 일반적인 접근 방식이 존재합니다. 이 섹션은 이러한 접근 방식을 설명하며, NDK를 처음 접하는 사람들에게는 필수적인 내용은 아니지만, 향후 개발 중 발생할 수 있는 문제를 이해하는 데 도움이 될 수 있습니다.

Ensuring Compatibility & Obsoleting

NUKE 스크립트 (.nk) 파일의 특징:

  • 플레인 텍스트 형식으로 저장
  • Node Graph(DAG)의 직렬화된 버전 포함
  • 기본값과 다른 UI 설정값만 저장 (최적화를 위해)
  • 노드와 노브(knob) 이름에 따라 값을 저장

버전 관리 기법:

  • 노드 이름은 유지하면서 버전 정보는 별도로 저장
    • tooltip이나 text knob에 버전 저장
  • 이전 버전과의 호환성 유지가 중요
    • 동일 입력값에 대해 동일 출력 보장 (버그 수정 제외)
  • 버전 확인 방법
    • hidden/disabled knob에 버전 저장 (ALWAYS_SAVE 플래그 사용)
    • 버전 정보가 없으면 이전 버전으로 간주

Obsolete_knob 사용 케이스:

  • UI 요소가 변경될 때 호환성 유지를 위해 사용
  • 주요 사용 사례:
    • 컨트롤 제거 시: 값 무시 (에러 방지를 위해 존재는 유지)
    • 컨트롤 이름 변경 시: 기존 값을 새 노브로 전달
    • 컨트롤 극성 변경 시: 저장된 값의 역을 새 노브에 설정

이러한 방식들은 스크립트 호환성을 유지하면서 소프트웨어를 발전시키기 위한 필수적인 기술적 해결책들입니다.

Breaking Compatibility & Appending Version Name

NUKE에서는 플러그인 버전 호환성을 관리하기 위해 두 가지 방법을 사용합니다:

1. 버전 유지:

  • 노드 이름에 버전 추가: 새 버전의 플러그인은 호환성을 깨지 않도록 노드 이름에 버전 번호를 추가합니다. 예를 들어, Merge 노드는 Merge와 Merge2로 나뉘며, Merge2는 새로운 기능을 가진 비호환 버전입니다.
  • UI 차별화: 노드 메뉴 항목은 기본 클래스와 다를 수 있으며, displayName을 사용하여 다른 이름을 표시할 수 있습니다. 예를 들어, Merge2는 기본적으로 "Merge"로 표시됩니다.
  • 여러 버전이 공존:
    • Merge (Merge1)
    • Merge2
  • 메뉴 표시 방식:
    • Merge [Merge]
    • Merge [M]
    • Merge2
  • 클래스명과 표시명의 분리
    • displayName() 함수로 노드 그래프상 표시명 지정
    • 예: Merge2 클래스가 "Merge"로 표시

2. 호환성 깨기:

  • 버전 관리 방식: 호환성을 의도적으로 깨고 플러그인 버전마다 다른 이름을 사용합니다. 예를 들어, Truelight3는 이전 버전과 호환되지 않으며, Tracker3는 오래된 Tracker를 대체하지만, 기존 스크립트에서 사용할 수 있도록 동일한 UI를 제공합니다.
  • 명시적인 버전 관리: 외부 번들에서는 <node name>_<major version>_<minor version> 형식으로 버전 정보를 포함하여 호환성을 명확하게 구분합니다.
  • Truelight:
    • Truelight3까지 발전
    • 이전 버전(1,2)은 64비트 라이브러리 지원 중단으로 제거
  • ColorCorrect:
    • CCorect의 후속 버전
    • 완전히 다른 이름 사용
  • Tracker:
    • 현재 Tracker3
    • 이전 버전과의 호환성을 위한 gizmo 제공

3. 수동 스크립트 업데이트:

  • 스크립트 수정: 사용자가 스크립트를 수동으로 수정하여 기존 버전의 클래스를 새로운 클래스로 교체할 수 있습니다. 하지만 이 경우 렌더링 결과가 달라질 수 있습니다.

4. 외부 플러그인의 버전 관리:

  • Ocula의 경우:
    • <노드이름><주버전><부버전> 형식 사용
    • 더 명시적인 버전 구분
  1. 수동 업데이트:
  • 사용자가 텍스트 에디터로 스크립트 수정 가능
  • 구 버전 클래스명을 새 버전으로 변경
  • 렌더링 결과 변경 가능성에 대한 인지 필요

이 방식은 기존 스크립트와 새 버전의 플러그인이 호환되도록 하며, 새 버전은 더 나은 기능을 제공하지만, 오래된 스크립트는 여전히 사용할 수 있도록 합니다.

DDImage Versioning

NUKE의 DDImage API 버전 관리에 대해 정리해드리겠습니다:

  1. API 변경 정책:
  • 주요 버전이나 부버전 변경 시 API가 변경됨
    • 예: 6.1v3 → 6.2v1 (재컴파일 필요)
  • 패치 버전 변경에서는 API 유지
    • 예: 6.2v1 → 6.2v2 (재컴파일 불필요)
  1. 버전 관리 도구:
  • ddImageVersionNumbers.h 헤더 파일 사용
  • 주요 매크로: kDDImageVersionInteger
  • 전처리기 지시문으로 버전별 코드 관리
  1. 코드 예시:
#if kDDImageVersionInteger >= 62100
    // NUKE 6.2v1 이상 버전용 API 호출
#elif kDDImageVersionInteger < 60100
    #error Pre NUKE 6.0 there was no equivalent call. Not supported.
#else// NUKE 6.0v1 ~ 6.2v1 버전용 API 호출
#endif
  1. 레거시 관련 주의사항:
  • ddImageVersion.h는 더 이상 사용하지 않음 (obsolete)
  • DD_IMAGE_VERSION_MAJOR, DD_IMAGE_VERSION_MINOR 등의 오래된 심볼 사용 지양
  • 최신 NUKE 버전에서는 이러한 레거시 심볼들이 영향을 미치지 않음

이러한 버전 관리 시스템은 플러그인 개발자들이 여러 NUKE 버전을 지원하면서도 코드베이스를 효율적으로 관리할 수 있게 해줍니다.

'Nuke > NDK' 카테고리의 다른 글

NDK - 2D Architecture  (0) 2024.12.07
NDK - Building & Installing Plug-ins  (0) 2024.12.07
NDK - 기본 개념  (0) 2024.12.07
NDK - 용어  (1) 2024.12.07