aronze's blog

[Terrain paper] Real-Time Generation of Continuous Levels of Detail for Height Fields

신동호 — Mon, 23 Nov 2009 10:46:55 GMT

fetch 의 단위와 카메라와 fetch 의 거리의 비율에 의해 유동적으로 LOD 를 처리하는 방법(CLOD)에 대해 이야기 하고 있습니다.

[Terrain LOD] Runtime Regular-Grid Algorithms - ROAM(1997~)

신동호 — Sat, 21 Nov 2009 06:58:00 GMT

참조문서: http://www.cognigraph.com/ROAM_homepage/index.html

ROAMing Terrain: Real-time Optimally Adapting Meshes

영어도 수학도 기반 지식도 너무 많이 부족한 것을 느낌니다. 대략적인 ROAM 의 방식(이등변 삼각형을 쪼개는 것과, 쪼개면서 이웃한 삼각형을 이어주기 위해 추가 분할이 필요하다는 것, split/merge 를 하기 위한 queue 를 사용했다는 점) 정도 이해하고 넘어갑니다.

읽으면서 아이디어가 떠올라 기록합니다. DEM(고도 데이터의 세계 표준 포멧입니다. NASA 나 USGS 같은 곳에서 구할 수 있습니다.) 과 인공위성 이미지를 가지고 특정 지형의 대략적인 형태를 가져와 지형을 만들 수 있습니다. DEM 의 resolution 이 20m(대략 가장 정확한 무료 DEM 이 이정도 크기인 것으로 알고 있습니다) 인 경우 1024x1024, 16bit height map 한장으로 20kmx20km 를 커버할 수 있으며 이는 파노라마 없이 거대한 지향을 노출할 수 있는 정도의 크기 입니다.

이 맵을 그대로 사용하는 경우 지형의 디테일이 너무 떨어 지는 것이 문제입니다만 최신의 논문을 살펴보면 이 디테일 부분은 노이즈와 geometry shader 혹은 texturing 을 통해 극복 가능할 것으로 보입니다.

실제로 디테일이 중요한 영역(terrain 을 사용하는 목적에 따라 다를 수 있겠습니다만)은 그렇게 크지 않습니다. 제 아이디어는 전체 지형 덩어리를 DEM 을 통해 자동으로 만든 후 아티스트가 원하는 특정지역(관심지역)에 폴리곤을 집중할 수 있어야 한다는 점이 중요하다는 관점에서 시작합니다. 전체 지형에 대한 height map 이 무수히 많은 mipmap 을 가지고 있다고 생각해 보면 - 일반적인 mipmap 은 디테일이 뭉갤 때 사용하지만 제가 생각하는 고도데이터의 mipmap 은 디테일을 올리기 위해 사용하는 것입니다 - 1024x1024 짜리 지형을 4개로 나누어 512x512 가 커버하는 영역을 다른 1024x1024 고도맵 4장으로 커버할 수 있도록 하는 것을 생각해 볼 수 있습니다. 하지만 우리는 이 모든 지역에 관심이 있는 것이 아니며 관심있는 1개 구역의 추가 디테일만 필요한 경우 실제 필요한 height map 은 1024x1024 2장 뿐입니다.

20m resolution 맵의 특정 구역을 10m resolution 으로 바꾸어 아티스트가 직접 수정할 수 있도록 하였습니다. 하지만, 여기에 1024x1024 한장이 추가로 들어간다면 원래 있었던 512x512 이미지가 버려지게 됩니다. 하지만, 이 녀석은 resolution 이 좀 부족할 뿐이었지 버려질 필요는 없습니다. 즉, 정리하면, 이전 512 이미지를 그대로 사용하는 경우 관심지역의 resolution 을 20m 에서 10m 하는데 필요한 데이터는 중간 고도(10m) 의 데이터 뿐입니다. 또한 중간 고도 데이터는 독립된 고도를 표시하는 것이 아닌 부모 고도의 offset 데이터를 가지고 있는 것이 좋을 것 같습니다. 이 가정은 아티스트가 보다 맵을 쉽게 수정할 수 있도록 도와줍니다. (아티스트가 원하는 지형에 원하는 브러쉬를 사용하여 전체 고도를 수정하는 경우 브러쉬의 resolution 보다 작은 고도맵은 offset 정보로 부모의 고도를 상속받은 것이나 마찬가지 으므로 같이 조정이 되겠죠. )

