Hybrid

[번역] 게임을 위한 유체 시뮬레이션 (소개)

creavol@gmail.com (Hybrid) — Tue, 06 Mar 2012 22:56:32 +0900

역자(?)의 말

원문은 Interl Software Network에서 연재 된 문서인 Fluid Simulation for Video Games이다. 이 문서는 2년 정도 지났지만, 아직 번역된 것이 없어서 시작하기로 했다.

물론 원작자에게는 허가를 받은 상태고, 일주일에 글 하나를 목표로 하고, 현실적으로는 2주에 한개가 될듯 하다(제발 3주까지 가지 말기를ㅜ_ㅜ). 문서는 총 11편.

샘플 번역은 아래(다음주에 1편 전체가 올라감). 가독성이 좀 떨어지더라도 원어 표기를 가급적 잘 해두는 것을 지향하고, 샘플로 알 수 있듯이 번역이 서툴러서 형편 없으니 언제든 지적은 ㄳ.

다음주 월요일부터 (빠르면) 한편씩 올리겠습니다! (__)

게임을 위한 유체 시뮬레이션

원문: Fluid Simulation for Video Games
저자: Dr. Michael J. Gourlay

유체 역학의 소개

비디오 게임은 우리 주변 환경을 탐험하고 상호작용하고 싶도록 유도하며, 유체 운동(fluid motion) 같은 현실 세계의 현상이 추가됨으로써 몰입도있고(imersive) 재밌는 가상 세계가 만들어 진다. 최근 물리 시뮬레이션은 더욱 사실적으로 변했지만, 시뮬레이션은 거의 강체(rigid body)에만 한정되었다. 천이나 유체 같은 연속체(continuous media)의 넓게 퍼지는(pervasive) 시뮬레이션[1]은 보기 드문 것으로 남아있고, 이는 주로 유체 역학(fluid dynamics)이 유체의 시뮬레이션을 어렵게 만드는 난문, 그러니까 개념과 계산에 있어서의 난문을 수반하기 때문이다. 이번 문서에서 유체 역학과 그 시뮬레이션 테크닉을 설명함으로써 연재를 시작한다. 연재는 비디오 게임에서 사용할만한 유체 시뮬레이션 알고리즘의 예시로 마무리 된다.

유체 시뮬레이션을 시작하기 위해, 유체 역학의 기본적인 것들을 이해해야 한다. 약간의 기초를 다루는 것으로 시작하자.

유체란 무엇인가?

유체는 어떤 흐르기도 하며(다른 말로, 그 물질을 담는 용기의 형태를 취하는) 형태 변형(deformation)을 거스르지 않는(잡아 끌면 따라 미끄러지는) 물체를 말한다. 사람들은 종종 유체(fluid)와 액체(liquid)를 혼용하여 사용하지만, 엄밀히 말하면, 유체라는 용어는 액체와 기체(gas)를 모두 뜻한다. 가스는 가스를 담는 용기를 완전히 채우는 반면, 액체는 용기의 모양에 의존하지 않는 “자유 표면(free surface)”을 가지고 있다. (종종, 컴퓨터 그래픽스를 사용하여 액체를 가시화할 때, 액체의 표면만을 렌더링 하는 경우가 있다. - 예를 들어 연못의 물결이나, 물 줄기) 액체와 기체의 차이는 유체를 어떻게 모델링하느냐에도 영향을 줄 수 있다. 하지만 둘다 같은 기본 유체 공식을 따르고 비슷한 특징을 공유한다.

그럼 연기(smoke)는 어떠한가? 연기는 기체와 비슷하게 행동하고 액체의 표면과는 같지 않은 일종의 표면 같은 것을 가지고 있는 것처럼 보인다. 연기는 기체와 작은 부유(suspended) 미립자들(particulates)로 구성되어 있으며, 이 미립자들의 조합은 연무질(aerosol)이라 불리운다. 이 미립자들은 기체의 움직임에 영향을 주지 않고 기체의 움직임을 따라간다. (게임 플레이어가 이 움직임을 보게 한다) 보통은 연기를 기체처럼 다루고, 여러 특성-예를 들어 밀도나 구성물- 중 하나를 다르게 한다.

물리 시물레이션의 다양성

여기부터는 다음 이 시간에....

기타

이 번역물은 긁어서 다른 곳으로 그대로 복사하는 배포는 금지입니다. 링크를 걸어주세요.
종종 오타, 오역 수정이 있을 수 있습니다.

번역 이상함: pervasive simulation [본문으로]

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

댓글 쓰기

Spherical Harmonics Lighting WebGL Demo (Renewal)

creavol@gmail.com (Hybrid) — Sun, 05 Feb 2012 12:46:15 +0900

이전에도 올린 데모지만, 가지고 놀 용도로 약간의 기능을 추가했다. 세가지 SH Light 세트(배경)를 사용할 수 있으며 실시간 변경을 해볼 수도 있다.

링크는 요기: Spherical Harmonics Lighting WebGL Demo

기본적인 컨트롤은,

Rotation: SH 라이트를 회전 (실제로는 SH 라이트 대신 노말을 회전한다)
Smooth Transition: SH 라이트간에 변화를 시간 보간해서 렌더링 하는 기능

그 외의 오른쪽 패널에서는 실제 SH 값을 변경해볼 수 있다.

설명은 아주 간단하게만 남기고 예시를 두개만 적어본다. (오른쪽 패널의 SH 모양에서 녹색은 양수, 적색은 음수를 뜻한다)

SH 에서 m=0, l=1 부분에서 다음처럼 (-1, 1, 0)을 입력하면(나머지는 전부 0으로 둠),

다음과 같이 렌더링 된다.

실제로는 9개의 SH 세트가 R, G, B 각각에 대해 따로 있는건데, 하나로 묶어서 본 것이다. 즉, m=0, l=1 에 해당하는 SH 계수에 색깔을 입력하는게 아니라, R에 해당하는 SH에 -1을, G에 해당하는 SH에 1을 입력한 것이다.

마찬가지로 m=-1, l=2 에서 (-5, 5, 0)을 입력하면 (1로 입력하면 색깔이 약해서 큰 수로 입력했다),

다음과 같이 렌더링 된다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

댓글 쓰기

지난 1년간 몇가지 언어들을 사용해보며..

creavol@gmail.com (Hybrid) — Sat, 14 Jan 2012 01:42:26 +0900

갑자기 자기전 rein 님의 블로그에서 2011, 내 프로그래밍 언어는…라는 글을 보고 탄력 받아 작성한다.

그런데 사실상 맛만 본 언어들이 많다. 맛을 본 것을 토대로 올해는 하나하나 잡고 깊게 파려는 생각이다.

C++

당연히 주력 언어지만, boost는 작년에 처음 써봤다. asio 때문에 써본 것인데, 정식으로 C++11 를 넘어 간 후 필요에 따라 boost를 사용할 생각이라 아직까지는 깊게 써볼 생각이 없다. (많이 나아진 것이다. 예전엔 STL도 사용하기를 굉장히 꺼려했다. 지금 생각하면 부질 없지만, 굳이 좋은 점을 찾자면 필요성을 직접 느끼고 써보는 건 좋은 것 같다.) 어쨌건 올해는 C++11를 본격적으로 파고 들어가야할듯.

Lua

썼다고 할 수 없을 정도로 간단하게 사용했다. Script로 사용해서 C++툴에 붙어서 사용하는 형식이었는데, 썼다고 하기 좀 민망할 정도긴 하다.

JSP (Java Server Pages)

거의 10년만에 다시 JSP를 해보는 것 같다. 웹서버를 Clojure 혹은 Python으로 만들까, PHP로 할까 하다가 좀 고급 기능들을 다루기 위해서 JSP를 썼다(나에게는 PHP보다는 JSP가 더 친숙하다).

여러 곳에서 다양하게 썼는데, 가장 처음 만든건 Crash Dump 파일들을 저장해주고, 웹에서는 다운로드를 지원 해주는 것. 웹에서 다운로드를 할 때는 일별/월별/연도별로 실시간으로 zip파일로 압축해서 다운로드 할 수 있도록 한 것이었다. 역시 Java 가 문서화도 잘되어 있는데다 고급 기능들을 잘 지원해서 별 어려움 없이 진행했다.

하지만 동기화 문제라던가, 속도, 최적화 문제는 그렇게 신경 쓰질 못했다는 점이 아쉽다(대규모 접속용이 아니라 현실적으로는 거의 문제가 없지만, 개발 관점에서는 아쉬운 부분).

HTML5, Javascript

웹 페이지를 JSP로 매우 간단한 HTML로만 만들다가, 슬슬 HTML5로 그래프를 그리거나 하는 작업들을 추가했다. 그래프는 RGraph를 이용하고 쿼리나 UI는 jQuery jQuery UI를 사용한 덕에 쉽게 작성할 수 있었다.

여기서 배우는 교훈은, Internet Explorer 를 추방하자!!!

Python

쉘 스크립트 대신에 썼다. Batch 파일은 한계가 있고, Windows Powershell 생각보다 쓰기 쉽지 않았고(익숙해지는데 시간이 좀 걸릴 듯) 직관적인 언어인 Python 이 여러모로 훨씬 쉬웠다.

그렇다고 고급 기술들을 사용한 것은 아니었는데, 소스 내부를 정규식(Regular Expression)을 이용해서 변환을 한다던지, 자동화 관련 작업들, unicode 관련 작업들을 사용하는데 유용하게 썼다.

인상적인건, 사실 Python 책은 초반에 잠깐 맛만 보고 관뒀는데, 막상 필요한 것을 짜기 시작하니 검색으로 별 어렵지 않게 쉽게 구현할 수 있었다(직관적인 언어인듯).

짜증나는건 공백 4개랑 탭을 구분한다는 거. 언어 스스로가 Fortran 마냥 들여쓰기(indentation)를 문법의 일부로 인식하는데, 탭을 실수로 눌렀다가 컴파일이 안되면 다행, 전혀 의도치 않은 방식으로 돌아간적이 있어서 고생했다.

그 외에는 아주 간단한 socket network programming 을 구현해야하는 상황이 있었는데, C++로 짤까 잠시 고민하다가 결국 python 코드 단 네줄로 해결했다. -_-b

*참고: The Best: Python : Socket Programming

Clojure

Clojure는 Lisp(리습)의 수 많은 방언(dialects) 중 하나로, C/C++ 등 빠른 언어로 짜여진게 아닌 JVM 위에서 돌아간다는게 특징인 언어다. 기존 Lisp이 수 많은 소괄호로 이루어져서 가독성에 문제가 많았는데, Clojure는 중괄호, 대괄호를 도입해서 좀 더 나은 가독성을 제공한다는것이 하나의 장점이고, JVM 위에서 돌아가는 만큼 모든 Java 패키지를 쓸 수 있다는 장점 또한 큰 특징인 언어다.

특정한 목적의 Socket 서버를 구현해야했었는데, 다소 고집을 부려서, Clojure 로 도전을 했다. Clojure는 Java를 기반으로 하기 때문에 다행히 Java에 NIO라는 적절한 패키지가 존재했기 때문에 이것을 토대로 사용했다.

참고: Wishful Coding: NIO in Clojure

기본 코드가 존재하는 상황에서도 작업 시간이 좀 걸렸는데, 그 이유는 Living Coding의 맛을 좀 더 살리고, 단발성의 코드를 그대로 사용하기보다는 Multi-thread 기반으로 작업을 위해 이것저것을 시도해봤다. 아니, 아직 이 부분은 해결 중이다. 그리고 이런식의 wrapping package를 만들 때마다 항상 있던 평소 버릇대로 가급적 범용적으로 사용할 수 있도록 수정하고 테스트하느라 시간이 걸린듯.

이 서버를 좀 더 확장해서 성능도 좀 더 신경쓰고, 기능도 여러가지를 넣어볼 예정. 다음 주에는 MongoDB를 붙여보게 되지 않을까 싶다.

참고: github: CongoMongo - Clojure용 MongoDB 라이브러리

그리고 lein을 이용한 프로젝트 관리는 정말 최고다.

참고: github: leiningen

Clojure에 관련된건, NIO 서버, lein, 3D 에 관해서 조만간 블로그에 자세히 다룰 예정(이라고 말하고 안쓴게 한두가지가 아닐텐데......).

Java

얜 곁다리. JSP가 Java기반이고, Clojure도 역시 Java 기반으로 JVM 위에서 돌아가는데다 java 자료구조와 패키지를 그대로 쓸 수 있다는 점에서 java 역시 많이 간접적으로 찾아보게 되었다.

정리

여러 언어를 해본 후 얻은 진짜 교훈은 각 언어의 특징도, 몇가지 언어를 알게 되었다는 점도 아니었다(물론 Clojure에서 느끼는건 그 이상).

Javascript의 예

가령 Javascipt의 경우는 난 아직 책 전체를 보진 못했고, 기초 부분만을 봤다. 하지만 이 기초 부분, 그러니까 아주 아주 재미 없는 뻔히 아는 문법이라던가 기초 자료구조 부분 등을 보면 매우 중요한 것들이 많이 나온다.

사실 Javascript라는 언어 자체가 쉽다면 굉장히 쉬울 수 있는 언어라서 검색하다보면 금방 원하는 것을 구현할 수 있다. 현실적으로 어느정도 프로그래밍에 익숙한 프로그래머라면 대부분의 구현은 쉽고, 빠르게 해낼 수 있다. 하지만 성능상의 문제, 버그를 막는 문제는 그 지겨운 책 기초 부분에 많이 나와있었고, 이 부분은 단순히 필요한 것을 찾아 구현해내는 것으로는 배울 수 없는 부분들이었다.

어느정도 숙련된 프로그래머라면 새로운 언어를 배우는 것은 그다지 어려운 일이 아니다[1]. 하지만 그 훌륭함(?) 때문에, 인터넷을 통해 상대적으로 얻기 쉬운 정보와 라이브러리등을 통해 원하는 구현은 어렵지 않게 해낼 수 있지만, 그 덕분에 다시 한번 기초를 접한다는 것은 굉장히 괴로운 상황(심심한, 재미 없는, 죽을 것 같이 따분한, 두꺼운 책을 다 볼 시간 따윈 없음)에 대면하게 되는 것이라서 정작 중요한 핵심과 기초를 놓치게 되기 쉽다. 다시 말해, 아이러니하게도, 직관을 가지고 핵심을 습득하는 훌륭함 때문에 기초를 놓쳐 훌륭함을 잃게 된다는 말이다.

