공간 컴퓨팅을 위해 3D 애셋 최적화하기

안녕하세요 Scott Wade입니다 Apple Vision Pro 앱 및 콘텐츠를 담당하는 테크니컬 아티스트입니다 오늘 세션 ’공간 컴퓨팅을 위해 3D 애셋 최적화하기’를 시작하겠습니다

이 세션에서는 이 샘플 장면을 사용해 콘텐츠를 가장 멋지게 구현하기 위해 수행할 수 있는 단계를 안내하겠습니다 이 세션에 링크로 연결된 샘플을 다운로드해 따라 하실 수 있습니다 고해상도 디스플레이와 Apple Vision Pro의 높은 프레임률을 활용하면 사용자에게 멋진 경험을 선사할 수 있지만 여러분이 작업해 오신 기타 플랫폼과는 다른 콘텐츠를 Apple Vision Pro용으로 개발해야 합니다 이 세션에서는 염두에 두어야 할 주요 고려 사항을 알아본 후 3D 콘텐츠 생성을 시작하겠습니다 그런 다음, 폴리곤 수 목표를 어느 정도로 해야 하는지 살펴보죠 선택한 콘텐츠 생성 도구에서 내보낼 때 알아야 할 사항 텍스처 메모리를 효율적으로 사용하는 방법 머티리얼과 셰이더 최적화하기 스카이돔을 설정하기 위한 팁 마지막으로 이미지 기반 조명을 효율적으로 맞춤화하는 방법을 알아봅니다

먼저 염두에 두어야 할 몇 가지 예비적 측면을 살펴보겠습니다 애셋 생성을 시작하기 전에 고려해야 할 가장 중요한 사항은 콘텐츠가 표시되는 방식입니다 많은 애셋을 사용하는 몰입형 앱인가요? 공간에 있는 볼륨에 표시되나요? 공유 공간에 표시되나요 즉, 다른 애플리케이션이 동시에 렌더링될 수 있나요? 또한 중요한 점으로, 콘텐츠의 프레젠테이션이 사용자 입력에 따라 달라지나요? 이러한 모든 선택은 애플리케이션 성능에 영향을 주며 다른 콘텐츠 최적화를 필요로 할 수 있습니다 보는 사람의 뷰가 매우 중요한 이유는 Apple Vision Pro에서는 GPU가 패스스루 비디오가 아니라 여러분이 실제로 렌더링하는 픽셀만 처리하기 때문입니다 앱이 표시되는 크기에 따라 GPU 워크로드 크기가 조절됩니다 즉, 비몰입형 장면은 훨씬 더 빠르게 렌더링될 수 있습니다

반면에 몰입형 장면은 전체 뷰 모든 프레임을 렌더링하므로 GPU가 수백만 개의 추가 픽셀을 렌더링해야 합니다

이 점을 고려하면 테스트 없이 성능에 대한 특정 목표를 정하기는 어려울 수 있으니 일찍 테스트를 해 봐야 합니다 공유 공간에 있는 앱의 경우에는 다른 애플리케이션이 동시에 실행될 수 있습니다 몰입형 앱은 더 많은 화면 영역을 사용해 프레임 시간이 증가하죠 따라서 몰입형 애플리케이션은 종종 가장 많은 최적화 작업이 필요합니다 삼각형으로 측정되는 장면의 폴리곤 수는 파악해야 할 주요 성능 지표입니다 일반적인 지침으로는 몰입형 장면 하나당 500,000개 이하의 삼각형을 권장하고 공유 공간의 애플리케이션에는 250,000개 이하를 권장합니다 이는 보는 사람이 한 번에 볼 수 있는 내용에 따라 크게 달라집니다 또한 매우 큰 객체는 분할하는 것이 좋습니다 예를 들면, 지형을 청크로 분할해 카메라를 벗어나면 컬링할 수 있죠 안전한 목표를 원한다면 뷰의 삼각형 수를 약 100,000개로 유지하여 충분한 헤드룸을 확보합니다 이러한 요소를 고려한 후 콘텐츠 빌드를 시작하면 예산을 초과하지 않을 수 있습니다