수정의견: 중간 고도 데이터가 offset 인 경우 종속성에 의한 문제가 생기므로 독립되어야 합니다.

결론: 1024x1024 고도맵에 512x512 한장을 추가하여 전체 resolution 20m 인 맵의 관심 지역의 resolution 을 10m 로 만들 수 있습니다.

tag : terrain, roam

[LOD] SIGGRAPH 2002 Course Materials

신동호 — Thu, 19 Nov 2009 20:57:12 GMT

이 똑똑한 집단이 1년후 얼마나 발전했을까요:D

참조 문서: http://lodbook.com/course/2002/

Frameworks: Discrete, Continuous, and View-Dependent LOD

SIGGRAPH 가 무슨 행사처럼 한번에 쫙 하는가 보군요. 여기는 그냥 도입 부분에서 오늘 LOD 에 대한거 한다랑, 1년전 첫 시간에 이야기 했던걸 그래로 우려먹고 있습니다.

Algorithms for Simplification

흠.. 먼가 미세한 차이가 있는지 몰라도.. 이 발제도 중복입니다..

Appearance-Preserving Simplification

그림 몇 장 추가되고 중복입니다..

Measuring Geometric and Attribute Error
Visual Perception and LOD
Balancing Fidelity and Performance

이제 깨달았습니다. 다 중복이고 뒤에 두개만 추가된거 같습니다. 작년에 못온 사람들을 위해 다신 한거 같네요;

Terrain LOD

Terrain LOD 에 대해 본격적으로 고민하기 시작하는 군요.

일반 객체와 비교하여 정적이고 단순하며 고도맵 기반의 2차원적인 구현이 가능하다는 점은 구현하기 쉬운 부분이지만 USGS, NASA 등의 군사/인공위성 등을 동원한 고도 데이터(DEM 등)을 이용하여 지형을 만드는 경우 천만/억 단위 폴리곤까지도 필요하기 때문에 이 부분을 고려하는 것이 어려운 부분이라고 말합니다.

이 논문에서는 제가 여기 저기서 줏어 들었던 단어들이 총 출동 하는 군요. 쿼드 트리와 바이너리 트리에 대한 설명이 나오면서 클립맵에 대해 참조로 거론하고, 가상 메모리/디스크 페이징 등의 이야기도 하고 있습니다. CLOD(Continuous LOD) 은 실시간 뷰 종속석인 첫 번째 알고리즘으로 1996년에 나왔다고 하는군요. 특징은 regular grid, btree(binary tree), 쿼드트리 블락을 사용한다는 점입니다.

이어 1997년, ROAM(Real-time Optimally Adapting Meshes) 가 등장합니다. 특징은 regular grid, btree(binary tree) 에다가 2개의 우선순위 큐만 사용한다는 것입니다.

1998년에는 CLOD 가 확장되었다고 하는 군요. 이녀석은 regular grid 에 btree 가 아닌 쿼드 트리를 사용하고 top-down 이라는 건 무슨 뜻인지 잘 모르겠군요. 같은 시기 VDPM(View-Dependent Progressive Meshes) 가 나왔는데 이건 패스..

2000 년에는 좀 특이한 녀석이 나타난 것 같은데.. 완전 다른 방식으로 만든 것 같네요. 그림이..- -;

2001 년에 나타난 녀석은 어디서 많이 보던 그림입니다. regular grid, top-down, btree 를 사용했으며.. 이 시점에 거의 근래의 대용량 terrain 의 모습이 갖추어 진 것 같습니다. 이 상태에서 큰 발전 없이 지금에 이르렀다는 느낌이 들 정도로 기술이 성숙한 느낌이 듭니다. GPU 가 발전하면서 이 시점의 CPU 에서 돌아가던 것들을 GPU 로 옴기는 것이 요즘 기술의 방향일까요?

