[Unity Pixyz 최적화] Unity Warehouse Scene 최적화하기

---

Unity Warehouse Scene

Unity Technologies

---

 

서론

지난 [Unity Sentis] ObjectDetection (Yolo v7 tiny) Bounding Box 구현의 이해 글에 이어서 작성합니다.

 

[Unity Sentis] ObjectDetection (Yolo v7 tiny) Bounding Box 구현의 이해

 

 

해당 포스팅에서 진행하게 될 내용은 최적화 관련 내용입니다. 당시 핸즈온 대상으로 진행해야 했기 때문에 진행자의 입장에서 가장 중요한 부분은 누구나 프로젝트를 실행할 수 있어야한다는 점이였습니다.

 

따라서 당시 최소사양을 GTX 1660으로 잡았는데 이는 원본 프로젝트가 HDRP이기 때문이였습니다.

 

관련해서 본 포스팅에서 사용한 HDRP 프로젝트인 Unity Warehouse는 Asset Store에서 다운로드 받을 수 있습니다.

Unity Warehouse | 3D 공장 | Unity Asset Store

 

정확한 포스팅을 위해, 원본 프로젝트를 그대로 사용합니다. 대신 본 포스팅에서 제가 진행하는 방법이 100% 맞지 않고 보다 좋은 방법이 있을 수 있다는 점 (특히 아티스트의 관점으로 보았을 때) 양해해주시면 감사하겠습니다.

 

Optimizatino Overview

 

최적화 진행에 앞서, 빠른 최적화를 위해 Unity Pixyz Plugin 그리고 Unity Pixyz Studio를 사용하였습니다.

또한 유니티 버전은 2022.3.16을 사용하였으니 참고 바랍니다.

 

Pixyz Plugin의 경우 현재 2.0.5 버전까지 출시되었으나 Package Manager를 통해 설치할 경우 자동으로 최신 버전을 설치하기 때문에 다음의 포스팅을 참고해주시길 바랍니다.

[Pixyz Plugin] Pixyz Plugin 2.0.0 버전 업데이트

 

환경 이해하기

우선 기본적으로 최적화를 진행하기 전에 해당 환경에 대한 이해를 시작해보도록 하겠습니다.

저는 모든 오브젝트를 하나하나 클릭하면서 확인해보았습니다. 그 중 관심있게 보았던 내용을 말씀드립니다.

 

Batching 검사

Cardboard 확인하기

 

가장 먼저 확인을 진행한 부분은 Batching입니다. Batching이 3000개가 된다는 부분이 이해가 되지 않았기 때문에 여러 메테리얼을 돌려서 쓰고 있는지? 같은 오브젝트가 같은 메쉬 정보를 사용하고 있는지에 대해 확인해보았습니다.

 

대표적으로 가장 많이 사용되는 Cardboard 박스를 통해서 확인해보도록 하겠습니다.

 

 

Cardboard A와 B는 모두 Cardboard_A라는 메쉬를 사용하고 있습니다. 이를 통해서 렌더링시 Batching의 이점을 사용할 수 있습니다. 그 외에 메테리얼의 경우 각각의 박스의 종류에 맞게 메테리얼을 다르게 사용하고 있는 것을 볼 수 있습니다.

 

따라서 위의 케이스의 경우 문제없이 Batching이 되었다고 생각할 수 있습니다. 하지만 실제로는 Label.cs를 통해 각각의 오브젝트가 batching 숫자에 기여하고 있습니다. 해당 스크립트는 아래와 같이 작성되어 있습니다.

 

using UnityEngine;

namespace UnityWarehouseSceneHDRP
{
    public class Label : MonoBehaviour
    {
	    private void Start()
	    {
            int[] array = { 0, 1, 2, 3 };
            System.Random rand = new System.Random();

            for (int i = array.Length - 1; i > 0; i--)
            {
                int j = rand.Next(i + 1);
                int temp = array[i];
                array[i] = array[j];
                array[j] = temp;
            }

            Renderer renderer = GetComponent<Renderer>();
		    renderer.material.SetVector("_Label_Offset_1", new Vector2(Random.Range(-0.1f, -0.9f) - array[0] * 2, Random.Range(-0.25f, -0.75f)));
            renderer.material.SetVector("_Label_Offset_2", new Vector2(Random.Range(-0.1f, -0.9f) - array[1] * 2, Random.Range(-0.25f, -0.75f)));
            renderer.material.SetVector("_Label_Offset_3", new Vector2(Random.Range(-0.1f, -0.9f) - array[2] * 2, Random.Range(-0.25f, -0.75f)));
            renderer.material.SetVector("_Label_Offset_4", new Vector2(Random.Range(-0.1f, -0.9f) - array[3] * 2, Random.Range(-0.25f, -0.75f)));
	    }
    }
}

 

System.Random을 사용하기 떄문에 각각의 컴포넌트에서 random으로 실행되고 이를 따라 상자의 개수만큼 Batching이 늘어나게 됩니다. 해당 프로젝트에서 Label을 사용하지 않기 때문에 스크립트 및 모든 프리팹에서 Label을 삭제하였습니다.

 

 