다음으로, 콘텐츠 생성 및 편집에 어떤 앱을 사용할 수 있는지입니다

다행히도 많은 옵션이 있습니다 가장 중요한 점은 작업한 내용을 USD 형식으로 저장할 수 있다는 것입니다 이 점을 고려할 때 Blender Autodesk Maya, SideFX Houdini 등의 애플리케이션은 멋진 선택 사항입니다 openusd.org에서 USD 생태계에 대해 자세히 알아보세요 전 Blender 4.1을 사용할 예정이니 해당 애플리케이션으로 전환하죠

지금은 더 큰 장면 내의 몇 가지 개별 애셋에 초점을 맞추겠습니다 보는 사람으로부터의 거리에 따라 적절한 폴리곤 수를 사용해 모델링했습니다 이는 판단하기 어려울 수 있으므로 제가 즐겨 사용하는 방법은 장면에서 카메라를 생성하여 보는 사람의 관점에서 해당 콘텐츠가 어떻게 보일지를 시각화해 보도록 하는 것입니다 여기에서는 카메라를 평균 눈 높이인 1.5m 지점의 장면 중앙에 배치했습니다 이제 카메라를 회전하여 콘텐츠가 보는 사람에게 얼마나 크거나 작게 보일지를 파악합니다

애셋을 USD로 내보낼 준비가 되었지만 이는 사용할 특정 usd 파일 유형을 선택해야 한다는 의미입니다 여러 유형이 있기 때문입니다 각 유형이 어떤 경우에 가장 적합한지 빠르게 살펴보죠! USDA는 ASCII 형식이므로 일반 텍스트로 읽을 수 있습니다 USDA는 협업 파일에 적합합니다 예를 들면, 여러 사용자가 편집할 수 있는 장면 등입니다 이러한 이유로 Reality Composer Pro에서 장면 형식으로 사용하죠 텍스트 형식을 사용해서도 병합 충돌을 해결할 수 있습니다 여러 사용자가 동시에 동일한 파일로 작업하는 경우에 말입니다 USDC는 바이너리 형식입니다 이 형식은 모든 USD 호환 앱에서 열 수 있지만 일반 텍스트로 읽을 수는 없습니다 하지만 많은 양의 데이터를 저장하기에 훨씬 더 효율적입니다 예를 들면, 지오메트리 등입니다

USDZ는 압축된 형식입니다 과거에 AR 애셋으로 작업하셨다면 익숙하실 수 있습니다 USDZ는 텍스처 등 애셋에 대한 모든 종속성을 포함하며 이를 위한 내부 파일 구조를 생성합니다 따라서 USDZ는 애셋의 게시 및 배포에 적합합니다 하지만 압축을 풀지 않으면 편집할 수 없습니다

제 애셋은 주로 지오메트리이므로 이를 USDC로 저장하려고 합니다

Blender에서 머티리얼을 이미 설정했지만 머티리얼의 선택을 해제하려고 합니다 Reality Composer Pro의 Shader Graph 기능 중 일부를 활용하고 싶기 때문입니다 그런 다음 내보내기를 누릅니다 Reality Composer Pro의 Project Browser에 이를 가져와 장면에 추가하면 두 가지를 확인할 수 있습니다

첫 번째는 마젠타 색상으로 Reality Composer Pro에서 할당된 머티리얼이 없음을 알려 줍니다 이것이 바로 우리가 기대하는 바입니다 확인할 수 있는 나머지 한 가지는 객체가 회전되었다는 것입니다

좌표계에 대해 설명할 좋은 기회네요

RealityKit은 -Z가 앞쪽 Y가 위쪽, +X가 오른쪽이라고 가정하는 좌표계를 사용합니다 Blender는 Z를 위쪽으로 Y를 앞쪽으로 사용합니다 일부 다른 애플리케이션은 다른 단위 축척을 사용할 수도 있습니다 RealityKit은 미터를 사용합니다 축척이 이미 적용된 콘텐츠를 가져온다면 이 때문일 수 있습니다 애셋 가져오기 테스트는 일찍 해야 합니다 그래야 비일관성 해결 방법에 대한 일관된 계획을 세울 수 있습니다