Out-of-Core Simplification

전.혀. 모르겠습니다. 패스.

tag : lod, siggraph2002

[LOD] SIGGRAPH 2001 Course Materials

신동호 — Thu, 19 Nov 2009 20:47:00 GMT

terrain 관련 궁금한 내용 중 LOD(Level of Detail) 에 대해 먼저 살펴보고 있습니다. 아래 논문들은 좀 오래된 문서지만 역사의 흐름도 알아볼 겸 보고 있습니다.

참조 사이트: http://lodbook.com/course/2001/

Frameworks: Static vs View-Dependent LOD

정적인 LOD 를 사용하던 시대에서 카메라에 종속적인 동적 LOD 의 시대로 넘어가는 것 같군요.

Measuring Simplification Error

LOD 사용으로 인해 계산 오류가 생긴다는 것을 지적하고 있네요. 점과 점의 거리와 점과 선의 거리등이 달라 노멀맵과 같은 경우 오류가 생길 수 있다는 식의 내용입니다. 노멀의 경우 LOD 당 필요하다고 말하네요.
해석도 해석이지만 참조 논문만 주욱 있군요. 전반적인 흐름에 초점을 두는 것이 좋을 것 같다고 생각해 봅니다.

Algorithms for Generalized LODs

지금의 저에게는 안드로메다 이야기이긴 합니다만(이미 무효가 된 정보를 공부하고 있다는 느낌도 좀 드는군요:D 펜티엄2에 부두3가 테스트 머신인걸 보니 더 안습입니다), 가만 보다 보니 아이디어가 하나 떠올라 기록합니다.

최종 디스플레이되는 뷰포트가 1024x768 이고 카메라로부터 떨어진 임의의 구역 Z 의 경우 최소 고도와 최대 고도의 차가 100m 라고 가정합니다. 구역 Z 와 카메라와의 거리로 계산하여, 고도차 20m 가 1개 픽셀로 나타낼 수 있음을 알게 되었습니다. 이 경우 구역 Z 의 고도 데이터는 최대 20m resolution 이 된다고 생각합니다. 그 이상의 디테일로 그려도 최종 결과에는 변화가 없을 것이기 때문입니다.

Visual Perception and LOD

1. 가까이 있는 물체가 먼 물체보다 더 디테일 해야 한다. 2. 관찰자의 관찰 방향에서 각도가 작은 물체일 수록 디테일 해야 한다. 3. 속도가 느린 물체일 수록 더 디테일 해야 한다.(Motion blur 효과가 있으면 더 좋음, 지형은 움직이지 않는 물체이니 속도가 매우 느린 물체가 되겠군요; 하지만 포스트 프로세싱 모션블러를 생각해 보면, 중요한 것은 관찰자의 입장에서 관찰자가 움직인 경우 지형은 상대적인 속도를 가지게 되고, 따라서 화면에 디스플레이되는 결과를 가지고 이전 프레임과 현재 프레임 사이의 속도로 지형의 속도를 계산할 수 있다고 생각합니다.) 4. DOF(Depth of Field) 의서 포커싱된 지점에 있는 물체일 수록 더 디테일 해야 한다.(그 반대 경우 디테일을 날려 버릴 수 있다는 것이 더 중요하겠죠)

역시 인간의 눈이 블러를 만들어 내고 그 현상이 공간감과 끈김없는 장면에 대한 인식을 준다는 것은 중요한 내용인 것 같군요. 얼마전에 블로깅한 24 fps vs 60 fps 가 다시 생각납니다.

한편으로는 이렇게 복잡한 형태의 LOD 가 들어갈 경우 물리적인 처리(충돌) 등이 너무 복잡해 지는 것은 아닐까 걱정이 됩니다. PhysX 의 heightfield 를 사용하려면 단순한 형태의 height map 을 넘기고 거의 비슷하게 그려내야 비주얼과 물리가 일치되는 모습을 볼 수 있을 텐데, 구현의 그날은 아직 멀었는데 문서만 검토하면서도 왠지 잡생각이 많이 드네요.

