전자상거래 3D 자산 최적화 파이프라인 자동화

CAD 프로그램에서 내보낸 3D 모델을 WebGL 또는 AR 서비스로 업로드하려고 시도한 적이 있다면 아마도 최대 파일 크기, 끝이 없는 진행률 표시줄 및 낮은 프레임 속도 문제에 직면했을 것입니다.

3D 데이터의 크기와 성능을 최적화하는 것은 좋은 온라인 대화형 경험을 제작하는 데 매우 중요합니다. 파일 크기가 작을수록 CDN을 통해 푸시하는 데 필요한 클라우드 스토리지와 데이터가 더 적기 때문에 수익성에도 좋습니다.

이 문서에서는 잘 시각화된 3D 모델을 생성하기 위해 자동화된 파이프라인을 설계하는 방법을 설명합니다. 이를 통해 최소한의 수동 노력으로 웹 및 AR에 사용할 수 있는 완전히 상세한 모델을 작성할 수 있습니다.

오프라인 렌더러에서 제작 또는 시각화하기 위해 3D 모델을 제작하는 경우 휴대용 장치, 웹 브라우저, AR 앱 및 기타 저사양 장치에 표시하는 데 적합하지 않은 경우가 많습니다. 이는 콘텐츠 제작 팀이 원활한 렌더링과 빠른 다운로드를 보장하기 위해 소스 자산을 최적화하거나 저가형 장치로 변환하는 데 많은 시간을 소비한다는 것을 의미합니다.

이 문서에서는 일반적인 3D 자산 최적화에 대해 다루고, 특히 이 프로세스가 Substance 재질 및 라이브러리와 상호 작용하는 방법을 다룹니다.

권장사항: NSDT 편집기를 사용하여 프로그래밍 가능한 3D 장면을 빠르게 구축하세요.

3D 모델을 수동으로 최적화하는 것은 지루하고 시간이 많이 소요될 뿐만 아니라 생산 과정에서 병목 현상이 발생하기 쉽습니다. 문제는 최적화가 본질적으로 소스 자산의 다운스트림이라는 것입니다. 즉, 소스 자산(3D 모델, 재료 등)에 대한 모든 변경 사항이 최적화된 자산에 반영되어야 함을 의미합니다. 따라서 최적화된 콘텐츠를 조기에 미리 볼 수 있는 것과 최적화하는 데 걸리는 시간 사이에는 갈등이 있습니다.

소스 모델이 제작 과정에서 여러 번 변경될 것으로 예상된다면 최종 마무리 후에 최적화하는 것이 더 효율적입니다.

이는 최적화를 자동화의 주요 목표로 만듭니다. 이곳은 예술적 표현을 위한 장소가 아닙니다. 자동화된 파이프라인은 자산 라이브러리의 모든 측면이 변경되는 시기를 감지하고 영향을 받는 자산을 다시 최적화합니다.

1. 3D 최적화 파이프라인 개요

전자상거래와 유사한 설정을 살펴보겠습니다.

소스 3D 모델은 CAD 패키지, DCC 패키지 등 다양한 위치에서 가져올 수 있습니다. 정점과 다각형 외에도 텍스처 UV 및 일반 정보도 있다고 가정합니다.

재료 라이브러리는 3D 모델의 소스 재료 세트입니다. 아래 이미지는 재료의 좋은 출발점이 되는 Substance Source에서 가져온 것입니다. 그러나 이러한 재료는 사내에서 제작할 수도 있고 실제 재료 샘플에서 생성할 수도 있습니다.

Substance의 재질은 절차적이므로 사용자가 매개변수를 설정하고 사전 설정을 정의할 수 있습니다. 머티리얼은 애플리케이션별 설정과 함께 머티리얼 인스턴스라고 불립니다. 예를 들어 동일한 가죽 재질을 빨간색과 파란색 가죽 재질로 인스턴스화할 수 있습니다.

재료를 선택한 후 이를 개체의 특정 부분에 할당합니다. 소파의 경우 쿠션에는 패브릭 소재를, 다리에는 금속 소재를 지정할 수 있습니다.

재질이 없는 모델(왼쪽)과 재질이 지정된 모델(오른쪽)

동일한 모델에 다양한 분포 구성이 있을 수도 있습니다. 이 예에서는 동일한 소파라도 패브릭과 가죽 쿠션이 다를 수 있습니다.

동일한 모델의 두 가지 재료 배열

1.1 출력 대상

장치마다 기능이 다르며 이전 세대 휴대폰의 브라우저에서 잘 작동했던 것이 고급 PC에서는 매우 다르게 작동할 수 있으므로 우리는 다양한 목적에 맞게 다양한 모델을 생산할 수 있기를 원했습니다.

가장 간단한 형태의 파이프라인은 다음과 같습니다.

이 프로세스는 처리 중인 하나의 모델을 보여 주지만, 아이디어는 여러 재료 구성의 여러 출력을 가진 여러 객체가 이 프로세스를 거치게 된다는 것입니다.

컨셉 파이프라인에는 모델 최적화와 머티리얼 적용이라는 두 단계가 있습니다. 모델 최적화는 이러한 단계 중 첫 번째 단계이며 재료 적용은 다운스트림에서 발생합니다. 즉, 3D 모델을 변경하면 재료의 최적화 및 재적용이 시작되지만 재최적화 없이 재료를 변경할 수 있습니다.

파이프라인은 단순화되었으며 실제 파이프라인에는 더 많은 단계와 종속성이 있을 수 있습니다.

1.2 효율적인 자동화를 위한 고려 사항

위와 같은 구조화된 파이프라인을 사용하면 최적화된 모델 생성 프로세스를 자동화할 수 있습니다. 즉, 제품 수명 전반에 걸쳐 최신 시각화 모델을 보유할 수 있습니다.

자산 파이프라인을 효과적으로 실행하려면 작업 간의 관계와 어떤 데이터가 어떤 출력에 영향을 미치는지 이해해야 합니다. 즉, 소스 데이터가 변경되면 무엇을 구축해야 하는지 빠르게 파악할 수 있습니다.

몇 가지 예:

• 재료 라이브러리의 재료가 변경되면 해당 재료를 사용하는 모든 출력을 다시 작성해야 합니다.
• 새 출력 대상을 추가할 때 해당 대상에 대해 모든 모델을 처리해야 합니다.
• 3D 모델이 변경되면 해당 모델에 대한 모든 대상의 모든 구성을 다시 작성해야 합니다.
• 자동화된 프로세스를 트리거하는 시기와 방법에는 결과가 얼마나 빨리 필요한지, 컴퓨팅 성능이 얼마나 많이 사용되는지 간의 균형이 필요합니다. 변경 사항이 있을 때마다 실행을 트리거하면 빠른 결과를 얻을 수 있지만 곧 다시 변경될 모델 작업에 많은 시간을 소비하게 될 수도 있습니다.