올해 macOS에는 미리보기에서 좌표와 축척을 변경하는 기능이 새로 도입됩니다 자세한 내용은 ’USD 및 MaterialX의 새로운 기능’ 세션을 참고하세요 Reality Composer Pro에 가져올 때 애셋을 조정하기 위해 X 축에서 -90도 회전을 적용하겠습니다

이제 텍스처를 적용하고 어떻게 하면 더 효율적으로 만들 수 있을지 확인합니다 Reality Composer Pro의 Shader Graph를 사용하여 머티리얼과 텍스처를 설정하겠습니다 Shader Graph의 머티리얼 설정에 관한 기본 정보가 필요한 경우 2023년의 ’Reality Composer Pro의 머티리얼 살펴보기’ 세션을 참고하시기 바랍니다 저는 이 애셋에 대해 기본 PBR 머티리얼을 이미 시작 및 적용했고 텍스처만 적용하면 됩니다 Project Browser에 있는 항목을 사용해 해당 머티리얼로 이동하고 파일 참조를 선택하여 기본 색상을 추가합니다

색상 이미지를 추가하는 경우 색상 공간도 선택해야 합니다

색상 공간은 텍스처와 관련되므로 개요를 간략히 살펴보겠습니다 Reality Composer Pro에서는 색상 공간이 대시로 구분된 2개 항으로 표현됩니다 sRGB - Display P3처럼요

첫 번째 항은 전송 함수로 값을 코딩하는 데 사용되는 곡선을 정의합니다 sRGB는 지각적 텍스처를 위한 것으로 렌더러에서 직접 볼 수 있습니다 기본 색상이나 조명을 비추지 않은 색상처럼요 Linear는 데이터 또는 HDR 이미지에 사용됩니다 다음 항은 색영역입니다 이는 색상 공간의 최대 범위를 정의합니다 Vision Pro에서 디스플레이 P3는 기본 디스플레이 색영역이지만 Xcode로 앱을 빌드하는 경우 다른 색영역을 사용하는 텍스처는 디스플레이 P3로 변환됩니다 일관된 결과를 얻으려면 텍스처가 작성된 의도를 선택하세요 제 텍스처는 sRGB 디스플레이 P3로 작성되었으니 이를 선택하죠

거칠기와 앰비언트 오클루전을 위한 텍스처를 추가하겠습니다

이러한 흑백음영 텍스처에는 색상 공간을 선택하는 옵션이 없음을 확인할 수 있습니다 Shader Graph가 이것이 데이터라고 올바르게 가정하기 때문입니다 즉, 여기에 변환을 적용하고 싶지 않습니다 하지만 이러한 흑백음영 텍스처는 앱이 빌드될 때 압축되지 않습니다 즉, 필요한 것보다 더 큰 공간을 차지하게 됩니다 이 문제를 해결할 방법이 있는데 이를 텍스처 패킹이라고 합니다

텍스처 패킹에서는 색상 텍스처의 다양한 채널을 활용하여 개별 파일들의 텍스처 데이터를 더 큰 하나의 파일로 결합합니다 예를 들어, 거칠기, 메탈 앰비언트 오클루전 텍스처를 각각 빨간색, 초록색, 파란색 채널로 사용합니다 그런 다음 해당 데이터를 단일 텍스처 파일로 결합합니다 추가 보너스로, 이 RGB 텍스처는 이제 앱을 빌드할 때 압축됩니다 흑백음영 텍스처를 패킹하면 PBR 애셋의 총 크기를 최대 40% 줄일 수 있습니다 패킹된 텍스처를 가져오면 이 노드에 대해 vector3 유형을 선택해 셰이더가 이것이 데이터 텍스처임을 알도록 해야 합니다

