안녕하세요. 처음으로 글을 쓰는 rihwan (유인환) 입니다. 사실 이렇게 글을 쓰는 것은 참으로 오래 간만이라 살짝 어색하지만, 나름대로 열심히 써보도록 하겠습니다. 우선 간략하게 제 소개를 드리면 저는 현재 대학원에서 석사 과정으로 그래픽스를 공부하고 있고, 또 박사를 들어가려고 준비하고 있습니다. 그리고 제 주요 관심사는 Photorealistic rendering과 Real-time rendering 이렇게 주로 2가지 분야입니다. 제 공부의 목표 중 하나는 Photorealistic scene을 실시간으로 만들어내는 것이죠. 이 부분에 대해서는 나중에 다뤄보도록 하겠습니다.

앞으로 저의 목표는 Siggraph, Eurograph, 그리고 Siggraph Asia의 논문을 분석하고 또 게임에 응용할 수 있는 방법에 대해서 제 생각을 얘기하고 또 토론을 해보고 싶습니다. 하지만 곰곰히 생각해보니, 무작정 저 논문들을 이해한대로 그대로 쓰고 끝냈다가는 중간의 내용이 너무 붕뜨는 경향이 있을 것 같아 천천히 하나씩 가장 쉬운 부분부터 복잡한 부분까지 최대한 자세히 써보고자 합니다. 물론 부족한 부분이 매우 많을 것이므로, 틀린 부분을 찾으시면 과감히 지적해주시면 수정하도록 하겠습니다.

앞으로 제가 관심있게 분석해볼 논문들은

Ray Tracing 계열
 - Ray Casting
 - Simple Ray Tracing
 - Distributed Ray Tracing
 - Path Tracing
 - Photon Mapping

Character Animation 계열
 - Mesh Deformation
 - Skeleton animation

Subdivision & Level of Detail 계열

Fluid Simulation 계열

Large scale rendering 계열
 - Terrain
 - Character

Etc...

이제 잡담은 그만하고 바로 본론으로 들어가 보겠습니다. 오늘은 "Automatic Rigging and Animation of 3D Characters" 라는 2007년 Siggraph 논문입니다.

논문은 아래의 링크를 따라가시면 있습니다.
http://www.mit.edu/~ibaran/autorig/

링크에 들어가시면 비디오, 논문 (PDF), 소스 코드, 실행 파일까지 해서 모두 공개되어 있습니다. 그러니 한번 직접 실행해보시면 이 논문의 목표를 이해하는데 도움이 됩니다. 혹시나 영어로 써 있어서 움찔하시는 분들을 위해서... 우선 실행을 직접 해보기 위해서 아래의 링크를 우선 갑니다.

http://www.mit.edu/~ibaran/autorig/pinocchio.html

그럼 Windows Binary라고 있는데, zip 파일을 다운로드 합니다. 그리고 압축을 어딘가에 풀어주시고, 콘솔 윈도우를 열어 해당하는 디렉토리로 들어갑니다. 그리고 다음과 같이 쳐서 실행합니다.

"DemoUI.exe /data/cheb.obj -motion /data/walk.txt"

위의 명령에서 첫번째 argument인 /data/cheb.obj는 메쉬 데이터입니다. OBJ 파일 포맷은 3D Mesh를 정의하는 ASCII 파일 포맷으로 매우 단순한 포맷이기 때문에 자주 사용되고는 합니다. 거의 Position, Normal, Texture, Index, Material 정보만을 포함하는 문자열 포맷입니다. 그리고 두번째 argument인 -motion은 다음에 나오는 것이 에니메이션 데이터임을 의미하고, 마지막의 /data/walk.txt는 실제 에니메이션 정보만을 가지고 있습니다.

위 이미지는 프로그램을 실행한 모습입니다.

해당하는 모델 파일은 아래와 같습니다. 즉 아무 것도 없는 메쉬 파일에다가 뼈대를 끼워맞추고 에니메이션을 적용하는 것이 목표입니다.

Rigging이라는 용어를 이해하기 위해서는 기본적으로 Skeleton animation이 돌아가는 방식에 대해서 살짝 언급할 필요가 있습니다. Skeleton animation은 사람이 움직이는 방식을 본 뜬 에니메이션 방법입니다. 사람이 움직일 때 우선 근육이 뇌의 명령에 따라서 수축 및 이완을 하고 그 수축 및 이완된 힘이 사람의 뼈를 움직이게 합니다. 단단한 뼈대가 움직이면서 사람이 움직이게 됩니다. 당연히 그에 따라서 당연히 사람의 겉모습(피부, 스킨)도 움직이게 되지요. 물론 가장 정확하게 사람의 움직임을 표현하려면 근육을 시뮬레이션해야 겠지만, 그것은 사실상 게임에서는 너무 계산량이 커서 현재까지는 거의 불가능해 보입니다. 하지만 근육은 무시하고 피부가 뼈대에 붙어 있다고 생각하여 실제로 뼈대만 움직이고 피부는 뼈대를 따라 움직이게 할 수 있다면 에니메이션을 만들어내는 것이 생각보다 단순해질 수 있습니다. 위와 같은 이유로 Skeleton animation이 만들어졌지요. 여기서 피부를 뼈대에 붙이는 작업을 Rigging이라고 합니다.