또 다른 접근 방식은 처리 능력을 더 많이 사용할 수 있거나 더 저렴할 때 밤에 프로세스를 실행하는 것입니다. 즉, 최신 모델이 매일 아침 준비되어야 함을 의미합니다.

또한 사용자가 모델 프로세스를 실행할 시기를 결정하여 필요할 때 최신 모델을 얻을 수 있도록 하는 것도 가능합니다.

3D 작업 흐름의 자동화 부분에서 흔히 발생하는 문제는 예술적 통제력 상실입니다. 자동화가 이루어지기 전에 모든 예술적 결정이 내려지기 때문에 이는 사실이 되어서는 안 됩니다. 최적화 단계는 .tiff 파일로 저장된 이미지를 웹 사이트에 배치하기 전에 .jpeg 형식으로 압축하는 것과 동일한 방식으로 보아야 합니다. 최적화 단계를 자동화하면 배포 모델을 최적화하는 데 시간을 소비할 필요가 없으므로 창의적인 작업에 더 많은 시간을 할애할 수 있습니다.

자동화된 솔루션을 사용할 때 주요 고려 사항은 수동 교정이 수행되는 방법과 시기입니다. 특정 모델에 대해 프로세스의 출력이 충분하지 않은 경우 본능적으로 생성된 출력 자산을 수정하는 경우가 많습니다. 이 접근 방식의 문제점은 자산이 변경될 때마다 수정 사항을 다시 적용해야 한다는 것입니다(변경 사항은 자동화 파이프라인의 다운스트림이므로). 일반적으로 모든 출력 조정은 다음에 파이프라인이 실행될 때 적용될 수 있도록 자동화 파이프라인의 설정으로 수행되어야 합니다. 모델이 최종 상태인지 확신하지 않는 한 수동 수정은 권장되지 않습니다.

조정하는 가장 좋은 방법은 레이어 설정을 재정의하는 것입니다. 파이프라인의 기본값은 자산별로 재정의될 수 있으므로 다른 자산에 영향을 주지 않고 성능이 떨어지는 자산에 대해 더 높은 품질 값을 설정할 수 있습니다.

2. 3D 모델을 최적화하는 이유는 무엇입니까?

입력 데이터의 최적화는 웹 및 휴대용 장치를 위한 우수한 3D 모델을 생성하는 데 중요합니다. 고급 렌더링을 위해 만들어진 CAD 모델이나 모델은 일반적으로 이러한 목적에 적합하기에는 너무 세밀하고 크기가 너무 큽니다.

최적화를 통해 개선하고 싶은 주요 사항은 다음과 같습니다.

• 렌더링 성능
• 배터리 수명
• 다운로드 크기
• 메모리 사용량

이러한 서로 다른 목표는 종종 일치합니다. 작은 모델은 일반적으로 더 빠르게 렌더링되고 장치의 배터리 전력을 더 적게 사용합니다.

2.1 최적화된 모델 평가

최적화 내용을 살펴보기 전에 결과의 시각적 품질을 평가하는 방법을 알고 있는지 확인하는 것이 중요합니다. 핵심은 항상 유용성 측면에서 모델을 평가하는 것입니다. 400x400픽셀 웹 뷰어나 휴대용 장치에서 보기 좋게 디자인된 모형을 만드는 경우 세부 사항을 보존하거나 확대하지 않으면 보이지 않는 아티팩트를 제거하기 위해 설정을 조정하는 데 시간을 투자한다는 것은 "우리는 너무 상세하고 너무 무거워서 다운로드할 수 없는 모델입니다.

렌더링 성능과 관련하여 벤치마킹 없이 무엇이 최상의 결과를 생성할지 예측하는 것이 항상 쉬운 것은 아니지만, 아래 설명된 대로 좋은 결과를 생성하는 경향이 있는 다양한 경험적 방법이 결합되어 있습니다. 또한 목표 프레임 속도와 다운로드 크기에 도달하더라도 사용량이 적은 GPU는 배터리를 덜 소모하므로 핸드헬드에서는 더 작고 빠른 것이 여전히 중요합니다. 게임 아티스트를 위한 GPU 성능 문서에서는 이 주제를 더 자세히 다루고 있으며 3D 모델을 빠르게 렌더링하는 방법을 이해하는 데 유용한 리소스입니다.

2.2 폴리곤의 수

다각형 수와 다각형 밀도는 모델을 빠르게 렌더링하고 빠르게 다운로드하는 데 중요한 부분입니다. 다각형과 정점이 많을수록 GPU가 이미지를 생성하기 위해 수행해야 하는 계산이 더 많아집니다.

GPU는 일반적으로 더 크고 균일한 크기의 다각형을 렌더링하는 데 더 적합합니다. GPU는 병렬성이 뛰어나고 더 큰 다각형에 최적화되어 있습니다. 다각형이 더 작고 얇을수록 음영처리된 영역에서 더 많은 평행성이 낭비됩니다. 이 문제는 과채색으로 알려져 있으며 위에 링크된 기사에서 다룹니다.

일반적으로 결과 모델의 와이어프레임을 살펴보고, 보려는 크기로 모델을 시각화할 때 와이어프레임이 너무 조밀하지 않은지 확인하는 것이 가장 좋습니다.

디테일을 희생하지 않고 다각형 수를 줄이는 효과적인 방법은 노멀 맵을 사용하는 것입니다. 아이디어는 우리가 물체의 실루엣이 상호 작용하는 방식보다 빛이 물체와 상호 작용하는 방식에 더 민감하다는 것입니다. 이는 세부 사항을 삼각형 데이터에서 일반 맵으로(즉, 모델에서 텍스처로) 이동할 수 있고 더 큰 다각형을 사용하면서도 조명의 원시 데이터에서 세부 사항을 얻을 수 있음을 의미합니다.

다음은 원본 모델의 세부 정보가 포함된 노멀 맵(왼쪽) 및 (오른쪽) 없이 최적화된 동일한 모델입니다.

대부분의 작은 디테일이 노멀 맵에 있는 수준으로 모델을 최적화하면 메시가 더 나은 UV 맵을 가질 수 있습니다. UV 맵을 생성할 때 작은 세부 사항과 날카로운 모서리가 문제가 되는 경우가 많습니다. 단순한 모델은 큰 다이어그램이 적고, 낭비되는 채우기 공간이 적으며, 눈에 보이는 이음새가 적은 경향이 있습니다. 이는 자동 UV 매핑 모델에서 문제가 될 수 있습니다.

2.3 GPU 드로우 콜

그리기 호출은 객체를 렌더링하기 위해 렌더러가 GPU와 통신해야 하는 횟수를 나타냅니다. 일반적으로 한 개체에서 다른 개체로 전환하거나 다른 텍스처를 사용하려고 할 때마다 GPU에 알림이 필요합니다. 즉, 동일한 모델이 하나의 메시와 하나의 텍스처 세트로만 구성된 경우 여러 부분으로 분할되거나 다양한 재료를 사용하는 객체는 렌더링하는 데 더 많은 비용이 듭니다.

2.4 텍스처 해상도