이렇게 하면 색상 공간 변환이 적용되지 않습니다 RGB 텍스처를 별도의 개별 채널로 분할하기 위해 Separate 3를 사용하겠습니다

그런 다음 개별 입력에서 거칠기와 ao 텍스처를 연결할 수 있습니다

이제 노멀 맵을 추가해 보겠습니다 노멀 맵은 데이터로 간주되므로 다시 vector3 유형을 사용합니다

하지만 해당 텍스처를 연결하면 갑자기 애셋이 잘못 표시됩니다 걱정 마세요, 노멀 맵이 이상하게 표시되면 대개 2가지 문제입니다 잘못된 형식과 잘못된 데이터 범위입니다 노멀 맵에 일반적으로 사용되는 두 형식은 OpenGL과 DirectX이며 RealityKit은 OpenGL 형식의 노멀 맵을 사용합니다 비슷해 보일 수 있지만, DirectX 형식에선 초록색 채널이 반전되죠 제 경우에는 텍스처가 OpenGL 형식임을 알고 있으니 데이터 범위 문제를 살펴보겠습니다

사용 중인 머티리얼의 노멀 맵은 범위가 -1부터 1까지입니다 하지만 이미지에는 0부터 1까지의 값만 포함됩니다 이미지에서 범위를 조정하려면 약간의 수학 계산이 필요합니다 2를 곱하여 범위를 0부터 2까지로 늘릴 수 있습니다

그런 다음 1을 빼서 범위를 -1부터 1까지로 전환할 수 있습니다

이제 좋아 보이네요! 다행히, RealityKit에는 한 단계로 이를 수행하는 노드가 있습니다 바로 Normal Map Decode입니다

잠깐 말씀드리자면 Shader Graph에 NormalMap이라는 노드도 있음을 보셨을 것입니다 동일한 이름의 Blender 노드와 달리 이 노드는 텍스처의 범위를 변경하지 않습니다 다른 애플리케이션과 다른 경우에는 노드에 대한 툴팁을 꼭 읽어 보세요 이를 추가하니 이제 애셋이 멋지게 구현되네요

하지만 애셋마다 이 설정을 하지 않아도 된다면 좋을 것입니다 다행히, Reality Composer Pro에는 머티리얼 인스턴스가 있습니다 머티리얼 인스턴스는 머티리얼의 로직을 재사용하는 멋진 방법이며 이때 노출된 매개변수를 변경할 수 있습니다 이렇게 하면 애셋을 설정할 때 시간을 절약할 수 있을 뿐 아니라 하지만 앱 내 성능에도 도움이 됩니다 엔진이 동일 셰이더 그래프의 중복 사본을 로드할 필요가 없으니까요 현재는 머티리얼에 노출된 매개변수가 없으므로 모든 인스턴스가 동일할 것입니다 이 경우에는 모든 파일 참조를 선택하겠습니다 오른쪽 클릭하고 입력으로 승격합니다

이제 오른쪽 패널에서 해당 입력에 액세스할 수 있습니다 기본 머티리얼을 오른쪽 클릭하고 Create Instance를 선택합니다

텍스처 입력을 편집할 수 있음을 확인할 수 있네요 하지만 기본 그래프 자체는 편집할 수 없습니다 다음 애셋에 추가해 보겠습니다

어떤 애셋에 사용되는지 알도록 머티리얼 인스턴스 이름을 바꾸죠

적용해 보면 여전히 이전 텍스처를 사용 중임을 확인할 수 있습니다

하지만 이제 해당 인스턴스를 선택하면 기본 색상, 노멀 및 패킹된 텍스처로 바꿀 수 있습니다

그 덕분에 패킹된 텍스처를 다시 분할하거나 애셋을 생성할 때마다 노멀 맵의 범위를 변경할 필요가 없어졌습니다 이제 두 번째 애셋이 설정되었고 첫 번째 애셋을 설정할 때 걸렸던 시간보다 더 빠르게 완료했습니다 다음으로, 장면을 살펴보고 최적화된 머티리얼과 셰이더 선택 사항에 대해 알아보겠습니다 앞서 봤던 장면을 가져와 개별 애셋과 함께 사용하겠습니다

