[📜일지] 에전에 올린 2d 게임 개쩌는 아이디어 구현해왔어

[와따따(csh0403kr)]

캐릭터 스프라이트를 (몸, 헤어, 의류 등)
텍스쳐 하나에 통합해서

캐릭터용 오브젝트 대신

메쉬 하나를 생성하고

uv 좌표를 쪼개 메쉬를 생성하고
해당 uv좌표에 캐릭터가 있으면 텍스쳐를 그리는 거

이론상 캐릭터 1만 마리가 있어도

배칭, 드로우콜은 단 하나

이걸 한 번 구현해봤어

일단 캐릭터 5마리야

배칭이랑 드로우 콜 1추가

각 캐릭터마다 좌표를 다르게 했어 

uv좌표로도 이동이 가능했고, 애니메이션도 가능할 것 같아 

더 확실한 테스트를 위해서

절차적 랜덤 섬을 만들고, uv좌표에 텍스쳐를 그려봤어

오브젝트의 메쉬는

125*125? 이 최대야

그래서 100*100(1만 개)로 메쉬를 나눴어

메쉬 125*125 제한을 풀 수 있는데

심리스도 만들 겸 그냥 했어

총 좌표는 100만 개

1만 개마다 배칭 1개

드로우콜은 오직 1개

일단 테스트 해본 건

1000*1000

3000*3000

5000*5000

사이즈였고

별 차이 없었어

[익명(124.57)]

[엘제에(purple8cloud)]

하드웨어인스턴싱이랑은 머가다른거임??

[와따따(csh0403kr)]

거의 똑같지

[익명(175.126)]

이.. 이기뭐꼬

[익명(221.146)]

바둑판으로 쪼개서 그 한칸마다 정보를 담아서 캐릭터가 있는 칸들만 그려준다는 거임? 이렇게 되면 캐릭터가 자연스럽게 이동을 못하잖아 옆칸으로 이동할때 갑자기 칸을 순간이동하게 되는거지 부드럽게 이동을 못하는거 아님? 내가 잘 못 이해가고 있다면 알려줘

[익명(221.146)]

그리고 깊이버퍼도 사용못하는거 같은데 누가 뒤에있고 앞에있는지도 불가능할텐데 그냥 무슨 아이디어인지 내가 정확히 이해를 못하는거 같아서 자세히 설명해주면 ㄳ

[와따따(csh0403kr)]

이동하는 건 a*로 구현했고 캐릭터 이동은 메쉬 버텍스 값에 런타임에서 가중치를 넣으면 부드러운 이동이 가능해 깊이 버퍼는 uv 순서 변경으로 처리할 수 있어 깊이 버퍼는 더 연구할 수 있을 것 같아

[와따따(csh0403kr)]

참고로 캐릭터 하나하나에 이미 깊이버퍼가 적용되어 있어 몸, 두상, 앞머리, 뒷머리 전부 다른 텍스쳐야

[익명(221.146)]

메쉬를 배치하는데 어떻게 각 메쉬를 따로 이동이 가능함? 그러려면 배치하기전에 부분 메쉬를 이동시킨다음 다시 배치시키고 드로우 콜을 해야되는건데 부분메쉬들이 많아지면 그 부분 메쉬를 각각 이동시킨 다음 배치하는데에 드는 오버헤드가 더 큰거 아님? 다시 말하지만 너의 아이디어가 흥미로운데 어떤식으로 구현이된건지 내가 정확히 이해를 못하고 있는거 같다

[익명(221.146)]

어느정도는 배치 전에 매쉬를 변경하는식이 성능에 큰 영향은 없지만 너의 아이디어처럼 몇만개를 배치하는 성능상의 이점을 내세우려면 그 몇만개가 전부 따로 이동할 수 있어야 된다는 얘긴데 그러려면 오히려 그 몇만개를 일일이 배치시켜주는 로직이 훨씬더 무거워질거기 때문에 그냥 배치를 안하고 변경시킬 메쉬들만 그때그때 처리해주는게 더 나을텐데 아무리 생각해도 캐릭터들이 거의다 멈춰있는게 아니라 대부분 따로 움직이기 시작하면 배치의 장점이 의미가 없어지는 거잖아 이게 유니티에서 배치할때 정적인 메쉬들을 위주로 배치하는 이유이기도 하고