다시 얘기해보면, 피부(skin)은 정점과 인덱스들로 구성되어 있습니다. 그리고 각각의 정점은 일부의 뼈대로부터 영향을 받게 되어 있습니다. (좀 더 정확한 내용을 보고 싶으시다면 Real-Time Rendering 제 2판의 76 페이지 부분을 살펴보시면 좀 더 자세히 설명되어 있습니다. 또는 해골책이라고 불리우는 IT EXPERT 3D 게임 프로그래밍을 보셔도 해당 내용이 훨씬 자세히 설명되어 있습니다) 예를들면 팔꿈치의 피부는 팔의 윗부분 뼈(윗팔뼈)와 아랫부분 뼈(자뼈 & 노뼈)의 영향을 동시에 받게 됩니다. 이와 같이 각각의 피부(정점)이 어디어디의 뼈에 어느 정도의 영향을 받는지를 설정하는 것을 Rigging이라고 합니다.

한가지 Rigging의 문제점은 모델러 또는 에니메이터분들이 Rigging을 하는데 생각보다 오랜 시간이 걸린다는데 있습니다. 또 변경하는 것도 쉽지가 않습니다. 따라서 만약 Rigging을 자동적으로 계산해낼 수 있다면 모델러와 에니메이터분들께 매우 큰 도움이 될 수 있으며, 또한 하나의 에니메이션 뼈대를 가지고 여러개의 메쉬에 바로바로 Attaching을 할 수 있게 됩니다. 이 것은 엄청난 장점이 될 수 있는 것이, 만약 에니메이션 동작 하나를 디자인해놓고, 이 동작을 여러 모델에 바로 적용할 수 있으면 게임 제작하는데 엄청난 효율성을 주게 되지요.

But! 그럼 이 논문이 주는 방법이 완벽하냐? 제가 테스트해보고 확인해본 바로는 완벽하지 않습니다. 제한 조건이 꽤나 까다롭습니다. 모든 메쉬는 closed여야 합니다. 의미는 모든 삼각형은 서로서로 완벽하게 연결되어 있으며, 어디에도 빈틈이 없어야 한다는 의미입니다. 또한 뼈대의 구조와 비슷한 메쉬의 형태를 가지고 있어야 합니다. 또한 뼈대는 미리 정의된 빼대만을 허용하고 있으며 손가락등의 디테일은 표현할 수 없습니다.

하지만 위의 단점에도 불구하고 주는 장점이 매우 크며, 약간 제한적으로 적용한다면 게임에도 적용할 수 있다고 저는 생각하고 있습니다. 그래서 이제 자세히 분석을 해보자면...

이 논문은 2개의 중요한 카테고리로 나눠져 있습니다. 첫번째는 미리 정의된 뼈대를 mesh에 끼워맞추는 작업입니다(embedding). 두번째 작업은 끼워맞춰진 뼈대를 가지고 heat diffusion 방정식을 사용해서 각 피부의 정점에 어떤 뼈대가 어느 정도의 영향을 끼치는지 계산해내는 작업입니다.

Skeleton embedding
만약 존재하는 하나의 메쉬가 있다고 했을 때 그 메쉬 안에 미리 정의된 뼈대를 (비율을 조절하고, 또 위치를 좀 바꿔서) 가장 잘 집어 넣는 방법이 이 작업의 목표입니다. 이 작업은 사실 완벽하게 해결하기란 거의 불가능에 가깝습니다. 그래서 여기서 제시하고 있는 해결책도 사실 완벽하다고 볼 수 없습니다.

1. 캐릭터를 우선 Unit scale로 re-scaling 합니다.

2. Distance Fields를 계산합니다. 여기서 Distance Fields라는 것은 3 차원에서 하나의 점이 있을 때 그 점에서 가장 가까운 Mesh에서의 거리를 의미합니다. 즉 가장 가까운 삼각형을 찾고, 또 그 가장 가까운 삼각형에서의 정확한 거리를 계산한다는 의미입니다. 일반적인 거리는 양수와 음수가 없으므로, 안인지 밖인지가 구분되지 않습니다. 따라서 여기서는 삼각형의 normal을 이용해서 안과 밖을 구분하는 것으로 보이는데 이 부분은 정확하지는 않습니다. 어쨋든 양수와 음수를 구분해서 메쉬의 안인지 밖인지를 구분할 수 있도록 Distance field를 계산합니다. 이 계산은 3D Volume 데이터로서 계산하는 것이 아니라 Octree로 메쉬를 나누고 그 Octree의 하나의 셀마다 계산한다는 의미입니다.

3. Octree에 기록된 Distance field 값을 기준으로 하여 뼈대의 위치가 될 수 있는 후보군을 추출해냅니다. 이 추출은 값의 연속성(C1 continuity)을 기준으로 하여 다른 셀과 비교하여 결정하게 됩니다.

4. 3번에서 추출된 후보군들을 가지고 우선 거리 순으로 정렬을 하고 다시 거리가 큰 순서로 sphere를 만들어냅니다. 이 중에서 sphere는 다른 sphere의 center를 포함할 수 없다는 규칙도 동시에 가지고 있습니다.

