블로그 이미지
˙Jisoo

카테고리

분류 전체보기 (72)
Programming (33)
Game Project (14)
Daily Life (12)
Photo Shots (11)
Total11,466
Today26
Yesterday77
기능들을 합쳐갈수록 하나만 있을때 발생하지 않던 문제점도 생기고 신경써줘야 할 부분이 많아지네요.
지형시스템 뒤로는 맵에 배치할 것들을 만들어주려고 하는데 이제 최적화에도 신경을 써야 할 때 같습니다~
지형시스템에서 카메라의 시야에서 보이지 않는부분은 아예 렌더링을 안해서 프레임을 확보 할 예정입니다.
아직 구현방법은 생각해보지 않았는데 좀 빨리 해놓을걸 이제야 하려니 귀차니즘의 발동과함께 작업속도가..............ㅠ.ㅠ
일단 급한건 오브젝트에 애니메이션을 불러오는쪽을 해결봐야겠네요..
지금은 단순히 X파일에서 오브젝트의 버텍스 정보만 얻어오는 수준이라서 아무것도~~없구요
현재 메쉬정보들이 각각 클래스 안에 있어서 몬스터가 많아지면 많아질수록 메모리도 많이 잡아먹는데 몬스터클래스와 오브젝트 정보를 관리할 매니저클래스를 따로 만들어서 메모리를 아껴야 할 필요가 느껴지네요. 3D 메쉬 사이즈가 생각보다 어마어마하더군요..;;

일단 다른 특별한 기능은 없고 지형 클래스에서 getHeight 으로 높이를 구해서 특정 높이 아래 지역에서만 테스트용 모델을 뿌려줬습니다.
그리고 렌더링 하는 부분에서 카메라와의 거리를 측정하여 특정 거리를 넘어가면 렌더링되지 않게 아주 기본적인 처리를 해줬습니다..
이걸 응용해서 카메라와의 거리를 레벨별로 나누고 먼 레벨일수록 모델의 섬세함을 떨어트려서 LOD를 구현 할 예정입니다. (이렇게 하는게 맞는지는 모르겠습니다 ㅡ,.ㅡ;;)



포그를 끄고 확인해보았습니다.
MMORPG 같이 아주 방대한 크기의 게임에서는 필드간의 이동시 로딩도 없애려고 쓰레드를 사용하여 카메라의 범위 내에 들어오기 전에 맵의정보나 로딩이 비교적 긴 파일들을 로딩해온다고 하더군요..
그래서 좀 느린 컴퓨터에서 전혀 안보이던 물체들이 한순간에 생기곤 하나 봅니다.. ^^;





포그를 켰습니다.
포그가 있어도 간혹 모델의 크기가 큰 경우에는 안개속에서 갑자기 뿅 튀어나오는 경우가 있는데
카메라와 거리측정시 모델의 중심과 거리를 재기때문에 거리에서 모델의반경을 빼주니 간단히 해결이 됩니당.


갈길은 먼데 요즘들어 밀려오는 귀차니즘과 FM에 다시 빠져버려서 속도가 너무 더뎌지네요... ㅠ.ㅠ
Posted by ˙Jisoo

댓글을 달아 주세요







이번에는 멀티텍스쳐링과 안개 기능을 넣었습니다.
처음에 멀티텍스쳐링이 안되서 고생을 했는데 알고보니 멀티텍스쳐의 레이어의 개수만큼 지형을 렌더링해줘야되더라구요.
뭐가 잘못되서 그렇게 되는건지 원래 그런건지는 잘 모르겠지만 원래 이런거라면 쓸데없는 연산이 너무 많아져서 나중에 손을 봐야겠네요..
이런 쓸데없는 연산낭비를 해결하기위해 보통 쉐이더로 텍스쳐스플래팅을 구현하는 것 같습니다.
나중에 LOD 구현을 할때도 쉐이더가 필수적이라 LOD 작업 할 때 쉐이더를 적용 할 예정입니다.
LOD가 적용될 때 버텍스가 사라졌다 나타났다 하기때문에 uv좌표가 손실되서 쉐이더가 필수적이라고 하는 것 같습니다.