GPU는 모델의 보기 크기에 적합한 해상도의 텍스처를 선택하고 너무 높은 텍스처 해상도 사용과 관련된 성능 및 품질 문제를 피하는 데 능숙합니다. 전송된 모델의 보기 제한으로 인해 불필요하게 고해상도 텍스처가 포함되기 쉽습니다. 실제로는 전체 해상도로 표시되지 않으므로 사용자에게 불필요한 다운로드 시간이 발생합니다.

2.5 오버드로

오버드로우는 다른 폴리곤 뒤에 있는 폴리곤을 렌더링할 때 발생합니다. 대부분의 객체에서는 일부 오버드로가 불가피합니다. 그러나 간단한 보기 시나리오의 경우 사용자가 모델과 상호 작용하는 방식에 관계없이 결코 표시되지 않는 다각형이 있을 수도 있습니다. 예를 들어, 소파 프레임 위에 시트 쿠션이 별도의 개체로 배치된 소파를 상상해 보세요. 사용자가 쿠션을 제거할 수 없는 경우, 쿠션의 바닥과 쿠션이 얹혀지는 프레임 부분이 전혀 보이지 않습니다.

좋은 최적화 솔루션은 이러한 불필요한 영역을 식별하고 제거하여 보이지 않는 영역의 다각형을 다운로드하거나 렌더링할 필요가 없도록 할 수 있습니다. 더욱이 많은 텍스처 장면에서 텍스처 이미지 공간은 이러한 보이지 않는 다각형에 할당됩니다. 즉, 텍스처 데이터를 낭비하고 다운로드 크기에 부정적인 영향을 미치며 실제로 보이는 영역의 텍스처 해상도를 줄이게 됩니다.

2.6 지적재산권 보호에 있어 모델 최적화의 역할

마지막으로, CAD 프로그램에서 생성된 데이터로 작업할 때 3D 모델에는 제품 제작 방법에 대한 세부 정보가 포함되는 경우가 많습니다. 최적화된 솔루션은 내부 개체를 제거하고 작은 세부 사항을 노멀 맵과 텍스처 정보로 변환합니다. 이로 인해 시각화에만 사용되는 모델에서 제품을 리버스 엔지니어링하기가 어렵습니다.

3. 좋은 파이프라인의 기초

위의 모든 사항을 포함하는 자동화된 파이프라인을 구현하는 것은 어려운 작업이 될 수 있습니다. 그러나 기본 사항을 올바르게 이해하면 나중에 많은 어려움을 겪을 수 있습니다.

3.1 데이터 레이아웃

성공적인 자동화 노력의 전제 조건은 데이터에 대한 구조화된 접근 방식입니다. 사용된 재료 라이브러리와 어떤 재료가 어떤 개체에 할당되었는지에 대한 명확한 아이디어를 갖는 것이 중요합니다. 또한 이 자료를 파이프라인에 표시하려고 합니다. 이렇게 하면 파이프라인이 변경 사항을 추적할 수 있으므로 변경되지 않은 항목을 재처리하는 데 시간을 낭비하지 않아도 됩니다.

추가 공유 네트워크 드라이브(또는 기타 잠재적 위치)를 마운트하지 않고도 전체 소스 자산을 찾을 수 있도록 모든 데이터는 일부 중앙 저장소에 저장되어야 하며 해당 저장소 외부의 데이터에 대한 참조를 허용하지 않아야 합니다. 데이터 형식을 선택할 때 추적에 도움이 되도록 독립형이어야 하거나 다른 파일에 대한 참조에 쉽게 액세스할 수 있어야 합니다.

3.2 의존성 추적

자산 간 관계를 추적하면 변경된 내용만 재구축할 수 있습니다. 종속성 추적 및 작업 실행이 더 세분화될수록 증분 자산 빌드는 더 작아집니다.

예를 들어 종속성 추적이 재료 라이브러리를 단일 불투명 엔터티로 처리한다고 가정합니다. 재료를 변경하면 모든 재료 데이터를 최신 상태로 유지하기 위해 모든 모델을 강제로 다시 빌드하게 됩니다. 개별 재료 변경 사항을 추적하면 수정된 재료를 사용하는 개체만 다시 만들 수 있습니다.

3.3 실행

종속성을 해결한 후에는 결국 원하는 출력을 생성하기 위해 여러 빌드 작업을 수행해야 합니다. 이러한 작업은 대개 독립적이며 병렬로 실행될 수 있습니다. 이는 빌드 프로세스가 여러 CPU 또는 시스템에 걸쳐 확장될 수 있음을 의미합니다. 실행 부분에는 이러한 작업을 예약하고 원하는 출력을 생성하기 위해 적절한 도구가 호출되는지 확인하는 작업이 포함됩니다.

최적화 파이프라인에서 수행되는 작업의 예는 다음과 같습니다.

• 그리드 최적화
• 텍스처 렌더링
• 텍스처 압축
• 장면 조립

3.4 캐싱

빌드 프로세스 중 중간 결과를 캐시하여 증분 빌드 속도를 높일 수 있습니다. 예를 들어 최적화된 로우 폴리 출력이 있습니다. 배포 준비가 완료되기 전에 텍스처를 적용해야 하므로 자산으로 직접 작동하지 않을 수 있습니다. 그러나 이 로우 폴리 자산은 중간 단계로 캐시될 수 있습니다. 이렇게 하면 자산에 사용된 재질이 업데이트될 때 다시 제작할 필요가 없으며 재최적화를 방지하기 위해 프로세스를 단순화할 수 있습니다.

캐싱은 다시 만들 수 없는 데이터를 손실하지 않고 캐시를 지울 수 있으므로 이 문제에 대한 편리한 솔루션입니다. 이렇게 하면 증분 빌드 성능과 임시 데이터 저장소 간의 적절한 균형을 유지하기 위해 크기를 지속적으로 줄일 수 있습니다.

4. 3D 자산 최적화 파이프라인의 예

다소 추상적인 이 기사에 구체적인 내용을 제공하기 위해 자산 최적화 파이프라인의 간단한 구현을 구축하기로 결정했습니다.

여기서 나의 목표는 파이프라인의 다양한 측면을 보여주는 것입니다. 특히 Substance의 재질이 자산 최적화 작업 흐름에 어떻게 참여하는지 보여주는 데 중점을 둡니다.

이 파이프라인의 목표는 고해상도 3D 가구 모델을 가져와 작고 빠르게 렌더링할 수 있는 모델을 자동으로 생성하는 것입니다. 파이프라인은 주로 Python으로 구현되며 단일 Windows 시스템에서 기본적으로 실행되도록 설계되었습니다.

설명된 원래 파이프라인은 다음과 같습니다.

처리 상자에 세부 정보를 추가하면 다음과 같은 결과를 얻습니다.

다음은 예제 파이프라인을 통해 최적화된 단일 모델의 개요입니다. 이 파이프라인은 여러 모델과 동일한 모델의 여러 질량에 적용될 수 있습니다. 파생 자산은 증분 빌드 속도를 높이기 위해 빌드 시스템에서 캐시할 수 있는 중간 출력을 나타냅니다.

