해당 레퍼런스에서 사용하는 오브젝트 풀링을 사용하였다.
탄막이 Velocity(Rigidbody)를 통해 움직이고 있어 이전에 대여 및 반납되었던 탄막을 다시 대여할 경우 의도치 않은 결과가 발생하여, 반환하는 메서드에 앞서 초기화 작업을 하는 스크립트를 추가 해 주었다.
•
위치 초기화
•
방향 초기화
•
Rigidbody가 있다면 velocity와 angularVelocity 초기화 → 이 방법을 사용하였더니 효과가 있었다.
public static void ReturnToPool(GameObject obj)
{
if (!inst.poolDictionary.ContainsKey(obj.name))
throw new Exception($"Pool with tag {obj.name} doesn't exist.");
// 오브젝트의 위치와 회전을 초기화
obj.transform.position = Vector3.zero;
obj.transform.rotation = Quaternion.identity;
// Rigidbody가 있다면 velocity와 angularVelocity 초기화
if (obj.TryGetComponent<Rigidbody>(out Rigidbody rb))
{
rb.velocity = Vector3.zero;
rb.angularVelocity = Vector3.zero;
}
inst.poolDictionary[obj.name].Enqueue(obj);
}
C#
복사
유니티에서 제공하는 오브젝트 풀링 패키지는 내부 구조를 분석하기 매우 힘들었기 때문에, 새로운 풀링 구조에서 훨씬 자유도 높게 커스텀이 가능할 것으로 예상된다.
반환쪽에서 Queue를 사용했던 이전 풀링 구조와는 다르게 작동중인데, 분석 내용을 보면 특별히 무리가 없는 모습을 보인다.
4월 8일(월) 새 ObjectPooler만을 도입한 경우의 Stat
중간발표 때 받은 피드백을 바탕으로 두 가지 정도의 최적화를 진행하자.
배치수가 계속 오르는 걸 보면, GPU인스턴싱이나 오브젝트들의 재사용이 사실상 안 되고 있는 것 같고, Shadow casters도 지금 사용하는 오브젝트만큼 계속 증가하는 걸 보면 탄막 하나 당 그림자를 모두 사용하는 것으로 보인다. 그래서 그래픽적인 최적화를 먼저 시도해보는 게 좋을 것.
GPU인스턴싱 등을 사용해서 GPU가 한방에 처이를 해준다거나 시도 해 볼 수 있을 것 같고, 그럼에도 이상하다 싶으면 단순한 큐브같은 형태의 오브젝트로도 테스트를 해보길.
총알에 모두 Rigidbody를 사용하고 있는가? (Yes). 차라리 총알이나 이런 애들에게서 Rigidbody를 분리시키고, 고정된 오브젝트에 Rigidbody를 주어 연출을 더 추가적으로 넣어주는 방법도 고려해 볼 수 있음.
•
Shadow
•
GPU 인스턴싱
•
Rigidbody 사용 오브젝트의 변경
Shadow casters 모두 제거
탄막의 Mesh Renderer와 Trail의 Renderer에서 Cast Shadows를 모두 Off로 바꿔준다.
같은 장면에서 5000 이상었던 Shadow casters를 24로 줄였다.
GPU 인스턴싱
아래와 같이 탄막 및 Trail에 사용된 여섯개의 머테리얼에서 GPU Instancing을 체크한다.
두 가지 방법의 최적화를 진행했지만… 잘 모르겠다 개선이 되었는지
그래도 프로파일러를 통해 아까와의 스크린샷과 비교하면
•
전 : 지연시간 평균 30ms 정도로 보임
•
후 : 지연시간 평균 25ms 정도로 보임
대충 이 정도의 개선일까.
그리고 Rigidbody를 제거함으로써 성능개선은 확실히 될 것이라고 생각하는 게, 이전에 Translate이슈로 Rigidbody로 바꿨을 때, 성능차이가 무척 눈에 보였었다. 그래서 Rigidbody를 사용하지 않는 방향으로 롤백한다면 아마 나아질 것으로 예상. 다만 이전에 플레이어-탄막 간 충돌이 잘 되지 않아 Rigidbody와 Velocity 조작을 통한 탄막 이동으로 교체하였기 때문에, 이는 다시 해결해야할 과제가 될 것이다.
추가적인 최적화 작업은
와 같이 보면 좋다.