차이

문서의 선택한 두 판 사이의 차이를 보여줍니다.

--- unity:iphone-drawcall-batching [2018/02/22 11:34] – 바깥 편집 127.0.0.1
+++ unity:iphone-drawcall-batching [2018/10/22 10:24] (현재) – 119.192.146.206
@@ 줄 1: / 줄 1: @@
 {{tag>유니티 unity}}
-======그리기 호출 일괄처리======
+======그리기 호출(Draw Call) 일괄처리======
-스크린에 오브젝트를 그리기 위해서는, 엔진은 그래픽 API(iOS 경우OpenGL ES)에 그리기 호출을 하여야 합니다. 모든 그리기 호출은 그래픽 API 안에서 많은 량의 연산을 필요로 합니다. 그러므로, 그리기 호출은 CPU 측에 많은 부하를 초래합니다.
+스크린에 오브젝트를 그리기 위해서는, 엔진은 그래픽 API(iOS 경우OpenGL ES)에 그리기 호출(Draw Call/이하 드로우콜)을 하여야 합니다. 모든 드로우콜은 그래픽 API 안에서 많은 양의 연산을 필요로 합니다. 그러므로, 드로우콜은 CPU 측에 많은 부하를 초래합니다.
-유니티는 실행시에 오브젝트 다수를 묶고, 한번의 그리기 호출로 동시에 오브젝트를 그리는 스마트기능이 있습니다. 이 기능을 일괄처리(batch)라고 부릅니다. 유니티가 더 많은 오브젝트를 일괄처리 할수록, 더 좋은 렌더링 성능을 가지게 됩니다.
+유니티는 실행시에 오브젝트 다수를 묶고, 한번의 드로우콜로 동시에 오브젝트를 그리는 스마트기능이 있습니다. 이 기능을 일괄처리(batching/이하 배칭)라고 부릅니다. 유니티가 더 많은 오브젝트를 배칭 할수록, 더 좋은 렌더링 성능을 가지게 됩니다.
-유니티에서 내장된 일괄처리는 모델링 툴에서 단순히 기하를 통합(또는 Standard Asset 패키지로부터 CombineChildren 스크립트를 사용) 하는 것보다 이점이 있습니다. 유니티에서 일괄처리는 가시결정(visibility determination)단계 _후_에 발생합니다. 그러므로, 엔진은 각각의 오브젝트들을 누락시킬 수 있으며, 표현된(rendered) 기하의 양을 일괄처리 없는 단계로 유지합니다. 모델링 툴에서 기하를 통합하는 것은 반대로 효율적인 누락(cull)을 막아, 더 높은 양의 기하가 표현되는 것을 초래합니다.
+유니티에서 내장된 배칭은 모델링 툴에서 단순히 기하(Geometry/이하 지오메트리)를 통합(또는 Standard Asset 패키지로부터 CombineChildren 스크립트를 사용) 하는 것보다 이점이 있습니다. 유니티에서 배칭은 가시결정(visibility determination)단계 _후_에 발생합니다. 그러므로, 엔진은 각각의 오브젝트들을 누락(culling/이하 컬링)시킬 수 있으며, 표현된(rendered) 지오메트리의 양을 배칭이 없는 단계로 유지합니다. 모델링 툴에서 지오메트리를 통합하는 것은 반대로 효율적인 컬링을 막아, 더 많은 양의 지오메트리가 표현되는 것을 초래합니다.
-=====재료들=====
+=====메테리얼=====
-같은 재료를 공유하는 오브젝트들만 일괄처리가 가능합니다. 그러므로, 좋은 일괄처리를 위해서는, 더 많은 오브젝트들의 재료를 공유할 필요가 있습니다.
+같은 메테리얼을 공유하는 오브젝트들만 배칭이 가능합니다. 그러므로, 좋은 배칭을 위해서는, 더 많은 오브젝트들이 메테리얼을 공유할 필요가 있습니다.
-질감에 있어서만 차이가 있는 두 동일한 재료를 가지고 있다면, 이 질감들을 하나의 큰 질감으로 통합할 수 있습니다. 이 과정을 [[http://en.wikipedia.org/wiki/Texture_atlas|//texture atlasing//]]라고 종종 부릅니다. 일단 질감들이 같은 지도 안에 있게 되면, 하나의 재료를 대신 사용할 수 있습니다.
+텍스쳐에 있어서만 차이가 있는 두 동일한 메테리얼을 가지고 있다면, 이 텍스쳐들을 하나의 큰 텍스쳐로 통합할 수 있습니다. 이 과정을 텍스쳐 아틀라싱([[http://en.wikipedia.org/wiki/Texture_atlas|//texture atlasing//]])이라고 종종 부릅니다. 일단 텍스쳐들이 같은 맵 안에 있게 되면(아틀라스 텍스쳐를 사용하면), 하나의 메테리얼을 사용할 수 있습니다.
-스크립트로부터 공유 재료 속성들을 접근하려면, 변환하려는 [[ScriptRef:Renderer-material.html|Renderer.material]] 이 재료의 복사본을 만들 것임을 명심하십시오. 대신, 재료를 공유하려면 [[ScriptRef:Renderer-sharedMaterial.html|Renderer.sharedMaterial]]를 사용하십시오.
+스크립트로부터 공유 메테리얼 속성들을 접근하려면, 변환하려는 [[ScriptRef:Renderer-material.html|Renderer.material]] 이 메테리얼의 복사본(instance/이하 인스턴스)을 만들 것임을 명심하십시오. 대신, 메테리얼을 공유하려면 [[ScriptRef:Renderer-sharedMaterial.html|Renderer.sharedMaterial]]를 사용하십시오.
-=====동적 일괄처리=====
+=====동적 일괄처리(dynamic batching/이하 다이나믹 배칭)=====
-유니티는 같은 재료를 공유하면, 하나의 그리기 호출로 움직이는 오브젝트들을 자동으로 일괄처리 할 수 있습니다. 동적 오브젝트들을 일괄 처리하는 것은 _정점당_오버헤드를 가집니다. 그러므로, 일괄처리는 _300_ 정점 이하를 가지는 메쉬들에게 적용됩니다.
+유니티는 같은 메테리얼을 공유하면, 하나의 드로우콜로 움직이는 오브젝트들을 자동으로 배칭 할 수 있습니다. 동적 오브젝트들을 배칭하는 것은 _버텍스당_오버헤드를 가집니다. 그러므로, 다이나믹 배칭은 버텍스가 _300_개 이하인 메쉬들에게 적용됩니다.
-동적 일괄처리는 자동으로 이루어지며, 추가적인 작업을 필요로 하지 않습니다.
+다이나믹 배칭은 자동으로 이루어지며, 추가적인 작업을 필요로 하지 않습니다.
 Tips:
-  * 균일한 비율을 사용하세요(예: X:1, Y:1, Z:1). 비 균일한 변환 비율 즉X:1, Y:2, Z:3 또는X:1, Y:1.00001, Z:1는 일괄처리의 실패를 야기합니다.
+  * 균일한 스케일을 사용하세요(예: X:1, Y:1, Z:1). 비 균일한 스케일 즉X:1, Y:2, Z:3 또는X:1, Y:1.00001, Z:1는 배칭의 실패를 야기합니다.
-  * 다른 재료 인스턴스를 사용하는 것은 일괄처리의 실패를 야기합니다.
+  * 다른 메테리얼 인스턴스를 사용하는 것은 배칭의 실패를 야기합니다.
-  * Prefab의 인스턴스들을 사용하는 것은 같은 메쉬와 재료를 자동으로 사용하는 것입니다.
+  * Prefab의 인스턴스들을 사용하는 것은 같은 메쉬와 메테리얼을 자동으로 사용하는 것입니다.
-  * 사용되는 쉐이더의 정점 구조 크기는 일괄처리 할 수 있는 모든 개수의 정점에 영향을 미칩니다. 만약 쉐이더가 Vertex Position 과 하나의 UV를 사용한다면, 450개 가량의 정점을 일괄처리 할 수 있습니다. 만약 쉐이더가 Vertex Position과 표준의 UV하나를 사용한다면, 300개 가량의 정점이 일괄처리 됩니다. 만약 쉐이더가 Vertex Position과 표준의 UV0와 UV1, 탄젠트를 사용한다면, 180개 가량의 정점이 일괄 처리 됩니다.
+  * 사용되는 쉐이더의 버텍스 구조 크기는 배칭 할 수 있는 모든 개수의 버텍스에 영향을 미칩니다. 만약 쉐이더가 Vertex Position 과 하나의 UV를 사용한다면, 450개 가량의 버텍스를 일괄처리 할 수 있습니다. 만약 쉐이더가 Vertex Position과 표준의 UV하나를 사용한다면, 300개 가량의 버텍스가 일괄처리 됩니다. 만약 쉐이더가 Vertex Position과 표준의 UV0와 UV1, 탄젠트를 사용한다면, 180개 가량의 버텍스가 일괄 처리 됩니다.
-=====정적 일괄처리=====
+=====정적 일괄처리(static batching/이하 스테틱 배칭)=====
-정적 일괄처리는 반면에 엔진의 어떤 사이즈의 기하(같은 재료를 공유하고 움직이지 않는 조건에서)를 위한 그리기 호출 수를 줄입니다. 정적 일괄처리는 동적 일괄처리보다 훨씬 더 효율적입니다. 더 적은 CPU 파워를 소모하므로 정적 일괄처리를 선택해야 합니다.
+반면에 스테틱 배칭은 엔진의 모든 규모의 지오메트리(같은 메테리얼을 공유하고 움직이지 않는 조건에서)를 위한 드로우콜을 줄입니다. 스테틱 배칭은 다이나믹 배칭보다 훨씬 더 효율적입니다. 더 적은 CPU 파워를 소모하므로 스테틱 배칭을 선택해야 합니다.
-정적 일괄처리를 이용하기 위해서는, 대상 오브젝트들에게 정적임을 지정해야 하며, 게임에서 움직이거나 회전 비율조정을 해서는 _안_됩니다. 그러기 위해서는, 인스펙터의 정적 체크박스를 사용하여, 대상 오브젝트를 표시해야 합니다:
+스테틱 배칭을 이용하기 위해서는, 대상 오브젝트들에게 Static을 지정해야 하며, 게임에서 움직이거나 회전 스케일을 조정해서는 _안_됩니다. 그러기 위해서는, 인스펙터 우상단의 Static 체크박스를 사용하여, 대상 오브젝트를 표시해야 합니다:
 {{:unity3d:StaticTagInspector.png}}
-정적 일괄처리를 사용하는 것은 통합기하를 저장하기 위해서 추가의 메모리를 필요로 합니다. 정적 일괄처리 전에 같은 기하를 공유하는 다수의 오브젝트가 있다면, 기하의 복사는 각각의 오브젝트를 위해 이루어 것입니다 (에디터 안에서나 실행 시). 이는 항상 좋은 생각이 아닙니다. 때로는 메모리의 공간을 적게 유지하고 특정 오브젝트들을 위해서는 정적 일괄처리를 피하여 표현 성능(rendering performance)의 희생을 치러야 합니다.   예를 들어, 밀집한 숲에서 나무들을 정적으로 표시하는 것은 중요한 메모리의 영향을 줍니다.
+스테틱 배칭은 통합된 지오메트리를 저장하기 위해서 추가적인 메모리를 필요로 합니다. 스테틱 배칭 전에 같은 지오메트리를 공유하는 다수의 오브젝트가 있다면, 지오메트리의 복사는 각각의 오브젝트를 위해 이루어 것입니다 (에디터 안에서나 실행 시). 이는 항상 좋은 생각이 아닙니다(이 문장과 앞문장 무슨말인지 모르겠음). 때로는 메모리를 적게 유지하고 특정 오브젝트들을 위해서는 스테틱 배칭을 피하여 렌더링 성능(rendering performance)의 희생을 치러야 합니다.   예를 들어, 밀집한 숲에서 나무들을 스테틱으로 표시하는 것은 메모리에 막대한 영향을 줍니다.
-정적 일괄처리는Unity iOS Advanced에서만 사용가능 합니다.
+스테틱 배칭은 Unity iOS Advanced에서만 사용가능 합니다.
 =====더 읽기=====