4.1 데이터

이 파이프라인의 데이터는 최대한 단순하게 유지하기 위한 디스크의 파일 세트입니다. 그들은 다음과 같이 나뉩니다:

• 메시: .obj 파일
• 소스 자료: 물질 .sbsar 파일
• 재료 라이브러리: .sbsar 파일을 참조하는 .json 파일과 사전 설정, 매개변수 및 재료 배율 선택을 위한 추가 설정입니다.
• 재료 할당: 모델의 일부를 각 모델의 재료 인스턴스 및 스케일과 연결하는 .json 파일입니다.
• 파이프라인: 최적화된 대상 프로필(예: 모바일, VR 등)을 설명하는 .json 문서입니다.
• 작업: 최적화할 모델, 사용할 재료 배열, 출력을 생성할 파이프라인을 설명하는 .json 문서입니다.

4.2 메시 파일 형식의 OBJ

기하학에 .obj 파일을 사용하는 이유는 단순성 때문입니다. 쉽게 만들고 공유할 수 있습니다. 텍스트 기반이므로 어떤 이유로 그룹 이름이 누락되거나 잘못된 경우에도 쉽게 편집할 수 있습니다.

파이프라인의 메시에 대한 주요 제한 사항은 UV 차트가 UV 페이지에 맞아야 한다는 것입니다. 모양의 재료를 타일링하는 데 사용할 수 없지만 원하는 경우 겹치거나 다른 페이지에 있을 수 있습니다. 이상적으로 모든 UV 차트의 크기는 모델의 월드 공간 크기를 기준으로 조정되어야 텍스처가 모든 부분에 동일한 비율로 적용됩니다.

아래에서는 동일한 모델의 두 가지 다른 UV 레이아웃을 볼 수 있습니다. 왼쪽 레이아웃은 그래프가 UV 타일 경계를 교차하기 때문에 문제를 일으키는 반면, 오른쪽 레이아웃은 정상적으로 작동합니다.

4.3 재료 라이브러리

사용된 재료 라이브러리 형식은 .obj의 MTL 형식이 아닌 사용자 정의 .json 파일입니다. MTL 형식은 Substance 재질 바인딩이나 절차적 매개변수 설정을 지원하지 않으므로 이러한 기능을 갖춘 간단한 사용자 정의 형식을 도입하기로 결정했습니다.

다음은 재료 라이브러리의 재료 인스턴스 예입니다.

{ 
   // ... 
   // Leather is the name of the instance 
   "Leather": { 
        // sbsar file referenced 
        "sbsar": "${assets}/material_library/sbsar/Sofa_Leather.sbsar", 
        "parameters": { 
            // These are parameters on the sbsar 
            "normal_format": 1, 
            "Albedo_Color": [ 
                0.160, 
                0.160, 
                0.160, 
                1 
            ], 
            "Roughness_Base": 0.353 
        }, 
        "scale": [ 
            // A material relative scale for the UV 
            20.0, 
            20.0 
        ] 
    } 
    // Additional material instances 
    // ... 
} 

예제 파이프라인에서 모든 재질 인스턴스는 단일 재질 라이브러리 파일에 저장됩니다.

이러한 재질은 다음 맵을 사용하여 PBR 금속 거칠기를 기반으로 합니다.

• 기본 색상: 기본 색상 맵
• 노멀: 노멀 맵
• 거칠기: 거칠기 맵
• 메탈릭: 메탈릭 맵

4.4 재료 할당

재료 할당은 모델의 부품을 특정 재료 인스턴스와 연결하는 별도의 파일입니다. 재질 할당에는 모델별 배율 요소도 포함되어 있어 서로 다른 모델 간의 텍스처 그래프 배율 차이를 보상합니다.

형상에서 재료 할당을 분리하면 사용자가 동일한 모델에 다른 재료 구성을 할당하거나 동일한 그룹 이름을 공유하는 모델 간에 재료 구성을 공유할 수 있습니다.

다음은 재료 할당 구성의 예입니다.

{ 
    // Legs is the name of the part in OBJ file 
    // If similar scenes share part names the same  
    // material assignment file can be used for all of them 
    "Legs": { 
        // Material refers to a material instance 
        // in the library 
        "material": "Metal", 
        // Scale is the scale of the material associated with this 
        // part. It will be multiplied by the scale from the  
        // material instance 
        "scale": [ 
            1.0, 
            1.0 
        ] 
    }, 
    // Additional assignments to other parts 
    "Cushions": { 
        "material": "Leather", 
        "scale": [ 
            1.0, 
            1.0 
        ] 
    }, 
    "Frame": { 
        "material": "Wood", 
        "scale": [ 
            1.0, 
            1.0 
        ] 
    } 
} 

4.5 출력 형식으로서의 GLB

.glb 파일은 메시 데이터, 장면 데이터 및 텍스처가 단일 파일로 압축되는 .gltf 버전입니다. 저는 이 프로세스의 출력 형식으로 .glb를 사용합니다. 이는 메시, 재료 및 생성된 모든 텍스처를 압축한 파일로 표현하고 웹 및 모바일 3D 뷰어에 대한 광범위한 업계 지원을 제공하기 때문입니다.

4.6 파이프라인 정의

파이프라인은 특정 대상 하드웨어에 대해 수행될 최적화의 다양한 측면을 설명합니다.

예시 파이프라인은 다음과 같습니다.

{ 
    "import": { 
        // Resolution for reference source textures 
        // Insufficient resolution in the source textures 
        // will come out as blurry areas in the model 
        // Must be an integer power of 2 
        "material_resolution": 2048 
    }, 
    "reference": { 
        // Enable or disable reference model 
        // creation 
        "enable": true 
    }, 
    "optimize": { 
        // Target size in pixels for which the model 
        // quality should be optimized. Anything above 
        // 2000 will be very time consuming to produce 
        "screen_size": 600, 
        // Resolution for the utility maps for the model 
        "texture_resolution": 1024, 
        // Bake tangent space using Substance Automation 
        // Toolkit if true, use Simplygon if false 
        "bake_tangent_space_SAT": true, 
        "remeshing_settings": { 
            // Angle in degrees between surfaces in  
            // a vertex to split it with discrete  
            // normals  
            "hard_edge_angle": 75 
        }, 
        "parameterizer_settings": { 
            // How much stretching is allowed inside 
            // a chart in the generated UV layout for 
            // the model 
            "max_stretch": 0.33, 
            // How prioritized large charts are for the 
            // UV layout  
            "large_charts_importance": 0.2 
        } 
    }, 
    "render": { 
        // Texture resolution for the atlas 
        // for the optimized model. Should typically 
        // be the same as the texture_resolution in  
        // optimize 
        "texture_resolution": 1024, 
        // Offset for mip map selection. 0 is default, 
        // Negative values gives sharper and noisier results 
        // Positive values give blurrier results 
        "mip_bias": 0, 
        // Enable FXAA post processing on the map to give 
        // smoother edges between different materials 
        // (doesn't apply to normal maps) 
        "enable_fxaa": true, 
        // Blurring of the material id mask before compositing  
        // to give smoother borders between materials  
        // (doesn't apply to the normal map) 
        "mask_blur": 0.25, 
        // Enable FXAA post processing on the normal map to  
        // give smoother edges between different materials 
        "enable_fxaa_normal": true, 
        // Blurring of the material id mask before compositing  
        // the normal map to give smoother borders between  
        // materials  
        "mask_blur_normal": 0.25, 
        // Clean up edges around charts on normal maps 
        "edge_clean_normal_maps": false, 
        // Normal map output format and filtering 
        // For most cases 8 bpp is enough but 
        // for low roughness and 16bpp is needed to avoid 
        // artifacts 
        "output_normal_map_bpp": 8, 
        // Enable dithering for the normal map. Typically only 
        // relevant for 8 bpp maps 
        "enable_normal_map_dithering": true, 
        // Dithering intensity. Represents 1/x. Use 256 to 
        // get one bit of noise for an 8bpp map 
        "normal_map_dithering_range": 256, 
        // Paths to tools for compositing materials and 
        // transforming normal maps 
        "tools": { 
            "transfer_texture": "${tools}/MultiMapBlend.sbsar", 
            "transform_normals": "${tools}/transform_tangents.sbsar" 
        } 
    } 
} 