하지만, LOD 만 생각했을 때에는 절대적인 성능 차이가 있군요.

Temporal and Visual Fidelity

최하 프레임이 중요하다는 이야기와 함께 일률적인 프레임의 중요성에 대한 이야기로 시작하는 군요. (역시 그런건가-_-) 뒤에 나오는 이야기는 번역도 이해도 잘 안되는 군요. 패스.

tag : lod, siggraph2001

terrain 연구 시작

신동호 — Thu, 19 Nov 2009 14:52:45 GMT

오래 전부터 terrain 엔진에 대해 궁금한 것들이 많았는데, 이번 기회에 관련된 논문과 정보들을 분석해 보기로 마음을 먹었습니다.

http://vterrain.org/
terrain 에 대한 연구를 모아놓은 곳입니다.

http://wwwcg.in.tum.de
얼마전부터 terrain 관련 최신 논문을 찾다가 가장 최신의 논문이 올라온 곳을 따라왔더니 이 곳이었습니다. 동영상등을 보시면 아시겠지만, 정말 기술의 발전이 눈부신 것 같습니다.(물론 실시간입니다.)

tag : terrain

30 Frame per Second vs 60 Frame per Second

신동호 — Thu, 19 Nov 2009 14:38:58 GMT

참조 문서: http://www.daniele.ch/school/30vs60/30vs60_1.html

** 번역이 깔끔하지 못하고 느려서, 저한테도 다른 사람들한테도 저의 번역 행위가 별로 도움이 되지 않는다고 판단한바, 앞으로는 참조 문서와 내용에 대한 간단한 정리 위주로 글을 올릴까 합니다. 물론 구독하시는 분은 없습니다만; 그렇다는 것이죠;

극장에서 재생되는 영화와 같은 영상물은 24fps 로 제작됩니다. 극장에서 재생하는 방식은 모니터와 같은 주사관을 통해 한라인씩 출력하는 방식이 아니라 한방에 찍어 빛으로 뿌리기 때문에 더 적은 프레임을 사용해도 괜찮은 것이죠. 더 중요한 사실은 영상물에 모션블러가 들어가 있기 때문에(실제 영상을 찍었기때문에) 그 정도 fps 로도 인간이 연속된 영상으로 인식할 수 있는 것입니다.

게임과 같은 경우는 조금 다른데요, 60 프레임이 나와야 한다고 하네요. 물론 가장 큰 이유는 위에서 언급했던 모니터의 주사방식과 완전한 아날로그 형태의 모션블러가 불가능 하기 때문입니다.

tag : 30frame, 60frame, frame, eye

[TTS] Text to Speech

신동호 — Wed, 18 Nov 2009 07:55:03 GMT

TTS(Text to Speech) 란 문자를 목소리로 변환하는 기술을 말합니다. 뉴스 같은 걸 웹에서 긁어서 mp3 로 변환, 자동차에서나 운동하면서 들으면 좋을 것 같아 서칭을 좀 해봤는데 마땅한 솔루션이 없군요. 우리나라의 경우 voiceware 라는 곳의 품질이 좋아 구입하려했으나 불법 복제등의 이유로 기업형 판매만 하고 있고, 외국의 경우 http://free-translator.imtranslator.net/speech.asp?dir=ko 사이트에서 판매를 하고 있으나, 왜인지 한글 TTS 는 판매를 하지 않네요; 이런 기술이 대중에게 널리 사용되지 못하고 있다는 것이 안타깝네요.

tag : tts

[Windows7] chm 파일 보는 방법

신동호 — Thu, 12 Nov 2009 08:36:38 GMT

DirectX10, 11 을 공부해보고 싶었던 참에 이번에 대학생 할인가 구매 찬스가 있어 windows7 을 구입하게 되었습니다. 다행히도 대학교 이메일만 살아 있으면 구매가 가능하더군요; 아무튼 정말 저렴한 가격 39900원에 10년간 미뤄뒀던 OS 구매의 꿈을 이루었습니다:D