그러다보니 필요에 따라 상황에 맞는 적절하다고 생각하는 언어를 선택해서 코딩을 한다는게 좋으면서도 참 위험하다는 생각을 하게 되었다. 상황에 맞는 언어를 다양하고 빠르게 익히는 것도 분명 중요하고 좋은 것이지만. 그것으로 언어 전체를 판단하거나 그 언어의 묘미를 놓치게 된다는 것은 다소 아쉬운 상황인 것 같다.

다른 사람들의 조언

책 실용주의 프로그래머(Pragmatic Programmer)에서 저자 앤드류 헌트(Andrew Hunt)와 데이비드 토마스(David Thomas)는 1년에 프로그래밍 언어 한개씩을 배우라고 조언한다.

피터 노르빅(Peter Norvig)은 프로그래밍 1년 완성(Teach Yourself Programming in Ten Years)이라는 글에서 다음과 같은 좋은 말들을 해준다.

최소 다섯가지 프로그래밍 언어를 배워라. class abstractions (자바 또는 C++) 지원하는 언어, coroutines을 (Icon 또는 Scheme) 지원하는 언어, functional abstraction (Lisp 또는 ML) 지원하는 언어, syntactic abstraction (Lisp) 지원하는 언어, declarative specifications를 (Prolog또는 C++ 템플렛) 지원하는 언어, 그리고 parallelism을 (Sisal) 지원하는 언어를 한개씩 배워라.
Pascal: (이미 비슷한 언어를 알고 있다면) 3일안에 Pascal의 문법은 배울 수 있을지 몰라도 그 문법을 어떻게 제대로 쓰는지는 배울 수 없다. 예를 들어, 당신이 Basic 프로그래머라면 Pascal의 문법으로 Basic 스타일의 프로그램을 짤 수 있을지 몰라도 실질적으로 Pascal이 어떤 과제를 해결하는데 좋은지(그리고 나쁜지) 배울 수 없다. 핵심은 무엇인가? Alan Perlis는 이렇게 말했다: "당신의 프로그래밍에 대해 생각에 영향을 미치지 않는 언어는 배울 가치가 없다.

Lisp에 굉장한 매력을 느끼는 나로써는 Lisp계열의 언어(혹은 다른 함수형 언어라도)를 꼭 배우길 권장한다. 해커와 화가라는 책을 쓰기도 한 폴 그레이엄(Paul Graham)은 리스프의 근원(The Root of Lisp)이라는 글에서 모든 프로그래밍 언어는 Lisp에 닯아 간다고 했을 정도고 나도 실제로 어느정도는 그렇다고 본다.

피터 노르빅은 Design Patterns in Dynamic Languages에서 GoF 책의 23가지 패턴 중 16가지가 Lisp에서는 보이지 않거나 더 간단하다고 말한다[2]

가급적 여러 언어를 안다는 것...

Lisp 언어를 모른 다는 것은 언어의 틀에 빠지기 쉽다고 본다. 그리고 python 등의 실용적이면서도 사용하기 쉬운 언어를 모르고 가령 익숙하다는 이유로 C++만을 고집한다면, 정말 어리석은 일이 아닐 수 없다(다시 강조하지만 간단한 테스트 소켓 프로그램을 단 4줄만으로 해결했다).

다양한 언어를 아는 것, 그리고, 단순히 그 언어로 표면적으로 보이는 목적만을 달성하기 보다는, 기초를 충분히 습득해야한다는 것이 정말 중요하다는게 지난 1년간 배운 것들이다.

또 그래야만 훌륭한 프로그래머라고 주장하는 사람도 있다. [본문으로]
논쟁거리가 될 수 있는 주제인데, 찬우님이 디자인 패턴(Design Patterns)에 대한 생각에서 좋은 말씀을 해주신다. [본문으로]

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

댓글 쓰기

올해 목표였던 The Art of Computer Programming 읽기

creavol@gmail.com (Hybrid) — Tue, 27 Dec 2011 23:23:33 +0900

The Art of Computer Programming을 드디어 다 읽었......다고 말하면 좋겠지만, 1권 전체도 아니고, 1.2까지 읽었다. 1.3절부터는 MIX라는 (이론적인) 기계어파트다. 예제문제도 거의 대부분 나중으로 미뤘고 * 표시가 되어 있는 1.2.11도 이 책을 처음 읽을 때는 그냥 넘어가도 좋다길래 착하게 말을 듣기로 하고-ㅅ-;; 안 읽었다.

원래 올해초 목표는 1권 전체를 읽는 것이었는데, 중간에는 거의 안봤고, 현실적으로 1.2까지만이라도 꼼꼼하게 보자는 생각으로 목표를 수정했다. 그래도 연말이라도 열심히 봐서 간신히 이 정도라도 본거 같다. 사실 1.2까지의 분량은 (숫자가 말해주듯) 매우 적은데, 대신 그만큼 매우 꼼꼼하게 볼 생각으로 봤다. 한줄 한줄 이해될 때까지 보고, 가급적 풀어보고, 예제 문제도 직접 풀어볼만한건 풀어보면서 진행했다.

보면서 가장 열받는건-ㅅ-+

It is easy(not difficult) to prove(drive) that ….

이라고 써있는 부분들.... 아어...... 위와 같이 써있으면 넘어갈 핑계가 없다. 일단 꼼꼼하게 보기로 했기 때문에 이런건 이해 될 때까지 붙잡고 봤다.

그 외에도 좌절을 안겨주는 말들은 요런거.

It is obvious that ...
Elementary probability theory is sufficient for most of the applications in this book. --pp101

우쒸.... 싸우자!

원래 올해 목표가 한권 전체였다가 축소 된만큼, 내년 목표는 좀 더 현실적으로 생각하고 있다. 1권 연습문제를 풀이(여기서 풀만한거 골라 내는 것도 일인데.....)와 챕터 1 정도? 욕심부리기보다는 최대한 꼼꼼하게 읽다보면 1년이 후딱 가지 않을까...

그 외의 목표는 PBRT(Physically Based Rendering: from Theory to Implementations) 전체 다 읽기(올해와 동일-ㅅ-;;). 이 책은 난이도보다는 분량과의 싸움. (아침마다 한시간씩 읽던지 해야지 원...)

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

댓글 쓰기

웹게임으로도 등장한 Bastion

creavol@gmail.com (Hybrid) — Sat, 24 Dec 2011 13:21:55 +0900

Bastion은 쿼터뷰(isometric view)의 액션 RPG 게임이다. 스팀에서도 팔고 있음.

이 게임이 크롬 웹스토어에 있다길래 당장 해봤다.

일단, 그간 웹에서 본 게임들 중 퀄리티는 최고였다. 그 이유는 NaCl로 만들었기 때문인데, 이 때문에 이걸 진짜 웹 게임이라고 부를 수 있을지는 잘 모르겠다.

Bastion

일단 스크린샷부터.

메인 메뉴부터 (적어도 내가 해본 만큼은) 원래 게임과 동일하다.

게임이 끝나면,

돈을 내야함. 공짜인줄 알았더니, 스팀에서 파는 가격과 동일한 $14.99을 지불해야 풀 버전을 할 수 있다.

NaCl (Native Client)

처음엔 순수 HTML5 & WebGL인 줄 알았는데, 알고보니 NaCl이라는 플랫폼으로 개발되어진 게임이다.

NaCl은 Native Client의 약자로, 일반적인 HTML과 Javascript이 아닌 low level을 접근가능하고 컴파일 된 코드를 돌리는 크롬 전용 플랫폼이다. 웹에서 돌린다는 취지는 좋은데, 이미 비슷한게 있었다가 망하고 큰 문제점을 두루두루 남긴 ActiveX를 뒤를 쫒지 않길 바랄 뿐이다. 물론 ActiveX 보다는 훨씬 여러모로 낫겠지만, 그래도 많은 우려를 낳을 수 있을 것 같다.

이미 우려는 여러곳에서 하고 있는거 같다.

NaCl seems to be 'yearning for the bad old days, before the web,' Native Client is about building a new platform – or porting an old platform into the web [...] it will bring in complexity and security issues, and it will take away focus from the web platform.

- Håkon Wium Lie, Opera's CTO[1]

아직 NaCl을 자세하게 보진 못해서 이렇다, 저렇게 말할순 없는데, 어쨌거나 현재의 HTML5 & Javascript도 성능상 한계가 있는건 사실이니 좀 더 추이를 지켜보는게 좋을 것 같다.

Google Native Client: The web of the future - or the past? [본문으로]

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

댓글 쓰기

킨들 터치(Kindle Touch) 도착!!

creavol@gmail.com (Hybrid) — Tue, 29 Nov 2011 01:04:51 +0900

킨들 터치(Kindle Touch)가 왔다. 아직 아마존에서 한국으로는 직배송을 안해주기 때문에 한달 동안 구입 여부를 고민하고 주문하고 고민하고 취소 하고 다시 고민하고 그러다가 구매대행으로 겟!

킨들 키보드(Kindle Keyboard, 원래는 킨들 3라는 이름)와 비교를 중심으로 간략하게 적으려고 한다.

아무런 책이 없는 첫화면. Collections(일종의 리스트)는 다른 기기(내 경우 킨들 키보드)로부터 가져오기(import)를 할 수 있다. 아쉬운 점은

동기화는 아니다.
말그대로 Collections의 목록만 가져오기하는 것이라서, 책은 일일이 넣어야 된다(좀 귀찮...).

킨들 키보드와의 비교. 좀 더 넓게 찍었어야 하는데, 촬영 배경이 그닥 좋지 않아서 -ㅅ-;;

일단 외관은 당연히 가볍다. 킨들 키보드보다 약간 가볍다. 킨들 터치는 액정이 움푹 들어갔는데, 이것도 아주 맘에 든다. 킨들 터치의 버튼은 홈버튼과 전원 버튼이 전부.

아래 쪽에 있는 킨들 키보드의 전원 스위치는 슬라이드 형식인데, 킨들 터치의 전원은 버튼이라서 눌러지기 쉽다. 좀 아쉬움.

구입한 버전은 광고 버전(쫌 더 싸다)이라 광고가 들어가는데, 별로 거슬리지 않는다. 위에 화면은 껐을 때 화면. 이건 그냥 킨들 어플 광고.

켰을 때 메인 화면에도 들어간다. 물론 책을 볼때는 광고가 안보인다.!

어쨌건 터치를 구입한 큰 이유는 두가지, 터치와 X-Ray 기능.

책 넘기기는 버튼이 따로 없이 터치를 통해 작동하는데, 생각과는 다르게, 책 넘겨지는 속도가 킨들 터치보다 킨들 키보드가 더 빠르다. 킨들 터치가 대략 1.5~2배 정도 느리다고 보면 될 듯.

하지만 터치감은 생각보다 좋다. 반응 속도는 느린데, 그거 신경 안쓰고 빠른 타자가 가능하다. 감압식이 아니라 부드럽게 좋은 느낌으로 터치가 된다.

터치가 문제가 되는 것은 지문이 남는 것인데, 아무래도 일반 액정이 아니다보니까 그렇게 크게 티는나지 않아서 신경안쓰일 정도다. 근데 한 한두시간 정도 보면 어떨지 모르겠다.

그리고 기대하던 X-Ray 기능!! 사실 이 기능 때문에 구입했다고 봐도 된다. 위 화면은 왕좌의 게임(A Game of Thrones: A Song of Ice and Fire)에서 X-Ray를 켰을 때 화면. 현재 페이지에 나오는 인물들을 보여준다.

현재 챕터나 책 전체에 나오는 캐릭터들을 한번에 볼 수도 있다. 심지어 사람외에 주요 단어들도 볼 수 있다(여기서는 Dothraki, Free Cities 등).

그 중에 용어나 캐릭터를 누르면 이렇게 자세하게 나온다! Daenerys Tagaryen을 눌러봤다. 으악!!!

가지고 있는 책들 몇개를 눌러봤는데,

안되는거,

Status Anxiety
Physically Based Rendering: from Theory to Implementation (PBRT)

되는거

Steve Jobs
The Ultimate Hitchhiker’s Guide

PBRT는 당연히 안된다지만, Status Anxiety는 쬐...끔 기대했는데, 역시 안되고, The Ultimate Hitchhiker’s Guide 는 상대적으로 오래된 책이라 지원해줄지 걱정했는데 다행히 지원한다.

왕좌의 게임 같은 경우 워낙 인물이 많고 복잡해서 그리고 천천히 읽고 있느라 인물들에 대해 까먹기 쉬워서 X-Ray가 가장 필요한 책이었다. 아주 제대로 써먹을 듯. (실제로 아이폰/아이패드용 왕좌의 게임 (비공식) 어플을 구입해서 종종 인물 정보를 읽어보곤 했다.)

정리하자면, 킨들 키보드와 킨들 터치는 무조건 한쪽이 좋은건 아니고 장단 점이 있다.

킨들 터치의 장점

터치다. -_-ㅋ 어쨌건 편하다. (예를 들어 사전 찾을 때 커서 이동 없이 그냥 꾸욱!)
X-Ray 기능이 지원된다(단, 이건 현재 그냥 킨들이라는 이름을 가지고 있는 신형 킨들도 지원한다).
디자인이 이쁘다. 키보드가 안달려서 좋다.
키 입력이 훨씬 편하다.

킨들 터치의 단점

페이지 넘김 반응 속도가 1.5~2배 더 느리다.
한 손으로만 쓰기에 다소 무리가 있다. (개인적으로는 전혀 신경 안쓰는 부분)
지문이 남는다.
전원 스위치가 버튼식이다.

PS. 사진은 못 찍었는데, 사전 크기도 맘에 든다. 킨들 키보드는 커서로 사전을 찾으면 상단이나 하단에 두 줄만 보여서 원래 의미를 파악하기 힘들 때가 많은데, 킨들 터치는 터치를 하게 되면 화면 가운데에 5줄이 보여서 좋다. 하지만 아쉽게도, 반응 속도 & 처리 속도가 좀 늦어서 사전 찾는 속도가 결국 그렇게 빠르지는 않다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

댓글 쓰기

컴퓨터 속의 수학과 물리 - 확률 분포