4.7 숙제

작업은 모든 모델, 재료 할당 및 파이프라인 프로세스를 지정하기 위한 시작점입니다. 다음은 작업의 예입니다.

{ 
    // Scenes to optimize 
    "scenes": { 
        "sofa-a1": { 
            // OBJ file with geometry in 
            "mesh": "${assets}/meshes/sofa-a1.obj", 
            // Different material variations to produce for this model 
            "material_variations": { 
                // These are references to material assignment files 
                "sofa-a1-leather": "${assets}/material_bindings/leather.json", 
                "sofa-a1-fabric": "${assets}/material_bindings/fabric.json" 
            } 
        }, 
        // Additional scenes goes here 
        // ... 
    }, 
    // The material library with material instances in to use 
    "material_library": "${assets}/material_library/material_library.json", 
    "pipelines": { 
        // A pipeline to run for the scenes 
        "lq": { 
            // Reference to the definition file 
            "definition": "${assets}/pipelines/lq.json", 
            // Paths for reference models and optimized models for 
            // this pipeline 
            "output_reference": "${outputs}/lq/reference", 
            "output_optimized": "${outputs}/lq/optimized" 
        }, 
        // Additional pipelines to run 
        // ... 
    } 
} 

4.8 파이프라인의 핵심 언어인 Python

Python은 파이프라인을 구현하는 데 사용됩니다. 널리 지원되는 언어이며 많은 문제를 즉시 해결할 수 있는 기능을 갖추고 있습니다. 프로세스에서 여러 도구에 대한 바인딩을 사용하여 다른 애플리케이션에 대한 브리지를 만드는 대신 파이프라인 구축에 쉽게 집중하고 싶습니다.

4.9 SCons 종속성 추적 및 실행

파이프라인에 사용되는 종속성 추적 및 실행 시스템은 SCons 빌드 시스템입니다. 종속성을 추적하고 마지막 빌드 이후 변경된 데이터만 다시 빌드하여 증분 빌드 비용을 최소화하려고 시도하는 Python 기반 빌드 시스템입니다. 이는 실행자로 작동하고 중간 결과의 캐싱도 수행함을 의미합니다.

Python 기반 빌드 시스템을 사용하면 빌드 작업과의 상호 작용이 간단해지기 때문에 편리합니다. pip 모듈 시스템에서도 사용 가능하며, Python 환경을 갖춘 사람이라면 누구나 쉽게 설치할 수 있습니다.

또한 파이프라인은 Python 스크립트로 직접 실행을 지원하므로 디버깅이 더 쉽습니다. 스크립트에서 파이프라인을 직접 실행하는 경우 각 실행이 처음부터 다시 빌드되며 독립적인 작업을 병렬로 처리하지 않습니다.

4.10 다각형 최적화

최적화를 위해 Simplygon의 Remesher 2.0을 사용합니다. Simplygon은 게임 산업에서 다각형 최적화의 표준으로 간주되며 많은 제어를 통해 매우 컴팩트한 메시를 생성할 수 있습니다. 여기에는 다양한 시나리오에 적용할 수 있는 여러 가지 최적화 전략이 있지만 단순화를 위해 파이프라인에 대해 하나를 선택했습니다.

리메스터에는 메시를 최적화하는 데 필요한 많은 속성이 있습니다.

• 모델을 적극적으로 최적화하며 올바르게 사용하면 훨씬 적은 수의 다각형을 사용하여 좋은 결과를 얻을 수 있는 경우가 많습니다.
• 모델의 모든 내부 형상을 정리하고, 오버드로 및 보이지 않는 표면에 대한 텍스처 할당을 줄이며, 모델에서 관련이 없거나 독점 정보를 제거합니다.
• 전체 모델에 대한 새로운 텍스처 아틀라스를 생성합니다. 즉, 모델이 원래 어떻게 설정되었는지에 관계없이 단일 드로우 콜과 동일한 양의 텍스처 데이터로 렌더링할 수 있습니다.
• 소스 메시의 텍스처, 노멀 등이 최적화된 모델에 정확하고 고품질로 전달될 수 있도록 소스 메시에서 대상 메시로의 매핑을 생성합니다.
• 특정 보기 크기에 맞게 최적화할 수 있습니다. 특정 크기나 해상도의 뷰어에서 예측 가능한 품질로 모델을 표시하려는 경우 이 정보를 대상 해상도로 제공할 수 있습니다. 결과는 해당 크기에 맞는 모델이 됩니다. 리메스터라이저는 이 특정 품질에 대한 텍스처 크기를 제안할 수도 있지만 이 기능은 이 파이프라인에서 사용되지 않습니다.
• 저는 과거에 Simplygon에서 일한 적이 있습니다. 따라서 이 경우 Remesher 2.0을 사용하는 이유 중 하나는 Remesher 2.0이 생성하는 결과 유형과 더 잘 작동하도록 도구를 구성하는 방법에 매우 익숙하기 때문입니다. 그것으로.

Simplygon에는 이 파이프라인에 적합한 다음과 같은 속성도 있습니다.

• 여기에는 모든 최적화 및 장면 생성을 구동하는 Python API가 있어 Python으로 생성된 나머지 파이프라인과 도구를 쉽게 통합할 수 있습니다.
• .obj 및 .glb 파일을 읽고 쓸 수 있습니다. 이는 재료와 텍스처가 관리되는 방법에 대한 많은 제어를 제공하므로 이 도구를 사용하여 사용자 정의 재료가 포함된 소스 데이터를 읽고 Substance를 사용하여 생성된 텍스처가 포함된 .glb 파일을 작성할 수 있습니다.