5. 4번에서 추출된 sphere들을 가지고 graph 구조를 만들어냅니다. graph 구조를 만들 때 서로 겹치는 sphere들을 연결하여 만듭니다.

6. graph 구조를 skeleton과 비교하여 graph를 노드들을 일부 제거합니다. skeleton과 같은 수준의 joint를 가지도록 조절하게 됩니다. 이 부분은 살짝 애매하네요...

7. 나머지 작업은 해당하는 본을 끼워넣는 작업입니다. 이 부분에서는 뼈대의 비율들, 뼈대의 축들, 그리고 뼈대의 사이즈를 미리 정의된 뼈대와 비슷하도록 6번에서 계산된 결과를 수정하는 작업을 의미합니다. 또한 여기서는 정점 내에 들어갈 때 좀 더 잘 맞도록 수정하는 작업도 포함하고 있습니다. 수학적인 계산들이 들어가며 모든 조건을 만족시키는 완벽한 해법은 사실상 존재하지 않기에 테스트와 또 penalty function이라는 것을 두어 어느 비율, 축, 사이즈에 대한 가장 적절한 해법을 제시하고 있습니다.

위의 과정을 마무리하게 되면 사실 mesh에 끼워맞춰진 skeleton이 나오게 됩니다. 이렇게 나온 skeleton은 제가 테스트해본 결과 사실 가끔 에러가 있습니다. 메쉬가 잘 영역이 구분되어 있어야 에러가 없어지는 경향도 있었구요.

Skin Attachment
이 논문에서는 Linear Blend Skinning(LBS)라고 불리우는 사실은 가장 일반적인 형태의 Skinning을 사용하고 있습니다. 또 가장 일반적인 형태의 Skinning에서는 하나의 정점에 여러개의 본(일반적으로 최대 4개)이 각각 자기의 영향력 (W_i)를 가지고 있습니다. 즉 피부를 뼈대에 붙이기 위해서는 각각의 정점에 대해서 어느 뼈대가 영향을 미치는지, 그리고 어느 정도 영향을 미치는지를 계산해내어야 합니다.

이 계산을 위해서 조건이 몇가지 있는데, 우선 mesh의 resolution에 관계가 없어야 합니다. 즉 삼각형이 몇개든 관계없이 정확하게 계산할 수 있어야 합니다. 뼈대의 영향력은 부드럽게 변화되어야 합니다. 세번째 조건은 두 뼈대의 근처의 정점의 두 영향력은 거의에 어느 정도는 비례해야 합니다. 가까운 뼈대가 더 영향력을 많이 주어야 한다는 의미입니다. 위 조건을 만족하는 방법으로 이 논문의 저자는 heat diffusion 방정식을 제시하고있습니다. heat diffusion 방정식의 평형 조건은 위 3가지 조건을 만족시키기 때문입니다. 사실 heat diffusion 방정식은 매우 많은 영역에 사용되고 있으며 그 부분을 skin weights(각 정점의 붙은 뼈때의 영향력들)에 응용한 것이죠.

사실 정상적으로 heat diffusion 방정식의 평형 상태(equilibrium)을 계산해내기 위해서는 volumetric 연산을 해야 하지만 너무 느려서 여기서는 메쉬 위에서 해당 방정식을 근사하는 방법을 택합니다.

논문에서는 수학적으로 좀 더 자세히 설명하고 있습니다. 이 부분은 사실 좀 저도 완전하지는 않고 희미하게 이해하고 있습니다. 그러니 좀 복잡하다 싶으면 그냥 건너뛰셔도 관계는 없습니다. 사실상 목표와 해법은 제시되어 있고 실제로 어떻게 계산하느냐에 대한 부분이니까요. 이 부분을 이해하시면 직접 구현할 수 있습니다만, 목표는 이 논문의 전체적인 흐름을 이해하고 응용하는 것이니까요. 아래는 평형 상태인 heat diffusion 방정식이고...

i = i 번째 bone
j = j 번째 vertex

첫번째 term인 -△w^i 는 △는 discrete surface Laplacian
w^i는 벡터. i 번째 bone으로부터 받는 영향력 벡터입니다
p^i는 벡터. 만약 j번째 정점의 가장 가까운 bone이 i인 경우에만 1이고 나머지의 경우는 모두 0입니다.
H는 행렬. H_jj = c / { d(j)^2 }. d(j) = j번째 정점의 가장 가까운 bone과의 거리. c는 상수.

즉 위 공식은 복잡해보여도, 전체적으로 보면 단순한 계산입니다. 우선 bone을 기준으로 정점을 선택하거나 아님 정점을 기준으로 bone을 선택하던지 간에 관계없이, bone (i 번째)와 vertex (j 번째)가 선택이 되면 가능한 weight을 계산하는 방법입니다. laplacian 연산을 통해서 부드럽게 미분된 형태의 weight 값을, 그리고 두번째 H*weight을 통해서 거리에 의한 영향력을 연산하고 있으며, 마지막 H*p는 전체 합은 항상 1이 되게끔 (equilibrium)을 만족시키고 있습니다. 위의 연산을 모두 하게 되면 각각의 정점마다 어느 bone으로부터 어느 정도의 영향력을 받아야 하는지를 모두 계산해낼 수 있습니다.

