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의 경우:
- <노드이름><주버전><부버전> 형식 사용
- 더 명시적인 버전 구분
- 수동 업데이트:
- 사용자가 텍스트 에디터로 스크립트 수정 가능
- 구 버전 클래스명을 새 버전으로 변경
- 렌더링 결과 변경 가능성에 대한 인지 필요
이 방식은 기존 스크립트와 새 버전의 플러그인이 호환되도록 하며, 새 버전은 더 나은 기능을 제공하지만, 오래된 스크립트는 여전히 사용할 수 있도록 합니다.
DDImage Versioning
NUKE의 DDImage API 버전 관리에 대해 정리해드리겠습니다:
- API 변경 정책:
- 주요 버전이나 부버전 변경 시 API가 변경됨
- 예: 6.1v3 → 6.2v1 (재컴파일 필요)
- 패치 버전 변경에서는 API 유지
- 예: 6.2v1 → 6.2v2 (재컴파일 불필요)
- 버전 관리 도구:
- ddImageVersionNumbers.h 헤더 파일 사용
- 주요 매크로: kDDImageVersionInteger
- 전처리기 지시문으로 버전별 코드 관리
- 코드 예시:
#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
- 레거시 관련 주의사항:
- 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 |