이 전체 장면에서는 단일 텍스처만 사용하는 대부분의 애셋에 조명을 비추지 않은 머티리얼을 사용합니다 이를 위해 Blender와 같은 외부 애플리케이션에서 조명을 설정하고 모든 셰이딩 정보를 객체당 단일 텍스처로 베이킹했습니다 RealityKit에서 실시간 조명을 사용하면 성능에 영향을 미칩니다 동적 조명은 신중히 사용하고 가능한 한 베이킹합니다 이 장면이 청크로 분할되어 있다는 사실도 눈치채셨을 겁니다

이 점은 중요합니다 눈에 보이지 않는 엔티티가 카메라를 벗어나면 컬링될 수 있게 해 주기 때문이죠

Blender에서 체커보드 머티리얼이 적용된 상태로 이 장면을 보면 거리에 따라 텍스처 해상도가 얼마나 낮아지는지 알 수 있습니다 실제로, 현재 텍스처 해상도의 절반 이상이 보는 사람을 직접 둘러싼 5~10미터에 집중됩니다 보는 사람이 많이 움직이지 않을 경우 화면상의 거리와 크기에 따라 텍스처 해상도를 조정하는 것이 매우 좋습니다

조명을 비추지 않은 장면에서도 고려할 점은 알파 투명도 사용이며 가능한 한 이를 최소화하기 위해 노력해야 합니다

투명 머티리얼은 비용이 많이 듭니다 투명한 각 레이어에 대해 GPU가 동일한 픽셀을 여러 번 컴퓨팅해야 하기 때문입니다 이를 오버드로우라고 합니다 이 점은 겹겹이 쌓인 투명한 레이어가 많은 경우에 특히 문제가 됩니다

예를 들어, 이 잔디는 투명 텍스처를 사용하는 것처럼

보일 수 있지만 실제로는 풀잎 지오메트리를 사용했습니다 마찬가지로, 이 관목에는

불투명한 코어를 사용하고 투명 카드만 추가했으며 가장자리를 따라 가장 큰 효과를 갖게 됩니다 이렇게 하면 폴리곤 수가 증가하지만 경험상, 투명한 픽셀을 줄이는 대신에 더 많은 삼각형을 사용하는 것이 거의 항상 더 낫습니다 물론 전반적인 삼각형 예산을 벗어나지 않아야 합니다 장면이 준비되었으니 이제 스카이돔이 필요합니다 스카이돔이 없으면 보는 사람이 장면 가장자리 너머로 자신의 패스스루 환경을 보게 될 것입니다

제 경우에는 Blender로 생성한 반전된 구체를 사용하지만 여러분은 원하시는 지오메트리를 사용할 수 있습니다 충분히 크거나 사용자로부터 충분히 멀리 떨어져 있도록 하세요 이 구체의 지름은 약 500미터입니다

스카이돔이나 스카이박스에 고해상도 텍스처를 원하시겠죠 이와 같이 작은 디테일이 포함된 이미지의 경우 최소 8K의 수평 해상도 또는 흐릿함을 줄이기 위해 한층 더 높은 해상도를 원하실 것입니다

이 텍스처의 크기를 고려할 때 사용자에게 보이지 않을 부분이 있는 경우 텍스처를 자르는 것이 좋습니다 이 경우에는 수평선 바로 아래를 자르겠습니다 이 장면에서 제가 만든 스카이돔을 살펴보겠습니다 이 단 하나의 애셋이 화면의 얼마나 많은 부분을 차지하게 될지 확인할 수 있습니다 스카이돔과 스카이박스에 조명을 비추지 않은 머티리얼을 사용하는 것은 중요하며, 이는 최적화해야 할 첫 번째 애셋 중 하나입니다

스카이박스가 준비되면 장면이 실제로 하나로 결합됩니다