creavol@gmail.com (Hybrid) — Thu, 10 Nov 2011 13:03:18 +0900

개요

(가상의 상황) 어느 날 다음의 요구사항이 들어온다.

(1) 과녁을 향해 화살을 쏘는데 정밀도(능력치)가 낮으면 골고루 쏘고, 정밀도가 높으면 한 곳에 더 집중해서 쏜다. (2). 근데 정밀도가 높아도 오발이 약간은 있어야함. 물론 정밀도가 높을 수록 오발은 줄어들것.

이것에 대한 구현 방법은 무척 많다. 가장 좋은 방법이란 없다. 여기서는 그 중에, (물론 내가 생각하기에) 가장 엘레강트하고 뷰티풀한 방식인 수학의 확률을 이용한 방법을 소개한다.

1번의 조건만 있다면, 그리고 쉽게 구현을 하고자 한다면 다음과 같이 표현되도록 그 범위만 지정하면 된다.

<그림 1> 정밀도가 낮을때, 높을 때

하지만 2번의 조건이 있을 경우, 또는 없더라도 좀 더 창의성을 발휘하면 다음과 같이 할 수도 있다. 여기서 빨간색은 화살이 많이 쏴진 지역을 뜻한다.

<그림 2> 정밀도가 낮을때, 높을 때

이 글에서 다룰 내용은

위와 같은 분포 그래프를 만들고,
점을 찍을 때(화살을 쏠 때), 원하는 분포가 나오도록

하는 것이다. 보통은 일반적으로 일정한 분포로 값을 내주는 랜덤 값을 이용하기 때문에, 일정한 분포의 값을 원하는 분포로 변환하는 것이 가장 핵심이라고 볼 수 있다.

확률 밀도 함수(Probability Density Function, PDF) 만들기

원래는 원 모양의 2차원 과녁을 생각해야하지만, 편의상 그냥 1차원으로 생각해서 거리만 생각한다.

<그림 3> 세로축은 랜덤. 가로축이 과녁과의 거리의 역(오른쪽에 맞을 경우 더 정확히 쏜 것으로 간주). 왼쪽 그림은 점의 분포가 동일한데, 오른쪽 그림에는 x=1 부분에 더 많은 점이 찍혀 있다.

위의 그림의 확률 분포를 그래프로 그리면 아래와 같다.

<그림 4>x축은 정확도. y축은 확률 밀도(probability density)

x축이 1인 지점은 화살을 정확하게 명중 시키는 것을 뜻하고, 0인 지점은 가장 빗나가게 쏜 것을 뜻한다. 이때 y축이 확률 밀도 함수(PDF, probability density function)다.

일단 확률 밀도가 생소할 수도 있는데, 일단은 틀리지만 쉬운 의미로는 그냥 그 지점의 확률이라 생각해도 된다.

위의 <그림 4.b>에서 PDF인 P는 다음의 형태를 취한다.

여기서 x=1일 경우 확률 밀도가 4이고, x=0일 경우 확률 밀도가 0이라는 말인데, 확률 밀도는 확률과 비슷하지만 조금 달라서 1을 넘을 수가 있다[1].

여기서 중요한 조건이 있다. x의 범위는 임의로 0부터 1까지로 잡았는데, 이 구간의 PDF 값을 적분하면 1이 되어야 한다(화살을 쏠 때 불발이 없다는 가정).

<그림 4.b>에 해당하는 이 함수를 구현을 하면(어떻게 구현하는지는 밑에 설명), <그림 3.b> 처럼된다.

정밀도와 연결하기

라는 곡선은 함수에서 b를 3으로 지정했을 때 a가 4가 됨을 구해서 얻은 곡선이다. 즉, 함수를 적분하면 1이 되는 점을 이용하면, a = b+1 의 관계가 성립됨을 알 수 있다. 결국 형식으로 그래프를 만들 수 있다. 여기서는 편의상 계속 b를 3으로 두고 진행한다(하지만 사실 상수로 바꾸지 않고 b로 둬도 별로 어렵지는 않다).

이걸 정밀도 s이라는 변수와 함께 사용해보자. s이 0일 경우 화살을 워낙 못쏴서 고르게 쏘도록 할때(<그림 3.a>, 사실 이렇게 쏘는 것도 능력이긴하다.)의 PDF는 이라 정하고, s=1일 경우는 방금 만든 가파른 곡선인 를 사용한다.

방금의 두 PDF, , 를 s를 이용해서 선형보간을 시켜보자. 그러면 최종적으로 이 되는데, 여기서 한번 더 이 새로운 PDF도 적분 했을 때 1이 되는지 확인해보면 무리 없이 1이 된다.

여기까지의 과정을 그래프로 그려보자. 와 는 둘다 2차원 그래프지만, 여기에 s을 더하면 3차원 그래프가 된다.

<그림 5>

s=0일 때의 단면 그래프는 <그림 4.a>와 같고 s=1일 때의 그래프는 <그림 4.b>와 같다. 0.5 쯤에 있는 애매한 그래프도 바로 얻을 수 있는 장점이 있다[2].

누적 분포 함수(Cumulative Distribution Function, CDF) 만들기

자, PDF 함수를 만들고 나면 끝인 것 같지만, 큰 장벽이 남아 있다.

PDF는 확률 분포다. 확률 분포만으로는 제대로 사용할 수 없다. 어떤식으로 사용해야하냐면, 우리가 임의 랜덤 값을 주고 함수에 넣으면 짠 하고 원하는 값이 나와야 하는데, 그 원하는 값의 분포가 바로 PDF여야 한다. 좀 더 구체적으로 말하자면 실제 PDF와 우리가 사용해야할 함수는 사이에 CDF라는 함수가 존재하고, 우리가 필요로하는 함수는 CDF의 역함수다.

CDF 함수는 누적 분포 함수(Cumulative Distribution Function)를 뜻하며, PDF 함수로부터 다음과 같이 정의 된다.

즉, C(x) 값은 x가 0부터 x까지인 구간(전구간)의 PDF 함수를 적분한 것이다. 처음 전제조건으로 PDF를 적분하면 1로 하기로 했기 때문에 결국 (적어도 여기서는) C(1)는 항상 1이다.

어쨌건 한번 CDF를 구해보자.

이걸 다시 그래프로 그리면 다음과 같다. s가 어떤 값이던지 C(0)는 0이고, C(1)는 1인 것이 특징이다.

<그림 6>CDF에서는 x가 0에서 1로 올라갈때 CDF값(y축)도 같이 올라가는 것이 특징. s값에 관계 없이 항상 C(0)=0, C(1)=1이다.

드디어 막다른 골목을 마주하게 된다. 최종적으로 CDF의 역함수를 구해야하는데, 결론부터 말하자면 이 C(x) = (1-s)x + sx^4 는 역함수가 존재하지 않아서, 이걸 그대로 사용할 수가 없다.

왜 CDF의 역함수가 필요한지는 밑에서 보고, 아무튼 일단 이걸 우회하기 해보자. 방금은 와 에서 를 만들고 를 만들었는데, P(x)를 합치지 말고, C(x)의 역함수를 만들고 합쳐보자.

최종적으로 이므로 에서 y값이 우리가 전달해줄 랜덤 값이 되고 y값으로부터 원하는 x값을 얻게 된다.

CDF의 역함수

왜 역함수가 필요한지를 살펴보자. C(X)의 역함수부터 보자. PDF는 결코 음수는 될 수 없기 때문에 CDF에서 x가 0부터 1로 점차 늘어갈 수록 y값은 절대 줄어들지 않고 점점 늘어만 간다.

<그림 7>

역함수라 함은 y축과 x축이 바뀐 형태를 뜻한다. 이 그래프에서 축 자체를 바꾸지 않고, y축에서 일정한 간격으로 y값을 선택한다고 해보자(빨간선), 그러면 그에 해당하는 x축의 x값이 나오는데, 이 x값이 바로, PDF에 따라 분포된다. 즉, 파란선을 보면 x=1에 가까운 곳에 더 집중되어 분포가 되는 것을 알 수 있다(y축의 빨간선이 일정한 가격인 것이 중요).

결국 C(x) 역함수에 우리가 (0과 1사이에) 고르게 분포된 랜덤 값을 하나 전달하면, 필요한 값(이 경우 정확도 x)이 나온다. 이것은, 우리가 어떤 함수의 분포인 PDF를 정의하면 일정한 분포를 가지는 랜덤 값들의 집합을 통해 원하는 PDF 형태로 분포되어 있는 값들의 집합을 얻을 수 있다는 것이 된다.

후... 길게 왔다. 결국엔 수식 한 줄이 나오고, 자바스크립트 한 줄 코드인

return (1-s)*y + s * Math.pow( y, 1/(b+1) ); // b는 편의상 3

요걸 얻어내기 위해 여기까지 왔다. 랜덤값 y를 전달해주면, x값이 리턴된다. 그 값을 쓰면 되고, s값 조절에 따라 분포가 달라지는 것을 확인할 수 있다.

s값의 변화에 따른 분포를 확인하기 위해 자바스크립트로 웹 시뮬레이터(?)를 만들어봤다.

이 자바스크립트 코드는 크롬 15, 사파리 5.1.1에서 테스트 되었음.
오페라에서는 dat.GUI 라이브러리 문제로 실패했음. IE는 테스트하지 않음.
dat.gui 라는 자바스크립트 GUI 라이브러리를 사용했음.
Acuracy는 이 글에서 말하는 s 변수.
FunctionType 을 Polar로 바꾸면 원형 과녁으로 바꿔볼 수 있음.

눈치 챈 사람도 있겠지만, 여기에 한 가지 함정이 있는데, 로는 안타깝게도 원하는 <그림 2>의 원형 과녁을 만드는데 사용할 수 없다. 그 이유는, 지금까지는 1차원적인 것들만 생각해서 x를 거리의 역으로 생각했는데, 이걸 그대로 사용해서는 원하는 분포를 얻을 수 없다. <그림 2>의 원형 과녁은 2차원의 극 좌표계로 표현해야하기 때문에 다시 다 계산해야한다[3]. 과정은 다소 복잡해서 과감히 생략하고, 결론적으로 함수는 다음과 같이 변형된다.

그리고,

여기서 , 같은 함수는 약간 꽁수를 통해 구했다[4]. 이 전반적인 과정은 숙제(-_-ㅋ?)로 남기도록 하겠다(극 좌표계와 데카르트 좌표계의 변환에 대해 덜 익숙한 사람들에게는 어려울 수 있다. 참고자료인 PBRT책을 참고할 것을 강력히 추천한다.).

위에 있는 웹 시뮬레이터에서 FunctionType을 Linear에서 Polar로 변경하면 원형 과녁을 볼 수 있다. 슬라이더 컨트롤에서 Ability는 s값을 의미하는 것으로 0과 1사이로 조절할 수 있다. s값이 1에 가까울 수록 특정 지점에 집중 되는 것을 확인하면 된다.

응용 & 결론

사실 나 같은 사람이야 이런 과정을 재밌어 하는 건데, 분명 그렇지 않은 사람들도 많고, 또 이 과정은 그렇게 본보기가 되기 좋은(사용하기 쉬운, 깔끔한) 과정은 아니다.

하지만 이렇게 한번 해두면

return (1-s)*y + s * Math.pow( y, 1/(b+1) );

혹은

return (1-s)*Math.sqrt( y ) + s * Math.pow( y, b );

같은 쉬운 코드가 나오고, 이 코드는 그때부터 이론적인 도출 없이 이것저것 (s값의 변화를 조절하거나 b값을 조절하는 방법 등) 커스터마이징 해볼 수 있다. 모든 것이 다 이론적으로 완벽한 수식으로 떨어질 순 없다. 하지만, 그렇다고 이론적인 도출 과정 없이 위의 함수를 만들어내는 것도 사실 쉽지 않다. 가장 좋은 방법은 이론의 명확함과, 현실적인 시도(다른 말로 삽질)가 부드럽게 어울려지는 것이라 생각한다.

참고문헌

Physically Based Rendering: from Theory to Implementation 2/E, Matt Pahrr, 2010
dat.gui: 자바스크립트 GUI 라이브러리
WolframAlpha: 2D/3D 그래프는 여기서 그렸음.

심지어 무한대가 될 수도 있다. 디락 델타 함수 참조. [본문으로]
이 때 1-s와 s를 사용하지 않고 예를 들어 1-s^2와 s^2를 사용할 수도 있다. 그러면 양 끝이 아닌 중간도 정밀도에 따른 변화 정도를 조절할 수 있다. [본문으로]
사실은 극 좌표계를 쓰지 않고 샘플을 걸러내는 방법으로 우회하면 가능하다. 리젝션 방법(Rejection method)이라고도 하는데, 사실 이 방법이 이어서 설명하는 방법보다 훨씬 깔끔하다(물론 장단점이 있다). [본문으로]
구했다기보다는 정확하게는 사용하기 쉬운 CDF를 만든 후 역으로 PDF를 도출했다. [본문으로]

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

댓글 쓰기

알랭 드 보통 내한 기념 사인!

creavol@gmail.com (Hybrid) — Mon, 24 Oct 2011 01:31:30 +0900

요즘 알랭 드 보통(Alain de Botton) 책에 푹 빠져있다. 덕분에 딴 공부들을 소홀히 할때도 있었고, 반면 최근 한주는 드 보통의 책을 거의 못 보기도 하고 그랬지만, 꾸준히 붙잡고 틈틈히 읽는 중. 그 와중에 내한을 했다! 강연도 했지만, 추첨에서 처참히 탈락 ㅜ_ㅜ 사인회만 부랴부랴 쫒아가서 받아왔다.

사인은, 지금 보고 있는 책까지 본 세권 중에 가장 좋아하는 책, <Status Anxiety(불안)>에 하나 받고, 아직 안봤지만 평가가 좋은 <The Art of Travel(여행의 기술)>에 받았다. 데뷔작 <Essays in Love(왜 나는 너를 사랑하는가)>에도 받으려 했지만, 시간관계상 사인은 2권까지만 해준다길래... 흑.

지금 보고 있는 책은 <The Pleasures and Sorrows of Work>. 재미만 따지자면 아직까지는 기존에 봤던 <Satstus Anxiety>나 <Essays in Love> 보다는 훨씬-_-ㅋ 재미 없지만, 그래도 다 보고 나면 여러 좋은 생각을 얻을 수 있는 책인 것 같아서 좋은 느낌으로 보고 있다.