[익명(221.146)]

캐릭터하나에 텍스쳐를 여러개 쌓아서 그렸다는건 프레임버퍼에서 텍스쳐를 블랜딩했다는거지? 캐릭터하나를 몸메쉬, 두상메쉬 이렇게 여러개로 나눈다음에 각각 그렸다는게 아니라?

[익명(221.146)]

내가 이해를 못하는건지는 모르겠는데 아마 너의 방식은 유니티에서 정적인 메쉬들을 자동배치함으로써 얻을 수 있는 장단점과 같아보이는데 차이점이 있다면 유니티의 인터페이스로 메쉬를 배치해주면 자동으로 분석후 필요에 따라 배칭 해준다는거고 너의 방식은 너가 직접 수동으로 배칭을 조절할 수 있다는 것의 차이 맞나?

[와따따(csh0403kr)]

일단 애니메이션까지 수동으로 만들면 비용 측면에서 엄청 큰 이득을 볼 수 있어 그리고 지금 구현 중인 게임이 오픈월드라서 Npc캐릭터들이 렌더링을 하지 않아도 시간마다 자동 움직이는 시뮬레이션을 해야하는데 Npc 수 마다 렌더링 더미 오브젝트를 까는 것보다 직접 렌더링을 제어하는 게 편하고,빠르더라

[와따따(csh0403kr)]

그리고 메쉬는 따로 이동이 가능해 하나의 게임 오브젝트에 사각형 메쉬가 100개 있다고 배칭을 200번 하는 게 아니잖아? mesh의 버텍스 배열의 크기가 4면 삼각형 2개 8에 삼각형 4개…

[와따따(csh0403kr)]

유니티 하드웨어 인스턴싱를 직접 수동으로 구현한거지 단지 나는 게임 오브젝트가 필요 없어서 비용이 크게 절감된거고 내 하이라키 창에서 test오브젝트 단 한개가 캐릭터 1만 개 렌더링을 담당하고 있어

[익명(123.108)]

개념상 gpu 로드를 cpu로 처리하는거 같은데 굳이 그럴 필요 있을까

[와따따(csh0403kr)]

렌더링 자체는 gpu로드가 맞아 버텍스, uv, 삼각형을 계산하고 만드는 건 결국 cpu에서 처리하는 거니까

[Kaonuri(hon454)]

이거 엔진에서 해주는 기능인뎅

[와따따(csh0403kr)]

엔진에서 한 번 돌리는 것보다 스크립트 상에서 수동 제어하는 게 훨씬 가벼워 접근성도 뛰어나고

[Kaonuri(hon454)]

이렇게 하면 배치/드로우콜의 횟수는 줄어들지만 한번에 소모되는 연산량이 높아져서 실질적인 성능은 프로파일링을 해봐야 할 것 같은데 유의미한 차이가 있는지 궁금하네

[와따따(csh0403kr)]

큰 차이는 없지 유니티도 하드웨어 인스턴싱 할 때 버텍스, uv 연산은 똑같이 할 테니까 오히려 게임 오브젝트를 통해 엔진 내부에서 도는 게 아니라서 더 빠를 지도 몰라

[와따따(csh0403kr)]

유니티는 100개 오브젝트의 하드웨어 인스턴싱을 하려면 오브젝트 100개를 하이라키 창에 올려야 하는데(메모리가 올라가지) 내가 구현한 경우에는 오브젝트 단 한 개로 하드웨어 인스턴싱 1만 개를 연산하니까

[와따따(csh0403kr)]

연산을 멀티스레드로 돌리면 눈에 띌 정도로 빨라질 것 같은데

[익명(123.108)]

이런건 렉이 걸릴만한 게임부터 만들고 나서 해