전에 올렸던 산 맵을 불러온 화면.
현재 텍스쳐들의 상황을 보자면...
모래바닥   --- BaseTexture
풀            --- Blending Texture
풀#           --- Blending Texture Alpha Map
바위         --- Blending Texture
바위#        --- Blending Texture Alpha Map
라이트맵    --- Light Map

이런 구조로 텍스쳐가 로드되어있고

모래바닥 (modulate) 라이트맵
지형 렌더링  // 1pass
풀 * 풀# (modulate) 라이트맵
지형 렌더링 // 2pass
바위 * 바위# (modulate) 라이트맵
지형 렌더링 // 3pass

이런 순서로 렌더링 되고 있습니다.

풀#,바위# 알파맵은 따로 그래픽툴에서 그리는 것이 아닌 자동으로 알파맵이 생성됩니다.
기준은 경사입니다.
평지와 이루는 경사가 가파른부분에 바위를 칠하고 그것보다 조금 덜 가파른곳에 풀을 칠하는 형태입니다.
아래는 풀# , 바위# 알파맵입니다.

   


왼쪽이 풀# 알파맵이고 오른쪽이 바위# 알파맵입니다.
검은부분은 텍스쳐가 적용되지 않고 하얀색으로 갈 수록 텍스쳐의 진하기가 강해집니다.




확인을 해보기 위해 테스트용으로 만들어놓았던 맵파일입니다...
이렇게보니 의도를 파악하기 쉽죠?






덕분에 이런 거칠은 지형도 그냥 지형맵만 만들어주면 알아서 텍스쳐 알파맵을 생성해주니 굉장히 편합니다.
텍스쳐 알파맵 자동생성은 이렇게 두세겹 적용 / 경사기반 까지만으로 해두고 다른 프로그래밍에도 좀 투자를 한 뒤 나중에 여유가 생길때 마다
여러 공식을 만들어서 자동지형생성 알고리즘을 새롭게 만들예정입니다.
풍경보는걸 좋아해서인지 다른것보다 지형에 집착이 강합니다...ㅎㅎ;
Terrain.Render(float age = 30.0f) 이런식으로 하면 지형의 30년 후 변화된 모습이 렌더링되도록 age 기반의 지형시스템을 꼭 만들고 싶습니다 @_@;



아 참... 안개기능에 대해서 안썼는데 정말 써보려고하니 쓸게없네요............;;
그냥 다렉에 기본으로 있는 기능으로 쓴거라...
다음에 쉐이더를 이용한 멋진 안개를 만들면 그때 또 써보도록 하겠습니다...!
Posted by ˙Jisoo

댓글을 달아 주세요



외부지형데이터를 raw 파일로 받아서 높이를 지정하도록 하였습니다.
인덱스버퍼 포맷을 변경하여 더 큰 지형을 생성할 수 있도록 하였습니다.
기존에는 16비트 WORD 로 받았는데 256 * 256 크기의 지형에서 크기를 초과하여 끝부분 표현이 제대로 안되었는데
32비트 UINT 로 바꿔줌으로써 훨씬 큰 지형이 표현 가능하게 되었습니다. 이렇게까지 필요한가 싶지만;; 나중에 최적화가 필요하면 조금 낮춰야겠네요.
테스트 해본결과 1024 * 1024 보다도 더 큰 타일 갯수에서도 인덱스를 잘 잡아주고, 지금 계획으로는 1 타일의 단위가 1제곱미터로 작게는 128 * 128 로 시작해서 커봐야 512 * 512 정도의 맵을 사용 할 예정이기에 충분하다고 생각되네요.
Posted by ˙Jisoo

댓글을 달아 주세요

최근에 달린 댓글

최근에 받은 트랙백

글 보관함