장점 & 단점 분석
자동적인 Rigging을 위한 Heat diffusion 부분은 매우 unique하며 다른 많은 논문에서 이 아이디어를 차용하고 있습니다. 물론 계산된 결과도 매우 훌륭하지요. 하지만 skeleton embedding에 대한 부분은 결과는 그럭저럭 괜찮아 보이지만, 완전하지 않습니다. 특히 또다른 논문 (Skeleton Extraction by Mesh Contraction)에서 제시하고 있는 방법에 비하면 단점이 많습니다 (http://visgraph.cse.ust.hk/projects/skeleton/). 그래서 만약 두 논문을 합치면 생각보다 좋은 결과물이 나올 것으로 보입니다만, 이미 비슷한 아이디어 (완전히 같지는 않지만 비슷한 연산을 하는)로 나온 논문이 존재합니다.

어쨋든 게임의 실무적으로 보자면 Skeleton embedding을 방금 제시한 Skeleton Extraction By Mesh Contraction을 이용해서 처리하고, Heat Diffusion을 이용하여 skin weights를 계산해낸다면 하나의 동작을 여러개의 메쉬에 바로바로 적용할 수 있을 것으로 생각됩니다.

워낙 쟁쟁하신분들이 너무나도 상세하고 자세하게 글들을 쓰셔서 글쓰는데 많

이 위축이 되네요 ㅜ.,ㅜ..저같은 허접때기가 낄자리가 아닌것 같기도 하구요.

심각하게 고민중입니다..(챙피해....부끄러...정말...뭘써야할지...컥...)


실제로 저는 이론보다는 제가 개발하면서 느꼈던점들을 그래픽과 연관지어서

아주 간단히(자세히는...정말...못하지요..전문적인 지식이 거의 없어요 ㅜ.,ㅜ)

서술형으로 접근하려고 햇는데 글이 올라오는걸 보니 어마어마 합니다 ㅜ.,ㅜ

저번에 했던 이야기의 연장선으로 좀더 이야기를 해보려고 합니다.

제가 요즘 팀 관리만 하고있기에 별로 쓸내용이 없네요 ㅜ.,ㅜ

제가 하는 말들은 너무나도 일반적인 것 입니다 !!ㅜ.,ㅜ

그래도 뭔가는 써야 하기에..이번에도 두서없는 그냥 저의 생각을 적어봅니다

이쁘게 봐주세요 ㅜ.,ㅜ

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

보통 디자이너들 컨셉단계에서 이미지를 생각하고 구체화하는 작업자들이 보통의 프로그래머들과의 교류를 통해 결과물을 요청합니다. 이단계에서 많이들
 

"그냥 이렇게 해줘~~!!"  "이런느낌 좋자나요~~!!" "이거 안돼나??"

이런식의 막무가내로 대화를 시작하는 경우가 많지요..

물론 많은 사람들이 원화나 컨셉디자인이 게임 비쥬얼의 방향성을 결정 짓는다

고들 말들은 많이 하지만 그 과정에서 어떻게 접근해야 서로가 원하는걸 이해

하기 쉽고  서로 양보 할수 있는지에 대해서 답답해 하는 현실에 닥치게 되는

경우가 많습니다.

보통 팀의 AD 아트디렉터와 TA 나 TD 분들이 이런역활을 많이 해주시니 그래

도 큰 프로젝트에서는 다행이 커뮤니케이션이 잘되는 걸로 알고 있습니다.

부러우면 지는것이지만 ...부러운건 사실이지요...(저도 개인적으론 TA나 TD가

있던 팀에 있어본적이 없습니다...ㅜ.,ㅜ 사실 없는게 당연하다고 생각했을수도....ㅜ.,ㅜ)

간혹가다가 그래픽 하시는 분들이 이런것에

관심을 너무 갖는거에 부담을 느끼시는 분들도 종종 있으시더군요.

선무당이 사람잡는다...라는...

하지만 필요한 것들이라고 생각합니다.




"이미지는 이미지일뿐!!!! "

원화나 컨셉따로.. 3디 모델링따로.. 최종 인게임 샷 따로.. 노는 경우가 많이들

있습니다.

크게 리얼과 툰 방식의 그래픽을 기본으로 두고 이야길 한다면 매우 간단하겠

지만 리얼에서도 여러 부수적인 영향으로 느낌이 많이들 다르지요.

다들 엔진 탓을 많이들 합니다. 특히 그래픽 디자이너분들은

"우리엔진이~~~XXX 이였으면~~!!"

제가 가장 많이 듣는 소리중 하나였습니다.

 
사실 프로라 하면
(저희..그래도 월급쟁이들인데..프로 아닌가요 ㅡ,.ㅡ 프로아니면 ...월급받으면 안돼자나요...)

주어진 현실에 맞게 최대한 잘 할수 있는 방법을 고민하는것도 바른 선택이 아

닐까 생각합니다. 주어진 스펙안에서 최대한 잘할수 있는것을 찾는 것이 매우

중요한것 같습니다.


그럼 디자이너들이 좀더 무엇을 알아야 커뮤니케이션할때 좋을까에 대한 요점만 간단히 정리해 보도록 하겠습니다.(지극히 개인적인 관점으로 정리한 부분입니다. 전문적인 용어등은 절대~~!!있을수 없습니다 ㅜ.,ㅜ)


우리는 지금 어떤 엔진을 쓰고 있는가~!!

최신기술을 원하는가!!! 그럼 공부해라~!!!



우선 3디결과물들이 어떻게 게임안에서 표현이 되는지에 대한 파이프 라인의

이해가 제일 중요 할것입니다.

자체적으로 지원하는 렌더링 방식이 무엇인가를 우선 알아야 합니다.

동적인 라이트를 사용하는지 정적인 라이트를 사용하는지 아니면 정적인 라이

트에서의 그래픽 퀄리티를 높이기위한 방법이라던가 쉐이더에 대한 이해 이런

것들이 필요로 합니다. 과연 우리게임엔진으로 내가 원하는 그런 그래픽 느낌

을 구현할수 있는가 또는 그것을 구현하기위해 얼마나 많은 시간과 인력의 투

자가 필요한지까지 알면 더 좋겠지요. 그것을 하기위해 필요한 요소들은 무엇

인지 타 게임은 이러한 방법을 써서 이렇게 표현 햇다더라의 지식정도는 갖고

있어야 서로 커뮤니케이션을 하는데 있어서 도움이 많이 됩니다.

위와같이 이렇게 멋진 그림을 그려준다고!!!!!(그려주면 좋지요...ㅜ.,ㅜ)

"우리가 나아가야할 비주얼 방향성은 꼭 이래야만해~~!!A군 만들어줘~!"
하며 단정짓는다고 ~~!!

위처럼 이렇게 머찐 그래픽이 나오는건 아니니까요...
또한 똑같은 좋은 엔진을 쓴다 한들 개발팀의 여건에따라 전혀 다른 느낌이 나오기도 하니까요.




또한 누구나 최신기술 좋은 엔진에서 가지고 있는 기능이나 그안에서 낼수있는 퍼포먼스를 원합니다..이해합니다. 욕심 나겠지요...탐나겠지요..(저역시도 사람이다보니....) 그렇다면 적어도 용어나 그 기술에 대한 이해는 적어도 해야할것 아닌가요?!

무작정 손가락으로 가르키며 이거~~!! 이런거~~!!

욕심히 과하면 이상한 결과를 초래할수도 있습니다.

주로 국내에서 보편적으로 좋은 엔진 그래픽 죽인다 하는 엔진..언리얼과 크라이엔진 정도겠네요...왠만한 초신 기술은 다 들어가 있지요..근데..

               최신기술????엥????

어떻게?
 
어떤원리로 ?

이런분들이 많이 있습니다.

그래픽을 관장하는 요소들에는 빛과 효과 물체 등 여러 요소가 있습니다

그중 원하는 느낌으로 화면을 구성하는데 지배적인 것이 빛입니다.

어떤원리와 기능을 가지고 이런 효과를 가져오며 화면에 뿌려지는 지에 대한

이해정도만 있더라도 좀더 커뮤니케이션에 도움이 될거라고 생각합니다.


실제예로 이번에 배틀필드 3가 나왔을때 그래픽 디자이너들이 다들 감탄 사를

날리더군요..우와~~죽인다 재미있겟다...

나도 저런 게임 만들어보고 싶어~~!! 우워워워워~~!!

진심이 묻어나오는 감탄사 였습니다. 저역시도 게임화면에 감탄을 했지(멋쩌멋쩌!!!)


그러나 그중에 프로스트 바이트 엔진이나 실제 게임내에서 구현된 기술에 대한
문서를 찾아본 디자이너는 별로 없더군요.

뭐 영어로된 문서들이다 보니 그거에 대한 거부감이 많이 있어서 그럴지도 모

르나 우리에겐 구글이 있으니까요(저도 안되는 영어도 낑낑 되면서 가끔 봅니다..ㅜ.,ㅜ이미지가 되도록 많은 문서가 필요해요 ㅜ.,ㅜ)


배틀필드3 의  인터뷰 내용중

"언차티드3 콘솔버전과 비교했을때 배틀필드 3콘솔 버전은 어떠한가요"

라는 질문에 이런 대답을 했더군요 나름 생각이 많아지게 하는 글귀 였습니다.

"솔찍히 우리는 굳이 비교를 하려고 노력하지도 않습니다. 우리는 오직 우리 자신과 비교할 뿐입니다. 왜냐하면 우리가 다른 콘솔 게임을 기준으로 삼아서는 우리가 뽑아내려고 분투중인 퀄리티를 얻을 수 없기 때문이죠"

자신만만하고 당당한 모습이더군요.

우리도 언젠가는 그누구와 비교할수없는 그래픽을 가진 그런 게임을 만들기위

해 노력할것이고 그러기 위해서는 디자이너와 프로그래머들과의

적극적인 커뮤니케이션은 꼭 필요한 과정이라고 생각합니다.


아~~!! 그전에...꼭 그래픽만 훌륭하다고..좋은게임은 절대 아닙니다..

그냥 욕심이지요 ㅜ.,ㅜ. 게임은 게임자체로 재미가 있어야 할거 같아용

리처드 파인만이란 유명한 물리학자가 있죠.
이 사람이 "파인만 씨, 농담도 잘하시네!"라는 책을 쓴 게 있는데
(실제로 농담도 잘 했답니다) 거기에 보면 이런 구절이 나온답니다.




음... 그러고보니 수도꼭지 물줄기가 아래로 갈수록 홀쭉해지다가 나중엔 방울방울로
뚝뚝 떨어지죠. 근데 언뜻 생각해도 고딩 레벨에서 쉽게 풀리는 건 아닌 것 같은데-_-

노벨상 받은 분이니 그러려니...라지만 왠지 빡치더군요-_-!

나는 비록 과학자는 아니지만 그래도 고등 수학, 물리 다 한 엔지니어인데!
게다가 사실 이런 일은 할 필요가 없다라니 왠지 엄청 해보고 싶지 않습니까.
자고로 일이란 무익할 수록 하고 싶은 법 (?)

그래서 해봤습니다!

게임 개발과의 연관성은... 호...혹시 게임 개발하다가 수도꼭지에서 떨어지는 물을
시뮬레이션할 일이 있을 수도 있지 않을까요 하하하하 (...)



일단 물줄기가 얇아지는 이유는 중력 때문인 것으로 보입니다.
수도꼭지에서 나온 물이 중력에 자유낙하하면서 속도가 점점 빨라질 테니까요.
시간당 나오는 물의 양은 일정한데 점점 물이 빨리 떨어지니 물줄기가 얇아질 수밖에 없겠죠.

직관적으론 그렇고... 좀 더 제대로 하려면 물의 점성이나 공기 저항 같은 것들을
고려해야겠지만 물의 양이 많은 경우 그닥 영향이 없을 테니 다 무시하고
중력만 생각했을 때 물줄기의 모양이 어떻게 되는지 알아보겠습니다.



물줄기의 단면도입니다. r이 수평, h가 수직 축이고 H가 현재 물줄기의 가장 밑단입니다.
일단 생각나는 것들부터 주르륵 써보죠. 중력가속도는 g로 하고...
H에 있는 물들은 중력에 의해 가속이동하므로 시간 t일 때 1/2 gt^2에 있게 되죠.

①

그리고 펌프가 멀쩡하다면 단위시간당 나오는 물의 부피가 일정할 겁니다.
총 물의 부피를 V, 초당 공급되는 물의 양을 P라고 했을 때 V를 시간 t에 대한 식으로
나타내면 다음과 같습니다.

②

총 물의 부피를 물줄기 식에서 도출할 수도 있을 건데요.
지금 그래프는 단면도로 그렸으나 실제로 물줄기는 원기둥 형태일 테니
총 부피는 그걸 고려해서 다음처럼 되어야겠죠.

③

우리가 구하고 싶은 건 결국 높이에 따라 변하는 물줄기의 반지름이므로
목표는 r(h)입니다. ③을 H로 미분해서 정리해봅시다.



④

dV / dH가 거슬리는데... ①, ②번 식이 t로 이어져 있어서 얘네를 이용하면 dV / dH 꼴을
만들 수 있을 것 같습니다.

우선 ①번을 다음과 같이 정리할 수 있습니다.



원래 루트 풀면서 플러스 마이너스 부호가 다 나오는데 시간이 음수인 세계(...)는 무서우므로 뺍니다.

이걸 ②에 넣어주면 가 됩니다.
이제 양변을 H로 미분하면 가 나옵니다.

네 드디어-_- 이걸 아까 나온 r(H), ④번에 넣으면 나왔네요.
h = H인 경우에 반지름 r은



...로 나옵니다. h 빼면 다 상수니깐 C로 빼고 r(h) = Ch^(-1/4) 그래프를 그려보면



처음에 예상했던 것과는 달리 h가 0에 가까운 곳에서 r이 무한대가 되네요.
h가 0인 곳은 물 속도도 0이라 물이 어디 도망 못 가고 쌓이기만 하니 당연할라나...

실제로 써 먹을 거라 생각하면 수도꼭지에서 튀어나올 때의 물 초기속도가
v인 경우 h = 1 / 2 gt^2이고 v = gt니깐... h를 v에 대한 식으로 정리하면
h = v^2 / 2g로 나옵니다. 저 식에 v 넣고 h를 구해서 그 h부터 아랫부분 쪽을 쓰면 되겠죠.
물 나오는 양 P랑 중력 가속도 g까지 넣고.

아... 아까 이거 쉽다던 건방진 고딩 누구야 대체-_- 힘들어 죽겠는데.
고딩이 이거 풀 수 있으면 걔는 노벨상도 받을 거다!!

네, 여튼 물 분자의 장력에 의해 방울방울 떨어지는 것까지 나타내는 식은
못 구했지만 수도꼭지 물줄기가 얇아지면서 떨어지는 것까지 설명하는 데에는 성공했네요.
물줄기가 얇아져서 중력보다 표면장력이 지배적인 힘이 되면 또 다른 모델로 식을
도출해볼 수 있을 것 같습니다.

자, 고딩 파인만 이건 어떻게 설명할텐가! 물줄기가 안 가늘어지고 그대로 떨어지는데!



틀린 거 있으면 지적해주시고 궁금한 거 있으면 질문해주세요~!

 안녕하세요.^^ 기획 쪽에서 어떤 글을 써야 하나 굉장한 고민을 했습니다.

고민 끝에 오늘은 제 개인적인 생각에 경험을 더해서 즉흥적으로 글을 써 보기로 합니다.
(좀 편하게 쓰니 날림이어도, 뜻을 전달하는데 의미를 두겠습니다.~^^ 죄송)

·        무어의 법칙이란?

·        온라인 게임 개발 “무어의 법칙”?

·        왜 이런 현상이..?

·        마무리

 

 

·        무어의 법칙이란?

·        마이크로칩 기술의 발전 속도에 관한 일종의 법칙으로, 마이크로칩에 저장할 수 있는 데이터 양이 18~24개월마다 두 배씩 증가한다는 법칙이다. 이는 컴퓨터 성능이 거의 5년마다 10배, 10년마다 100배씩 개선된다는 것을 의미한다.

 

·        온라인 게임 개발 "무어의 법칙"?

·        게임 개발 양의 증가 속도에 관한 일종의 법칙으로, 유저들을 만족 시키기 위해 만들어야 하는 개발 양이 18~24개월 마다 두 배씩 증가한다는 법칙이다. 그냥 넋 놓고 개발하다가는 1년의 절반이상을 야근해야 하며, 해마다 야근 일수가 늘어나고 최악의 경우에 개발 양의 증가 속도를 못 따라가 게임이 출시하지 못하게 된다.(기간과 배수는 따라쓴거니 큰 의미 없습니다^^)

·        주로 온라인 게임에 해당되며 게임에 따라서는 해당 되지 않는 경우도 있습니다.^^

 

·        왜 이런 현상이..?

·        유저들의 경험 축적

·        기존의 것은 당연히 있어야지!

·        뭐야~ 탈것도 없냐~ 와우는 있다고~

·        + 주관석 해석을 더해야 함.

·        뭔가 다른 새로운 것이 있어야 한다.

·        와우 빼꼈네~ 똑같잖아. 새로운 것이 하나도 없네

 # 기존의 것+ 새로운 것 = 게임A, 게임A + 새로운것 = 게임B, 게임B + 새로운 것 = 게임C , ...... , 게임N

·        경쟁작의 출시 및 서비스

·        아이온은 커스터마이징이 죽인데

·        우리는 발톱까지 커스터마이징하는 기능을 추가한다!.

·        트랜드

·        요즘은 게임에 SNS요소를 추가하는 것이 대세지!

 

·        품질향상

·        조금 더 편하고 스마트한 것을 향한 무한 경쟁.(잡스님의 영향도 큼...)

·        UI나 유저 편의성 개선은 끝없는 경쟁.

·        편한 것에 한번 익숙해지면, 불편한 것이 크게 다가옴.

 

·        더 멋있고 화려하게!..

         

·        마무리 

• 현실적으로 대응이 정말 쉽지 않습니다.(덕분에 야근을 엄청하고 있습니다.ㅠㅠ)
• 이론상으로는 다음과 같은 추천이 있습니다.
• 판을 깨는 새로운 게임디자인
• 미래를 예측하는 초능력 발휘
• 자원을 유연하게 쓸 수 있는 자본력
• 많은 분들의 의견을 듣고 싶습니다~

 

• 다만, 꼭 전하고 싶은 것은 “게임 개발 양이 증가한다"라는 것의 인지입니다.
• 맞기 전에 알고 맞으면, 본능적으로 몸을 움직여 덜 아프다고 하죠^^
• 원인을 모르면 KO될 때까지 얻어 맞습니다. ㅎㅎ
• 그리고, 더 나아가서 후행적 대응에 머무르지 말고, 선행적 대응을 할 수 있도록 노력하자 입니다.
• 대부분 개발자의 노력에 의한 후행적 대응을 하고 있으며, 이에 실패할 경우는 불행한 종말(?)을 맞이하게 됩니다
• 원인을 누군가에게서 찾으려고 하죠..

 

부족한 글 여기까지 읽어 주셔서 감사합니다~

(__)

To. Pope

필명은 “원숭이사냥꾼”으로 해주세요~

안녕하세요 도플광어입니다.

저는 주로 일리히트엔진 하나를 가지고 극한까지(분자단위까지 ^^;) 해부해보도록 하겠습니다. 

그렇지만...
타엔진과의 비교하여 성능에 대한 언급은 되도록 피할예정입니다. 예를 들면 공군 조종사가 쓰는 연습기와 실제 전투기와의 성능 을 비교하는 일은 어리석은 일이라는 생각입니다. 

아카데믹한 방향으로 포스팅을 진행하도록 하겠습니다. 성능을 떠나서 하나의 엔진을 끝까지 분석 해보는 것은 의미 있는 일이라고 봅니다.(그렇다고 일리히트엔진이 공부용 전용 엔진이라는 건 아닙니다. ^^ 충분히 실용적입니다.)

먼저 일리히트 엔진을 간단히 설명하자면...

The Irrlicht Engine is an open source high performance realtime 3D engine written and usable in C++. It is completely cross-platform, using D3D, OpenGL and its own software renderers.

위 설명과 같이 c++기반의 클로스 플랫폼 실시간 3디 랜더 엔진 입니다. 독일산 엔진입니다.(정확히 말하자면 원저자는 오스트리아 분입니다.)

현재 일리히트엔진은 1.7.2가 최신버전입니다만  svn 에 1.8beta 버전이 준비중에 있습니다. 오늘(2011.12.21)은 여기서 최신버전을 받아서 (rev 4020) 진행 하도록 하겠습니다.


그리고 저는 ms기술에 대한 거부감때문에 되도록 ms 기술(특히 VS2010 , DX, .Net)에 대한 언급은 피하도록 하겠습니다. 물론 제가 맞다 잘못됐다를 떠나서 다양한 방향을 추구하는 사람은 소수라도 존재해야된다는 생각입니다. 맥에서 작업을 하는것을 기본으로 하겠지만 되도록 플랫폼에 종속되는 않는 방법을 사용하도록 노력하겠습니다.

https://irrlicht.svn.sourceforge.net/svnroot/irrlicht

svn 클라이언트등를 이용해서 여기서 소스 코드를 끌어 옵니다.
( 참고로 svn 클라이언트는  svnx 를 사용했습니다. [사용법 바로 가기] )

컴파일 환경은 아래와 같습니다.

xcode 4.2.1
Max OSX 10.7.2


먼저 xcode로 'trunk/source/irrlicht/macosx/MacOSX.xcodeproj' 을 오픈합니다.

그리고 몇가지 프로잭트 설정을 해주어야 합니다.

trunk/include/irrCompileConfig.h 헤더파일에는 컴파일시 플랫폼에따라 선택적으로 컴파일 가능하도록 하는 매크로 설정을 바꿔 줄수가 있습니다.
예를 들어 DX 설정이 맥이나 리눅스에서는 적용되지 않도록 되어 있는 부분이 아래와 같이 구성되어있습니다.

엔진 기능별로 선택적으로 빼고 넣을수도 있습니다.

 예를들어 _IRR_COMPILE_WITH_GUI_ 부분을 주석처리 하면 내장 유아이 관련된 부분이 컴파일되지않습니다. 외부 유아이 엔진을 사용할경우에는 이런식으로 엔진을 가볍게 다이어트 할수가 있습니다.

엔진의 모든 기능을 단위별로 묶어 놓았기 때문에 처음 엔진을 분석하실때 이것을 참고 해서 단위별로 나눠서 분석하시는것도 방법입니다.(독일사람들이 정리 정돈을 참깔끔하게 잘한다는 느낌이 드는 부분입니다.)

현재 맥에서 컴파일 하려면 몇가지를 수정하고 하셔야합니다.

1. 프레임버퍼 비활성화

COpenglExtensionHandler.h 헤더 파일에 위와 같이  #undef GL_ARB_framebuffer_object 추가 해줍니다. 그렇지않으면 프레임 버퍼 관련한 함수들이 정의가 되지않았다고 에러가 나옵니다.
포럼에서 이 문제를 물어보니 이 부분 담당하시는 분이 자기는 엑스코드3 쓰는데 너도 그거 써라 이렇게 말씀을 하시더군요^^;  

2. MACOSX 64비트 문제

COpenglExtensionHandler.h 의 2325줄을 아래와같이 size_t로 타입 캐스팅해줍니다.

COpenGLMatrialRenderer.cpp 의 내용을 아래와 같이 수정해줍니다.

3. 가상키 선언 주석처리 

CirrDeviceMacOSX.mm 파일에서 virtual keybord를 열거형으로 선언되어있는것들을 모두 주석 처리합니다. 10.7 sdk 부터는 똑같은 이름으로 내부프레임워크에 들어가있기 때문에 이름이 서로 충돌하게 됩니다.




4. 빌드 세팅


Architectures -> Standard
Base SDK-> Latest MacOSX

Build Options->Compiler for c/c++/object-c-> LLVM GCC4.2

libirrlicht.a 선택을 하고 빌드를 합니다.

 

컴파일이 성공적이라면 결과파일인 libirrlicht.a는 MacOSX/build/debug에 위치합니다.

다음부터는 본격적으로 하나하니씩 기능별로 분석을 해나가도록 하겠습니다.




ps.
wondows의 경우는 source/ 에있는 .sln 프로잭트를 열어서 vs를 이용해서 컴파일하면 별문제 없이 컴파일이 됩니다. 이건 별다른 설명 필요없이 간단합니다. 좀 허무 하죠 ㅡ.ㅡ? 그랬다면 죄송합니다.






 

pass 1. 일단 오브젝트를 정상적으로 그립니다. 이때 깊이 테스트와 쓰기 모두 활성화 시킵니다.

Pass 2. 그리고는 오브젝트를 확대해서 그리되 라이팅을 끄고 검은색으로 뒷면을 그립니다.  이때 역시 깊이 테스트를 수행하기 때문에 확장 오브젝트의 뒷면 중 정상 오브젝트에 의하여 가려지는 부분은 걸러지기 때문에 오브젝트의 윤곽만 남게 됩니다.

 

 이런 방식은 완벽하게 오브젝트의 실루엣만을 뽑아내게 됩니다. 즉, 오브젝트 내의 외각선은 표현이 되지 않는것이죠. 엄밀히 말하면 실루엣을 표현하는 것이지 엣지를 표현하는 방식은 아닙니다.