하지만 기쁨도 잠시.. chm 도움말 문서가 블락이 되어 열리지 않더군요. 다음은 windows7 을 설치한 후 chm 파일이 보이지 않는 경우 대처 방법입니다.

1. 정확한 내용은 아니지만 단순 chm 은 보안상의 문제가 있어 윈도 어떤 버전에서 부턴가 방식이 약간 바뀐 것으로 알고 있습니다. windows7 에서도 이런 내용 때문인지 기본적으로 열람할 수 없도록 블락을 거는 것이 기본 설정으로 되어 있는 것 같습니다.
2. 본론으로 들어가서 열려고 하는 chm 파일을 선택한 뒤 오른쪽 클릭을 하여 속성을 선택합니다.
3. 일반 텝에서 "차단 해제" 를 클릭하고 "적용" 을 클릭하고 "확인" 을 클릭합니다.
4. 다시 chm 파일을 실행해 보세요. 이제 잘 보일 겁니다.

tag : windows7, chm

[링크] 동양과 서양의 차이

신동호 — Mon, 28 Sep 2009 20:06:27 GMT

개발 이외의 자료는 링크하지 않으려고 했지만, 꽤나 공감가는 그림을 봐서 링크합니다. 동양과 서양의 차이를 중국 디자이너가 그렸다고 함니다. 공감가면서도 한편으로 씁쓸하군요:D

http://blog.naver.com/booyaso/50071240127

프로그래밍, 그것을 알려주마! - 아키텍쳐 편1

신동호 — Wed, 23 Sep 2009 11:55:18 GMT

이런 글을 쓰기 애매한 초보 프로그래머 입니다만, 전부터 프로그래밍에 대한 핵심을 정리하고 싶었습니다.

언어

언어는 표현의 수단입니다. 표현은 나도 할 수 있지만, 상대방도 할 수 있습니다. 언어가 있기에 사람들끼리 소통, 즉 커뮤니케이션을 할 수 있는 것입니다.

프로그래밍 언어도 마찬가지 입니다. 컴퓨터와 프로그래머, 프로그래머와 프로그래머 사이를 연결해 주는 고리, 프로그래머는 프로그래밍 언어를 통해 자신을 표현하고 다른 프로그래머와 코드로 이야기 합니다.

이러한 언어적 관점에서, 우리는 우리가 왜 언어를 배워야 하는지 언어를 배우면서 추구해야 할 오의가 무엇인지 정의해 볼 수 있습니다.

1. 언어는 컴퓨터 뿐만이 아니라 사람과도 통신하는 수단이므로, 읽기 쉬워야 합니다.
2. 언어는 자신을 표현할 수 있는 강력한 도구이자 자신의 생각을 정리할 수 있는 수단이므로, 간결하고 튼튼하며 논리적으로 표현할 수 있는 능력이 중요합니다.
3. 언어 유희라는 말이 있습니다. 실용성을 극한으로 밀어 붙인 언어의 끝에는 아름다움이 있습니다. 더 넣을 것도 뺄 것도 없는 군더더기 없는 상태를 말하죠. 즉, 실용성을 근간에 둔 아름다움을 추구해야 합니다. 언어는 소통의 도구이면서 동시에 인간이 개발한 가장 훌륭한 장난감 입니다:D

논리

가끔 컴퓨터 바탕화면이 지저분한 친구들을 보게 됩니다. 그런 친구들의 공통점은 정작 중요한 순간에 필요한 것을 찾는데 너무 많은 시간을 소모한다는 점입니다.

우리는 언어를 사용하여 자신의 논리를 쌓아 올릴 수 있습니다. 이 때 기본은 정리입니다. 정리되지 않은 논리는 무너지기 쉽습니다. 왜 그럴까요? 프로그래밍의 복잡도 그래프는 2차 함수의 그래프처럼 처음에는 그런데로 견딜만 하다가 어느 순간이 지나면 스스로 감당할 수 없는 마지 노선을 만나게 되어 있습니다. (사실 프로그래밍에 한정된 이야기는 아니죠-ㅁ-; 눈 앞의 불만 끄다가는 언젠가 이런 상황이 오는 것이 인지상정입니다.) 하지만, 처음부터 논리가 견고하고 예외가 없으며, 혹시 있을 지 모르는 예외에도 유연하다면, 또한 그 모든 논리들이 일목 요연하게 정리되어 있다면, 항상 복잡도의 그래프를 수평하게 유지하는 것이 가능합니다.