앞으로 볼 책들. 원서를 기준으로 보고 이해가 안가는 부분은 번역서를 찾아가며 보고 있다. 그나마 <Status Anxiety>는 번역서 없이 봤는데, <Essays in Love>나 <The Pleasures and Sorrows of Work>는 너무 너무 어려워서 번역서를 꼭 끼고 본다. 어려워도 원서를 고집하는 이유 중에 하나는, 번역서로는 드 보통의 문체를 제대로 접할 수 없어서. 물론 세권째 본다한들 익숙해지는건 별로 없지만서도-_-, 번역서는 제2의 창작이니만큼 내용을 떠나 표현, 문체까지 전달받을 순 없다[1]. (그래서 이 고생을 하고 있다ㅜ_ㅜ)

좀 자세한 감상평은 한 2~3권을 더 보고 남길 예정. 아직은 그냥 책에 푹 빠져 있는게 좋다. ~.~

전에도 블로그에 소개했던 동영상, <알랭 드 보통: 보다 온화하고 부드러운 성공 철학>. 이 동영상 덕에 이렇게(왕팬)까지 되버렸다.ㅎㅎ

그렇다고 번역이 이상해서.. 라는 것은 아니다. 약간 다른 말이긴 한데, 정영목씨가 옮긴 <<일의 기쁨과 슬픔>>은 번역이 매우 맘에 든다. 그래서 찾아보니, 드 보통의 다른 책들 여러개도 번역했다. 번역은 참 맘에 들지만, 그래도 좋아하는 작가의 표현 그대로를 전달 받을 수 없는건 포기할 수 없다.ㅎㅎ [본문으로]

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

댓글 쓰기

셧다운제를 보며...

creavol@gmail.com (Hybrid) — Sun, 23 Oct 2011 01:34:54 +0900

셧다운제가 시행된다고 난리다. 대략적으로 셧다운제는 여가부가 스스로 밥그릇 좀 챙겨보고자 협박(?)을 포함한 별짓을 하다가 그것도 안되니까 결국은 한번 죽어봐라 하는 의도로 끝까지 밀고나간 말도 안되는 제도다. 12시 이후에 청소년들의 게임을 '강제적으로' 규제하겠다는 것. 찾아보면 많이 나오고, 많이 이슈가 되는 내용이라 개인적으로 문제점이라 생각하는 점을 간단하게만 나열하자면,

주민등록번호 도용 장려 - 결국에는 게임할꺼면 부모님 주민등록번호를 쓰라고 장려하는 셈. 가정에서 부모님이 게임을 허락해도 못하는게 옳은 것인가?
자율권 침해
비디오 게임을 포함한 게임, 놀이라는 것을 나쁜 것이라고 여기는 우리나라 특유의 이상한 분위기 - 학생은 공부할 때라는데, 그게 현실적으로만 맞는 얘기지, 절대 올바른 것은 아니다. 법과 규제는 올바른 것을 장려하도록 해야하는데, 우리나라는 이상하게 거꾸로 학생들의 놀이 문화를 없애고 공부 스트레스만 어떻게든 늘려보려함.

여가부는 원래 그런 사람들이라, '원래 저런 사람들인 줄은 알았는데, 대놓고 저렇게 자기 밥그릇 좀 챙겨보려고 아무 생각 없이 일을 한다는 것을 티를 내는구나' 정도의 느낌만 받았다.

아군?

그런데 진짜 답답한건 아군(?) 진영들. 자꾸 이상한 얘기를 한다.

오늘 트위터에서 본 얘기는 대략 이렇다.

셧다운제가 뭐가 문제인지 모르겠다고? 결국엔 외국 게임들이 우리나라에 서비스를 안하는게 문제. 모바일 게임 스토어가 안들어오는 것과 같은 맥락.

이 사람이야 말로 진짜 문제를 놓치는 것 같다. 게임 하지 말라고 주장하는데, 외국 게임이 우리나라에 안들어온다는데 저쪽에서 꿈뻑하겠는가? 저 얘기를 하면 더 좋아할꺼다. (아니? 셧다운제가 실시 되면 외국 게임들이 못들어온다고? 일석이조네!) 사실 이런 시각은 셧다운제 얘기가 나오는 처음부터 종종 있어왔다. 예를 이런 맥락의 얘기를 하는 사람들이 있다.

셧다운제? 게임 산업을 다 죽이려는거냐?

저쪽에서는 게임이 마약이라고 없애한다고 주장하고 있는데, 이쪽에서는 돈 얘기, 개발자 입장에서 당장 밥줄 끊기는 얘기 따위나 하고 있다. 아마 저쪽에서는 '마약 산업이 돈을 얼마나 많이 벌고 있는데 죽이려고 하냐?'로 들리지 않을까 걱정된다.

좀 더 비약적으로 비유를 하자면,

담배를 피우지 마세요. 마약을 하지 마세요. 도박을 하지 마세요.

라는 말에, (혹은 관련된 국가 조치에)

아니, 담배 산업 죽이려는거냐! 마약 산업(?) 죽이려는거냐! 도박 종사자들을 실업자로 만들셈이냐!

라는 말로 대꾸하는 셈이다. 분명히 (잘못되기야했지만) 지금 저쪽에서는 청소년을 유해매채로부터 보호한다는데 돈 얘기나 게임 산업 얘기나 하는 건 분명히 잘못됐다.

굳이 말하자면, 여가부나 셧다운제를 찬성하는 사람들은, 게임 산업을 죽이려고 하는게 맞다.

근본적인 문제

근본적인 문제는 우리나라 특유의 빡센 문화다. 여유가 없다. 여유 시간을 갖는 다는 것 자체가 죄악시 되고, 쉽게 접할 수 있는것이 게임이다. 나도 어렸을 때는 부모님이 아무런 논리적인 근거 없이, 게임은 나쁜 것이라고 가르치셨다. 아무리 왜 나쁜지 물어봐도 명쾌한 해답은 안해주셨고, 못해주셨다. 문제가 될만한 것을 찾자면 중독이 문제일 수 있는데(실제 중요한 문제이긴 하다), 이 세상에 중독될 여지가 있는 모든 것들을 없애는 것이 바람직한 것은 아닐 것이다.

게임은 마약이 아니다. 그런데, 마약과 동일시 한다거나, 무조건 해롭기만 하는 것으로 보는 것은 분명 잘못됐다. 어느 시대나 놀이 문화라는 것이 있었고, 지금은 그것이 비디오 게임의 형태로 존재할 뿐이다. 중독은 분명 문제가 될 수 있지만, 그것은 게임 자체를 타겟으로 삼기 보다는 중독 자체를 다르게 봐야 하는 것이다[1].

청소년에게 게임은 마약이나 다름 없다.

여기에 다음과 같이 대응하지 말고,

게임(마약) 산업 죽이려고 하는거냐?

내 생각엔 이렇게 대응해야 옳다.

특히 청소년에게 마약은 해롭지만, 게임은 마약이 아니다. 게임은 긍정적인 측면도 많이 가지고 있다. 부정적인 측면만을 보고 그것을 없애기 위해 긍정적인 효과까지 모두 없앤다면 여러 부수 효과[2]들이 생겨날 수 있다.

셧다운제. 분명 나도 반대하는데, 제발 '게임 산업' 얘기, '돈 버는' 얘기로 셧다운제를 반대 하진 않았으면 좋겠다.

PS. 이런 것들에 대해 얘기하다보면 항상 극단적인 생각을 가진 사람들이 존재한다(개인적으로는, 해답은 언제나 양 끝이 아니라 중간 쯤에 있다고 본다).

게임을 무조건 나쁘게 보는 쪽이 한 쪽 끝이고, 다른 한쪽은 게임이 전혀 나쁘지 않다고 하거나, 게임의 중독성을 단순히 개인의 탓으로 돌리는 사람들이다. 나는 개인적으로 양 끝은 (절대값하면 그 값이 똑같듯이) 똑같이 나쁘다고 생각한다.

정말 셧다운제를 할 것이면, 하루 몇시간 이상하면 셧다운을 한다던지 하는 것이 그나마 나은 방법이다(물론 이것조차도 찬성하는 것은 아니다). 지금의 셧다운제와 비슷한 문제를 가지고는 있지만, 적어도 이러한 시간제 셧다운제는 '중독'을 막는다는 명분 정도는 가지고 있다. [본문으로]
자살율이 늘어난다던지, 폭력, 일탈 등이 늘어 날 수 있다. 실제 간접적으로 연관될 수 있는, 충분히 이러한 결론을 위해 사용될 수 있는 연구/통계 결과는 지금도 어느정도 존재한다. [본문으로]

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

댓글 쓰기

RAGE - 실망, 실망, 실망

creavol@gmail.com (Hybrid) — Sun, 16 Oct 2011 01:28:27 +0900

안좋은 얘기를 주로 할건데, 너 따위가 감히 존 카맥(John Carmack)의 작품을 까냐 말해도 할말은 없다. 축구 못하는 사람이 평소 잘하던 축구 선수를 보고 평소 잘하다가 왜 요즘 계속 못하는건데!라고 따지는 것과 비슷하다고 보면 되겠다.

그래픽 - 단점

기본적으로 모든 것들이 다 정적이다. 맵과 관련된 모든 것들은 다 파괴할 수도 없고 움직일 수도 없다. Crysis 2가 모든 것을 동적(계산)으로 밀고 나가는 이 시대에, RAGE는 모든 것을 정적으로 해버렸다[1].

하늘은 안움직이다. 구름 한 점 꿈틀대지 않는다. 쿨하다, 존 카맥.

분위기로 봐서 이건 천이다. 하지만 움직이지 않는다. 총으로 쏴도 구멍은 커녕 움직이지도 않는다. 그 외에도 의자를 포함해서 그보다도 작은 물체들 모두 그냥 정적이다.

물은 그냥 그래픽이 별로다. 뭐, 이 정도는 별 문제는 아닐지도.

요즘은 SSS(Subsurface Scattering), SSSSS(Screen Space Subsurface Scattering) 같은게 게임에 나올 정도로 기술이 발전되어 있다. 그 정도까지는 바라지 않기는 한데, 아무튼 피부의 질감을 살리는건 매우 어렵고 단순 디퓨즈 텍스쳐 이상이라는 말. RAGE에서는 그냥 디퓨즈 텍스쳐만 썼기 때문에 그냥, 그냥....... 음...... 별로다. 쩝. (텍스쳐는 디테일 하다.)

노말 맵이 없다. 아............... 메가 텍스쳐 탓일까? 텍스쳐에 전부 노말맵을 둘순 없어서 일까? 결국 저 빤짝빤짝 것들은 다 그냥 텍스쳐에 붙여져 있는 형태다. 아........

결과적으로 모든게 정적이라는 것은 캐릭터가 시점을 변화 시켜도 보이는 것들이 변하지 않는 다는 것인데, 이 때문인지, 맵을 구분하기고 좀 힘들다. 가끔 문이 열려 있는데도 문을 못 찾거나 한 적이 있다. 물체의 구분이 잘 되지 않는다는 말.

그래픽 - 장점

텍스쳐를 발랐으니 바위는 참 멋지다(근데, 상대적으로 다른 텍스쳐는 별로다).

Adaptive HDR과 Tone Mapping을 이 정도로 사실적으로 구현한 게임은 본적이 없다. Half-life 2 - Lost Cost에 이어, A.V.A에서도 Adaptive HDR을 사용하긴 했는데, 특정 위치를 가면 변환하는 효과가 보이게 되는 가짜(Fake) 방식이었다. RAGE에서는 그 단계를 좀 더 플레이어의 위치에 의존하도록 만들어서 매우 부드러운 효과 변환을 볼 수 있다.

색감은 정말 어떻게 했을까 싶을 정도로 잘했다. Alice: Madness Returns에서는 색감도 잘 썼거니와 가끔 색감의 변화를 주기는 하는데, 그 색감의 변화는 극히 일부분에만 끼워넣기로 사용하느라 어색한 감이 제법 있다. RAGE에서는 매우 부드럽고 자연스럽다.

색감 변화가 개인적으로는 너무 심하게 변할 때는 거부감 같은게 들긴 했다. 하지만 그걸 제외하고 그냥 기술적인 측면 자체로는 정말 멋지다는 말만 나오는 효과인듯.

게임

Borderlands의 스타일, 분위기에 좀 더 사실적이고 판타지스러운 그래픽이 첨가 됐다고 하면 비슷할 것 같다.

레이싱 요소를 참 많이 넣었는데, 실제로 레이싱의 사실적인 정도를 굳이 따지면 형편 없는 정도. 차가 공중에 있을 때 방향키를 누르면 공중에서 이동을 한다던지-_-ㅋ 모래밭에서 아무리 드리프트를 하려고 해도 전혀 소용 없다던지, 아쉬운 부분이 좀 있다. 물론 사실적인 레이싱이 들어갈 필요는 없긴 한데, 게임의 분위기상 약간의 드리프트 정도는 있어야 하는거 아닌가 생각.

마지막으로, 존 카맥의 게임은 항상 적을 쏘고, 비틀 거릴 때 다시한번 쏘면 안죽는 경우가 있었다. 즉, 비틀거리는 동안 적이 잠시 무적시간이 존재하는 것인데, 게임의 흐름을 참 방해한다는 생각이 들었다.

총평

Dear John Carmack이라는 글을 링크하고 싶다. 글 초반에 이런 말이 있다.

I'm really enjoying it, but please John, don't ever make a game like Rage again.

게임을 재밌게 하고는 있는데, 제발 이런 게임은 다신 만들지 말아주세요.

존 카맥의 스타일은 원래 스토리 (비중이) 없이 쏴죽이는 것이었는데, 이 게임은 스토리가 게임 플레이의 흐름이 되버렸다. 그런데 스토리가 참 재미가 없다.

위의 글을 전반적으로 다 공감하는 것은 아니더라도, 대체적으로는 공감되는거 같다. 여기서 I'm enjoying 은 게임이 재밌다, 라는 말이 아니라, 그냥 잘 하고 있다 정도로 보면 되지 않을까 한다. 나도 그냥 잘 하고 있는 정도. 아에 너무너무 재미 없어서 손도 못댈정도는 아니고, 그냥 재미 없는 정도. 그 외의 하드웨어 드라이버 버그 문제도 그렇고, 이번의 오랜만에 나온 게임이 여러가지로 아쉬운 점이 많다.

