본문 바로가기

글

 (20)
DailyStudy_블랜더의 장점 블랜더의 가장 큰 장점은 뛰어난 실시간 렌더링인 것 같다. 맥스와 같은 기존 모델링 툴에서는 렌더링 하는데 시간이 꽤 걸린다. 간단하게 렌더링하면 퀄리티가 좋지 못하다. 반면 블랜더는 실시간 렌더링 결과가 정말 뛰어나다. 최종 결과물과 거의 비슷한 퀄리티를 실시간으로 볼 수 있다. 이게 블랜더의 가장 큰 장점이다. 내 일이 전부 모델링뿐이라면 모를까 대부분 모델링에서 텍스처링까지 하고 엔진에 넣어보는 작업을 하게 된다. 그럴 때면 내가 맞는 방향으로 가고 있는지 확인하기 위해 한번씩 렌더링을 걸어보는 작업이 중요하다. 그럴 때 맥스는 좀 불편하다. fbx를 따로 가져가서 따로 렌더링을 해봐야 한다. 렌더링 세팅을 해줄 수 있지만 그러면 파일이 필요 이상으로 무거워진다. 블랜더는 파일도 가벼우면서 실시간 ..
DailyStudy_19_블랜더 렌더 패스 블랜더로 컨셉아트를 그리고 있다. 렌더패스가 생각보다 더 유용하게 쓰인다. mist가 기본적으로 근경과 원경을 확실히 나눠줘서 너무 좋고, 처음부터 3D 메쉬에 매핑하면 될 것을 귀찮아서 안 하고 포토샵으로 텍스처를 입히고 있는데 이게 그냥 했다면 미친짓이었겠지만 렌더패스로 노말을 뽑아서 하니까 할만하다. 그리고 뽑은 노말 z 축을 마스크로 걸어서 색을 칠해주니 위에서 내리 쬐는 빛의 영향을 표현하기 정말 편하다. 그냥 무작정 오버레이로 뽑으면 좀 어색하게 나오는데 이건 정말 괜찮게 나온다. 블랜더 짱
DailyStudy_18_버그 수정 처음에 플레이어 캐릭터를 더미로 세워두고 테스트를 하다가 AI로 따로 진화한지 얼마 되지 않았다. 그래서 아직 버그가 계속 나온다. 체력부분에도 버그가 있다. 일반 공격을 할 때는 멀쩡한데 특수 공격을 하면 플레이어와 AI의 체력이 동시에 깎인다. 하...그래도 지금 발견하고 고치고 있ㄴㄴ게 참 다행이다.
DailyStudy_17_블루프린트_Decorator 블루프린트 최적화를 하면서 대부분 다 고쳤는데 버그가 하나 남았다. 비헤이버 트리에서 wait 노드가 문제다. 1.7초 이상 기다리면 버그가 일어난다. 정확히 1.7초다. 만약 wait 노드를 꼭 써야 한다면 1.7초는 무조건 넘길 것이다. 그래서 wait 노드를 쓰지 않는 방법을 생각해봤다. 아마도 Decorator를 쓰면 될 것 같다. 기존의 태그로 캐릭터 액션과 스테이트를 정의하는 시스템과 업데이트 비헤이버 함수를 통합하려고 했었는데 wait를 안쓰고 뭔가 잘 할 수 있는 방법이 뭐가 있을까 고민을 해보니 Decorator를 쓰면 될 것 같았다. 함수 내에서 태그를 검사하는 것보다 비헤이버 트리에서 데코레이터로 태그를 검사하는 기능을 만드는게 더 범용성 있고 AI별로 적용할 수 있고 좋을 것 같았다..
DailyStudy_16_블랜더 렌더링ailyStudy_16_블랜더 렌더링 요즘은 컨셉아트를 블랜더로 한다길래 나도 블랜더로 만들어보는 중이다. 써보니 왜 다들 쓰는지 알 것 같다. 우선 프로그램이 가볍다. 기존의 3D 툴이나 렌더링을 할 수 있는 게임 엔진, 마모셋 같은 프로그램은 무거운 편이다. 기본 용량도 크고 그 안에서 할 수 있는 작업도 많은만큼 부하가 크다. 반면 블랜더는 용량 자체가 굉장히 작다. 반면 성능은 필요에 따라 기존의 프로그램들과 동일한 모습을 보여준다.렌더링 퀄리티가 괜찮다. 프로그램이 가볍고 무겁고 간에 렌더링 퀄리티가 좋지 않았다면 안 썼을 거다. 렌더링 퀄리티가 괜찮다. 렌더링 속도도 좋은 편이다. 가볍게 좋은 렌더링 퀄리티를 뽑을 수 있다보니 간단하게 작업을 하고 바로 포토샵으로 넘겨서 작업을 하거나 아니면 블랜더에서 더 퀄리티를 높이기도 한다...
DailyStudy_15_캐스팅 제거 블루프린트를 계속 최적화하고 있다. 지금 최적화를 한번 한 게 다행이다. 꼬인 게 그리 많지 않아 쉽게 풀 수 있었다. (나중에 ㅇ이걸 하려고 했다면 와우...) 덕분에 casting을 사용하지 않는 다양한 방법을 시도해보고 있다. Game State Manager 시스템을 도입했다. 원래 두 캐릭터가 서로 casting 하면서 정보를 공유했는데 메모리를 많이 잡아먹고 오류가 많이 나서 프로젝트가 꺼지기도 했다. 그래서 둘의 정보를 Game State 클래스 블루프린트에서 관리하고 두 캐릭터는 각각 begin play에서 state manager를 변수화해서 사용한다. 메모리 문제도 없어졌고 코드도 더 읽기 쉬워졌고 무엇보다 나중에 AI가 플레이어의 공격을 피하는 동작을 만들 때도 도움이 될 것 같다. ..
DailyStudy_14_ 래그돌 디버깅 다른 시스템을 마저 만들기 전, 이미 만들어 놓은 시스템을 점검하면서 최적화하고 고칠 부분은 고치고 있다. 최적화는 생각보다 문제는 없었다. 몇가지 틱 이벤트만 지워주고 casting 몇개만 없애주면 지금 할 수 있는 일은 다 했다고 볼 수 있다. 검사 해 봤을 때도 레퍼런스 의존도가 심하지 않았고 메모리 대부분은 텍스처와 애니메이션이었다. 래그돌에는 문제가 조금 있었다. impulse가 두번 적용되는 문제가 있었다. 디버그 목적으로 print string을 중간중간 잘 넣어 놓은 덕분에 빠르게 고칠 수 있었다. 컴포넌트의 일부에서 변수를 공유하는 바람에 오류가 난 것 같았다. 변수를 분리해주니 문제가 사라졌다.  래그돌 상태일 때 카메라가 플레이어를 따라오지 않았다. 래그돌 상태에 진입하면 멈추고 다시..
DailyStudy_13_Casting, Tick 사실 프로젝트가 크지 않기때문에 그렇게까지 많은 노력을 기울이지 않아도 큰 문제는 없다. 그래서 괜히 귀찮아지고 고쳐야하나 싶은 부분이 많기도 하다. 그러나 두가지는 꼭 짚고 넘어가야 좋을 것 같다. Casting과 Tick이다. Casting은 의존성을 지나치게 높이고 똑같은 애를 여러번 캐스팅하면 문제가될 수있다. Tick은 매 프레임 계산이 들어가기 때문에 문제가 된다. 특히 블루프린트에서는 C++과 다르게 Tick 이벤트의 부하가 심하다. 이 두개는 무조건 개선하고 나머지는 깔끔하게 정리만 하려고 한다. 지금도 충분히 잘했다. 아마도..?

티스토리툴바