이런 상태를 유지하는 것은 매우 힘겨운 일이지만, 동시에 매우 가치있는 일입니다. 여러분의 프로그램에 버튼을 하나 추가하는 데 10분이 걸렸는데, 1년 뒤에는 8시간이 걸린다면, 여러분은 반듯이 1년 뒤에 끝이 보이지 않는 야근의 늪에서 허우적 거리게 될 것이기 때문입니다. 반대로, 여러분이 원칙을 유지하고 복잡도를 유지했다면, 비록 버튼을 하나 추가하는데 처음부터 1시간이 소모되었겠지만, 1년 뒤에에도 여전히 정시에 퇴근하여 여자 친구와 맛있는 저녁을 먹을 수 있게 될 것입니다. (여러분은 좀 더 열정적이기 때문에, 하루에 1000 개의 버튼을 추가면서도 여전히 뭔가 생산적인 다른 것들을 연구하고 있을 지도 모르겠군요:D)

패러다임

프로그래밍 언어의 패러다임이라는 말이 있습니다. 언어마다 어떤 고유의 사상이 있다는 것이죠. 생각해 보세요. 현존하는 프로그래밍 언어는 수천종에 달하며 지금 이시간에도 저물어 가는 언어들이 있습니다. 왜 그 많은 것들이 필요할까요?

여러가지 이유가 있겠지만, 그 근본에는 패러다임이라는 것이 있습니다. 생각이 다른거죠. 우리는 다 생각이 다릅니다. 같은 문제도 해결하기 위한 접근과 논리는 셀 수 없이 많다는 것이죠.(학생 시절 여러분의 레포트가 copy and paste 로 작성되었다는 것을 교수님이 귀신같이 알아내던 핵심 노하우 입니다. 원래 같을 수가 없는 겁니다:D )

문제를 해결하기 위한, 보다 적절한 접근 방법을 찾기 위해 언어 자체를 바꿔야 하는 순간이 올 수도 있습니다. 이 때 새로 태어난 언어는 뭔가 다른 패러다임을 가지게 됩니다. 이 과정에서 패러다임은 급격한 변화를 맡이할 수도, 혹은 기존 패러다임에서 조금 변형된 실무적, 혹은 튼튼한 구조로 바뀔 수 있습니다.

C 언어의 경우 흔히 절차적인 언어라고 말합니다. 논리를 순서대로 늘어 놓는 것을 말하죠. 하지만, 잘 생각해 보세요. 단순히 논리를 늘어 놓는 언어는 치명적인 단점이 있습니다. 김상무 상무 상 무상 유상무.. 와 같은 개그를 업무 시간에 하루종일 해야 하는 상황이 발생할 수 있습니다. 이 상황은 정작 본인의 상황이 되면 그다지 재미가 없습니다.

물론 C 언어는 그렇게 단순한 녀석이 아닙니다. 이런 상황을 개그라고 생각 안하고 심각하게 받아들였죠. 그래서 함수라는 것을 준비해 두고 있습니다.

함수는 문장에서 동사의 역활을 합니다. 나 공부하러 간다, 친구가 숙제하러 갔다, 사장님 골프치러 가신다, 등등 다 간다 아니겠습니까? 여러분이 C 언어를 만드는 입장이었어도 아마 함수라는 녀석을 넣었을 겁니다. 생각해 보세요. 나 XX 하러 간다를 1년 내내 타이핑을 하는게 직업이라면, 언젠가 결국 다들 어딘가 간다라는 것을 깨닫게 될 것이고, 이걸 좀 더 쉽게 할 수 있는 방법을 생각해 내지 않겠습니까? 그래서 이런 식의 함수를 추가하게 되는 겁니다.

간다(누가, 어디/모하러)

-- 다음 이시간에..

tag : programming