무도건 동적인게 좋은건 아니다. 동적이면 그만큼 정적 계산으로 할 수 있는 것들을 못하는 걸 포기하게 되니까. [본문으로]

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

댓글 쓰기

스탠포드 무료 온라인 강의 시작

creavol@gmail.com (Hybrid) — Mon, 03 Oct 2011 16:42:59 +0900

이미 해외 유명 대학들의 무료 강의는 제법 유명하다[1]. 그 중 가장 유명한 것 중에 하나가 MIT Open Courseware로, 정말 많은 강의들이 있다.

하지만, 이런 강의들은 전부 좀 아쉬운 점이 있는데, 피드백이 없다는 것이다. 그냥 강의 듣고 끝.

이번에 스탠포드에서도 세가지 강의를 시작했는데, 이 강의들은 피드백이 존재한다. 숙제가 있고, 채점이 있다. 물론 Q&A 포럼도 개설해놨다.

AI와 DB는 10월 10일이 시작. ML은 10월 1일인가에 시작했다. 난 AI와 ML을 신청해놔서 일단 개강(?)된 ML 보는 중.

강의는 요런식으로 보이는데, 필요에 따라 강의자의 얼굴이 보이기도 하고 강의 화면만 보이기도 하고 같이 보이기도 하고 그렇다.

위의 퀴즈는 원래 강의를 본 후 풀어보는 복습 문제다. 그냥 강의 보기 전에 풀어봤는데, 기본적인 ML은 잘 모르는 상태기 때문에 생소한게 많았다. 3번째 선형대수(Linear Algebra)는 아주 쉬운거라 고등학교 수학만 알아도 만점 받을 수 있는 정도인데, 연달아 똑같은걸 실수해서 4.0점;; 아무튼, 여러번(최대 100번까지) 재도전 할 수 있고, 문제를 푼 후 10분 이후부터 재도전 할 수 있다(여러번 해서라도 만접을 받는걸 장려).

위의 문제는 그냥 간단한 복습(Review) 퀴즈로 보면 될 것 같다. 강의 등록 할때 수준을 설정하는게 있는데, Advanced로 등록을 하면 프로그래밍 숙제까지 내준다(물론 아직까지는 초반이라 프로그래밍 숙제는 없다).

개인적인 관심사는 Artificial Life -> Genetic Programming -> Genetic Algorithm -> Artificial Intelligence, Optimization, Machine Learning 요렇게 흘러갔다. 그래서 개인적으로는 ML의 기초에 대해서는 잘 모르는 터라(사실 다른 것도 깊게는 모르지만) 좋은 기회가 된듯 하다. +_+

한국에도 존재한다. Korea Open Courseware - 특정 대학에서 하는건 아니고 여러 대학이 함께 있다. 앞으로 계속 발전하면 좋을듯. [본문으로]

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

댓글 쓰기

좋은 링크 모음 - 1

creavol@gmail.com (Hybrid) — Wed, 14 Sep 2011 01:10:29 +0900

따로 포스팅 할 건 많은데, 쓰기로 한 것들도 많고, 쓰다만 것들도 많은데, 개인적인 귀차니즘으로 인해(~~사실은 알랭 드 보통(Alain de Botton) 책에 빠져 있어서...~~) 우선순위에서 밀려나고 있다.

아무튼, 트위터나 커뮤니티등에서 얻은 링크들을 지속적으로 소개할 예정이다. 그냥 링크만 올리진 않고 아주아주 최소한의 소개 정도는 단다는 규칙하에...

1. 좋은 글 모음 - http://prog21.dadgum.com/archives.html

존 카맥(John Carmack)이 트위터에서 소개한 링크다. 이건 요약하기 좀 그러니 패스.

2. Walt Disney Publications

원래부터 있던 곳이지만, SIGGRAPH 2011 문서가 추가 됐다. 2010의 라푼젤 머리카락 쉐이딩 논문에 이어 이번에는 A Programmable System for Artistic Volumetric Lighting 외 몇가지 논문이 추가 됐다. Artistic Volumetric Lighting 논문은 라푼젤에서 머리카락 색깔이 변하면서, 생기는 조명효과에 대한 논문이다(사실은 자세히 안읽어봐서 여기까지. 내일 출력해서 봐야지).

3. Top Ten Most Influential Programming Books of All Time

Stackoverflow에서 투표한 것을 기반으로 만들어진 목록. GEB 책이 있는건 의외(전공서적이 아닌데...). 상위 책들은 워낙 유명해서 대체적으로 봤거나, 보다 만(-_-) 책들인데, 보다 만 책들은 생각난김에 마져봐야겠다는 생각이 든다.

4. 애플과 LLVM 프로젝트

LLVM 프로젝트에 관한 소개를 잘 해주는 글. LLVM(Low-Level Virtual Machine)은 본문에도 나와있지만 좀 더 요약하자면, 기존 VM(Virtual Machine)은 상위 수준인데 반해, 여기서는 저수준(Low-Level)을 의미하는 것으로, 가령, C언어든 C++언어든 플랫폼 독립적으로 코딩을 하면 그것이 저수준(어셈블리와 가까운) 코드로 변경되고 그것이 VM에 돌아가는 되는 시스템을 말한다.

자세한건 위의 글과 추가 링크를 참고.

5. emscripten

위의 LLVM과 연결해서 보면 된다. LLVM을 Javascript로 변환해주는 것으로, 결과적으로는 LLVM이 지원하는 모든 언어(예를 들면 C/C++)를 Javascript로 변환해주는 것이다. ㅡ0ㅡ;; 아직 자세히는 못봤다. 요즘 Javascript의 발전을 보면 정말 무섭다. ㅎㄷㄷ

6. three.js - Javascript 3D Engine

말그대로 Javascript 3D 엔진. 당연히 WebGL을 사용하는 것이고, 예전 글에서 살짝 언급했듯이, WebGL에서는 기본적인 수학 라이브러리 등의 부재가 문제가 될 수 있는데, 그런 문제를 이런 엔진들이 잘 해결해줄 수 있을 듯 하다. 단, 데모를 돌려봐서는 (샘플용) 인터페이스가 그다지 좋지 못했는데... 뭐, 그건 좀 수정하면 될듯 하다.

7. WebGL and HTML5 Challenges For The Future

WebGL과 HTML5 가 나아갈 방향이라고 보면 되겠다. WebGL에서는 버텍스 쉐이더에서 텍스쳐 샘플링이 안된다는 것 같이, 기존 OpenGL 에서 되지만 WebGL에서 안되는 것들이 제법 있다. 이런 것들을 잘 지적하고, 나름대로 대안책도 제시한 좋은 글이다.

사실 개인적으로는 이러한 문제들 보다는 리소스의 보안이나 매번 다운 받아야 하는 문제 등이 훨씬 중요한 이슈라고 생각하는데 그점에 대해서는 다루지 않았다(사실 이 점은 다른 곳에서 많이 다뤘지만). 크롬에서 리소스 캐슁하는 기능까지 들어가는 듯 하던데.. 이 문제는 이 기능이 발전하면 좀 더 대안이 생길지 모르겠다.

8. With Bitcasa, The Entire Cloud Is Your Hard Drive For Only $10 Per Month

회사 홍보가 되려나. -_-ㅋ

월 $10면, 하드 디스크를 통채로 클라우딩 해준다(용량 무제한). 쉽게 설명하면 다 서버에 저장했다가 다른 컴퓨터에서 그대로 복원하고 싱크할 수 있도록 해준다. 기사 내용에 의하면 데이터의 60%가 다른 사람과 겹치기 때문에 이런 서비스가 가능하다고 한다.

결론

원래 결론이 필요한건 아니지만...

요즘 돌아가는 추세를 보면 (누구나 알겠지만) 웹이 대세. 그냥 완전 대세. 한참 예전에 공개되었듯이 Javascript으로 리눅스도 돌릴 지경인데다가, 이미 파이썬 정도는 웹에서 바로 컴파일 해서 돌릴 수 있는 정도니, 크롬 OS, 크롬 북 같은 것들이 초창기에 받았던 시각과는 다르게, 웹에서 모든 것을 하는 시대가 이젠 좀 가까이 있는 것도 아니고 바로 코앞인 것 같다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

댓글 쓰기

킨들에서 수학 공식 보기

creavol@gmail.com (Hybrid) — Fri, 22 Jul 2011 21:38:00 +0900

킨들 (Kindle)

킨들은 아마존(Amazon)에서 나온 이북 기기다. 전자 잉크(e-ink)를 사용해서 눈이 편하다는 장점이 있지만, 아직은 색깔을 표현못하고, 반응속도가 매우 느린 등의 단점이 있다. 하지만 장점이 단점을 압도하기 때문에 개인적으로는 아이패드보다 만족감이 크다.

킨들에서 수학공식 보기

일반적인 텍스트 위주의 책들은 킨들로 보기 아주 좋다. 하지만 일단 그림이 들어가면, 1. 흑백이 되고, 2. 느려지고, 3. 공간을 차지한다. 하지만 사실 일반적인 그림이라면 잠깐만 보면 되기 때문에 그렇게 문제 될 것은 없다[1]

중요한건 수식! Advanced Global Illumination이라는 책은 컴퓨터 그래픽스 관련 전문 서적인데도, 킨들도 존재한다. 실물(하드커버)로 이미 가지고 있지만, 지하철에서 보거나(주로 킨들은 지하철용) 할 때 보면 좋겠다 싶어서 한달 정도 고민하고 질렀다(비싸다!).

모든 킨들 책은 초창기 몇십 페이지를 샘플로 볼 수 있다. 이 책의 경우에는 그 샘플 페이지안에 제대로 된 수식이 나오지 않아 실제 수식이 어떻게 보이는지 알 수가 없다-_-ㅋ. 샘플이 딱 끝나면 본격적으로 수식들이 나온다. 그럼에도 불구하고 킨들 버전을 구입했는데(수식 샘플을 볼 수 없어서 더 고민을 많이 했다), 결론부터 말하자면 매우 만족한다.

사진

결국 킨들에서 수식이 어떻게 보이는지를 구입전에 한번 보시라는 의미로 블로그에 올린다. 단, 눈으로 보는 것과는 좀 많이 달라서 잘 전달이 될지 걱정이다.

먼저 짧은 수식. 짧은 수식이나, 글 안에 있는 수식들은 위와 같이 매우매우 깔끔하게 나온다. 이정도면 퍼펙트.

보통은 이런식이다. 이미지가 길어서 그런지 흐릿하게 나온다. 사진으로는 잘 구별이 안될수 있는데, 원래 텍스트 글자와 비교하면 매우 흐린 것을 알 수 있다. 물론 흐릿하다해도 수식을 구분하고 의미를 알기에는 전혀 부족함이 없다.

마찬가지로 흐리다. 사진으로 보는거보다 더 흐릴 수 있다.

그림안에 글자가 크게 있을 경우는 매우 보기 좋다.

칼라야 당연히 안들어가지만, 원래 책도 대부분 흑백으로 되어 있기 때문에 그림을 보는데는 거의 지장 없다.

그 외의 꺽쇠 < 이런게 폰트가 좀 이상한 부분이 있었는데, 그걸 이 책의 킨들 제작을 할 때 잘 못 만든 것이고, 그리 큰 문제는 아니다. 굳이 정 신경 쓰이면 아마존에 문의를 하면 고쳐줄듯 하다.

또 중요한 것으로, 이러한 부분은 책마다 다를 수 있다. 가령, 도날드 카누스(Donald Knuth)의 책 중 하나인 Mathematics for the Analysis of Algorithms (Progress in Computer Science and Applied Logic)의 경우 킨들판이 존재하는데, 한 독자가 킨들 판의 퀄리티를 매우 안좋게 평가하기 때문에(글에서 분노가 느껴짐), 이런 책들은 조심해야한다. 가급적 샘플을 확인하고 사는게 좋다.

결론

(이 책처럼 잘 만들어졌을 경우) 우려와는 달리 매우 보기 좋다.
일반 텍스트와 거의 같은 가독성의 수식도 있지만, 흐릿하게 나올 수 있다. 수식의 스타일에 따라 다를 듯. 흐릿함을 감안하고 본다면 굿!
생각보다 빠르다. 보통 복잡한 이미지, 복잡한 표가 들어갈 경우 느려지는데, 페이지(일반 종이가 아닌 킨들 기준)당 두 세 줄 정도라면 속도는 별 장해가 되지 않는다.
책마다 다를 수 있기 때문에 가급적 샘플을 필히 확인!!

하지만 좀 큰 표의 경우는 문제가 될 수 있다. 실제, The Art of Agile Development를 예로 들면, 초반에 표가 엄청 큰게 나오는데, 일단 킨들로는 보기 어렵고, 페이지 넘기는게 오래 걸려서 무지 불편하다. [본문으로]

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

댓글 쓰기

WebGL - Spherical Harmonics Irradiance

creavol@gmail.com (Hybrid) — Mon, 23 May 2011 22:04:38 +0900

간략한 설명은 이전글에서.

클릭하고 드래그 하세요~

Chrome 등 WebGL을 지원하는 브라우져에서만 볼 수 있음. IE9는 될수도 있고, 안될 수도 있고, 그 이전버전은 안되는 것으로 앎. IE는 고려/테스트하지 않았고, 앞으로도 안할 것임. 이번엔 크롬에서 최신 버전 11.0에서 테스트 하였음.
소스 코드 매우 지저분함.
SH Irradiance부분을 보려면 initSH(), calcIrradianceSH() 부분을 보면 됨(자세한건 나중에 SH 연재할때 설명).
js파일은 WebGL Demo Repository에서 무단 링크 -_-ㅋ (트래픽 때문에 어쩔 수 없었어요. 봐주세요. ㅜ_ㅜ)
js파일을 로딩하느라 로딩 시간이 좀 길 수 있음.

소스를 보면 알 수 있듯이 teapot 물체 자체도 js파일로 되어 있다. -_-;; 데모용 파일을 얻어와서 트래픽 걱정 없이 올릴 수 있었는데, 이 다음에 올릴 PRT(Precomputed Radiance Transfer)는 정보가 무지 많아 올릴 방도가 없다(teapot 파일의 경우 binormal/tangent 데이타까지 합쳐서 200kb가 넘는다. PRT 데이타의 정점당 데이타는 그보다 많다).

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

