J s - A l m i g h t y

게임중 배경음악을 관리할 수 있는 Jukebox를 제작중입니다.
PES2010, FIFA10 같은 게임에서 볼 수 있습니다.
(주로 EA의 게임에서 많이들 나오지요.. 플레이어수준 까지는 아니고 간략히 재생중인 음악 정보를 보여주는 정도..?)
그보다는 조금 더 상세한 정보와 기능을 넣어보려 합니다.
일단 irrKlang이 사용하기 편리하게 되어있기에 제작하는데 큰 무리는 없어보입니다.
다만 음악파일의 PositionSeeking시 부하가 조금씩 걸리기에 Jukebox는 따로 스레드를 사용해줘야 할 것 같네요..
지금은 간단한 기능들만 있습니다.
이제 요놈들을 바로 출력하지 말고 텍스쳐에 저장했다가 게임도중에 적절한 순간에 튀어나오도록 해줘야겠네요~

이전 포스트에 써야 할 내용인데 동영상도 있고 해서 따로 포스트를 작성합니다.






좀비(..;;) 사이사이로 검은색 막대기 같은 것이 보이시나요?
단순 Bounding Sphere 를 이용하여 전체를 감싸는 충돌판정을 해줬었는데 좀 더 세밀하게 조정해주었습니다.
일단 뼈대의 변환행렬을 가져올 수 있어야 합니다. (이전 포스트에서 손에 무기를 쥐어주는 방식으로..)
그리고 해당 뼈대의 모양에 맞게 이쁘게.. x,y,z로 충돌처리 해줄 메쉬를 늘려주고 변환행렬을 곱해 적용시키면 됩니다.
보통은 Box 형식으로 뼈대크기대로 적용하는걸로 보아왔었는데, 제가 적용시켜 놓은것은 Sphere입니다..
모양만보면 절대 Sphere가 아닌데.. Face수를 적게해줘서 저런모양이 나오도록 해줬습니다.
솔직히 Box만들기가 귀찮아서 테스트겸 Sphere로 대신하려고 하였는데 사람형태의 메쉬에는 오히려 Box보다 찌그러트린 Sphere가 잘 맞는 것 같습니다 ㅡ,.ㅡ;;

아, 그리고 이렇게되면 충돌판정 연산수가 기하급수적으로 늘어나게 되지요.
그림에 나온 좀비의 세부 충돌판정용 Sphere의 수는 16개입니다.
만약 좀비가 20마리라면 320번의 연산을 해줘야하는 경우가 생기지요..
그러므로 Bounding Sphere를 이용하여 연산 수를 줄여줘야 합니다.
처음엔 뼈대정보도 얻어올 필요 없이 그냥 좀비의 위치만 얻어오고 좀비 메쉬의 크기만한 Bounding Sphere와의 충돌을 판정합니다.
만약 이전 단계가 참이라면 그때 세부 충돌판정을 해 주면 되겠지요.. 위의 그림처럼 타겟부분에 유효한 좀비가 하나만 들어왔다면
연산수는 320번에서 35번으로 확 줄어들게 됩니다.
꼭 세부충돌판정을 또다른 충돌판정으로 접근하진 않아도 됩니다. 방식에는 여러가지가 있지요~
전체 지도의 몬스터가 매우 많고 화면에 분포는 적을경우에는 세부충돌판정을 위해 Bounding Sphere를 사용하는 것 보다 현재 카메라의 View행렬, Projection 행렬 정보를 통해 보이지 않는 각도는 아예 제외시켜버리는 방법도 있습니다.

 

우선 최근까지 작업물의 결과 동영상입니다.
포스트가 올라오지 않은 날 동안 진행된 작업은..


높이맵이 아닌 오브젝트들의 높이도 참조하도록 하였습니다,
위치에 따라 여러개의 높이값들이 있을경우 (동일 위치에서 계단의 위/아래 등..)
현재 캐릭터의 높이에 따라 적절하게 높이를 선택하여 적용하도록 하였습니다. (계단 위로 올라갈 경우는 계단 위에 있게되지만, 아래로 지나갈경우의 높이는 지형높이를 참조)
여기는 별로 문제가 없는데 모서리부분에서 걸리적거리는 현상이 있습니다.
충돌판정시 오브젝트 끼임/뚫고지나감 현상 때문에 offset을 추가했더니 이렇게 걸리는 문제가 생기네요.
해결책은 있지만 처음부터 싹 갈아 엎어야 하는 상황이라...ㅠ.ㅠ;;