리메싱은 멀리서 본 모델에 매우 효과적인 공격적인 최적화 기술입니다. 그러나 객체 윤곽선과 메쉬 토폴로지에 큰 영향을 미칠 수 있으므로 너무 자세히 검사해야 하는 모델에는 적합하지 않습니다. 따라서 모든 시각화 시나리오에 적합한 솔루션이 아닐 수도 있습니다. 특히 여기에 사용된 구현은 투명성을 제대로 처리하지 못하므로 이 파이프라인에서는 이를 피해야 합니다. 객체의 메쉬 토폴로지를 깨면 애니메이션 등을 위해 분리된 부분이 합쳐질 수 있으므로 이 경우에는 특별한 주의가 필요합니다.

다른 3D 최적화 솔루션도 많이 있지만 기능이 많고 이전 경험이 있기 때문에 Simplygon을 자연스럽게 선택했습니다.

4.11 최적화된 모델 텍스처링

소스 메시의 텍스처를 최적화된 메시에 적용하기 위해 Substance Automation Toolkit을 사용하고 있습니다.

Substance Automation Toolkit을 사용하면 Substance Designer를 사용하여 텍스처 전송 프로세스에 사용되는 모든 작업을 구축하고 파이프라인의 Python 스크립트에서 호출할 수 있었습니다. 또한 텍스처 생성에서 최적화를 두 개의 개별 단계로 분리할 수 있습니다. 즉, SCons는 중간 파일을 독립적으로 추적할 수 있습니다. 이렇게 하면 모델이 동일하게 유지되는 한 재료 데이터의 변경으로 인해 형상 최적화가 트리거되지 않습니다. 최적화 자체는 머티리얼과 별개입니다.

4.12 3D 자산의 형식 변환

때로는 .obj 또는 .gltf를 DAE, GLB, PLY 등과 같은 다른 형식의 3D 자산으로 변환해야 할 수도 있습니다. 강력한 온라인 3D 형식 변환 도구인 NSDT 3DConvert를 최적화 파이프라인에 추가하는 것을 고려할 수 있습니다.

5. 파이프라인

파이프라인은 다음 단계로 구성됩니다.

5.1 텍스처 렌더링

이 단계에서는 처리된 모든 모델의 재료 리그를 살펴보고 사용된 모든 재료의 Substance PBR 이미지를 렌더링합니다.

5.2 참조 모델 생성

참조 단계에서는 원본 모델을 렌더 텍스처와 결합하여 참조 .glb 파일을 생성합니다.

이 참조 .glb 파일은 다운스트림으로 사용되지 않지만 "이전" 및 "이후" 영상을 위한 좋은 리소스입니다. 또한 최적화 중에 출력 문제가 발생했는지 아니면 소스 데이터에 문제가 발생했는지 디버깅하는 데 도움이 됩니다.

위의 .obj 섹션에 설명된 입력 UV 좌표의 제한으로 인해 UV 차트는 재질 규모 및 할당 규모에 따라 크기가 조정됩니다. 이렇게 하면 텍스처가 최적화된 모델과 동일한 크기를 갖게 됩니다.

5.3 최적화

최적화 단계에서는 소스 모델을 로드하고 Simplygon을 사용하여 리메싱 프로세스를 실행합니다. 이 과정에서 모델은 원래 UV 세트와 관련 없는 새로운 UV 세트를 얻게 됩니다.

리메싱을 수행하는 것 외에도 Simplygon Geometry Casters를 사용하여 텍스처 세트를 생성하고 소스 모델의 텍스처 데이터를 최적화된 모델로 전송합니다. 이러한 맵은 최적화된 모델의 새로운 UV 공간에 표시됩니다.

• 재료 ID. 이 맵은 각 텍셀의 재질 인덱스를 인코딩합니다. 이 맵을 통해 원본 모델의 어느 지점에 어떤 재료를 할당할지 결정할 수 있습니다.
  

• UV. 이 맵은 최적화된 모델의 텍스처 공간에서 소스 모델의 UV 좌표를 인코딩합니다. 이 맵을 사용하면 데이터를 최적화된 모델로 전송하기 위해 소스 모델의 텍스처에서 어디를 볼 것인지 결정할 수 있습니다.

이 맵은 0-1 사이의 16bpp 맵이므로 UV를 사용하여 재질을 타일링할 수 없습니다. 할당된 재질 타일은 텍스처 렌더링 단계에 적용됩니다.

UV 리매핑 텍스처를 사용하면 하이 폴리 모델에서 UV 좌표를 찾을 수 있으므로 원래 UV로 최적화된 모델을 텍스처링할 수 있습니다.

• 최적화된 모델의 UV 공간으로 표현되는 소스 모델의 주변 폐색. 주변 폐색은 소스 모델의 세부 정보를 사용하여 생성되므로 최적화에서 손실될 수 있는 영역을 가려 손실된 형상에 대한 시각적 단서를 제공합니다.
• 최적화된 모델의 UV 공간에 있는 소스 모델의 월드 공간 법선 및 접선입니다. 이 두 맵을 사용하여 원본 모델의 누락된 법선을 캡처하고 추가 처리를 위해 소스 모델에 적용된 접선 공간 법선 맵을 월드 공간으로 전송할 수 있습니다.
• 모델의 월드 공간 법선과 접선을 최적화합니다. 이러한 맵을 사용하면 소스 모델의 법선을 최적화된 모델의 접선 공간 법선 맵으로 전송할 수 있으며 소스 메시 법선과 여기에 적용된 접선 공간 법선 맵을 모두 캡처할 수 있습니다.

5.4 모델의 텍스처 렌더링 최적화

이 단계는 Substance Automation Toolkit을 사용하여 소스 모델에서 모든 소스 재질 맵을 전송하는 다단계 프로세스입니다. 물질 그래프는 처리 시 형상을 포함할 수 없으므로 물질 전달을 위해 최적화 단계의 그래프를 사용합니다. 기본 프로세스는 UV 전송 맵을 사용하여 샘플 위치를 선택하고 재질 ID 맵을 기반으로 텍스처를 선택합니다.

유틸리티 및 재료 맵 외에도 이 단계에서는 타일링 및 필터링을 제어하기 위해 밉맵과 관련된 각 재료의 크기 및 매개변수를 입력으로 사용합니다.

노멀 맵의 경우 소스 텍스처 공간 노멀 맵을 샘플링해야 할 뿐만 아니라 최적화된 모델을 위한 탄젠트 공간 노멀 맵을 생성하기 위해 소스 및 대상 메시의 노멀과 탄젠트도 포함해야 하기 때문에 프로세스가 더 복잡합니다.

전체 프로세스는 배포 이후까지 지연될 수 있습니다. 모델이 재료 프로파일링 장면에서 사용될 경우 서버의 Substance 엔진 또는 Substance Automation Toolkit을 사용하여 이 프로세스를 실행하여 사용자 입력을 기반으로 필요에 따라 이미지를 생성할 수 있습니다. 이는 전체 최적화를 실행하는 것보다 훨씬 빠릅니다. 관로.

