예전부터 써오던 방식인데 3D 모델을 2D 스프라이트로 변환해서 주로 쓰곤 했었음.
3D모델을 2D 형태로 굳이 변환시켜 성능이나 조작감을 조금이라도 높여 보고자 해서 쓰게 됐고
리소스가 부족하거나 할 때도 유용하게 쓰고 있음.
툴은 유니티 에디터 스크립트로 만들었고
개념은 단순하게 3D 모델을 애니메이션을 통해 동작 시키고
카메라 화면의 텍스쳐를 일정 프레임마다 저장해서 하나의 png파일로 만들어 Sprite화 해서 쓰는 방식이라고 보면 됨.
이런 모델을 애니메이션을 통해 동작시켜 텍스쳐를 저장하게되면
대충 이런식으로 Sprite로 만들 수 있고,
이걸 다시 2D 애니메이션 클립으로 만들어서 쓰고 있음.
필요를 못느껴 엄밀하게 3D 모델과의 성능차이를 검증하진 않았지만
당연히 빠를거라 생각은 되고, 리소스가 부족했을 때 활용하기에도 좋음.
혹시나 리소스에 허덕인다면 위에 개념을 적용해서 3D 모델을 가져다가 2D로 변환시켜 활용해보자
으음.. 그럼 특정 동작을 수정할 경우 다시 전부 변환..?
대신 메모리 공간을 많이 차지함.
어떤모델을 어떻게 비교했길래 메모리 공간을 많이 차지한거야??
그래픽 메모리 얘기임. 스프라이트 종류가 많으면 알게 됨.
많으면 당연히 많이 차지하는데 3D 모델이랑 비교해봤을 때 많이 차지한다는 의미 아님?
이미지 해상도, 프레임 수를 봐야하는데, 예시로 보여준 게 기준이면 2d가 더 많이 차지할 거임. 근데 엥간한 컴퓨터로는 다 감당 가능할거임.
...? 뭐 일단은 어떻게 했는지 모르겠지만 캡쳐화면 가지고 resolution이라던지 폴리곤 수를 추측해서 비교했나봐.
내가 몇 년전에 모바일환경에서 테스트했을 때 두 배 이상의 오브젝트수 차이로 프레임방어가 되는걸 확인했었는데. 조금 이상하네
프레임 방어는 되지. 공간 최적화의 얘기임.
내가 예전에 저 방식으로 했다가 vram용량이 생각보다 많이 차지했음. 동작은 잘 됐지만 사용자 입장에서 이 정도 그래픽이 이 만큼의 vram을 차지할 정도인가 라고 생각할 거 같아서, 그 이후로는 그냥 얌전히 도트 찍었음.
이게 도대체 무슨 헛소리야;;; 개발자는 맞아??
"3d모델 애니메이션을 2d 스프라이트 애니메이션으로 바꾸면, 스프라이트의 해상도와 프레임 수에 따라 공간을 더 많이 차지할 수도 있다"라는 소리임. 헛소리 같아 보였으면 무시해도 됨. 뭐 나쁘다고 말하는 것도 아니고 그냥 이 방식에 이런 특성도 있으니 유의하란 말임.
아니 위에는 "대신 메모리 공간을 많이 차지함." 이라고 아주 당당하게 말하더니, 얘기가 점점 쪼그라드네?
그리고 어떻게 캡쳐했는지도 자세히 얘기안했는데.. 뭐가 못마땅하셨을까?
슈퍼마리오 원더같은 2d 마리오가 아마 저런 방식활용할거임 - dc App
근데 성능에 대한건 생각을 해봐야하는데 카메라를 자유롭게 돌릴 수 있는지, 다양한 애니메이션이 필요한지에 따라 저 방법이 오히려 손해일 수 있음 - dc App
글쿤. 난 하데스 보고 따라했었는데
당연하게도 2D게임에 쓰이는거지 무작정 이 방법이 좋은게 아님. 3D 게임을 대체하세요 이런게 아니라 2D 게임에 쓰일 리소스를 이런식으로도 만들 수 있다가 취지임
카메라가 고정된 게임이라면 저 방식이 엥간하면 더 저렴함 저거 찍고 하는게 귀찮아서 그렇지 ㅋㅋ - dc App
그나저나 저거 에디터 더 개선하면 수요 있을 듯 - dc App
나도 아이소메트릭 고정 쿼터뷰인데 장식 같은 거 저렇게 처리해볼까.. 최적화 에셋 중에 페이크 3D랑 비슷한 맥락 같기도 하고
멀티겜 정도 아니면 성능이 솔직히 상관 있는 문제인가