하지만 이전의 PBR 애셋을 살펴보면 그리 좋아 보이지 않는 것을 확인하실 수 있습니다 장면의 나머지 부분과 동일한 조명을 사용하지 않은 것 같습니다 명확히 태양으로 인한 것이 아닌 하이라이트가 있네요 태양은 뒤쪽에 있는데 말이죠 그 이유는 스카이돔이 단지 메시일 뿐이며 PBR 애셋에 조명을 비추는 방식에 실제로 기여하지 않기 때문입니다 따라서 맞춤형 이미지 기반 조명 구현 방법을 살펴봐야 합니다 여러분은 이미지 기반 조명 즉, IBL에 익숙하실 수 있지만 일반적인 아이디어는 2D 이미지를 사용하여 환경을 나타내고 애셋에 셰이딩을 추가하는 것입니다 RealityKit에서 PBR 머티리얼은 이 셰이딩 방법을 사용합니다 이미지 기반 조명을 사용하는 주된 이유는 사용자가 방의 조명을 켜는 것과 같은 실제 환경의 변화에 머티리얼이 동적으로 반응하도록 하기 위해서입니다 이는 일부 경험에 적합하지만 이 장면에서 저는 실제 환경이 아니라 제가 만든 환경에 의해 애셋에 조명이 비춰지는 것처럼 보이게 하고 싶습니다 이렇게 하려면 몇 가지 구성요소를 추가해야 합니다 먼저, 새로운 Transform 구성요소를 생성하고

이름을 IBL로 지정하여 용도를 알 수 있도록 합니다

그런 다음 Image Based Light 구성요소를 추가합니다

여기에 장면의 사전 렌더링된 High Dynamic Range 이미지를 추가하죠

이는 HDR이어야 멋지게 구현되는 소수의 텍스처 중 하나입니다

IBL 텍스처는 위도/경도 형식이어야 하며 이를 정방형이라고도 합니다 HDR 텍스처는 로드 및 렌더링에 비용이 많이 들지만 이 장면에는 반사가 많이 적용되는 객체가 많지 않기 때문에 매우 작은 텍스처를 사용하겠습니다 이 텍스처는 가로 512픽셀 정도면 됩니다 즉, 스카이돔 텍스처 크기의 몇 분의 일에 불과하죠 거울과 같은 표면이 없는 한 종종 이보다 훨씬 더 높은 해상도가 필요하지 않습니다

이미지가 아직 애셋에 영향을 미치지 않고 있는데

그 이유는 추가할 사항이 하나 더 있기 때문입니다 바로 Image Based Light Receiver 구성요소입니다 PBR 객체의 부모 노드를 선택하고 여기에 수신기를 적용합니다

이렇게 하면 모든 자식 엔티티에 적용됩니다 이제 앞서 생성한 IBL 엔티티를 선택해 연결하기만 하면 됩니다 이러한 이유로 레이블을 지정했던 것입니다

이제 애셋에서 장면의 조명과 반사를 확인할 수 있습니다

요약하면, 스카이박스는 크고 동적 범위가 낮은 텍스처여야 합니다 이상적으로는 조명을 비추지 않은 머티리얼을 사용합니다 IBL은 위도/경도 형식의 HDR 텍스처여야 합니다 이상적으로는 낮은 해상도를 사용합니다 또한 효과를 확인하려면 이미지 기반 조명 구성요소와 수신기를 모두 추가해야 합니다 때때로 조명을 비추지 않은 색상 이상의 머티리얼이 필요하지만 전체 PBR 셰이더일 필요는 없습니다 이를 위해 셰이더 그래프에서 Environment Radiance 노드를 사용할 수 있습니다 이 수레 바퀴에는 금속 테가 있어야 하지만 베이킹된 탓에 금속처럼 보이지 않습니다

