요새 작업 내용입니다. 프로젝트 엡실론을 진행할때 엔진과 맵툴을 비롯한 엔진관련 툴들 코드를 대부분 제가 작성했습니다. 전체 코드의 95%정도라고 생각하는데 제가 작성하지 않은 코드중 한 부분이 삼각형에 대한 충돌처리 부분입니다. 정확히는 팀 동료가 초기 수학함수를 c코드로 작성했고 그걸 제가 가공했습니다. BSP트리를 이용한 삼각형 검출 코드를 추가하고 멀티스레드 버젼으로 작성했습니다. 또한 intel SSE를 사용하도록 x86/x64어셈블리코드로 재작성했죠. 라고 … More 삼각형 충돌처리 코드 작성중

일전에 언급한대로 라이트맵의 경계 부분, 금가는 부분들을 부드럽게 처리하는 작업을 진행중이다. 삽질 끝에 대충 완료. 아직 이슈가 많긴 한데 그냥 이 정도로 마무리 지으려 한다. 1. 라이트맵을 스크린 스페이스에서 블러링 한 다음 프로젝션으로 입혔다. 2. 블러링 효과를 높이기 위해 1/4 사이즈로 다운스케일과 업스케일을 하여 블러 필터를 걸었다. 3. 최종 텍스쳐 합성 시에 depth버퍼를 참조해서 엣지라고 … More 라이트맵 블러링

라이트맵을 직접 만들어서 구워보면 엣지 부분이나 오브젝트 잘리는 부분에서 금이 가는 현상을 볼 수 있다. 이건 사실 맥스에서 구워도 완전히 해결할 방법은 없다. 티가 덜 나게 할 뿐인데 라이트맵의 uv좌표를 디자이너가 직접 펼쳐준다면 확실히 좋은 효과를 볼 수 있지만, 그건 내가 추구하는 방식이 아니므로 어떻게든 자동화시키려고 했다. 처음엔 지오메트리를 3차원상에서 어떻게든 가공해서 처리하려고 했다. 별 짓을 … More 라이트맵 엣지 블랜딩 관련

라이트맵을 구현해 보신 분들은 아실겁니다. 시각적으로는 연결되어있는 오브젝트라도 기하구조상으로는 잘려있는 경우라든가 매쉬의 모서리 부분이라든가 라이트맵을 적용할때 어쩔 수 없이 금이 가는 현상이 있습니다. 오브젝트를 자르고 오브젝트 안에서 면을 펼쳐서 라이트맵의 uv좌표를 부여하다보면 인접한 매쉬가 반드시 인접한 텍셀을 가지도록 보장할 수 없습니다. 즉 모서리를 기준으로 바로 옆의 삼각형이지만 라이트맵 텍스쳐 상으로는 멀리 떨어진 텍스쳐 공간일 수 … More 요새 하는 작업

먼저번에 글을 올릴 당시엔 Height Field에 대해선 ambient occlusion이 적용되지 않던 상황이었다. 오늘까지의 작업으로 Height Field에 대해서도 ambient occlusion을 적용시켰다. 멀티스레드를 지원하고 계산 알고리즘을 최적화했다. 테스트에 사용된 맵의 경우 처음에 2시간 기다리다 포기. 몇 시간이 걸릴지 예상도 할 수 없었다. 다음날 알고리즘을 최적화하고 멀티스레드를 사용하고 8분 정도만에 빌드를 마쳤다. 여기에 필드 계산을 추가하고 몇 가지 … More 라이트맵 계산시에 Ambient Occlusion적용하기 #3

먼저는 간단한 모델에만 적용해봤는데 이제 좀 복잡한 맵 데이타에 적용해봤다. 당연히 너무 느려서 처리가 불가능할 정도. 한시간 넘게 기다리긴 싫어서 코드를 수정했다. 라이트맵 텍셀이 변경될 때마다 이진트리를 검색해서 삼각형을 가져오던 방식을 비슷한 평면상의 라이트맵 패치 그룹단위로 삼각형을 가져오는 방식으로 변경했다. 레이 충돌검사시 이전에 충돌했던 삼각형은 재충돌 가능성이 높으므로 삼각형 리스트의 가장 앞쪽으로 가져와서 검색 우선순위를 … More 라이트맵 계산시에 Ambient Occlusion적용하기 #2

몇 주전 kasa세미나에서 스크린스페이스에서의 Ambient Occlusion처리 방법에 대한 세미나를 들었다. 사실 난 Ambient Occlusion이 뭔지 몰랐다. 전혀 관심이 없었으니까. 발표자 분이 너무나 쉽게 설명을 잘 해주셔서 개념을 쉽게 이해할 수 있었다. 설명을 듣고나니 스크린스페이스에서 적용할 경우 당장이라도 지금 엔진에 적용할 수 있을것 같았다. 그런데 내 엔진의 경우는 라이트맵을 베이스로 사용하기 때문에 일단 라이트맵 구울때 Ambient … More 라이트맵 계산시에 Ambient Occlusion적용하기

셀프쉐도우를 넣기 위해서 손을 대기 시작한게 cascade shadow maps까지 와 버렸다. 일단 캐릭터를 위한 그림자로선 충분히 효과를 얻었으나 내친 김에 전체 씬을 cascade shadow maps으로 다 덮어버리면 어떨까 해서 이리저리 실험을 해봤다. 역시나 문제가 있는데 cascade된 뷰프러스텀 별로 depth bias가 달라질 필요가 있는데 도저히 수동세팅으론 맞출 수가 없다. ddx,ddy명령을 이용해서 텍셀 샘플링할때 최적의 bias를 구하는 … More 그림자 개선중#3 – Cascade Shadow Maps

어제 15시간동안 매달려서 멀티스레드 렌더링 코드 싹 들어내고 VSM을 이용해서 소프트쉐도우를 구현해봤다. 그럭저럭 괜찮은데 문제가 있다. 1. 라이트맵을 사용하기 때문에 움직이는 개체들의 그림자만 드리우려고 한다. 따라서 쉐도우맵에는 움직이는 개체들의 깊이값과 그 제곱만 기록한다. 즉 라이트맵을 사용하는 건물과 필드 오브젝트들은 쉐도우맵에 아무것도 기록하지 않는다. 기존 쉐도우맵 비교 방식이면 상관이 없는데 vsm의 경우는 체비셰프 부등식으로 그림자 색을 … More 그림자 개선중#2

전에는 셀프쉐도우를 사용하지 않았다. 처음에는 사용하려고 했으나 테스트를 해봐도 영 이쁘게 나오지 않았다. 기본적으로 만화풍 그래픽인데 셀프쉐도우를 써서 득될게 있나 싶어서 아예 사용하지 않았는데 요새 아이마스나 이런저런 카툰풍 게임들을 보면 셀프쉐도우가 깔끔하게 나오는것 같다. 셀프쉐도우를 쓰려면 쉐도우맵의 해상도 문제도 있고, 또 그림자의 계단현상도 해결해야하겠다는 생각이 들었다. 그냥 이 참에 그림자 코드 왕창 갈아엎기로 결정. 1. … More 그림자 개선중