Label.cs을 사용하는 오브젝트는 위와 같습니다.

 

Building 확인하기

프로젝트의 Building을 확인해보니 오브젝트가 각각의 index number를 갖고 있는 것을 확인하였습니다. 즉 아래와 같이 같은 Shutter임에도 불구하고 각기 다른 Shutter Mesh를 사용하고 있습니다.

 

 

위에서는 Shutter 5와 Shutter 6에서 각기 다른 Mesh를 사용하고 있음을 알 수 있습니다. 따라서 Frame Debugger를 돌려보면 아래와 같은 현상이 발생되게 됩니다.

 

 

보시면 같은 종류의 메테리얼 및 mesh 형상을 사용하지만 같이 묶여서 Batching이 되지 않은 것을 확인할 수 있습니다.

따라서 정확한 Batching을 위해 해당 오브젝트를 모두 같은 메쉬를 사용하도록 변경하였습니다.

 

하나의 오브젝트를 기준으로 잡고 ctrl+D를 통해 복사 붙여넣기로 재배치 진행함.

 

추가적으로 천장 그리고 공장 곳곳에 아래 같이 오브젝트가 배치되어 있는 형상이 있었습니다. 예를 들어서 Bldg_SteelFrame_Bottom의 경우, 배칭이 정상적으로 진행된 것으로 보입니다 (모든 형광색 프레임이 한번에 생성됨)

 

하지만 실제 프로젝트에서 메쉬 형상을 확인해보면 모든 SteelFrame이 하나의 메쉬로 묶여 있는 것을 확인할 수 있습니다.

 

 

이 경우 Occulusion이 진행되지 않기 때문에 CAD 툴에서 모두 분리 후 각각의 자리에 맞게 진행하였습니다.

 

 

위와 같이 더 이상 SteelFrame이 묶여 있지 않는 것을 확인할 수 있습니다. 이를 진행할 때도 각각의 오브젝트가 같은 Mesh 및 Material을 사용하는지 확인하여야합니다.

 

작업은 Blender 그리고 Fusion 360을 섞어 사용했습니다. CAD 사용 방법은 기술하지 않지만 기준 면잡고 split해서 진행하였습니다.

 

 

Combine

위의 프로젝트에서 해당 건물을 실제로 사용되지 않습니다. 따라서 Combine을 통해 위와 같이 파편화 되어 있는 오브젝트를 모두 하나의 메쉬 그리고 하나의 메테리얼을 사용하도록 수정하였습니다.

Combine meshes | Pixyz Plugin | 2.0.8

 

 

위와 같이 하나의 오브젝트로 묶고 메테리얼을 Merged한 것을 확인할 수 있습니다.

 

 

마찬가지로 보이지 않는 부분, 대표적으로 Bolt의 경우 없어도 티가나지 않지만... 약 16416개 정도의 tris를 사용하고 있습니다. 눈에 띄지 않는 부분은 모두 삭제하였습니다.

 

 

Decimate, LODs

이 후 Pixyz에서 가장 많이 사용하는 Decimate를 진행하였습니다. CAD 마다 기준 unit 및 어떠한 format을 타고 import 되었는지가 중요하기 때문에 주로 ratio 설정을 사용하는 편입니다.

 

LODs 및 Decimate 설정은 각 문서를 참고해주시길 바랍니다.

 

일반적으로 50 ~70% 값을 오브젝트에 따라 설정하였습니다.

LOD 및 Decimate를 적용할 경우 Light Baking 그리 UV를 UV Projection 또는 별도로 다시 수정해야줘야 하는 번거로움이 있을 수 있습니다. 따라서 전반적으로 input (시간) 대비 output (cost saving)을 고려하여 진행하는 것이 좋습니다.

 

단편적인 예로 위의 사진은 LODs를 적용하여 같은 Cardholder이지만 색감이 다르게 보입니다.

 

결론

최적화는 총 2가지 버전으로 진행하였고 최종적으로 15~20fps 정도 상승하였습니다.

 

우선 1안 (Tris : 17M -> 4.2M) 은 맵을 반으로 자르고 UV를 고려하지 않고 최적화를 진행하였으나 비쥬얼 퀄리티로 인하여 폐기하였습니다. 아래의 프로젝트의 경우 가장 적은 batches와 tris를 확인하실 수 있습니다.

 

2안의 경우, 비주얼 퀄리티는 그대로 유지하면서 삼각형의 개수를 17M에서 12M으로 감소하였습니다.

 

최종적으로 그래픽 퀄리티로 인하여 2안을 선택 후 발표를 진행하였습니다.

전반적으로 코드와 같이 기술적인 이해도보다는 반복 작업의 비중이 많습니다. 따라서 방향성 및 투입할 수 있는 시간 및 Target Device를 고려하여 작업을 진행하는 것을 추천드립니다.