댓글 쓰기

WebGL - Spherical Harmonics Irradiance 데모 (스샷)

creavol@gmail.com (Hybrid) — Sat, 21 May 2011 16:57:13 +0900

WebGL은 OpenGL 표준을 담당하는 Khronos Group에서 담당하고 있는 표준 Web용 그래픽 라이브러리다. 요몇년, 아니 요몇달간 무지하게 발전해서, 왠만한 프로그램이나 게임은 다 만들 수 있는 수준이 되었다.

WebGL은 내가 알기로는 현재 크롬에서 가장 많이 지원하고 있다. 다른 브라우져도 IE를 제외하고는 다 지원하고는 있다. WebGL이라는 이름에서 할 수 있듯이 내부적으로 OpenGL을 사용하고 javascript를 이용해서 API가 제작되어 있다. 단순히 기본적인 렌더링만 되는게 아니라 텍스쳐는 물론, 쉐이더 프로그래밍까지 지원하고 있다(이때 사용되는 쉐이더 프로그래밍 언어는 GLSL(OpenGL Shading Language)이다).

아무튼 좀 추이를 지켜보다가 드디오 오늘 처음으로 시작해보고 데모를 만들었다. 이번에 처음으로 만들어볼 목표는 PRT(Precomputed Radiance Transfer)를 구현하는 것이었는데, 그 중간 과정을 위해 오늘은 일단 SH(Spherical Harmonics)를 이용한 irradiance lighting부터 해봤다.

Spherical Harmonics Irradiance

R. Ramamoorthi, P. Hanrahan의 2001년 논문 에서 소개된 방법으로, 환경맵이 있으면 그걸 SH로 변환 후 실시간으로 irradiance map 형태로 사용할 수 있도록 해주는 기술이다. 즉, 거울과 같은 환경맵이 있을 때 그것이 diffuse 표면에 보일 때 은은하게 보이는 것을 표현하는 것이다.

이 맵을 위해 사용되는 SH 상수는 uniform 형태로 RGB가 9개가 필요한데, 많다면 많지만, 환경맵이나 irradiance map에 비해서는 무진장 적은 수다. 게다가 실시간으로 사용되는 속도도 빨라서, 공간에 배치하여 쓴다면 더 좋은 효과를 얻을 수 있다(자세한건 논문 참고).

어쨌건, SH의 역할을 확인하기에 좋은 방법이라, 구현해봤다.

원래 속도가 굉장히 빠른 방법인데다, 주전자 달랑 하나를 놨기 때문에 매우 빠르게 렌더링 된다(소스 코드는 다음에 공개~!).

WebGL 소감

생각보다 쉽고, 또 한편으로는 생각보다 조금 어려운 면도 있다. WebGL 이라는 라이브러리가 있기 때문에 기본적인 javascript 사용법과 OpenGL을 알고 있으면 약간의 삽질(!)을 통해 어느정도 익힐 수 있다.

그럼에도 불구하고 시간을 제법 뺏긴건 수학 함수 관련 문제들 때문이었다. 검색을 하다보면 정말 많은 수학 관련 라이브러리들이 있고, 그 중 몇몇은 종종 쓰이다가 사장되거나 하는 경우가 있었다(참고로 여기서 사용한건 J3DI 라이브러리다).

아무튼, 디버깅 툴도 제공해주는데 그건 사용안해봤고, 크롬의 웹 페이지 분석의 기능과 함께 사용하면 종종 어디서 문제가 생기는 지 등을 알 수 있어서 좀 불편하더라도 그럭저럭 문제를 찾아가며 해결할 수 있는 환경이 제공된다.

계획

블로그에 웹페이지를 그대로 올리면 좋겠지만, 관련 라이브러리들이 js 파일 형태로 되어 있고, 이걸 링크했다가는 봇이 긁어대느라 트래픽이 금방 부족해진다. js 파일들을 따로 링크하거나 해서 올릴 예정.

처음 말했듯 PRT를 구현할 예정인데, 사실 대부분의 계산은 사전 처리에 의해 계산하고, 그걸 txt파일로 빼올 것이기 때문에 소스는 별로 길지 않을 것 같다. 어쨌거나 속도가 좀 걱정이긴 한데, (정적인 물체에 대해, 매우 적은 폴리곤에 대해) 실시간 GI를 웹에서 돌려볼 수 있기 때문에 나름 의미가 있을 것 같다.

기타

구글은 크롬 OS를 통해 모든 것을 웹브라우져로 하도록 발전시키고 있다. 이런 동향과 관련해서 최근에 본것들 중 몇개를 링크해본다.

WebGL Demo - 여러 데모를 볼 수 있다. 인상적인 것 중 두 가지는 Spore Viewer와 Raytracer. Raytracer의 경우는 물론 구 렌더링 정도만 하긴 하지만, 그 계산을 쉐이더에 넣어서 하는 것을 볼 수 있다. 이 추세라면, OpenCL을 이용한 GPGPU도 가능할지도. -_-ㅋ
Skupt - 파이썬(Python)을 웹에서 바로 코딩
Skupt - 파이썬을 사용해서 WebGL을 코딩. Wrapping 방식이라 한계가 있을 듯 하지만, 파이썬을 이용한다는 데서 인상적이었다.
Javascript PC Emulator, Technical Notes - Javascript로 짠 리눅스 ㅡ,.ㅡ; 한께 들어 있는 tcc라는 컴파일러를 이용해서 c 프로그래밍도 가능 -_-ㅋ

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

댓글 쓰기

게으른자를 위한 프로그램.. Launchy

creavol@gmail.com (Hybrid) — Sat, 21 May 2011 11:03:44 +0900

** 사실 게으름과는 상관 없다. -_-ㅋ **

Launchy 는 '능률적인 프로그래머'라는 책에서 소개한 프로그램을 실행을 도와주는 세 프로그램 중 하나다. 다른건 안써보고 그냥 이게 너무 마음에 들어서 그냥 쓰는 중. 사실 예전부터 이런 프로그램을 직접 만들까 싶었는데, 더 추가할게 없을 정도로 이렇게 이미 멋진게 만들어진게 있었다.

프로그램의 목적은 간단하다. 머리속으로 실행하기 원하는 프로그램이 있을 경우 빨리 실행하는 것. 윈도우의 기본적인 기능을 포함하여 원하는 프로그램을 실행하는 다른 방법은 여러가지가 있다.

기존의 방법들

바탕화면에 깔기

장점 : 준비 과정이 쉽다.

단점 :

다른 프로그램이 바탕화면을 가리고 있으면 좀 까다로움.
바탕화면이 지저분해짐.

시작 프로그램에 넣고 마우스 클릭

장점 : 아무것도 안해도 된다.

단점 : 마우스 클릭이 너무 많고, 많은 리스트를 읽어가며 찾아야 한다.

아주 아주 싫어하는 방식임.

시작 메뉴에 넣음

시작버튼을 누르면 보이는 시작 메뉴에 넣을 수도 있다.

장점 : 아이콘드 크게 보이고 빠르게 실행할 수 있고 아주 좋다.(윈도우키 + 마우스 클릭 or 마우스 클릭 두번)

단점 : 몇개 못 넣는다.

윈도우 자체 검색 사용

이건 장점이 있나??? -_-;; 시작 메뉴를 열면 바로 검색을 할 수 있는데, 비스타부터 생긴 기능이다. 난 꺼버렸다. 단점은 어마어마하다.

인뎅싱 기능이 있는거 만으로도 리소스를 제법 많이 차지한다. 아무것도 안하는데 하드를 읽고 있으면 요 놈이 작동하는것이 원인일 가능성이 크다.
찾는 속도가 무.........지하게 느리다.
근데도 잘 못찾는다. -_-

결론 : 절대 쓰지 말것.

구글 데스크탑

멍청한 윈도우 인덱싱 기능과는 다르게 백그라운드에서 돌아가는 것도 매우 조용하고, 가끔 문제를 일으키긴 하지만 대체적으로 좋다.

장점 : 단축키(컨트롤 두번)으로 검색을 할 수 있는데, 시작 메뉴에 있는 것들도 검사해준다.

단점 :

못찾을 때가 제법 있다.
키보드를 친 후 나올때까지 기다리고, 찾아서 선택해야한다. (예를 들어 컨트롤 두번 + firefox 엔터, 이렇게 하면 바로 실행이 되지 않고 일단 검색이 되버린다.)

생각보다 잘 못찾고 일단 실행하는 과정이 너무 느려서 안좋아한다. 일반적인 파일 찾기도 이제 구글 데스크탑 대신 Search Everything이라는 툴을 사용하고 있다.

Launchy

프로그램 사이트: Launchy: The Open Source Keystroke Launcher

Launchy를 실행하면 위와 같이 간단하게 인터페이스가 보이고 원하는 프로그램을 바로 입력할 수 있다. 예를 들어 난 vs를 Visual Studio에 연결해 두었다. 구글 테스크탑과는 다르게 엔터를 누르면 바로 실행이 된다.

일단 특징은 이렇다.

시작 메뉴, 바탕 화면등 기본 폴더에 있는 디렉토리가 등록되어 있고, 기본적으로 exe 나 lnk 파일을 실행한다고 보면 되는데, 다른 실행 가능한 것들도 가능하다.
그 외의 다른 폴더도 추가할 수 있다.
스킨도 바꿀 수 있다.
그 외의 여러가지 기능들이 옵션으로 제공 되며, 플러그인도 지원한다.

에를 들어 나는 별도의 Launchy 폴더를 만들어서 거기에 vs 2008.lnk 로 바로가기 아이콘을 만들어 놨다. 위에서 vs 로 Visual Studio를 찾은 이유는 여기에 있다. 아쉬운점은 vs 가 Visual Studio 라고 뜨지 않고 그대로 vs 2008라고 뜨는 점인데, 어차피 아이콘으로 인식하면 되고, 빠르게 실행하기 때문에 글자는 그다지 중요하지 않다.

사실 단축 아이콘 찾는 기능이 뛰어나기 때문에 vs라고 찾아도 Visual Studio 2008.lnk 같은 단축 아이콘도 찾아주긴 한다. 이렇게 실행한것은 나중에 vs로 찾을 때 제일 상단에 위치해서보인다(다시 말해 프로그램이 똑똑해서 굳이 vs.lnk를 만들 필요는 없다는 말).

개인적으로 쓰는 방법/설정들

윈도우키 + G를 단축키로 설정[1]
적당한 곳에 Launch 폴더를 만들었다. 이곳에 내가 원하는 (예를 들어 시작 프로그램에 없는, 혹은 단축키를 바꾸고 싶어하는) 바로가기 아이콘들을 저장해둔다. 옵션(단축키 컨트롤+,)에서 이 폴더를 추가해둔다.
Launch 폴더 안에 Launch 폴더로 가는 바로가기도 하나 만들어둔다. 이렇게 하면 단축키 추가도 편하게 할 수 있다.
Visual Studio는 vs로, 만들어 놓고 작업 폴더의 바로가기는 work로 만들어둔다. 평소 DropBox도 무지 많이 쓰기 때문에 DropBox는 db로 연결해두 었다.

위의 설정을 해두면 나중에 단축키 만드는 과정은 다음과 같이 더 간편하게 된다.

윈도우키 + G, launch + 엔터
바로가기 추가
윈도우키 + G, F5를 눌러서 단축키 refresh

윈도우 자체가 빠른 흐름과는 거리가 멀다. 아무리 봐도 거리가 멀다.

윈도우키를 누르면 나오는 작업 표시줄에 고정되어 있는 바로가기
바탕화면에 있는 아이콘에 등록할 수 있는 단축키
(윈도우 7의 경우) 작업 표시줄에 바로 등록해놓고 <윈도우키+숫자>로 사용할 수 있는 단축키

등은 좋은 기능이 있긴하지만 이걸로는 한참 부족하다. 세 방법 모두 몇개 넣을 수 없다는 단점이 있다.

프로그램 실행시키는거, 원하는 폴더 찾아가는 시간은 사실 그리 길지 않다. 하지만 단순 인터넷 서핑만 하는게 아니라면, 하루에 프로그램을 실행하는 경우나, 폴더를 찾아가는 회수는 굉장히 많을 수 있다. 이렇게 함으로써 장점은 사실 시간 그 자체를 줄이기보다는 생각의 흐름이 끊기지 않게 해준다는데 있다. 원하는 것을 찾는 시간이 길어지다보면, 때로는 왜 이것을 원했는지 까먹을 때도 있고(응?) 폴더 찾느라 생각의 흐름이 끊기느라 효율이 떨어질 수도 있다. 따라서 윈도우의 부족한 점을 Launchy 툴을 써서 보완한다면 좀 더 효율적인 환경을 만들 수 있다.

구글 데스크탑이랑 겹치는데, 구글 데스크탑은 컨트롤 두번으로 사용하기 때문에 윈도우키 + G는 레지스트리를 이용해서 꺼버렸다(참고) [본문으로]

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

댓글 쓰기

SH 관련 글은 장기간 미뤄질 예정임!

creavol@gmail.com (Hybrid) — Thu, 07 Apr 2011 23:53:37 +0900

어차피 기다릴 사람도 없겠지만 -ㅅ-;;

개인사정(?)으로 인해 장기간 미뤄짐.

다음글 예고는 프레넬 효과~

그리고 이건 위의 내용하고 상관 없는!!

아마존에서 오늘 도착한 라푼젤(Tangled) 4디스크 콤보~!! 우리나라도 좀 이렇게 세트로 나오면 좋겠다. 국내에서 2D 블루레이+3D 블루레이 두개를 따로 구입하는 것보다, 아마존에서 콤보를 사는게 배송비를 합쳐도 더 싸다. -_-;

내용물은 2D 블루레이(서플 포함) + 3D 블루레이 + DVD + 디지털 카피 요렇게 4종!!

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

댓글 쓰기

Cryrsis 2 소감

creavol@gmail.com (Hybrid) — Sun, 03 Apr 2011 14:39:13 +0900

아래 내용은 전부 추측임, 다른 생각이 있으면 언제든 리플 달아주세요.