적의 충돌검사 판정 세밀화.
요곤 다음 포스트에 동영상과 함께 다시 올리겠습니다~




뼈대의 변환행렬 접근을 용이하도록 하여 뼈대에 다른 메쉬 부착 ( 여기선 손에 총 모델이 되겠지요 )
스키닝메쉬를 적용하면서 렌더링시 마다 변환행렬과 뼈대오프셋행렬 정보를 얻어오게 되는데, 다른 클래스에서 특정 뼈대정보를 참조하도록 검색용 메소드를 하나 더 만들어주었습니다.
현재는 부모노드에서부터 자식노드로 계층적으로 돌면서 뼈대이름이 맞나 확인하는 방식으로 되어있는데, GetBoneName() 같은 함수처럼 바로 뼈대정보를 얻어올 수 있는 방법은 없는지 더 고민을 해봐야겠습니다 ^^;
GetBoneID( boneName ) 과 같은게 미리 있으면 좋을텐데요

그리고 무기관리클래스를 추가하여 여러가지의 무기를 게임중에 수시로 바꾸며, 고유 속성을 갖도록 해주었습니다.
일단 지금 무기 고유 속성들을 보자면..
무기모델, 분당발사속도, 반동세기, 파워(데미지), 사운드파일, 연사가능여부(권총,저격총과 같은 경우 한 발 발사되면 마우스 왼쪽버튼을 Up시켜줘야 누르고 있을 때 계속 총이 나가는 현상이 없어지겠지요) 가 있네요.




간단한 파티클 시스템.
파티클 시스템을 만드는 것에는 문제가 없었지만 적의 충돌판정 확인 후 정확한 포지션을 얻어오는게 힘드네요..
지금도 완전하진 않습니다. 편법적인 계산으로 되어있는 상태지요..ㅠ.ㅠ
광선을 쏴준 지점에서(Originate Ray Position) 광선을 쏴준 방향으로 (Ray Direction) 주어진 길이를 이용하려 하였는데,
충돌판정은 잘 되는데 저 Originate Ray Position 값과 Ray Direction 이 그때그때 오차가 생기지 말입니다..
역행렬을 계속 곱하다 어디서 잘못된 것 같은데.. 여기도 좀 더 연구해봐야겠네요 ㅠ.ㅠ




쉐이더 기반 텍스쳐 스플래팅.
그전에 지형을 만들면서 스플래팅 효과를 내려고 했을땐 참 여러모로 낭비가 심했던 것 같습니다..
Multi Layered Terrain 말그대로 지형을 해당 텍스쳐마다 알파값을 적용시켜 여러개를 그려줬었습니다..
지형 하나에 2개의 레이어만 추가되어도 3번의 지형을 렌더링 해줘야 하는 낭비가.. ( Base + Layer1 + Layer2 )

그에 비해 쉐이더 기반의 텍스쳐 스플래팅은 구현도 쉽고 낭비도 없습니다.
여기서 낭비는 렌더링시 차지하는 시간도 시간이지만, 리소스 파일도 줄어듭니다..
알파텍스쳐를 알파값으로 이용하지 않고 rgb 값으로 이용을 해 주면 알파텍스쳐 한장에 적어도 3가지의 알파채널을 가질 수 있는 셈이지요.
이게 위의 게임(?)의 알파 텍스쳐입니다.
Base에 2개의 Layer를 사용하는데, 알파값 대신 위처럼 RGB를 다 써서 알파맵을 절약하자는 것이지요.
여기에 초록색을 추가하면 3개의 Layer를 사용하게되고, png형식으로 저장하여 알파채널까지 쓸 경우엔 4개의 Layer을 한 텍스쳐로 처리 할 수 있겠지요. 쉐이더에서 float4는 .rgba 니깐 말이지요~









열심히 코딩하고 나면..
뿌듯함과 동시에 밀려오는 스트레스(열심히 한 것 같은데 결과물을 보면 어째.... 코딩할수록 버그가..)...
그래도 프로그래밍의 목적이 약간의 뿌듯함이 모여 큰 성취감을 느끼는 것 아니겠습니까...ㅎㅎ;