5.5 최종 장면 조립

장면 구성 요소는 Simplygon을 사용하여 최적화된 형상을 로드하고 재료와 함께 .glb 파일을 저장하기 위한 새 렌더 맵을 할당합니다.

5.6 작업 처리 구현

작업 처리는 작업, 파이프라인, 재료 라이브러리 등에 대한 모든 종속성을 이해하고 추적하는 Python 스크립트로 구현됩니다.

다양한 빌드 단계는 별도의 Python 파일이며 파이프라인은 각 단계에 관련 매개변수와 입력 파일을 적용합니다. 파일 및 매개변수의 내용은 캐시 키 역할을 합니다. 즉, 마지막 실행 이후 변경된 내용이 없으면 다시 작성하는 대신 이전 결과를 재사용할 수 있습니다.

이는 불필요한 재처리를 피하기 위해 각 작업에 가장 작은 매개변수 세트를 적용하려고 한다는 의미입니다. 데이터를 프루닝하는 방법의 예로, 객체에 사용된 머티리얼 할당 파일에서 참조된 머티리얼 인스턴스만 매개변수로 적용되어, 처리 중인 모델에서 참조한 머티리얼 인스턴스에 대한 변경 사항만 새 빌드를 트리거하도록 보장합니다.

처리 스크립트는 두 가지 방법으로 실행할 수 있습니다.

• 빌드 모드. 이 모드에서는 모든 빌드 작업을 인식하고 Python에서 직접 실행합니다. 이는 캐싱을 고려하지 않으며 실행될 때마다 전체 파이프라인이 재평가됩니다.
• 드라이 런 모드. 이 모드에서는 모든 종속성 해결이 수행되지만 파이프라인을 실행하는 대신 해당 매개변수와 지정된 모든 입력 및 출력 파일이 포함된 빌드 작업 목록이 생성됩니다.
  테스트 실행 모드의 출력은 모든 빌드 시스템에서 사용될 수 있으며, 그런 다음 종속성 순서에 따라 결과를 병렬로 빌드할 수 있습니다.

5.7 SCons 각본

SCons 스크립트는 테스트 실행 모드에서 파이프라인을 실행하고 출력을 사용하여 모든 빌드 작업을 지정합니다.

작업을 수행하기 위해 Python 스크립트가 빌드 모드에서 사용하는 것과 동일한 빌드 작업을 사용합니다. 그런 다음 SCons는 어떤 작업이 독립적인지 식별하고 빌드가 빠르게 실행되도록 가능한 한 많은 작업을 병렬로 실행하려고 시도합니다. 또한 이미 최신 상태인 대상을 식별하고 변경된 대상만 빌드되도록 변경되지 않은 상태로 유지합니다.

5.8 코드 패키지

파이프라인 코드는 Substance Share에서 찾을 수 있습니다. 패키지에는 설치 및 실행 지침이 포함되어 있으므로 파이프라인을 직접 탐색할 수 있습니다.

6. 결과

6.1 출력 모델

여기서 비교는 생성된 참조 모델과 최적화된 모델을 비교하는 것입니다.

텍스처 밀도가 참조 모델에서 상당히 높기 때문에 이는 반드시 유사한 비교는 아니지만 모델 간의 차이에 대한 추정치를 제공해야 합니다. 또한 최적화나 텍스처링 프로세스가 결정적이지 않기 때문에 귀하의 실행과 우리의 실행 사이의 숫자가 동일하지 않을 수 있습니다.

6.2 샘플 라인

이 공정에는 LQ와 HQ라는 두 개의 라인이 있는데, 각각 저품질 라인과 고품질 라인입니다. LQ는 썸네일 크기 모델과 함께 사용하도록 적극적으로 최적화되었습니다. HQ는 600x600 픽셀 뷰어용입니다.

모델을 확인하세요:

6.3 다각형의 수

모델	다각형 개수	본부 폴리곤 수	LQ 다각형 수
소파 A1	96948	2226	256
소파 A2	133998	1496	168
소파 B1	740748	2628	238
소파B2	1009690	1556년	118

보시다시피, 최적화된 모델의 다각형 개수는 훨씬 더 적습니다. 또한 밀도가 높은 소스 모델은 낮은 소스 모델보다 훨씬 더 많은 다각형 수를 생성하지 않습니다. 이는 원래 다각형 개수가 아닌 대상 화면 크기의 백분율에 맞게 최적화하는 기능입니다. 다양한 CAD 패키지, 작업 흐름 및 디자이너가 매우 다른 소스 데이터를 생성할 수 있기 때문에 이는 바람직하지만 데이터를 시각화할 때 특정 보기 시나리오에 대해 일관된 패키지 크기가 필요합니다.

6.4 파일 크기

파일 크기는 이미지를 생성하는 다각형과 텍스처의 조합에 따라 결정됩니다.

모델	참고 사이즈 HQ	최적화된 크기 HQ	최적화된 크기 LQ
소파 A1 가죽	80MB	3.4MB	0.24MB
소파 A1 패브릭	78MB	4.4MB	0.29MB
소파 A2 가죽	80MB	3.3MB	0.22MB
소파 A2 패브릭	82MB	4.1MB	0.26MB
소파 B1 가죽	102MB	3.3MB	0.26MB
소파 B1 패브릭	104MB	3.8MB	0.29MB
소파 B2 가죽	112MB	3.4MB	0.23MB
소파 B2 패브릭	113MB	4.0MB	0.27MB

보시다시피 원본 모델과 최적화된 모델의 다운로드 크기에 큰 차이가 있습니다. 여기에는 대가가 따르며 이러한 모델은 실제로 면밀한 검사에 이상적이지는 않지만 고품질 모델의 추가 비용이 엄청나게 드는 의미 있는 보기 시나리오를 나타냅니다. 공평하게 말하면 참조 모델은 크기에 최적화되어 있지 않으며 더 높은 수준의 품질이 필요한 경우 더 작게 만들기 위해 수행할 수 있는 작업이 많이 있습니다.

6.5 GPU 드로우 콜

최적화된 모델은 모든 재질의 텍스처를 단일 아틀라스로 결합합니다. 즉, 단일 그리기 호출로 렌더링할 수 있습니다.

소스 모델은 3개의 서로 다른 재질 그룹을 사용하므로 대부분의 렌더러는 각 모델에 대해 3개의 그리기 호출을 제출합니다.

6.6 오버드로

최적화된 모델의 내부 형상이 정리되어 불필요한 오버드로잉이 거의 발생하지 않습니다.

콘텐츠 최적화가 영향을 미칠 수 있는 실제 상황의 예로 저는 8개 모델이 모두 포함된 Adobe Aero 프로젝트를 만들었습니다. 한 프로젝트는 참조 모델을 사용하고 다른 프로젝트는 최적화 모델을 사용합니다.