전반적인 흐름을 보자면, 기본적으로 ‘동적 물체, 동적 라이팅’에 중심을 맞춘듯 하다. 사실 정적 라이팅, 정적 물체가 많을 수록 그래픽 퀄리티는 좋아진다. 그런데, 그걸 모두 동적으로 해결하려다보니까 놓치는게 제법 있는 듯 하다.

정적으로 계산을 하면 포톤 매핑 같은 방법 이용할 수 있다. 실제 Halo3 관련 문서에서 포톤 매핑의 사용을 언급 하였다. 하지만, 크라이시스2에서는 기본이 동적이기 때문에, 혼합하여 사용하는 것을 극히 제한한듯 하다[1].

아무튼, 크라이텍에서 직접 자랑하듯, 자신들의 엔진은 전처리가 필요 없다고 하는데(아에 없는지 없어도 되는건지는 잘 모름. 즉, 원한다면 제작자가 포톤 매핑 같은 정적 기술들을 적용을 할 수는 있는건지는 모름), 그것이 일부는 독이 되는듯 하다.

일단, 테스트한 그래픽카드는 GTS450으로, 크라이시스2 때문에 구입했다. -_-^ 자동적으로 맞춰주는 사양은 HIGH, VERY HIGH, EXTREME 중 VERY HIGH인데, 문제점이 생기는 부분들은 EXTREME으로 변경해서 관찰도 해봤지만, 달라지는 것은 없었다.

사진은 클릭하면 커집니다!!

1. 소프트 파티클 부재 (패치 예정)

깜짝 놀랬다. -_-; 알고보니, 아직 DirectX 11을 지원안한다고 한다. 패치 예정임. 버그도 많은거보면, 급하게 출시한 듯 하다. DX11 지원이 들어가면, 소프트 파티클이야 당연히 적용 될듯. (스샷은 생략)

2. Motion Blur

딱히 문제점...이라기보다는, 현존하는 후처리 기반 실시간 모션 블러의 한계가 잘 나온 스샷임. 거대한 물체가 지나가는 장면이고, 이걸 보면 필터 샘플링을 몇개 썼는지 정도는 볼 수 있다. 이런 장면은 극단적인 장면이라 무시해도 좋고, 블러가 생기는 물체 경계 주위로 생기는 halo 현상도 그렇게 눈에 띄지 않을 정도로만 발생한다(다른 효과랑 섞어쓰기 때문일 수도...).

3. 동적 GI!!!

게임에서 정적 GI는 이미 예전부터 썼다. Radiosity 기법[2]이나 Photon Mapping 방식인데, 물체와 광원 모두가 정적이라는 한계와 오랜 시간의 전처리가 필요하다는 단점이 있다. 고런데, SH 방법이나[3], 크라이텍에서 밀고 있는 LPV(Light Propagation Volumes) 방식은 동적인데다가 전처리가 필요 없는 장점이 있다. 하지만, 그 때문에 생기는 단점도 존재한다.

일단은 관찰 할 수 있는 부분부터!!

가운데 쓰레기통 같이 생긴 것은 직접 조명을 받지 않는 부분이다. 따라서 이 쓰레기통에 보이는 조명은 간접 조명이라는 것. 이걸 들었다 놨다 해도 약하지만 제대로 보인다. 하지만 엄밀히 말하면, 왼쪽의 선반?같이 생긴 것도 조명을 받아야 되는데, 왠일인지 전혀 못받고 있고, 오른쪽에 멀리 있는 물체들도 전혀 못 받고 있다.

벽을 보면 바닥의 빨간 색들이 잘 반사되어 있다. 물론 이런 효과는 기존의 정적인 방법들로도 얼마든지 구현할 수 있지만, 여러가지 이유를 통해, 여기서는 동적으로 구현했다고 추측할 수 있다.

하지만 이 효과들이 생각보다 잘 나타나지는 않는다. 일단 매우 약하게 묻어나서 아쉬운 경우가 많다.

이 경우는 빨간색 싸이렌 경보 + 조명이 360도 회전하는 장면이다. 지금은 왼쪽을 비추고 있다. 사실성을 따지자면 오른쪽에 빨간색이 많이 묻어나야하는데, 많이는 커녕 아에 안묻었다고 볼 수 있다. 굳이 문제점이라고 할 순 없겠지만, 실시간 GI에 대해 기대를 많이 한만큼 그냥 좀 아쉬운 부분이다[4].

이건 어쩌면 버그라고 할 수 있을 듯 한데, 계단 밑, 조명이 없는 부분에서 구석이 밝게 나타나는 문제가 생겼다. 아마도 벽 반대편의 조명이 흘러들어온듯 하다. 이런 경우 정적인 GI를 이용한다면 사실 더 잘 표현될 수 있는 부분이다.

요약하자면, 동적을 외치느라, 정적으로 더 잘 표현될 부분을 놓친듯 하다. 이 스샷 같은 경우도, 건물은 어차피 정적이고, 빛을 정적으로 둔다면, radiosity나 photon mapping의 방법을 사용하여, 라이트맵을 사용하면 더 좋은 결과를 얻을 수 있을 것 같다(메모리/성능에 문제가 생길라나). 빛이 들어오는 부분을 빼면 바닥이 그냥 텍스쳐 발라진 것만으로 표현되는걸 보면 아쉽다(그래도 왼쪽 벽을 보면 곳곳에 명암이 진곳이 있는데, 이건 라이트맵이 아니라 SSAO다. SSAO에 엄청나게 의지하고 있다).

4. SSAO 뭥미?

심각하다. 예전에 SSAO(Screen Space Ambient Occlusion) 구현 할 때 생겼던 문제점을 그대로 가지고 있었다. 한가지 궁금한건, 원래 모든 컴퓨터에서 이렇게 보이는지, 아니면 내 컴퓨터에서 예상치 못한 결과가 나온 것인지인데, 그래픽 카드에 따라 이렇게 심한 결과가 나올 수 있나 생각이 든다. 어쨌건, 내 컴퓨터에서도 모든 상황에서 문제가 생기는 것은 아닌데, 다음과 같은 현상은 매우 빈번하게 발견할 수 있다.

물체 주변에 halo 현상이 빈번하게 관찰된다. 정말 눈에 거슬릴 정도인데, 너무 심해서 원래 SSAO를 도입한 게임은 전부 이런가 생각도 해보고, 내 컴퓨터와 궁합이 안맞나 생각도 해본다. 어쨌건, 이것만 봐서는 분명 문제가 있다[5].

반면, 이건 SSAO가 아주 잘먹은 좋은 예이다. 보통은 이런 구석진 부분은 라이트맵으로 처리하는데, 크라이텍 님하들은 쿨하게 그런거 없이, 실시간으로 SSAO를 사용해서 이 효과를 나타내준다. 증거 화면은 다음에 있다.

스샷을 보면 명암이 생기는 부분이 무척 넓다는 것을 알 수 있다. 이걸 봐서도, 기존의 포인트 방식의 SSAO 방식은 좀 무리가 있을 것으로 보여지고, 이런 경우 i3D 2010 논문의 Volumetric Obscurance 방식이 더 적합해보인다[6]. 이렇게 넓게 SSAO가 들어간 것을 보면, 물체마다 SSAO 스케일도 다르게 준건가 추측도 해본다.

5. 심각한 충돌체

충돌체가 실제 물체와 심각하게 맞지 않는 경우가 많다.

가운데 있는 동그란 조명기구는 어디 걸려 있는게 아니라 그냥 허공에 매달려 있다. 어딘가의 주위 충돌체에 걸려서 둥둥 떠있는 부분. 이런 장면이 제법 많다. 총 쏘다가 충돌체에 걸려서 적이 안맞을 때도 매우 빈번하다.

6. 기타 버그

아주아주 많다. 가장 심각한 것 중에 하나는, 게임을 하면서 Nano Suit를 업그레이드 할 때 쓰는 Nano Catalyst가 모이질 않는다던지 없어진다던지 하는 버그다. 이걸 사용하는게 게임을 쉽게 만들 수도 있고 재밌게 만들 수도 있는 중요한 요소다. 그런데, 버그 때문에 망쳐버렸다. 이 문제는 해외 포럼에서도 적지 않게 언급됐다. 그 외에도 버그가 종종 발견 된다.

7. 요약

일단, 기대가 컸기 때문에 그만큼 실망이 크고, 버그는 좀 많아서 게임을 즐기는데 방해가 됨. GI는 살짝 감상할 수 있는데, 왜 있나 싶을 때도 있긴 함. 글에서 스샷하나 안올렸지만, 쉐이딩 효과들은 그냥 최고인듯,

ps. 스샷을 찍고보니 더더욱....... 나도 와이드 모니터 사고 싶다. ㅜ_ㅜ

제한할 수 밖에 없는게, 정적인 부분의 퀄리티를 극도로 높여놓으면, 그만큼 동적인 퀄리티가 낮아보일 수 있다. 어쨌건 일단 이질감이 생긴다는 말. 디즈니 셀 애니메이션 같은 것이 예라고 할 수 있을 듯. [본문으로]
현재 이슈가 되는, 실시간 Radiosity 기법과는 좀 다름. [본문으로]
PRT Precomputed Radiance Transfer 방식을 말함. [본문으로]
아마도 ambient 를 강제로 달아버리거나, 반대편을 향해 가상의 조명을 달아버리면 이런 부분도 표현할 수 있을 듯하다. 아니면 Instant(Real-time) Radiosity를 제대로 활용하던지... [본문으로]
내가 구현했던 SSAO는 i3D 2010에서 나온 Volumetric Obscurance이었는데, 예전 크라이텍인가에서 이 논문을 인용한걸 보면, 이걸 도입했나 생긱이 들었다. 이 방법의 문제인가 싶기도 한데, 잘 모르겠다. 기회가 되면 자세한 테스트를...... (이 말뜻은, 앞으로 테스트 안하겠다는 말) [본문으로]
Ogre3D 포럼에서 이 방법을 더욱 개선한 방법도 누가 보여줬었는데, 자세히 안봐서 까먹었다. [본문으로]

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

댓글 쓰기

컴퓨터 속의 수학과 물리 - Spherical Harmonics - (1) 이론

creavol@gmail.com (Hybrid) — Sat, 12 Mar 2011 12:55:55 +0900

Spherical Harmonics(구면조화함수, 이하 SH)가 다른 곳에서는 얼마나 쓰이는지 모르겠다. 양자역학에서는 angular momentum 부분에서 쓰이는데, 렌더링 쪽까지 주욱 보니까 양자역학이나 컴퓨터 그래픽외에도 여러 곳에서 쓰일 수도 있다는 생각이 들었다(트위터를 통해 사운드에 관련된 부분에서도 사용된다는 얘기를 얼핏 듣긴 했다).

컴퓨터 그래픽에서의 SH는 사실 물리학에서 사용하는(즉, angular momentum 부분의) SH를 그대로 가져온 것은 아니었다. 실제로 물리적인 모델이 컴퓨터 그래픽에서 쓰이는 경우가 많았지만, 이 경우는 그런게 아니었기 때문에 물리학의 SH 와 컴퓨터 그래픽의 SH 가 연결이 되지 않아서 처음엔 혼란스러웠다.

글은 아마도 두 세개의 글이 될듯 하고, 세 파트로 이루어져있다.

수학적인 모델의 설명(지금 이글).
물리학에서의 SH
CG에서의 SH

3번을 위해서 2번을 볼 필요는 없다. 3번은 사실 여러개로 나뉘어질 가능성도 있다.

수학적 정의

실제 특성을 자세하게 알아보는 것이 아니라면 그렇게 어렵지 않다. 하지만 그런걸 지향하기보다는 수학적으로 엄밀하게 따라갈 수 있도록 글을 쓰려고 한다. 일단은 왜 이런걸 쓰는지는 생각하지 않고 일단은 말그대로 수학적 정의만 살펴보는걸로 시작한다.

SH 함수의 기본 모양은 이렇게 생겼다(l 은 ‘아이’가 아니라 ‘엘’이다).

m 은 지수(Y의 m 승)가 아니다. m 과 l 은 각각 함수의 모양을 나타내는 숫자이다. 즉, 과 은 그냥 모양이 다르게 생긴 함수다. 뭘 의미하는지는 천천히 보기로 한다.

SH에서 spherical이 말하듯이, 이 함수는 구면 좌표계로 표현된다. 구면 좌표계는 다들 알다시피 일반적으로 로 표현된다.

9개의 함수가 있다. 각 함수는 괴상한 모양과 각 함수의 오른쪽 상단의 구 모양의 함수로 보여지고 있다.

첫번째 그림에서 첫번째 줄은 m=0, l=0인 함수다. 두번째 줄은 모두 m=1이고, l은 왼쪽부터 -1, 0, 1에 해당한다. 세번째 줄은 추측할 수 있듯이, m=2이고, l은 -2, -1, 0, -1, 2이다.

이건 위의 9개의 함수중 m = 2, l = 0 인 함수다. 오른쪽 상단에 있는 구는 의 값을 색깔로 표현한 것이다. 이 때 구의 반지름에 해당하는 r은 모두 같은 값으로 해두고 색깔로 함수의 값을 구분하는 표현 방법이다 (eg. r=1).

반면 중앙에 크게 보이는 그래프는 값이 색깔이 아니라, 반지름 r 값이 된다. 그렇기 때문에 모양이 가지각색으로 보인다. 이쪽 표현이 좀 더 이해하기 쉬운 거 같다. 여기서 중요한건 l과 m의 값에 따라 함수의 모양이 다르다는 것.

사실 SH 함수의 정의도 아직 말하지 않았다. 함수의 정의는 다음과 같다(이 함수가 왜 이런 모양을 가지는 지를 자세히 볼 필요는 없다).

이제 이 SH 함수는 복소수라는 것을 알 수 있고 (여기서 N 은 normalize 용 상수), 여기서 P 는 associated Legendre[1] polynomials 이다. 이건 또 어떻게 생겨먹었냐 하면,

Legendre Polynomials :
Associated Legendre Polynomial :

이렇게 괴상하게 생겼다. 이것 역시 왜 이게 이렇게 생겼는지 자세히 볼 필요는 없다. 단, 왜 이런 괴상한 함수가 생겼는지가 궁금하다면 위키피디아를 비롯한 다른 참고 자료를 참고하면 되겠다. 좀 복잡해 보일 수 있는데, 실제로 필요한 것들만 걸러 받아들이면 된다. 여기서 필요한건 이러한 함수의 특성이다.[2]