멀리서 보면 괜찮을 수도 있지만 가까이서 보면 반사가 없다는 것을 알 수 있습니다 따라서 조명을 비추지 않은 머티리얼보다는 PBR 머티리얼을 사용해야 한다고 생각하실 수 있습니다 이전 애셋에서 했던 대로 말이지요 하지만 Unlit 셰이더를 사용하면서 이렇게 할 수 있는 방법이 있죠 제가 분리해 놓은 이 애셋에 대한 머티리얼 그래프에서 Environment Radiance 노드를 사용하면 조명을 비추지 않은

그래프 내부의 IBL에서 제공되는 셰이딩 정보를 사용할 수 있죠 Environment Radiance 노드의 반사 출력을 살펴보면 보는 각도에 따라 반사되는 장면을 볼 수 있습니다

확산 조명을 활용할 수도 있지만 이 경우에는 필요하지 않습니다 이미 텍스처에 베이킹되어 있기 때문입니다 이 경우에는 베이킹된 텍스처와 함께 반사광만 추가하고 싶습니다

이렇게 하면 뷰 의존 반사 효과를 구현하고 머티리얼이 훨씬 금속처럼 보이게 할 수 있습니다

Environment Radiance 노드를 사용하면 조명을 비추지 않은 일반 머티리얼보다 비용이 더 많이 듭니다 하지만 전체 PBR 머티리얼 사용보다는 비용이 적게 듭니다 이 노드는 동적인 조명 효과를 원하지만 전체 PBR을 사용하고 싶지 않은 상황에서 사용하세요 이렇게 하니 장면이 정말 멋지게 구현되었네요!

마지막 확인 사항으로 Reality Composer Pro에서 Statistics 패널을 살펴보고 예산 현황을 검토할 수 있습니다 108,000개의 삼각형을 사용 중이니 폴리곤 수 목표를 달성하고 있네요 더 좋은 점은 삼각형이 총 108,000개라는 것입니다 장면이 청크로 분할되어 사용자는 한 번에 그 절반 정도만 보게 되죠 총 메시, 텍스처, 머티리얼 수가 상당히 적습니다 1.2GB의 텍스처가 있지만 텍스처가 아직 압축되지 않았음을 기억하세요 Xcode로 애플리케이션을 컴파일하면 텍스처가 압축되어 크기가 약 300MB로 줄어들 것입니다 또한 투명 머티리얼의 양도 최소화했고 가능한 한 조명을 비추지 않은 셰이딩을 사용하고 있습니다 마지막으로 애플리케이션의 성능과 렌더링을 프로파일링하려면 RealityKit Trace를 사용할 수 있습니다 또는 장면의 엔티티를 디버깅하거나 코드의 어느 부분이 문제를 발생시키고 있는지 감지하려는 경우에는 새로운 RealityKit 디버거를 사용할 수 있습니다 이러한 도구에 대한 자세한 내용은 여기 나와 있는 세션을 참고하세요

지금까지 공간 컴퓨팅을 위해 3D 콘텐츠를 최적화하는 다양한 방법을 살펴봤습니다 다시 한 번 요약해 보죠 폴리곤 수를 적게 유지하고 한 번에 볼 수 있는 삼각형의 수에 초점을 맞추세요 화면에 표시되는 애셋 크기에 따라 애셋을 최적화하세요 텍스처를 패킹하여 메모리를 절약하고 압축 기능을 활용하세요 조명을 비추지 않은 머티리얼과 베이킹된 텍스처를 사용하세요 조명을 비추지 않은 머티리얼로 충분하지 않다면 Environment Radiance 노드의 사용을 고려하세요 마지막으로, 스카이박스 텍스처는 크게 유지하고 IBL 텍스처는 작게 유지하세요

몰입형 앱을 위한 사실적인 맞춤형 환경 구현에 대해 자세히 알아보려면 여기에 나와 있는 세션을 참고하세요 이러한 개념들을 염두에 두면 Apple Vision Pro를 위해 효과적이고 충실도 높은 3D 콘텐츠를 생성하실 수 있습니다 여러분이 공간 컴퓨팅을 위해 구현할 콘텐츠가 정말 기대됩니다 감사합니다!