이 프로젝트는 Adobe Aero 베타 데스크탑을 사용하여 생성된 다음 빠른 LTE 연결이 가능한 iPhone에서 열어 모델이 장치에 동기화되어 사용할 준비가 되었을 때의 차이점을 비교했습니다.

첫 번째 문제는 소파 B1과 소파 B2 두 대가 너무 무거워서 참조 모델을 사용한 프로젝트에서 로딩이 불가능하다고 판단되어 에어로 아이폰 앱에서는 전혀 나타나지 않았다는 점이었습니다. 소스 데이터의 폴리곤 개수는 훨씬 더 많으며 애플리케이션이 제대로 작동하도록 모델 가중치로 제한됩니다.

6.7 오픈 시간

프로젝트를 열고 동기화할 시간:

모델 유형	오픈 시간
참고	4분 50초
최적화	32초

6.8 실행 시간 처리 시간

최적화된 파이프라인은 6코어 2.6GHz Intel Core-7 CPU에서 실행됩니다. 그러면 4가지 모델에 대한 2가지 재료 구성에 대한 참조 모델과 최적화된 모델이 생성됩니다.

실행 모드	실행 시간
파이썬 네이티브	14분 25초
SCons 병렬 6코어	5분 50초

보시다시피 SCons를 통해 실행하면 프로세스 속도가 두 배 정도 빨라집니다. 6개의 코어를 사용할 수 있다는 점을 고려하면 다소 놀랄 수 있지만 실제로는 실행 중인 많은 프로세스가 본질적으로 멀티스레드이므로 코어를 추가해도 선형적으로 확장할 수 없습니다.

SCons의 진정한 이점은 수행된 작업이 시간이 많이 걸리지 않고 버그를 유발하지 않는 한 자산을 최소한으로 변경하고 점진적으로 구축할 때 발생합니다. 단, 처리 시간은 초 단위로 측정됩니다. 하류에는 많은 변화가 있었습니다.

6.9 상황에 따른 실행 시간

이 숫자를 볼 때 가장 먼저 고려해야 할 것은 이 작업을 수행하는 인간과 비교하는 것입니다. 저해상도 모델을 생성하는 것은 그 자체로 시간이 많이 걸리는 작업이며 잠재적으로 몇 시간이 걸릴 수도 있습니다. 이 역시 소스 모델이 바뀔 때마다 어느 정도 다시 해줘야 하는 작업이다. 이 프로세스를 자동화하는 것은 시간 소비 측면에서 큰 승리입니다.

명심해야 할 또 다른 사항은 프로세스가 사용자에게 숨겨지고 별도의 컴퓨터에서 실행될 수 있다는 것입니다. 즉, 빌드 컴퓨터의 백그라운드에서 실행될 수 있어 프로세스가 사용자 속도를 저하시키거나 워크스테이션을 불필요하게 묶지 않도록 보장합니다.

7. 일의 미래

샘플 파이프라인은 매우 제한되어 있지만 파이프라인을 통해 콘텐츠를 보다 효과적으로 최적화하고 배포하는 방법에 대한 개요를 제공해야 합니다. 확장 가능하고 더 나은 작동을 위해 추가할 수 있는 몇 가지 개선 사항은 다음과 같습니다.

7.1 텍스처 압축

모델의 텍스처는 .png 파일입니다. 더 작은 파일을 얻는 방법에는 여러 가지가 있습니다.

• 파이프라인에서 pngQuant를 구현합니다. pngQuant 도구는 품질 손실이 거의 없이 .png 크기를 크게 줄일 수 있고 뷰어에서 특별한 크기 조정이 필요하지 않은 손실이 있는 .png 압축기입니다.
• 현재 GPU 하드웨어 텍스처 압축에 대한 작업이 .gltf/.glb 확장자로 진행 중입니다. 이를 달성하면 파일 크기가 작아지고 로드 시간이 빨라집니다.

7.2 더 나은 Substance 매개변수 지원

현재 머티리얼 인스턴스 형식은 스칼라, 벡터, 불리언 등으로 작업하도록 제한되어 있습니다. 그러나 열거형 문자열이나 더 높은 수준의 매개변수 유형을 사용하려고 하면 오류가 발생할 수 있습니다.

7.3 추가 최적화 옵션/전략

이 최적화는 최소한의 매개변수 세트를 사용하여 단일 알고리즘만 노출합니다. 더 넓은 범위의 개체 유형을 대상으로 하기 위해 더 많은 옵션과 알고리즘을 도입해야 하는 데는 그럴 만한 이유가 있을 수 있습니다.

7.4 메시 압축

.gltf는 draco 메시 압축을 지원합니다. 여기에서 프로세스를 평가하지만 대부분의 데이터가 텍스처로 구성되어 있으므로 파일 크기에 큰 영향을 미치지 않습니다.

7.5 그리드 공유

이 파이프라인에서 메쉬는 다양한 재질 변경에 대해 동일합니다. .glb 대신 .gltf 파일에 결과를 기록하는 설정을 사용하면 메시 데이터를 다른 파일 간에 공유하여 디스크 공간을 덜 사용할 수 있습니다.

7.6 분해 작업

최적화와 텍스처 렌더링은 모두 여러 프로세스를 호출하여 구현되는 작업입니다. 더 작은 작업으로 분할되면 SCons는 해당 작업에서 더 많은 병렬성을 찾아 더 세부적인 종속성 추적을 허용할 수 있습니다.

7.7 노멀맵 축소

노멀 맵은 밉맵을 사용하여 필터링됩니다. 이는 노멀 맵에 적합한 필터가 아니며, 너무 미세하여 개체의 거칠기까지 표시되지 않는 노멀 디테일은 품질 향상을 위해 이동될 수 있습니다. 이는 LEAN 매핑에 관한 논문에 설명되어 있습니다.

7.8 자산 참조

현재 자산 참조(.sbsar 파일, 메시 등)는 로컬 파일 경로입니다. 이 설정은 단일 시스템에서 잘 작동하지만 파이프라인을 여러 시스템으로 확장하려는 경우 일종의 URI 체계를 사용하여 파일을 참조하여 시스템 전체에서 구조화된 방식으로 참조될 수 있도록 해야 할 수도 있습니다.

7.9 재정의 설정

실제 최적화 프로세스에는 문제가 있거나 특별한 설정이 필요한 일부 자산이 있습니다. 자산별로 반복 가능한 수정(예: 텍스처 해상도, 최적화된 품질 등)을 수행하는 편리한 방법은 설정 재정의를 사용하는 것입니다. 이를 통해 사용자는 파이프라인별, 자산별로 속성을 재정의할 수 있으며, 이는 파이프라인의 기본값을 재정의합니다.

7.10 더 큰 규모

대규모 배포의 경우 이러한 빌드 프로세스를 여러 시스템에 분산할 수 있습니다. 그러나 이는 SCons에서는 불가능하며 다른 빌드 시스템이 필요합니다.

---

원본 링크: 3D 자산 최적화 파이프라인 자동화 - BimAnt