일단, SH 함수의 수학적 형태는 알 수 있게 되었다. 아니, 형태는 그림을 보고 알면 되고, 그냥 l과 m에 따라 여러 형태가 존재한다는 것만 기억하면 된다.

어려워 보일 수 있지만, 사실 위의 polynomial 들을 모두 이해할 필요는 없기 때문에 별로 어렵지 않다. 여기에 핵심만을 몇개 덧붙여보면 다음과 같다.

에 따라 다양한 함수 모양이 존재한다.
은 0 부터 무한대까지의 값을 가지며, 은부터 까지의 정수를 갖는다.
실제 는 복소수 값이다(CG 에서는 이걸 실수 함수로 재정의해서 쓴다).
SH는 associated Legendre polynomials 를 통해 표현 되는데, 함수 내용을 깊이 알 필요는 없다.

Project and Reconstruction (투영과 복원)

예를 들기 위해 3차원 점을 생각해본다. 3차원의 점은 원래 이렇게 표현해야한다. 그런데 우리가 기본적으로(공통적으로) 를 알고 있으면 는 이제부터 신경쓰지 않아도 된다. 바꿔 말하면, 이제부터는 x, y, z만 알면 p 를 얻을 수 있다(여기서 3차원 공간의 를 basis 라 부른다). SH는 이 개념과 비슷하다.

일단 이론적으로 모든 구형 연속 함수(spherical continuous function) f는 다음과 같이 무한개의 SH 조합으로 바꿀 수 있다.

이처럼 함수 f를 계수 와 SH 함수의 조합으로 나타내는 것을 확장(expansion)이라 부른다. 근사 값이 아니라는 것과 무한대에 주목. 3차원 공간의 p는 3차원이라서 3개의 만 사용하지만, 여기서는 무한대의 개수가 필요하다. 물론 수학적으로 정의/증명됐을 뿐 이거 자체로는 정확한 계산은 하기 힘들다.

어찌됐건, 여기서 중요한건, 이론적으로 모든 를 안다면(ㅡ_ㅡ^) 를 알 수 있는 것이다.

이쯤 되서 잠시 직교성에 대해서 알아보자. 3차원 공간에서 는 서로 직교(orthogonal) 관계에 있다고 말한다. 즉, 전혀 방향이 다르고, 셋 중에 둘, 셋이 합쳐서 벡터를 이루어도, 각각의 값들은 서로 영향을 주지 않는다.

SH에서도 동일하다. 과 에서 m과 m’ 혹은 l과 l’ 둘 중 하나만 값이 달라도 서로 직교한다[3]. 단지 3차원이 아니라 무한대의 차원이라는게 다르다.

만약 이 3차원의 벡터 p 에서 x 혹은 y를 구하려면 어떻게 해야할까? 아주 쉽다. 이렇게 내적(inner product) 연산을 해주면 된다. 이러한 내적 연산은 투영(projection)이라고도 부르는데, 실제 SH에서도 k 를 구하는 과정을 투영이라 부른다.

대신 SH에서 투영 계산 방법은 약간 다르다. 같은 것들은 변하지 않는 벡터지만, SH는 상수가 아니라 함수다. 함수의 경우는 적분을 해서 직교성을 증명해야한다.

즉, 과 이 서로 직교하다는 것은 다음과 같은 방법으로 표현한다.

에서 n, n’이 같으면는 1, 다르면 0이다. 이 직교성을 이용하면, 이제 함수 f로부터 원하는 값을 적분 한방에 빼올 수 있다.

즉, 그냥 간편하게, 함수에다가 원하는 l, m에 대응하는 SH 함수를 적분하면 된다. 물론 계산은 Monte Carlo 등의 적분 알고리즘을 사용해서 컴퓨터가 계산하도록 하면 된다.

투영을 해보았으니, 이제 k 값을 이용해 원래 값을 얻어내는데, 이것은 사실 처음에 보여줬다.

앞서 말했듯이 이걸 확장(expansion)이라 부르는데, 지금 이처럼 투영한 k 값들로부터 얻어낼 경우는 복원(reconstruction)라고 한다.

Approximation (근사)

여기까지 약간 요약해보자. 아주아주 복잡한 함수 f 가 있다. 그런데 이 함수가 구면 연속 함수라면, 아무리 복잡해도 이걸 무한개의(-_-ㅋ) 실수 로 투영할 수 있고, 그걸 다시 복원하면, 원래 함수 f 를 얻을 수 있다.

학부 때 물리 교수님이 우스개소리로 그러셨다. 뭔가 물리 계산을 하다가 무한대가 나오면 틀린거라고....

물론 여기서는 틀린건 없지만, 무한대가 필요하니 일단 적어도 컴퓨터에서는 쓸 수가 없다. 이걸 무한개 대신 100개로 줄여보자. 그러면 f에서 100개의 계수 이 나오고, 이걸 다시 복원하여, f 의 근사치인 f’를 얻게 된다.

왼쪽 원래 함수(Original Function)에 아주 복잡해 보이는 함수 f 세개가 있다. 이 함수를 개의 k 로 투영 했다가 다시 복원했을 경우 어떻게 보이는지가 오른쪽에 나타나 있는 것이다. 원래 무한대가 필요하지만, 초반 몇십개만 가지고 사용했을 경우 어떻게 보이는지를 나타내주는 그림이다. 복잡한 모양을 복원할 수는 없지만, 얼핏 비슷한 모습은 만들어 낼 수가 있다.

이렇게 되는 이유는 초반일 수록 저주파(low frequency)이고, 후반일 수록 고주파(high frequency)이기 때문이다. 저주파는 뭔가 큼지막한 형태를 만들어주는 거고, 고주파는 세밀한 것을 만들어주는 것이다. SH의 핵심은 저주파는 남기고, 고주파는 버리겠다는 의미다. 그걸 그래픽에서 어떻게 쓸 수 있느냐는 다음 글에서 보여지겠지만, 어쨌거나 이 저주파만을 남길 수 있다는 것은 이점이 된다.

하지만, 이 k의 개수를 주목해보자. n을 통해 n번째 차수(n-th order)라 부르는 데, 이 때 k의 개수는 개이다[4]. 즉, n=10일 경우 100개나 필요하다. 100개나 써도 원래 함수와 비교하면 별로 만족스럽지 않다. 이는 다음글에서 조금은 더 자세히 다루겠지만, SH의 장단점을 잘 알려주는 중요한 부분이다. 실제 실시간 렌더링에서는 3차~5차 차수 정도만 쓴다고 한다.

이렇게 하면 기초적인 이론이 끝났다. 아마도 FT(Fourier Transformation)을 아는 사람이라면, 그것과 방식이 거의 같다는 것을 알 수 있다[5].

마지막으로 간단 요약

복잡해보이는 함수가 있다. 이 함수를 몇개의 숫자로 변환한다,
사실 무한개가 필요하지만, 앞에 몇개만을 활용하여 근사치를 활용 할 수 있다. 물론 상황에 따라서는 아에 수십개로는 택도 없을 수 있다(적어도 CG에서는 많이 사용하지 않는 범위 내에서 활용하는 것이다).
사전에 이 숫자를 투영을 사용하여 변환하고,
실전에서 이 숫자를 원래 함수의 근사 함수로 복원해서 사용한다.

끝 -_-ㅋ

다음 글에서는 물리에서는 어떻게 쓰이는지 아주 아주 간단히 다룬 후, 컴퓨터 그래픽에서 어떻게 쓰이는 지를 다룰 예정이다. 컴퓨터 그래픽 부분에서는 단순히 함수를 바꾸는 것 이상의 (재밌는) 일들을 한다. 단순히 투영 & 복원 과정만 사용해서는 SH를 사용할 이유는 거의 전혀 없다. SH 자체도 근사 값인데다, 계산 과정이 아주 가볍진 않다[6]. 하지만 convolution의 개념을 통해, 실시간으로 주변광을 모으거나, 실시간 라이트의 변화를 가져올 수 있는 장점이 있기 때문에 이 방법이 가치가 있다. 자세한건 다음 글에...

참고 자료

Mathematical Methods for Physicists, Arfken Weber - 유명한 수리물리 책. Spherical Harmonics 자체에 대해서는 내가 본 것 중에 가장 체계적.
Spherical Harmonics Lighting: The Gritty Details, Robin Green - Sony의 R&D 센터에서 나온 문서로 매우 자세하다. 이 글의 모든 이미지는 이 문서에서 얻었다.
Spherical Harmonics , Volker Schönefeld - 이 문서 역시 자세하다. 논문 형태도 아니고, 학회 Course 형태인 듯 한데, 관련 정보가 없어서 정체를 모르겠다.

Legendre 는 프랑스의 수학자 Adrien-Marie Legendre의 이름에서 따왔으며, 르잔드르라고 발음함. [본문으로]
내 기억이 맞다면, 학부 수준의 양자역학에서도 이 함수를 자세하게 뜯어서 배우진 않았다. 생각해보면 이 함수를 뜯어서(eg. 증명) 볼 필요는 별로 없을 듯 하다. [본문으로]
정확한 표현으로는 정규직교(orthonormal)가 맞는 표현이다. [본문으로]
이 차수에 대한 개념은 상황에 따라 다르게 표현된다. Green의 문서나 PRT(Precomputed Radiance Transfer) 논문에서는 n=0이면 SH 함수가 0개임을 뜻하고, n=2일 경우 l이 0~2가 되어, n^2의 개수를 갖는다. 반면, Schönefeld의 문서나 SH를 사용한 Irrdaince를 소개한 논문에서는 n=0은 l=0임을 뜻하도록 하여, (n+1)^2개의 SH 함수를 의미한다. [본문으로]
FT에서도 비슷하게 frequency domain 으로 변환을 한다. 모든 연속 함수를 다룰 수 있다는 것도, 투영/확장 개념까지도 동일하다. [본문으로]
계산 과정에서 독특한 회전 변환이 필요하다. [본문으로]

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

댓글 쓰기

게임 GI(Global Illumination) 관련 문서 미리 보기

creavol@gmail.com (Hybrid) — Tue, 01 Mar 2011 23:16:25 +0900

Crytek의 문서로 시작했다가, 다른 문서들을 쭈욱 훑고 다시 Crytek의 문서로 돌아왔다. 참 긴시간을 돌아다닌(?) 것 같다. 기회가 되면 분명 블로그에 다시 자세하게 적을 예정이지만, 일단 훑고 온 기념으로 요약!!!(사실은 미리보기)

Valve - Shading in Valve's Source Engine

가장 기초가 되는 문서다. (상대적으로) 그렇게 어려운 것도 없고, 구현하기도 가장 쉽다. 만약 관련 기술들을 맨땅에 구현을 하게 된다면, 특히 여기서 사용하는 Ambient Cube 방식은 다른 방법들을 구현하기 앞서 가장 먼저 구현해보기 적합하다. 물론 Ambient Cube를 위해서 기본적으로 Raytracer는 갖춰야한다.

기본적으로 각 점마다 6개의 irradiance 값을 미리 계산해서 배치한다. 그리고 주인공 캐릭터들은 가장 가까운 점을 얻어와서 간접조명(indirect illumination)으로 사용한다.

(참 쉽죠?)

아주 간단한 방법과 (실시간에서) 적은 계산량으로 간접 조명을 보여줄 수 있다. 그 외의 shading 합성 그림은 참고자료로도 좋다.

Sony - Spherical harmonics Lighting: The Gritty Details

일단 유명한 SH(Sherical Harmonics) 논문은 두개가 있다.

An efficient representation for irradiance environment maps

이 논문은 SH를 이용해서 irradiance volume을 표현하는 방법을 소개한 논문이다.

Precomputed radiance transfer for real-time rendering in dynamic, low-frequency lighting environments

그걸 이어 받아 이 논문(PRT)에서는 물체간의 SH값의 교류를 통한 self-transfer를 소개하고, glossy reflection 구현을 소개한다.

(자세한 설명은 생략한다.)

SH에 대한 확실한 이해가 없다면, 두번째 PRT 논문이 참 어려운 편이다. 소니 문서는 이런 방법을 매우 자세히 설명해주었다.

예를 들어 이 PRT 논문에서 간략하게 한줄-_-^로 설명하는게 있다면, 소니에서는 그 방법을 풀어적었다(회전과 관련된 부분이 그렇다).

이 소니 문서는 좀 분량이 많은 편이다. 나름대로 기초(?)부터 다양하게 다루려했기 때문인데, 좋은 본보기가 되는 듯.

Bungie - Lighting and Material of Halo 3

이 문서는 SH를 실제 게임에 적용하는 사례를 보여준다(소니의 문서는 실제 게임 적용 사례는 아니다). 전반적인 흐름은 Photon Mapping과 같은 실제 오프라인 렌더링 기법을 기반으로 렌더링을 하고, 거기서 관련된 SH값들을 뽑아서 계산하는 것인데, 그 과정에서 SH값들을 텍스쳐에 어떻게 저장하는지까지 기술 되어 있기 때문에 매우 실용적으로 볼 수 있다.

PS. 100% 확신은 할 수 없지만(여러번 계산해보긴 했다), 9페이지에 d로 미분하는 것은 오타인듯 하다. c로 미분해야 제대로 된 결과가 유도된다.

Crytek - Light Propagation Volumes in CryEngine 3

뺑 돌아서(사실 여기 적은 게임 회사 문서 말고 일반 연구 논문들도 여러개 봐야만 했다) 다시 Crytek 문서로 돌아왔다. 워낙 분량이 많아서 여러가지를 봐야했는데, 그만큼 얻은게 많았다.

하지만 다른 문서들보다는 본 분량이 적어서 미리보기가 의미가 없을 것 같아서(틀릴까봐) 패스.

전반적으로 각 유명 회사들이 서로 문서를 공개하며 기술이 오고가는게 참 보기 좋았다. 언젠가 우리나라 게임회사도 참여할 수 있었으면 하는 바람임.

어쨌건 기회가 되면 나중에 하나하나 좀 더 자세한 리뷰를 다루겠음!

PS. 블로그에 올릴 SH 글은 하나 써둔지 오래인데, 블로그에서 수식 표현을 위해 사용하는 sitmo가 현재 몇주째 다운이다(따라서 내 블로그의 모든 수식이 엑박으로 보인다).

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

댓글 쓰기