2013년 12월 30일 월요일
시스템 악용과 팀(team)
사람들이 시스템을 악용하는 것을 고치려고 규제를 강화하는 경우가 있다. 하지만 그래도 어차피 악용할 놈들은 또 악용한다. 고로 시스템은 그대로 둔 채 그런 놈들을 제거하는 것이 팀을 파괴하지 않는 최선의 방법이다. - Pope Kim (2013.12.20)
2013년 12월 24일 화요일
2013년 12월 23일 월요일
만화그리는 프로그램
육아만화 웹툰로 한때 명성을 날리시던 연두부(부드러운 두부가 아닙니다 -_-) 님께서 유투부 클립스튜디오 강좌를 시작하셨습니다. 이야길 들어보니 이 툴이 만화그리는데는 꽤 괜찮은 프로그램이라고 하네요..
만화 그리시는 분중에 관심있으신 분들은 가서 살펴보세요. 아직도 강좌는 꾸준히 올라오고 있습니다.
만화 그리시는 분중에 관심있으신 분들은 가서 살펴보세요. 아직도 강좌는 꾸준히 올라오고 있습니다.
2013년 12월 18일 수요일
Visual C++ 리팩토링 익스텐션
Visual C#에 비해 Visual C++ 리팩토링 기능이 구린건 누구나 아는 일.. 뭐 사실 이유야 C#이 언어 자체에서 지원하는 기능이 C++보다 나은거지만... 옛언어와 최신언어의 차이랄까..
하지만 VC++ IDE 팀에서 익스텐션 형식으로 이걸 좀 보안할 수 있는 걸 내놨음..
http://visualstudiogallery.msdn.microsoft.com/164904b2-3b47-417f-9b6b-fdd35757d194?SRC=Home
참고로 설정에서
Tools->Options > Text Editor > C/C++ > Advanced > Disable Resolving
이걸 False로 해주라고 함
아마 이게 반응이 괜찮으면 2014년엔 정식버전으로 들어가지 않을까?
하지만 VC++ IDE 팀에서 익스텐션 형식으로 이걸 좀 보안할 수 있는 걸 내놨음..
http://visualstudiogallery.msdn.microsoft.com/164904b2-3b47-417f-9b6b-fdd35757d194?SRC=Home
참고로 설정에서
Tools->Options > Text Editor > C/C++ > Advanced > Disable Resolving
이걸 False로 해주라고 함
아마 이게 반응이 괜찮으면 2014년엔 정식버전으로 들어가지 않을까?
분류
개발,
C++,
Visual C++
2013년 12월 17일 화요일
2013년 12월 11일 수요일
MS-SQL에선 datetime대신 datetime2를 쓸것
그냥 다른 프로그래밍 하다가 알게된 사실.. 고로 퀵노트로 공유...
MSDN을 자세히 읽어보지 않으면 당근 알수없는것.. MSSQL에 시간날짜 등을 저장할때는 datetime대신에 datetime2를 써야한다. datetime은 SQL 표준을 안따르게 때문...
이에 대한 자세한 문서는 다음:
MSDN을 자세히 읽어보지 않으면 당근 알수없는것.. MSSQL에 시간날짜 등을 저장할때는 datetime대신에 datetime2를 써야한다. datetime은 SQL 표준을 안따르게 때문...
이에 대한 자세한 문서는 다음:
- 영문: http://msdn.microsoft.com/en-us/library/ms187819.aspx
- 한글: http://msdn.microsoft.com/ko-kr/library/ms187819.aspx
2013년 12월 10일 화요일
캐나다 프로그래머는 얼마나 버나?
캐나다 정부에서 발표한 자료가 있네요.. 각 지역별로 프로그래머가 시급을 얼마나 받는지 보여주는 자료입니다. 이 자료에서 연봉을 계산하시려면.. 다음 공식을 이용하시면 됩니다.
시급 * 40(시간/주) * 52주
http://www.workingincanada.gc.ca/LMI_report_bynoc.do?&noc=2173&reportOption=wage
업데이트: 링크에 안들어가진다는 분들이 많아서 스샷을 찍어왔습니다.
제가 있는 BC주 Lower Mainland 지역은 연봉이 다음과 같군요.
- 최저: $44,900
- 평균: $77,997
- 최고: $131,997
가장 급여가 높은 곳은 기름이 철철나오는 알버타 주이고.. BC주가 2등입니다.
시급 * 40(시간/주) * 52주
http://www.workingincanada.gc.ca/LMI_report_bynoc.do?&noc=2173&reportOption=wage
업데이트: 링크에 안들어가진다는 분들이 많아서 스샷을 찍어왔습니다.
제가 있는 BC주 Lower Mainland 지역은 연봉이 다음과 같군요.
- 최저: $44,900
- 평균: $77,997
- 최고: $131,997
가장 급여가 높은 곳은 기름이 철철나오는 알버타 주이고.. BC주가 2등입니다.
2013년 12월 3일 화요일
복셀 에디팅 팁
다신 안볼줄 알았는데.... -_- 요즘들어 다시 복셀(voxel) 에디팅에 대해 잠시 본 바.... 이 기회에 제가 이짓하면서 배운 교훈들을 짧게(정말?) 공유해볼까 합니다. 저번에 썼던 "혼합가능한 RGBM" 글 과는 달리 여기에 나열한 모든 정보/fact 들은 이미 온라인에 다 널려있는 내용입니다. 그냥 그 모든 내용들을 모아 제 의견을 약간 곁들인게 전부입니다.
1. isosurface부터 이해하세요
복셀 데이터를 주무르는 가장 실용적인 방법은 각 복셀마다 iso 값을 대입하는 겁니다. 다른 방법도 시도해봤는데요(물론 제가 발명해낸 기괴한 방법도 한번 시도해봤죠 -_-) 대부분 별로더라구요. 단점들이 있어요. 결국엔 iso 값으로부터 메쉬를 다시 생성해내는게 가장 실용적이고 메모리 친화적인 방법인거 같습니다. iso surface extraction에 대해 설명하는 무수한 논문이 있으나 정작 isosurface가 뭔지를 쉽게 설명하는 자료는 흔치 않더라구요.
여기 저기 뒤진 끝이 이 튜토리얼을 찾았습니다. 설명도 잘해놨구요. isosurface의 개념을 익히는데는 최고인듯 싶습니다. (물론 영어입니다... 이 글도 영문 블로그에 썻다가 한글로 번역하는 놈이기 때문에.. 혹시라도 괜찮은 한글자료 가지고 계신분은 공유좀 부탁 -_-a)
또한 3D Coat의 개발자가 매우 친절하게도 3D Coat에서 사용하는 복셀 데이터의 포맷을 공개해놨습니다. 이 데이터 구조를 들여다보는 것만으로도 복셀 에디팅에 대해 상당히 많은걸 배울 수 있습니다.
복셀 편집에는 큰 관심이 없고 그대신 임시 복셀 데이터로부터 절차적(procedurally)으로 거대한 지형(terrain)을 만드는게 목적이시라면 VoxelFarm inc의 블로그를 읽어보세요. 이 분 정말 천재더라구요. (실제 한번 만나도 봤습니다. 몬트리올 살때 -_-)
2. 복셀데이터는 "간접적" 으로만 변경할 수 있습니다
볼륨 데이터를 표현하기 위해 iso 값을 사용하게 되면 복셀 데이터를 변경할 수 있는 유일한 방법은 iso 값을 변경하는 것입니다. 이 연산들은 간단한 수학인데요. 각 iso 값을 증감하거나 이웃간의 값을 평균내는 등입니다. 물론 distance 함수를 직접 계산해서 새로운 isosurface 모양을 꾸겨넣을 순 있지요. (이 distance 함수에 대해서는 위에 링크를 걸어둔 튜토리얼을 참고해 주세요.)
iso 값과 최종 메쉬의 모양과는 1:1 관계가 없습니다. 즉 "이 edge를 0.2미터 오른쪽으로 늘리고 싶어. 그러니 복셀 값을 0.752로 바꿔야지!"라는 말을 할수가 없어요. 다시 말하면 최종 모양을 세밀하게 조절할 방법이 없습니다. 복셀의 밀도(density)를 아주 높이 올려도 (예: 1센치당 복셀 하나) 역시 마찬가지입니다. 이게 바로 제가 간접적으로만 복셀을 편집할 수 있다고 한 이유죠.
매우 뾰쪽한 edge를 가진 메쉬를 생성하는 새로운 알고리듬들도 있긴 합니다. 하지만 이 방법들은 복셀 편집을 위해 만들어진게 아닙니다. (자세한건 다음 섹션에서....)
3. 전통적인 마칭 큐브(marching cube)면 충분합니다
방금 말씀드렸듯이 iso데이터에서 메쉬를 생성하는 새로운 리서치들이 있습니다. 특히 Cubical Marching Square와 Efficient Voxel Octree가 꽤 주목할만한 리서치들인데요.
CMS는 매우 날카로운 edge를 생성할 수 있습니다. 단, 한가지 조건이 있습니다. 폴리곤 데이터로부터 iso값을 capture해야만 하지요. 이 방법은 큐브 표면에서 각 폴리곤 edge가 만나는 거리를 인코딩하는 방법으로 작동하거든요. 근데 실시간으로 이 데이터를 편집하려면(예: C4 engine이나 3D Coat에서 하는 것처럼) 꽤 힘들겠죠? 저도 edge의 교차점을 제대로 보존하면서 이 데이터를 편집할 실용적인 방법을 찾는데 실패했습니다.. ㅠ_ㅠ
EVO는 폴리곤 생성을 하는 기법이 아닙니다. 이건 CUDA에서 레이트레이싱을 하면서 실시간으로 복셀을 화면에 그려주는 기법입니다. 실시간으로 돌리만큼 꽤 빨라요. (보고 꽤 감동받았습니다. 데모한번 실행해보세요 ^_^) 그리고 복셀 데이터를 볼륨이 아닌 표면(2D 비슷한) 데이터로 저장했다는게 꽤 주목할만 합니다. 하지만 똑같은 문제점이 있지요. 이 데이터를 편집할 수 있는 쉬운 방법이 없어요 -_-
즉, 이 새로운 기법들은 모두 폴리곤 데이터를 복셀데이터로 캡춰한 뒤 아무런 수정없이 다시 보여주는데 유용한 방법이란 겁니다.
물론 전통적인 MC와 CMS를 사용해서 메쉬를 생성해내면 결과가 조금 달라집니다. 하지만 폴리곤 데이터를 완벽하게 재현해내는게 목적이 아니라 복셀 데이터 편집이 목적이라면 그 차이점은 무시해도 될 수준입니다. 편집툴에서 고치는 즉시 결과가 보이기만 하면(WYSIWYG) 어떤 방법을 써도 별 차인 없거든요. 하지만 MC가 CMS보다 최소 30% 이상은 빠릅니다. (둘다 최적화를 하지 않은 C# 프로그램에서 테스트해봤습니다. 물론 당연히 멀티쓰레딩은 했구요)
4. 정점버퍼를 최적화하세요
10 x 10 x 10 복셀에서 메쉬를 생성하면 삼각형이 1~2천개 정도 나오는건 예사입니다. 복셀 밀도가 높고 월드가 넓으면, 1500만개 삼각형도 금방 씁니다. 이 엄청난 정점 데이터를 GPU로 보내려면 느리더라구요. 고사양 그래픽 카드와 저사양 그래픽 카드에서 모두 테스트 해봤는데 둘 다 엄청 느렸습니다... -_-
그러니 간단한 정점버퍼 최적화라도 해주세요. 삼각형들 끼리 정점을 공유하고 인접 표면들끼리의 법선을 평균내는 것 등이요. 이러면 정점버퍼의 크기를 30~50% 정도 줄일 수 있습니다.
5. level-of-details을 쓰세요
정점들을 공유하는것 만으론 충분치 않습니다. 1500만개에서 30~50% 세이브해도 여전히 삼각형 수가 800~1000만 정도거든요. LOD 메쉬도 생성해주세요. 복셀 공간에서 메쉬를 생성하려면(아마 그러셔야 할껄요?) 매 n번째 복셀을 샘플링 하는 방법으로 LOD 메쉬를 만들면 됩니다. (LOD1은 매 2번째, LOD2는 매 4번째 등으로요..)
CMS를 사용하면 LOD를 만드는 게 그리 어렵지 않습니다. 이 알고리듬은 교차점 정보를 가지고 있으므로 LOD사이에서 끊김 현상이 없거든요. 하지만 제가 권해드린 것처럼 MC를 사용하신다면 틈이 벌어집니다. 이 틈을 메꾸는걸 아직 시도해보진 않았습니다만.. 만약 그런다면 TransVoxel 알고리즘을 먼저 시도해볼거 같습니다. Don Williams 아저씨도 이 방법을 써서 성공했다더군요.
높은 LOD 폴리곤으로부터 낮은 LOD들을 생성하는 방법도 있습니다. 이러면 복셀 데이터를 직접 사용하지 않아도 되지요. Voxel Farm이 이 방법을 씁니다. 이 방법의 장점이 하나 있는데요. 높은 LOD 메쉬를 재투영(reproject)해서 낮은 LOD 메쉬에 사용할 노말맵을 만들수 있습니다. 하지만 메쉬 단순화(simplification)는 제 입맛에 안맞더군요. 자세한 이유는 역시 다음 섹션에서... -_-
6. 메쉬 단순화(simplication)이 입맛에 안맞을 수도 있습니다
정점 데이터를 최적화 하는 다른 방법으로 메쉬 단순화 기법이 있습니다. Voxel Farm이 이 방법을 사용하고 결과도 그닥 나쁘지 않습니다. 하지만 전 별로 맘에 안들었습니다. 합쳐질 삼각형과 그러지 않을 삼각형들을 제 맘대로 선택할 수 있는 방법이 매우 제약적이기 때문입니다. 이 삼각형들 선택은 어떤 오차계산(error calculation) 알고리듬을 선택하느냐에 따라 다른데요. 모든 경우에 제대로 작동하는 함수를 도무지 찾을 수가 없더라구요.
이 방법이 다른 분들의 용도에 안맞는다는 말은 아닙니다. 그냥 저에겐 안맞았습니다.
자.. 그럼 이정도면 된듯 하니... 즐겁게 복셀을 주무르세요~ 하악x2~
포프
1. isosurface부터 이해하세요
복셀 데이터를 주무르는 가장 실용적인 방법은 각 복셀마다 iso 값을 대입하는 겁니다. 다른 방법도 시도해봤는데요(물론 제가 발명해낸 기괴한 방법도 한번 시도해봤죠 -_-) 대부분 별로더라구요. 단점들이 있어요. 결국엔 iso 값으로부터 메쉬를 다시 생성해내는게 가장 실용적이고 메모리 친화적인 방법인거 같습니다. iso surface extraction에 대해 설명하는 무수한 논문이 있으나 정작 isosurface가 뭔지를 쉽게 설명하는 자료는 흔치 않더라구요.
여기 저기 뒤진 끝이 이 튜토리얼을 찾았습니다. 설명도 잘해놨구요. isosurface의 개념을 익히는데는 최고인듯 싶습니다. (물론 영어입니다... 이 글도 영문 블로그에 썻다가 한글로 번역하는 놈이기 때문에.. 혹시라도 괜찮은 한글자료 가지고 계신분은 공유좀 부탁 -_-a)
또한 3D Coat의 개발자가 매우 친절하게도 3D Coat에서 사용하는 복셀 데이터의 포맷을 공개해놨습니다. 이 데이터 구조를 들여다보는 것만으로도 복셀 에디팅에 대해 상당히 많은걸 배울 수 있습니다.
복셀 편집에는 큰 관심이 없고 그대신 임시 복셀 데이터로부터 절차적(procedurally)으로 거대한 지형(terrain)을 만드는게 목적이시라면 VoxelFarm inc의 블로그를 읽어보세요. 이 분 정말 천재더라구요. (실제 한번 만나도 봤습니다. 몬트리올 살때 -_-)
2. 복셀데이터는 "간접적" 으로만 변경할 수 있습니다
볼륨 데이터를 표현하기 위해 iso 값을 사용하게 되면 복셀 데이터를 변경할 수 있는 유일한 방법은 iso 값을 변경하는 것입니다. 이 연산들은 간단한 수학인데요. 각 iso 값을 증감하거나 이웃간의 값을 평균내는 등입니다. 물론 distance 함수를 직접 계산해서 새로운 isosurface 모양을 꾸겨넣을 순 있지요. (이 distance 함수에 대해서는 위에 링크를 걸어둔 튜토리얼을 참고해 주세요.)
iso 값과 최종 메쉬의 모양과는 1:1 관계가 없습니다. 즉 "이 edge를 0.2미터 오른쪽으로 늘리고 싶어. 그러니 복셀 값을 0.752로 바꿔야지!"라는 말을 할수가 없어요. 다시 말하면 최종 모양을 세밀하게 조절할 방법이 없습니다. 복셀의 밀도(density)를 아주 높이 올려도 (예: 1센치당 복셀 하나) 역시 마찬가지입니다. 이게 바로 제가 간접적으로만 복셀을 편집할 수 있다고 한 이유죠.
매우 뾰쪽한 edge를 가진 메쉬를 생성하는 새로운 알고리듬들도 있긴 합니다. 하지만 이 방법들은 복셀 편집을 위해 만들어진게 아닙니다. (자세한건 다음 섹션에서....)
3. 전통적인 마칭 큐브(marching cube)면 충분합니다
방금 말씀드렸듯이 iso데이터에서 메쉬를 생성하는 새로운 리서치들이 있습니다. 특히 Cubical Marching Square와 Efficient Voxel Octree가 꽤 주목할만한 리서치들인데요.
CMS는 매우 날카로운 edge를 생성할 수 있습니다. 단, 한가지 조건이 있습니다. 폴리곤 데이터로부터 iso값을 capture해야만 하지요. 이 방법은 큐브 표면에서 각 폴리곤 edge가 만나는 거리를 인코딩하는 방법으로 작동하거든요. 근데 실시간으로 이 데이터를 편집하려면(예: C4 engine이나 3D Coat에서 하는 것처럼) 꽤 힘들겠죠? 저도 edge의 교차점을 제대로 보존하면서 이 데이터를 편집할 실용적인 방법을 찾는데 실패했습니다.. ㅠ_ㅠ
EVO는 폴리곤 생성을 하는 기법이 아닙니다. 이건 CUDA에서 레이트레이싱을 하면서 실시간으로 복셀을 화면에 그려주는 기법입니다. 실시간으로 돌리만큼 꽤 빨라요. (보고 꽤 감동받았습니다. 데모한번 실행해보세요 ^_^) 그리고 복셀 데이터를 볼륨이 아닌 표면(2D 비슷한) 데이터로 저장했다는게 꽤 주목할만 합니다. 하지만 똑같은 문제점이 있지요. 이 데이터를 편집할 수 있는 쉬운 방법이 없어요 -_-
즉, 이 새로운 기법들은 모두 폴리곤 데이터를 복셀데이터로 캡춰한 뒤 아무런 수정없이 다시 보여주는데 유용한 방법이란 겁니다.
물론 전통적인 MC와 CMS를 사용해서 메쉬를 생성해내면 결과가 조금 달라집니다. 하지만 폴리곤 데이터를 완벽하게 재현해내는게 목적이 아니라 복셀 데이터 편집이 목적이라면 그 차이점은 무시해도 될 수준입니다. 편집툴에서 고치는 즉시 결과가 보이기만 하면(WYSIWYG) 어떤 방법을 써도 별 차인 없거든요. 하지만 MC가 CMS보다 최소 30% 이상은 빠릅니다. (둘다 최적화를 하지 않은 C# 프로그램에서 테스트해봤습니다. 물론 당연히 멀티쓰레딩은 했구요)
4. 정점버퍼를 최적화하세요
10 x 10 x 10 복셀에서 메쉬를 생성하면 삼각형이 1~2천개 정도 나오는건 예사입니다. 복셀 밀도가 높고 월드가 넓으면, 1500만개 삼각형도 금방 씁니다. 이 엄청난 정점 데이터를 GPU로 보내려면 느리더라구요. 고사양 그래픽 카드와 저사양 그래픽 카드에서 모두 테스트 해봤는데 둘 다 엄청 느렸습니다... -_-
그러니 간단한 정점버퍼 최적화라도 해주세요. 삼각형들 끼리 정점을 공유하고 인접 표면들끼리의 법선을 평균내는 것 등이요. 이러면 정점버퍼의 크기를 30~50% 정도 줄일 수 있습니다.
5. level-of-details을 쓰세요
정점들을 공유하는것 만으론 충분치 않습니다. 1500만개에서 30~50% 세이브해도 여전히 삼각형 수가 800~1000만 정도거든요. LOD 메쉬도 생성해주세요. 복셀 공간에서 메쉬를 생성하려면(아마 그러셔야 할껄요?) 매 n번째 복셀을 샘플링 하는 방법으로 LOD 메쉬를 만들면 됩니다. (LOD1은 매 2번째, LOD2는 매 4번째 등으로요..)
CMS를 사용하면 LOD를 만드는 게 그리 어렵지 않습니다. 이 알고리듬은 교차점 정보를 가지고 있으므로 LOD사이에서 끊김 현상이 없거든요. 하지만 제가 권해드린 것처럼 MC를 사용하신다면 틈이 벌어집니다. 이 틈을 메꾸는걸 아직 시도해보진 않았습니다만.. 만약 그런다면 TransVoxel 알고리즘을 먼저 시도해볼거 같습니다. Don Williams 아저씨도 이 방법을 써서 성공했다더군요.
높은 LOD 폴리곤으로부터 낮은 LOD들을 생성하는 방법도 있습니다. 이러면 복셀 데이터를 직접 사용하지 않아도 되지요. Voxel Farm이 이 방법을 씁니다. 이 방법의 장점이 하나 있는데요. 높은 LOD 메쉬를 재투영(reproject)해서 낮은 LOD 메쉬에 사용할 노말맵을 만들수 있습니다. 하지만 메쉬 단순화(simplification)는 제 입맛에 안맞더군요. 자세한 이유는 역시 다음 섹션에서... -_-
6. 메쉬 단순화(simplication)이 입맛에 안맞을 수도 있습니다
정점 데이터를 최적화 하는 다른 방법으로 메쉬 단순화 기법이 있습니다. Voxel Farm이 이 방법을 사용하고 결과도 그닥 나쁘지 않습니다. 하지만 전 별로 맘에 안들었습니다. 합쳐질 삼각형과 그러지 않을 삼각형들을 제 맘대로 선택할 수 있는 방법이 매우 제약적이기 때문입니다. 이 삼각형들 선택은 어떤 오차계산(error calculation) 알고리듬을 선택하느냐에 따라 다른데요. 모든 경우에 제대로 작동하는 함수를 도무지 찾을 수가 없더라구요.
이 방법이 다른 분들의 용도에 안맞는다는 말은 아닙니다. 그냥 저에겐 안맞았습니다.
자.. 그럼 이정도면 된듯 하니... 즐겁게 복셀을 주무르세요~ 하악x2~
포프
2013년 11월 26일 화요일
알파혼합 가능한 RGBM
RGBM이란?
fat 버퍼(채널당 16비트)를 써서 HDR 렌더타겟을 저장하는게 가장 직관적인 방법입니다. 하지만 이러기엔 속도가 너무 느렸고 메모리도 많이 잡아먹었죠. 그래서 보통 HDR을 8비트/채널 버퍼에 인코딩(패킹)하곤 했었습니다. 다양한 패킹 방법들이 존재하는데 아마 그중에서 가장 널리 사용했던건 RGBM 이었을겁니다. (이 링크에는 LogLUV 패킹 방법에 대해서도 잘 나와있으니 잘 모르시는 분은 읽어보세요...무.. 물론 영어 -_-)
RGBM의 단점
근데 문제가 있었습니다.. 아티스트분들이 엄청 좋아하는거 하나를 할 수 없거든요.. 넵. .알파 블렌딩 입니다.. -_-
RGBM버퍼를 사용하면 알파블렌딩을 할 수 없는게 현실입니다. 달리 말하면 투명한 물체들을 못쓴다는거지요... 왜냐구요? RGBM을 사용할때 블렌딩을 하려면 다음과 같은 공식을 돌려야 합니다.
( DestColor * DestMultiplier * InvSrcAlpha + SrcColor * SrcAlpha ) / SrcMultiplier
여기서 몇몇 매개변수들을 좀 살펴보지요.
- DestMultiplier: DestAlpha 채널에 저장되어있습니다. 블렌딩 유닛이 쉽게 사용할수 있지요
- SrcMultiplier: 셰이더에서 알파채널로 출력(output)합니다
- SrcAlpha: 투명값입니다. 근데.. 이걸 어디다 저장하죠? 보통 같으면 알파채널이죠.. 근데 RGBM을 사용하면 .... 이미 multiplier를 알파채널에 출력하니... 바.. 방법이..... 아.. 맞다.. "premultiplied alpha." 라는게 있었죠? 셰이더 안에서 SrcColor에 알파값을 미리 곱해주면 됩니다. 대충 해결했군요.
- InvSrcAlpha: 하지만 바로 여기가 모든게 개판나는 곳입니다. 투명값을 더 이상 출력하지 않으니 InvSrcAlpha를 블렌딩 유닛에서도 쓸수 없고, 이걸 셰이더안에서 DestColor에 미리 곱해줄 방법도 없지요. 넵.. 망했습니다 -_-;
기존의 해결방법
그래서 이 문제를 해결하기 위해 먼 짓을 했냐구요?.... 아무짓도 안했습니다... -_- 그냥 렌더타겟을 하나 더 만들어서 문제를 피해갔지요. 모든 투명한 물체들을 HDR 인코딩 없이 이 새로운 버퍼에 그렸습니다. 그리고 나중에 그 결과를 신(scene) 버퍼에 합쳤지요.
간단히 말해 불투명(opaque)한 물체들은 HDR에 그리고 투명한 물체들은 LDR에 그리는 겁니다. 하지만 이러면 전체화면(fullscreen) 패스를 한 번 더 돌려서 버퍼들을 합쳐줘야 하므로 속도저하의 문제가 있었습니다. 그래서 속도저하를 좀 줄여보고자 투명버퍼의 크기를 절반 또는 1/4로 줄여주는 꼼수를 쓰기도 했지요.
뭐, 이래저래 여전히 RGBM 버퍼만 하나 쓰는것보단 메모리를 더 먹었습니다.
혼합가능한(Blendable) RGBM
자, 그럼 제가 최근에 고안해낸 꼼수를 알려드리겠습니다. 혼합가능한(Blendable) RGBM이라 이름을 붙였구요. 일단 간단히 요약부터 해보죠.
- 투명한 물체들을 수학적으로 올바른 방법으로 혼합합니다
- 따라서 별도의 메모리를 필요로 하지 않습니다.
- 투명한 픽셀들은 이전에 HDR 버퍼에 그려졌던 불투명 픽셀의 multiplier를 그대로 사용합니다.
- 하지만 정밀도(precision)의 문제가 생길수 있는데요. 특히 불투명 픽셀과 투명 픽셀의 값이 크게 차이가 날 경우 그렇습니다.
- 투명 물체가 픽셀값을 어둡게 만들경우 벤딩(bending) 효과가 나타날 수 있습니다.
- 또, 투명 물체가 픽셀을 어느정도 이상으로 밝게 만들수도 없습니다. (불투명 픽셀의 multiplier가 허용하는 것 이상으로 밝게 만드는게 불가능합니다)
자..그럼 이제 좀 차근차근 대충대충 설명해보죠..
일단 수학공식에 맞추기
RGBM 혼합공식을 다시 봅시다:
( DestColor * DestMultiplier * InvSrcAlpha + SrcColor * SrcAlpha ) / SrcMultiplier
InvSrcAlpha 때문에 망했다고 전에 말씀드렸죠? 이건 셰이더에서 알파채널 값에 SrcMultiplier를 넣기 때문이었습니다. 그럼 이걸 어떻게 해결할까요? 간단 합니다.. 그냥 SrcMultiplier를 버리면 됩니다.. -_-;;;;; 농담이 아닙니다.. -_-;;;; SrcMultiplier와 DestMultiplier를 같게 만들면 됩니다. 즉 DestMultiplier만 쓰면 되죠. 이따위 짓을 하고 나면 공식이 이렇게 변합니다:
( DestColor * DestMultiplier * InvSrcAlpha + SrcColor * SrcAlpha ) / DestMultiplier
이걸 풀면 이렇게 간단히 되죠.
DestColor * InvSrcAlpha + SrcColor * SrcAlpha / DestMultiplier
자, 이제 알파채널을 사용하지 않으니 SrcAlpha를 그냥 알파채널에 써주면 됩니다. 끝~
올바른 블렌딩 렌더스테이트 설정
전 하드웨어 블렌딩 연산을 가지고 노는걸 좋아합니다. 가끔 기발한 짓을 할수 있거든요. 예전에 스크린 스페이스 데칼 만들 때도 그런짓을 했지요. 이번에도 또 사고쳤답니다 -_- ㅋㅋ
위에서 보여드렸던 블렌딩 공식에 껴 맞추려면 다음과 같이 렌더스테이트를 바꿔주면 됩니다:
- SrcBlend: DestAlpha
- DestBlend: InvSrcAlpha
이렇게 하고나면 위의 혼합공식에 매우 가까워졌지요. 하지만 아직 한가지가 빠져있군요. SrcAlpha를 곱해주는 부분입니다. 이미 SrcBlend를 DestAlpha로 해줬으니 SrcAlpha를 블렌딩 하드웨어에 설정해줄 방법은 없군요. 해법이 뭐냐구요? 전에 했던것처럼 그냥 premultiplied alpha를 다시 쓰면 됩니다. ^_^ 셰이더에서 SrcColor에 SrcAlpha를 미리 곱해주세요.
자, 그럼 모두 다 해결된건가요?.... 불행히도 아닙니다.. ( -_-) 위 블렌딩 스테이트 까지 설정해준 다음엔 공식이 이렇게 되거든요.
자, 그럼 모두 다 해결된건가요?.... 불행히도 아닙니다.. ( -_-) 위 블렌딩 스테이트 까지 설정해준 다음엔 공식이 이렇게 되거든요.
DestColour * InvSrcAlpha + SrcColor * SrcAlpha * DestMultiplier
퉤.. -_- DestMultiplier를 나눠줘야 하는데 곱해주고 있군요.... 이걸 고치려면 RGBM 인코딩/디코딩 하는 법을 좀 바꿔주면 됩니다.
RGBM 인코딩/디코딩 방법 바꾸기
RGBM 인코딩/디코딩을 하는 오리지날 방법은 다음과 같습니다.
- M: max(RGB)
- encoding: RGB / M
- decoding: RGB * M
- alpha encoding: M / 6
이걸 제대로 돌게 만드려면 M을 역으로 뒤집어주면 됩니다. 그러면 인코딩시엔 곱하고 디코딩시엔 나눠줄 수 있습니다. M을 뒤집어주면 대충 이렇게 됩니다.
- M: 1 / clamp( length(RGB), 1, 6 )
- encoding: RGB * M
- decoding: RGB / M
- alpha encoding: M
max(RGB)대신에 length(RGB)를 사용한 이유는 나중에 투명한 물체가 픽셀을 더 밝게 만들 수 있도록 좀 마진(margin)을 준것입니다. 여기서 M을 계산하는 방법은 좀 핵(hack)이라 생각하는데요. 저 공식에 있는 1(두번 나옴)을 0.125같이 작은 수로 바꾸면 LDR에서 정밀도(precision)가 좀 더 나을겁니다. 그런데 이걸 1으로 두면 나중에 투명패스에서 사용할 수 있는 색상값의 범위가 최소한 0~1은 되니.. 그걸 보장하기 위해 저렇게 뒀습니다.. 뭐든간에... 이것보다 훨씬 괜찮은 M 계산법을 다른 분들이 찾아낼거라 믿습니다... :)
드디어 새로운 블렌딩 공식!
이제 이리저리 다 뜯어 고쳤으니 드디어 공식이 완성되었습니다:
( DestColor / DestMultiplier * InvSrcAlpha + SrcColor * SrcAlpha ) * DestMultiplier
이걸 전개하면 다음과 같이 됩니다.
DestColour * InvSrcAlpha + SrcColor * SrcAlpha * DestMultiplier
무하하하하 -_- 블렌딩 렌더스테이트에서 나온 계산하고 똑같죠? 드디어 완성되었습니다.. -_-v
Alpha 쓰기 끄기
잠만요.. 근데 투명값을 알파채널로 출력(output)해주면 HDR 버퍼에 이미 적혀있던 multiplier를 덮어 쓰겠네요? 그럼 안되지요. 알파값은 블렌딩 유닛에서만 필요한거니, 이게 렌더타겟에 적히는 걸 막아야합니다.
이것도 역시 렌더스테이트에서 alpha 쓰기를 마스킹해주는 것만으로 간단히 해결됩니다.
이것도 역시 렌더스테이트에서 alpha 쓰기를 마스킹해주는 것만으로 간단히 해결됩니다.
가산혼합(Additive Blending)
제 방법은 가산혼합과도 잘 동작합니다. 블렌딩 스테이트를 다음과 같이 바꿔주세요
- SrcBlend: DestAlpha
- DestBlend: One
주의점
앞서 밝혔다 싶이, 이 방법에는 두가지 단점이 있습니다.
- 투명한 물체가 픽셀을 너무 어둡게 만들면 벤딩효과가 보일겁니다. 정밀도가 모잘라서 인데요. 이건 이미 버퍼에 있던 픽셀들이 HDR 영역에 있었을때만 보이는 현상입니다.
- 투명한 물체가 픽셀값을 어느정도 이상으로 밝게 만들지 못합니다. 여기서 어느정도라 하면 불투명 픽셀들이 내뱉어낸 multiplier에서 허용하는 한도입니다.
혼합가능한 RGBM을 어느상황에나 사용할 수 있는건 아닙니다. 특별한 상황에서만 사용가능한데요. 실제 게임 만들면서 그런 상황을 본적이 있습니다. 뭐든간에 성능 또는 메모리상의 이유로 버퍼를 따로 하나 만들수 없고 비주얼 퀄리티를 약간 희생시킬 수 있다면 사용하세요. 결국 비주얼 퀄리티와 메모리간의 밸런스 문제니까요.
p.s.
새로운 콘솔용 게임을 만드시는 분들에게 HDR 패킹은 더이상 필요없을지도 모르겠습니다. 하지만 아직도 후진(?) 하드웨어 용으로 게임을 만드시는 분들이 계실테니, 그분들께 도움이 되었으면 하는 맘에서 오랜만에 동영상이 아닌 블로그 글을 썼습니다.. ^_^
포프였습니다.
2013년 11월 22일 금요일
VC++ 최적화된 코드 디버깅 하기
사실 게임프로그래머들 중에 release 빌드, 즉 최적화된 코드, 에서 디버깅하는 사람들이 많습니다. 이유는 뭐.. 당연히 debug빌드가 졸라 느린 경우가 있기 때문이지요.
근데 그럴때마다 watch 창에서 로컬변수들 보면 다 깨져나왔죠? ???? 로 나오거나 아니면 아예 잘못된 넘으로 나오던가요. 이걸 해결하려고 디스어셈블리보면서 register에 들어있는 메모리주소를 watch 창에서 casting해서 보는 경우도 있지요. 근데 디스어셈블리 보는게 꽤 귀찮은 짓인건 맞아요..
근데 이게 Visual C++ 2012부터 지원해주더라구요. 사실 공식적인 지원은 아닙니다. 그냥 내부적으로 마이크로소프트사에서 만들어서 다른 용도로 쓰고 있던 걸 누가 찾아낸 것 뿐이거든요. 공식적으로 문서화 되어있는 스위치도 아닙니다. 하지만 현재 VC2012하고 2013에서 다 돕니다. 잘 돕니다.
자 그럼 어케 하냐.... 컴파일러에 이 스위치 하나 넣어주면 됩니다.
/d2Zi+
이 스위치 하나 넣어주시면 됩니다.
실험결과 exe파일은 전혀 손대지 않습니다. pdb파일만 좀 바뀝니다. 고로 그냥 release빌드에서 켜주셔도 아무 문제가 없을것 같습니다.
p.s. 귀찮아서 스샷 생략합니다. 이거 찾아내신 분의 블로그에서 그냥 보세요 ㅎㅎ
끝.
포프
근데 그럴때마다 watch 창에서 로컬변수들 보면 다 깨져나왔죠? ???? 로 나오거나 아니면 아예 잘못된 넘으로 나오던가요. 이걸 해결하려고 디스어셈블리보면서 register에 들어있는 메모리주소를 watch 창에서 casting해서 보는 경우도 있지요. 근데 디스어셈블리 보는게 꽤 귀찮은 짓인건 맞아요..
근데 이게 Visual C++ 2012부터 지원해주더라구요. 사실 공식적인 지원은 아닙니다. 그냥 내부적으로 마이크로소프트사에서 만들어서 다른 용도로 쓰고 있던 걸 누가 찾아낸 것 뿐이거든요. 공식적으로 문서화 되어있는 스위치도 아닙니다. 하지만 현재 VC2012하고 2013에서 다 돕니다. 잘 돕니다.
자 그럼 어케 하냐.... 컴파일러에 이 스위치 하나 넣어주면 됩니다.
/d2Zi+
이 스위치 하나 넣어주시면 됩니다.
실험결과 exe파일은 전혀 손대지 않습니다. pdb파일만 좀 바뀝니다. 고로 그냥 release빌드에서 켜주셔도 아무 문제가 없을것 같습니다.
p.s. 귀찮아서 스샷 생략합니다. 이거 찾아내신 분의 블로그에서 그냥 보세요 ㅎㅎ
끝.
포프
2013년 10월 16일 수요일
[KGC 2013] 컴오히의2의 겨울 렌더링 기법
제 전 동료 다니엘이 KGC 2013에서 강연했던 컴오히2의 겨울 렌더링 테크 발표입니다. 다니엘의 부탁으로 제 블로그에 따로 올립니다..
2013년 10월 2일 수요일
아티스트에게 사랑받는 3DS Max 우버쉐이더
약속 드린대로 올해 강연했던 pt자료 공유합니다. 강연장이 가득 차서 뒤에 서계신분들도 많았고 아티스트/프로그래머 비율이 반반이라 꽤 즐거웠던 강연이었습니다. ^_^
2013년 9월 13일 금요일
[KGC2012] 최대로 효과적인 프로듀서 되기
스티브가 KGC 2012에서 강연했던 The Producer란 강연입니다. 부제는" 최대로 효과적인 프로듀서 되기"이군요.
스티브가 아직까지 안올렸기에 허락을 받고 제가 올리는 겁니다 ^_^
스티브는 올해에도 KGC에 강연하러 옵니다 ^_^/
스티브가 아직까지 안올렸기에 허락을 받고 제가 올리는 겁니다 ^_^
스티브는 올해에도 KGC에 강연하러 옵니다 ^_^/
2013년 9월 9일 월요일
2013년 9월 5일 목요일
제 이력위조에 대한 의혹...
페북에서 강산아 님이 소환하셔서 이런글이 있단걸 알았네요. 여기가서 보시면 잘 나와있습니다. 제가 강산아님에게 페북으로 답 달아드린것도 있구요.
뭐 여태까지 의혹이 있으셨다면 보고 판단하시기 바랍니다.
"""게임임코디에 실린 제 이력위조에 대한 의혹글"""
참고로 말씀드리면... 넵.. 저 제자랑 아주 잘합니다... 잘못된건가요?
업데이트 (2013/9/6): 게임코디에 싫어요 투표가 많아서 회원이 아니면 본문이 안보인다는군요.. 본문을 캡춰해서 놨습니다. 댓글은 다 볼수 있는데 본문만 못본다는게 좀 이상하군요 -_-a
뭐 여태까지 의혹이 있으셨다면 보고 판단하시기 바랍니다.
"""게임임코디에 실린 제 이력위조에 대한 의혹글"""
참고로 말씀드리면... 넵.. 저 제자랑 아주 잘합니다... 잘못된건가요?
업데이트 (2013/9/6): 게임코디에 싫어요 투표가 많아서 회원이 아니면 본문이 안보인다는군요.. 본문을 캡춰해서 놨습니다. 댓글은 다 볼수 있는데 본문만 못본다는게 좀 이상하군요 -_-a
분류
잡담
2013년 8월 7일 수요일
셰이더 프로그래밍 입문 틀린내용 업데이트(1쇄/2쇄)
최근에 현정님이 셰이더 프로그래밍 입문 1쇄에서 오타를 하나 찾아주셨는데... 1쇄 2쇄 공통 적용됩니다. 찾아주신 이쁜 현정님께 감사의 말씀 드립니다.
p.154
행기준 행렬
| Tx Bx Nx | -> | Tx Bx Nx |
| Ty By Ny | | Ty By Ny |
| Tz By Nz | | Tz Bz Nz |
여태까지 찾은 모든 잘못된 내용은 아래 페이지에 있습니다.
셰이더 프로그래밍 입문 정오표
p.154
행기준 행렬
| Tx Bx Nx | -> | Tx Bx Nx |
| Ty By Ny | | Ty By Ny |
| Tz By Nz | | Tz Bz Nz |
여태까지 찾은 모든 잘못된 내용은 아래 페이지에 있습니다.
셰이더 프로그래밍 입문 정오표
분류
개발,
도서,
포프의 쉐이더 입문강좌
2013년 7월 31일 수요일
유니티 prefab에서도 enum은 int일뿐
사실 C++ 에서 enum을 많이 쓰는 이유는 enum자체가 int값이랑 별 다르지 않기 때문입니다. 예를 들어
enum eAnimal
{
ANIMAL_DOG,
ANIMAL_CAT
};
이 있으면 ANIMAL_DOG은 0, ANIMAL_CAT은 1에 불과할 뿐이죠.
int dogIndex = ANIMAL_DOG;
이런게 아무 문제 없이 되었으니까요. 이제는 C#부터 비롯한 다양한 언어에서(아마 C++ 차세세대 규격도 그랬던듯) enum을 strong type으로 다뤄서 저런게 쉽게 안되게 하긴 하는데 그래도..
int dogIndex = (int)ANIMAL_DOG;
하면 여전히 dogIndex는 0이 됩니다.
근데 C#에서 재밌는게 enum으로 부터 스트링 값을 뽑아올수가 있지요. 즉 ANIMAL_DOG을 실행중에 "ANIMAL_DOG"이라 문자열로 가져올수도 있는겁니다. 그래서 유니티를 만지면서 함 실험을 해봤습니다. 유니티에서 prefab을 만들면 그 값을 기억하는데 이때 enum 형을 기억하면 과연 문자열을 기억하는지 아니면 int로 기억하는지 궁금했어요.
사실 은근 string으로 저장되길 바랬습니다... string으로 저장하면 이런게 되거든요..
만약 prefab에 ANIMAL_CAT을 저장해눴는데.. 그 후에 eAnimal에 새로운 놈을 추가하면..
enum eAnimal
{
ANIMAL_DOG,
ANIMAL_MOO,
ANIMAL_CAT
};
나중에 그 prefab을 읽어와도 숫자 1이 아닌 "ANIMAL_CAT"으로 읽히기에 중간에 다른 놈을 삽입해도 아무 문제가 없다는거죠...
근데 실험해보니... ANIMAL_MOO가 읽히더군요 -_-;
뭐 그래서 유니티에서 prefab저장할때 enum은 int 저장되는겁니다... 뭐 이거의 장점도 있어요.... 이름 바꾸긴 편하죠.. ANIMAL_CAT을 ANIMAL_MEOW로 바꿔도 아무 문제가 없거든요.
그럼 이상 후다닥 -_-
enum eAnimal
{
ANIMAL_DOG,
ANIMAL_CAT
};
이 있으면 ANIMAL_DOG은 0, ANIMAL_CAT은 1에 불과할 뿐이죠.
int dogIndex = ANIMAL_DOG;
이런게 아무 문제 없이 되었으니까요. 이제는 C#부터 비롯한 다양한 언어에서(아마 C++ 차세세대 규격도 그랬던듯) enum을 strong type으로 다뤄서 저런게 쉽게 안되게 하긴 하는데 그래도..
int dogIndex = (int)ANIMAL_DOG;
하면 여전히 dogIndex는 0이 됩니다.
근데 C#에서 재밌는게 enum으로 부터 스트링 값을 뽑아올수가 있지요. 즉 ANIMAL_DOG을 실행중에 "ANIMAL_DOG"이라 문자열로 가져올수도 있는겁니다. 그래서 유니티를 만지면서 함 실험을 해봤습니다. 유니티에서 prefab을 만들면 그 값을 기억하는데 이때 enum 형을 기억하면 과연 문자열을 기억하는지 아니면 int로 기억하는지 궁금했어요.
사실 은근 string으로 저장되길 바랬습니다... string으로 저장하면 이런게 되거든요..
만약 prefab에 ANIMAL_CAT을 저장해눴는데.. 그 후에 eAnimal에 새로운 놈을 추가하면..
enum eAnimal
{
ANIMAL_DOG,
ANIMAL_MOO,
ANIMAL_CAT
};
나중에 그 prefab을 읽어와도 숫자 1이 아닌 "ANIMAL_CAT"으로 읽히기에 중간에 다른 놈을 삽입해도 아무 문제가 없다는거죠...
근데 실험해보니... ANIMAL_MOO가 읽히더군요 -_-;
뭐 그래서 유니티에서 prefab저장할때 enum은 int 저장되는겁니다... 뭐 이거의 장점도 있어요.... 이름 바꾸긴 편하죠.. ANIMAL_CAT을 ANIMAL_MEOW로 바꿔도 아무 문제가 없거든요.
그럼 이상 후다닥 -_-
2013년 7월 24일 수요일
셰이더 프로그래밍 입문 GLSL 소스코드(비공식)
제가 출판했던 셰이더 입문 책의 샘플이 HLSL로 되어있는데 GLSL로 바꾸서 본인 블로그에 공개해주신 분이 계시더군요. 혹시라도 GL쪽을 더 많이 하시는 분들을 위해 여기에 링크를 걸어둡니다. 제목에 써놨듯이 비공식이며... 혹시라도 소스코드에 문제가 있더라도 전 모르는 일입니다.. 후후후 -_-
자 그럼 링크입니다.. 꺄아~
http://libsora.so/glsl_example/
자 그럼 링크입니다.. 꺄아~
http://libsora.so/glsl_example/
분류
개발,
도서,
포프의 쉐이더 입문강좌
2013년 7월 9일 화요일
2013년 7월 3일 수요일
2013년 6월 22일 토요일
잠을 제때 자지 않는 악순환
- 잠을 제 때 자러 가지 않는다.
- 그러면 충분한(7~8시간?) 수면을 취하지 못한다.
- 그러면 다음날이 피곤하다.
- 그러면 일의 능률이 오르지 않는다.
- 그러면 뭔가 자신이 보잘것 없는거 같아 허무하다.
- 집에와도 피곤하다.
- 그러면 다른 일 할 맘이 안든다.
- 그대신 술을마신다, 웹서핑을 한다, 아니면 그냥 넋놓고 시간만 낭비한다
- 잘시간이 되도 잘 수 없다. 오늘을 알차게 보내지 못한거 같은 느낌에 내 자신이 쓸모없이 느껴진다.
- 허무하다.
- 그래서 또 악순환은 반복된다.
이걸 너무나 잘 알고 있는데도 요 몇 주 이 따위로 보내는거 보면... 일이 그닥 재미가 없거나....먼가 기분이 다운인거다... 내 집이면 좋겠다. 그럼 피아노 치며 놀텐데...
2013년 6월 16일 일요일
최고가 되는건 어렵지 않다.
"최고가 되는건 어렵지 않다. 하지만 본인이 최고라는 사실을 깨닫는게 되는 건 어렵다... 그 반대인 사람들은 그냥 자만할 뿐이다."
김포프(2013/05/28)
김포프(2013/05/28)
2013년 6월 15일 토요일
2013년 6월 14일 금요일
[궁금증 리서치] 애완용 여우
오늘 어쩌다 애완 여우 비디오를 유투부에서 보게 되었습니다.
그래서 "응? 정말 여우를 애완용으로 키울 수 있는건가?"라는 생각이 들어서 좀 리서치를 했더니.. 가능은 하더군요.... 포퓰러 사이언스에 작년 10월에 기사가 실렸었습니다.
포퓰러사이언스 기사: Can I Have A Pet Fox?
이 기사를 대충 번역/요약 하면
그래서 "응? 정말 여우를 애완용으로 키울 수 있는건가?"라는 생각이 들어서 좀 리서치를 했더니.. 가능은 하더군요.... 포퓰러 사이언스에 작년 10월에 기사가 실렸었습니다.
포퓰러사이언스 기사: Can I Have A Pet Fox?
이 기사를 대충 번역/요약 하면
- 길들여진 야생동물이라 할때 영어로는 tamed와 domesticated라는 구분이 있음
- tamed는 그냥 야생동물을 훈련시켜서 길들인것.. 어렸을 때부터 야생여우를 키우면 tamed는 가능. 주인을 물거나 하진 않지만.. 주인이 공 던지면 가서 물어오거나 배 만져달라고 발랑 눕고 꼬리치는 짓 등은 안함. 그리고 가장 중요한 점은 이런 길들여진 특성이 자식에게 물려지진 않음
- domesticated는 수십대에 걸쳐 인간을 잘 따르는 놈들을 교배시킨 결과 사람을 아주 잘 따르고 꼬리도 치는 그런놈들. 한마디로 길들여진 유전자가 있기에 새끼들도 여전히 사람을 잘 따름
- 소련(그리고 현재는 러시아)가 50년대부터 이런 교배를 해왔고 따라서 현재 애완용 여우는 러시아를 통해서만 살 수 있음
- 가격은 한 600만원 정도
- 한가지 재밌는 점은 이렇게 선택적으로 교배를 한 놈들은 모냥새가 원래의 야생 여우와 조금은 다르고 여기저기 개의 흔적이 보인다나...
그럼 실제 게임개발과 아무 상관이 없지만.. 궁금해서 찾아본 리서치를 마무리 합니다... (원래부터 궁금증이 많아서 궁금하면 무조건 찾아보는 성격이라..... 프로그래밍도 그렇게 배웠습니다.. -_-)
2013년 6월 10일 월요일
밉맵 디테일 높이기
벌써 5년넘게 써오고 있는 방법인데 생각보다 모르시는 분들이 많은 것 같아 이방법을 공유합니다.
밉맵?
일단 밉맵이 뭔지는 다 아시리라 생각하고 굳이 밉맵에 대해서는 설명하지 않겠습니다. 모르시는 분들은 여길 참고하세요.문제점 및 일반적인 해결책
밉맵을 사용하다보면 정말 카메라를 가까이 들이밀지 않는한 텍스처의 디테일이 흐릿해 보이는 경우가 흔히 발생합니다. 보통 다음과 같은 방법들로 해결합니다.흔히 쓰는 해결법 1 - 텍스처 크기 늘리기
밉레벨이 낮아질수록 텍스처 크기가 절반씩 줄어드는 거니 젤 높은 디테일의 밉멥 텍스처크기를 크게 키워주면 그만큼 흐려지는 현상이 덜합니다. 하지만 메모리를 많이 잡아먹는다는 단점이 있어서 정 필요한 때만 제한적으로 사용하곤 합니다. (왜 흔히 라고 한거지 그럼 -_-)흔히 쓰는 해결법 2 - 밉맵 바이어스 쓰기
이걸 고치기 위해 흔히 쓰는 해결법은 밉맵 bias를 조절하는 방법입니다. 샘플러스테이트에서 정해주는 방법도 있고 셰이더에서 해주는 법도 있습니다. 뭐든 나쁜 방법은 아니고 가장 널리 쓰는 방법인데 여러가지 단점이 있습니다- 고디테일의 텍스처(크기가 큼)를 더 많이 쓰도록 bias를 주므로 텍스처 캐쉬의 성능저하 (그만큼 넣어야할 데이터가 많으니)
- 밉맵이 원래 해결하려고 하는 거리에 따른 애일리어싱 문제가 쉽게 더 생긴다.
- 모든 경우에 적당히 잘 동작하는 bias 값을 찾기가 쉽지 않다.
흔히 쓰는 해결법 3 - 밉맵 생성시 사용하는 필터 다르게 사용하기
보통 bilinear 필터를 사용해서 밉맵을 만드는게 일반적입니다. 그럼 그냥 주변에 있는 이웃 픽셀들 2x2개 모아다가 균등하게 혼합하는게 전부입니다. 이 외에 kaiser 필터 등을 사용하면 좀더 낫다고 해서 그렇게 하는 사람들을 봤지만... 개인적으로는 별 효과가 없다고 생각합니다.
제 해결법 - sharpening filter
생각보다 매우 간단합니다. 그냥 밉맵 텍스처에 sharpening 필터 한번 더 먹여주면 됩니다. -_- 사실 밉맵들이 흐릿해 보이는 이유가 bilinear 필터링만 쓰면 그냥 경계를 뭉게버린다는건데 여기다 sharpening 필터 한번 먹여주면 경계부분은 다시 적당히 또렷하게 살아나거든요...
오프라인 프로세스라 게임성능에 지장도 없고... 흔히 쓰는 해결법 2에서 말씀드렸던 단점들도 없습니다.. 그냥 밉맵만드실때 이런순서로 만들어 주시면 됩니다.
- 밉맵 0으로부터 밉맵 1 생성 (bilinear filter)
- 밉맵 1에 sharpening filter 적용
- 2번 결과물로부터 밉맵 2 생성(bilinear filter)
- 밉맵 2에 sharpening filter 적용
- 밉맵 끝까지 만들때까지 반복...
이 방법을 대충 포토샵으로 흉내낸걸 보여드리면 대충 이렇습니다. 오른쪽이 제 방법입니다.
2013년 6월 7일 금요일
[방명록 답변] 렌더러가 될려면 미술실력이 좋아야 하는가?
얼마전에 블로그 방명록에 질문이 달린게 있는데... 똑같은걸 궁금해 하시는 분들이 계실거 같아. 여기다 재 포스팅합니다.
일단 질문은 다음과 같았습니다.
"포프님처럼 렌더러가 될려면 미술실력도 중요한가요? 북미취업하기 책 구입해서 여러번 정독했는데 이 부분에 대해선 확답이 없는거 같아서요.제가 미술엔 전혀 인연이 없습니다 ㅠㅠ"
여기에 제가 달아드린 답변은 다음
별로 안중요합니다. 일단 제가 미술을 잘 못하고.... 색약도 있으며 -_-;;; 등등..제 주변을 봐도 미술을 하는 렌더러는 못봤어요.. 단 사진 찍는걸 좋아하는 친구들은 몇몇 봤음..(전 아닙니다..) 렌더러라는게 결국 빛을 잘 이해하는게 중요하거든요. 그래서 사진 찍는거 좋아하는건 도움이 될거 같아요..(역시 전 아니지만..) 하지만 반드시 그걸 직접 하지 않아도 빛의 물리학적으로 이해하는건 문제가 없다고 생각합니다..
미술은 크게 문제가 안되니 걱정마시길...
여기다 추가로 다시 몇가지 말하면
- 저 어렸을때는 그대로 미술 아주 못하진 않았습니다. 중학교 때까지 연필로 스케치 하는건 그래도 줄곧 하곤 했는데.. 수채화만 들어갔다하면 밑에 칠한게 마르는걸 기다리지 못하고 위에 다른 색깔을 자꾸 칠해서 전부다 번져버리는 관계로... 많이 망쳤습니다. 고등학교때는 미술 거의 안한거 같고.. 지금 뭐 그리라고 하면 아마 못그릴거 같습니다.
- 미술을 잘하면 도움이 될 것 같긴 합니다. 단 못해도 렌더러를 하는데 문제가 된다고 생각하진 않습니다.
- 위에서 말씀드렸지만 많은 렌더러들이 사진을 찍는다고 말씀드렸습니다. 아무래도 사진을 찍는 테크닉을 배우다보면 빛을 연구하기 때문인거 같은데요. 전 그 나마도 안합니다. 가끔 빛으로 인해 발생하는 걸 보면 핸드폰 사진기로 찍어보는게 전부입니다. DSLR같은게 없단 거죠 ㅎㅎㅎ.
- 사진을 찍진 않아도 밖에서 걸어다니면서 이리저리 빛을 관찰하고는 다닙니다. 잔디밭에 서면 제 옷이 약간 녹색을 띄는거나... 노란색 후드티를 입으면 제 얼굴이 노랗게 되는것.. 등등... 저녁에 밖에 나가면 하늘의 푸르른 색이 제 팔에 보인다거나.. 반투명한 나뭇잎 뒤에 있는 물체들은 어떤 빛을 받는지.... 이런건 관찰을 하게 되더라구요...
마지막으로
어떤 직업이든 반드시 한가지의 정도만 있는건 아닙니다. 사실 저도 제 동료들에 비하면 매우 정도에서 벗어난 인간입니다. (제 동료들은 컴터 그래픽쪽으로 박사학위 있고... 저보다 훨씬 학문적으로 관심이 많아요... 전 그보단 실제로 적용하는거에 더 관심이 많고...) 그냥 자신이 가진 장점 중에 렌더러에 도움되는걸 잘 찾고.. 정말 단점이 있다면 적당한 수준으로만 올리시는게 성공의 지름길이라 생각합니다.2013년 6월 5일 수요일
가슴뭉클해지는 책 리뷰
인터넷으로 가끔 검색해보면서 제 책의 리뷰들을 찾아보는데.. 오늘은 정말 마음이 뿌듯해지는 리뷰를 찾았습니다..
오늘은 평소와 다르게 약간 겸손모드라.. 제가 직접 텍스트를 긁어 붙이기엔 좀 낯이 간지러워서.. 링크 2개로 떼우겠습니다... -_-
p.s. 생각해보니 아직 나쁜 리뷰가 없네요. 1쇄에는 잘못된 내용도 몇개 발견되서 맘이 참 안좋았었는데 말이죠.. 다행히 제 판단이 틀리진 않았나봐요....^_^
오늘은 평소와 다르게 약간 겸손모드라.. 제가 직접 텍스트를 긁어 붙이기엔 좀 낯이 간지러워서.. 링크 2개로 떼우겠습니다... -_-
p.s. 생각해보니 아직 나쁜 리뷰가 없네요. 1쇄에는 잘못된 내용도 몇개 발견되서 맘이 참 안좋았었는데 말이죠.. 다행히 제 판단이 틀리진 않았나봐요....^_^
분류
도서,
자뻑,
포프의 쉐이더 입문강좌
2013년 6월 3일 월요일
C++ PIMPL 패턴.. 별로임 -_-;
생각해보니 개인적으로 PIMPL 패턴을 직접 구현해본적이 없다. 이런 패턴이 있다는걸 예전에 읽어본적은 있지만.. 그냥 '그닥 쓰고 싶은 생각이 안나는 놈?' 정도로 생각했다고 할까...
음 근데.. 지금 다루고 있는 코드베이스 안에는 PIMPL패턴이 아주 넘친다... 그래서 사용해본 뒤 소감이 어떻냐고? 안.좋.다. 게임 프로그래밍에서 이 패턴을 씀으로써 얻는 장점이 별로 없다고 생각한다. PIMPL 패턴의 장점이 뭘까? 다음 두가지 장점 정도가 아닐까?
따라서 PIMPL의 장점이 그닥 중요하가 와닿지 않는 반면.. 단점은 아주 절절히 느껴지는게 문제....
참고로 영어로 pimple은 뾰드락지를 말함 -_- 이런거...
음 근데.. 지금 다루고 있는 코드베이스 안에는 PIMPL패턴이 아주 넘친다... 그래서 사용해본 뒤 소감이 어떻냐고? 안.좋.다. 게임 프로그래밍에서 이 패턴을 씀으로써 얻는 장점이 별로 없다고 생각한다. PIMPL 패턴의 장점이 뭘까? 다음 두가지 장점 정도가 아닐까?
- API 설계와 구현의 확연한 구분: 소프트웨어 아키텍트 마스터가 API를 멋지게 설계해두면 쫄개 프로그래머/코드 몽키들을 와라락 달려들어 잘 숨겨진 파일안에 구현을 함
- 헤더파일간의 의존성(dependency)가 적음 = 컴파일 시간이 빠름
일단 장점 1번이 게임 프로그래밍 업계에서 큰 의미가 있다고 생각하지 않는다. 어느 엔터테인먼트 업계에서도 그러듯이 게임의 요구사항은 끊임없이 변하며 그에따라 API도 수도없이 바뀐다. 즉, 마스터가 API를 멋지게 설계하는 일 자체가 별로 없단 이야기. 그리고 다른 프로그래머들로부터 구현파일을 숨긴다는거 자체도... 좀 웃기지 않나? 게임 프로그래머들은 전체 소스코드를 보는 걸 좋아한다. 라이브러리를 만들어서 파는 3rd party업체가 아닌이상... 정말 별 의미가 없음...
게임 프로그래머들이 PIMPL 패턴을 왜 쓰는 주 이유는 사실 2번이라고 생각한다. C++ 의 컴파일 속도는 매우 구려요 -_-;;; 하지만 PIMPL 패턴 보다 컴파일 속도를 향상시킬 수 있는 다른 방법이 존재한다. 물론 조홀라 비싼 incredibuild를 말하는 건 아니다. 여태까지 써본 방법중에 가장 빠른 건 이미 10년전부터 널리 애용되고 있는 유니티 빌드였다.. 물론 공짜 -_-v... 이에 대한 제대로된 한국말 설명은 다음의 슬라이드를 참고...
게임 프로그래머들이 PIMPL 패턴을 왜 쓰는 주 이유는 사실 2번이라고 생각한다. C++ 의 컴파일 속도는 매우 구려요 -_-;;; 하지만 PIMPL 패턴 보다 컴파일 속도를 향상시킬 수 있는 다른 방법이 존재한다. 물론 조홀라 비싼 incredibuild를 말하는 건 아니다. 여태까지 써본 방법중에 가장 빠른 건 이미 10년전부터 널리 애용되고 있는 유니티 빌드였다.. 물론 공짜 -_-v... 이에 대한 제대로된 한국말 설명은 다음의 슬라이드를 참고...
따라서 PIMPL의 장점이 그닥 중요하가 와닿지 않는 반면.. 단점은 아주 절절히 느껴지는게 문제....
- 코드 읽기가 더 귀찮아진다. 파일 여러개를 뛰어다녀야만 겨우 구현코드를 볼 수 있다는 단점....매조키스트 아닌 다음에야 이걸 좋아할리가...
- 듬성듬성한 메모리 할당: pimpl 개체를 만들기 위해 따로 new를 호출해줘야 한다. 메모리 파편화, cache 관리 등의 이유로 개인적으로 클래스의 모든 멤버가 한번에 메모리할당되는 걸 좋아하고, 그 외에도 어떤 개체의 크기를 쉽게 알아오기에도 한번에 할당되는게 좋다.
- 추가적인 포인터 참조 연산 = 아주 조금 더 느림.... 이정도 포인터 점프 한번 더 하는게 성능에 아주 큰 영향을 미치지는 않는다. 하지만 엔진쪽 프로그래밍 하는 사람으로써 이런 필요없는 포인터연산이 성능을 10프로 이상 떨어뜨리는 걸 수도없이 봤기에... 매우 까탈스러울수밖에 없다... 아마 실제로 이 포인터 참조에 걸리는건 CPU 사이클 4사이클 정도일 테지만... pimpl 개체의 메모리 위치가 떨어져 있을 수도 있으니 cache 관리까지 들어가면 더 느릴수 있다는 것.... 물론 메모리 할당 순서를 손수 잘 컨트롤 해주면 이런 문제를 피할수도 있겠지만... pimpl 패턴의 장점이 크게 없는 이상 왜 이런 쓸데없는 짓을 해야하나 생각까지 든다.
결론... 핌플 맘에 안듬.... -_- 아니면 내가 뭔가 놓치고 있는게 있나?
참고로 영어로 pimple은 뾰드락지를 말함 -_- 이런거...
2013년 5월 22일 수요일
셰이더 프로그래밍 입문 2쇄 발매
셰이더 프로그래밍 입문의 1쇄가 전부다 팔렸습니다. 블로그에 절반을 공개해놨는데도.. IT 서점 시작이 불황이라는데도.... 잘 팔리는거 보니 기분이 좋네요.... 사주신 분들 모두 감사합니다. 그리고 교재로 채택해주신 대학 및 학원들도 매우 감사합니다. ^_^
2쇄에서 바뀐 내용중 가장 중요한건....
저자소개에 제 사진이 들어갔단 것입니다. 그리고 자기 자랑을 너무 안했다고 아버님이 노해하셔서... 자기자랑을 좀더 했습니다. BCIT 수석 졸업.. 쿨럭쿨럭 -_- 새로 바뀐 저자소개는 한빛미디어 홈페이지에서 즐겁게(?) 감상하실 수 있습니다.
그리고 그보단 덜(?) 중요하지만.... 1쇄에서 있던 오타와 잘못된 내용을 수정하였습니다. 1쇄 정오표는 제 블로그에 이미 올려두었습니다.
자.. 제 사진을 집에 고이 소장하시고 싶으신분들은 2쇄도 한권 씩 사주시면 됩니다.. 그럼 3쇄에는 누드사진을 실을지도.. 쿨럭쿨럭 -_-
2쇄에서 바뀐 내용중 가장 중요한건....
저자소개에 제 사진이 들어갔단 것입니다. 그리고 자기 자랑을 너무 안했다고 아버님이 노해하셔서... 자기자랑을 좀더 했습니다. BCIT 수석 졸업.. 쿨럭쿨럭 -_- 새로 바뀐 저자소개는 한빛미디어 홈페이지에서 즐겁게(?) 감상하실 수 있습니다.
그리고 그보단 덜(?) 중요하지만.... 1쇄에서 있던 오타와 잘못된 내용을 수정하였습니다. 1쇄 정오표는 제 블로그에 이미 올려두었습니다.
자.. 제 사진을 집에 고이 소장하시고 싶으신분들은 2쇄도 한권 씩 사주시면 됩니다.. 그럼 3쇄에는 누드사진을 실을지도.. 쿨럭쿨럭 -_-
2013년 5월 20일 월요일
1080P 이상의 디스플레이...
오늘 공원벤치에서 비맞으며 앉아있다가 한 생각...
드디어 제임스 카메론 아저씨의 아바타 영화를 봤다. (DVD로..)... 꽤 괜찮은 영화였는데... DVD화질을 1080P 디스플레이에서 보니 별로더라.. DVD는 480P지 아마..? 이제 사람들이 1080P 영상을 하도봐버릇 해서 DVD 품질이 구려보이는 현상.. 흑 -_-;; 심지어는 유튜브 비디오가 DVD보다 품질이 좋아보인다...
그럼 이젠 무슨 일이 일어날까? 1080P이상의 디스플레이가 필요할까?... 한동안 사람의 눈은 수백만개 픽셀 이상을 보지 못하므로 1080P 을 넘는 디스플레이는 쓸모없다고 믿는게 통설이었던거 같다..(1080P는 대략 2백만 픽셀이 나온다)... 하지만 사람의 눈의 그보다 많은 픽셀을 볼수 있단다.. 대략 6억화소... -_-; 그럼 당연히 1080P 이상이 필요하겠지...
그렇다면 어느날 TV가 이정도 이상의 픽셀을 지원하겠지..? 그럼 여기서 TV의 해상도를 더이상 높이지 않아도 될까...? 음.. 그건 아니라고 생각한다..인간의 눈이 한계가 아니라... 제조비용이 높아지는게 한계일듯 하다. 계산의 편의를 위해 인간의 눈이 대략 10억개의 픽셀을 볼수 있다고 해보자.. 그러면 40억개 픽셀이 달린 TV가 있다면... 인간의 눈의 4개의 픽셀을 하나로 인지할 것이다. 즉 4개의 픽셀을 혼합해서 하나로 만든것과 마찬가지 결과... 어... 그럼 이건 말그대로 4x 슈퍼샘플링 안티앨리어싱(SSAA)이 아닌가...? 160억개 화소면 16x 슈퍼샘플링 SSAA고... 이.. 이거 신나는걸? -_-;
하지만 앞에서도 말했듯이 픽셀을 더 추가하는게 너무 비싸질 지도 모른다... 하지만 LED가격이 계속 떨어지고 있고 LED의 소비전력도 매년 낮아지는 추세니.. 이건 문제가 아닐지도 모른다... 오히려 물리법칙의 한계상 더이상 픽셀을 추가하지 못하는 현상이 생기진 않을까? 싱글코어 CPU를 더이상 빠르게 만들지 못하게 된것 처럼....? 그럴지도.. 하지만 일단 6억픽셀부터 따라잡으려면 시간이 좀 걸릴거 같다 -_-;
2013년 5월 16일 목요일
난 왜 아직도 직장인인가...?
사실 난 게임개발을 직장인으로 먼저 시작한 놈이 아니다. 물론 내가 시작할때는 누군가를 채용할수 있는 게임제작회사란 존재자체가 거의 없었기에 창업을 꿈꾸는게 당연했다. 그리고 내 성향상 내 스스로 이루는걸 되게 좋아하는 성격이라... 자기 팀/회사를 성공적으로 키워나가는거에 꽤나 만족을 느끼는 스타일이다...
뭐 근데 그일은 어찌저찌 안되었고.... 잠시 법대로 외도한 뒤 캐나다 이민오면서 다시 게임쪽으로 돌아가기로 맘먹은건데... 그때는 일단 정착도 해야하고 해서 당연히 직장에 들어가겠단 생각을 했다. 그렇다면 난 대체 무슨 목표를 가지고 직장인을 시작한건가... 물론 난 이 일이 재밌어서 한다... 하지만 자신만의 것을 이르켜 세우는 것보단 직장인이 재미없는건 사실.. 따라서 직장인이 되는걸 합리화할만한 개인적인 목표가 필요했던 거 같다....
지금 생각해보니 내겐 크게 2가지 목표가 있었던 듯.....
1) 뛰어난 게임개발자로 인정받자 = 연봉 여섯자리 이상
난 남에게 인정받는걸 되게 좋아한다. 하지만 나 스스로를 판단하는 기준이 좀 엄격한 편이여서 "나 정말 실력 좋다." 나서서 말하지 못한 채 몇년을 허비(?)했다. 그러는 동안 수많은 개발자들을 만나보고 일해보면서 나를 다른사람에게 비교한 뒤에야... "아.. 내 실력이 꽤 좋은거구나.."라고 알게 되었다. (솔직히 좀 씁쓸했다) 아직도 내 스스로 날 판단할테는 "그냥 프로그래밍 하는 놈이지.."라고 생각한다. 남하고 비교할때만 자뻑이 되는거지... -_-... 그래도 웃긴건(아니면 다행인건?)...... 입바른 말 잘하기로 유명한 동료들이 그걸 인정한다는 것.. (물론 내자랑..)
하지만 이건 어디까지나 주관적인 판단일거다.. 난 사실 객관적인 지표로 실력을 인정받고 싶었다. 그게 바로 연봉... 난 자본주의 시장에선 몸값 = 실력이라 생각한다. 실력이 좋으면 당연히 돈도 많이 받아야하고.... 실력이 안좋으면 당연히 적게 받는다 생각.....물론 이상한 짓해서 몸값만 올리는 애들도 몇 봤지만 결국 걔네들은 몇년지나면 밑천 보여서 아무데도 못가더라...
내가 '이정도면 충분히 인정받은걸거야....'라고 목표로 정했던 연봉이 여섯자리 숫자, 즉 $100,000 이상이었는데.... 이 목표는 사실 이미 몇년전에 성취했다...... 고로 지금은 그냥 허무하고 밋밋한 느낌....
2) 언젠가 큰일을 벌일 동료들은 만나자.
두번째는 언젠가 기회가 되면 의기투합해서 큰일을 벌일 동료들을 만나는 것이었다. 주변을 둘러보면 최소한 한손에 꼽을만한 사람들은 이제 있는거 같다. 내가 사실 실력 좋다고 인정하는 프로그래머들이 매우 적은데.. 이 친구중에 몇명은 정말 내가 인정하는 사람들.. 그리고 삶을 바라보는 자세도 나와 비슷해서... 뭔가 같이 하면 매우 재밌을거 같다.
그리고 이건 지난 몇년간 계속 하고 있는 생각...
그럼 왜 나는 아직도 직장생활을 하고 있는걸까...? 아쉬운게 하나 있다면 정식으로 리드명함 달고 팀을 리드 못해본 것이다. 명함없이 리드는 해봤다. 리드 밑의 위치였는데.. 사실 사람들이 날 리드로 따른 경우... 그 뒤에 그 동료들이 날 리드로 원해서 거의 될뻔하다가 팀이 접히면서 다들 퇴사한 케이스... 리드는 정말 잘할 자신 있는데 그 뒤로 회사를 한 두번 옮겨다니면서 전혀 stranger들과 일하게 되니 아직도 리드를 하고 싶은지는 모르겠다. 난 내가 아끼는 팀원들을 이 끌때 보람을 느끼지... 빈 껍데기뿐인 리드 타이틀은 달고 싶지 않거든...
뭐 근데 그일은 어찌저찌 안되었고.... 잠시 법대로 외도한 뒤 캐나다 이민오면서 다시 게임쪽으로 돌아가기로 맘먹은건데... 그때는 일단 정착도 해야하고 해서 당연히 직장에 들어가겠단 생각을 했다. 그렇다면 난 대체 무슨 목표를 가지고 직장인을 시작한건가... 물론 난 이 일이 재밌어서 한다... 하지만 자신만의 것을 이르켜 세우는 것보단 직장인이 재미없는건 사실.. 따라서 직장인이 되는걸 합리화할만한 개인적인 목표가 필요했던 거 같다....
지금 생각해보니 내겐 크게 2가지 목표가 있었던 듯.....
1) 뛰어난 게임개발자로 인정받자 = 연봉 여섯자리 이상
난 남에게 인정받는걸 되게 좋아한다. 하지만 나 스스로를 판단하는 기준이 좀 엄격한 편이여서 "나 정말 실력 좋다." 나서서 말하지 못한 채 몇년을 허비(?)했다. 그러는 동안 수많은 개발자들을 만나보고 일해보면서 나를 다른사람에게 비교한 뒤에야... "아.. 내 실력이 꽤 좋은거구나.."라고 알게 되었다. (솔직히 좀 씁쓸했다) 아직도 내 스스로 날 판단할테는 "그냥 프로그래밍 하는 놈이지.."라고 생각한다. 남하고 비교할때만 자뻑이 되는거지... -_-... 그래도 웃긴건(아니면 다행인건?)...... 입바른 말 잘하기로 유명한 동료들이 그걸 인정한다는 것.. (물론 내자랑..)
하지만 이건 어디까지나 주관적인 판단일거다.. 난 사실 객관적인 지표로 실력을 인정받고 싶었다. 그게 바로 연봉... 난 자본주의 시장에선 몸값 = 실력이라 생각한다. 실력이 좋으면 당연히 돈도 많이 받아야하고.... 실력이 안좋으면 당연히 적게 받는다 생각.....물론 이상한 짓해서 몸값만 올리는 애들도 몇 봤지만 결국 걔네들은 몇년지나면 밑천 보여서 아무데도 못가더라...
내가 '이정도면 충분히 인정받은걸거야....'라고 목표로 정했던 연봉이 여섯자리 숫자, 즉 $100,000 이상이었는데.... 이 목표는 사실 이미 몇년전에 성취했다...... 고로 지금은 그냥 허무하고 밋밋한 느낌....
2) 언젠가 큰일을 벌일 동료들은 만나자.
두번째는 언젠가 기회가 되면 의기투합해서 큰일을 벌일 동료들을 만나는 것이었다. 주변을 둘러보면 최소한 한손에 꼽을만한 사람들은 이제 있는거 같다. 내가 사실 실력 좋다고 인정하는 프로그래머들이 매우 적은데.. 이 친구중에 몇명은 정말 내가 인정하는 사람들.. 그리고 삶을 바라보는 자세도 나와 비슷해서... 뭔가 같이 하면 매우 재밌을거 같다.
그리고 이건 지난 몇년간 계속 하고 있는 생각...
그럼 왜 나는 아직도 직장생활을 하고 있는걸까...? 아쉬운게 하나 있다면 정식으로 리드명함 달고 팀을 리드 못해본 것이다. 명함없이 리드는 해봤다. 리드 밑의 위치였는데.. 사실 사람들이 날 리드로 따른 경우... 그 뒤에 그 동료들이 날 리드로 원해서 거의 될뻔하다가 팀이 접히면서 다들 퇴사한 케이스... 리드는 정말 잘할 자신 있는데 그 뒤로 회사를 한 두번 옮겨다니면서 전혀 stranger들과 일하게 되니 아직도 리드를 하고 싶은지는 모르겠다. 난 내가 아끼는 팀원들을 이 끌때 보람을 느끼지... 빈 껍데기뿐인 리드 타이틀은 달고 싶지 않거든...
2013년 5월 15일 수요일
이젠 모발 게임만이 살길이다?
작년에는 한동안 콘솔게임이 죽네 마네 이야기가 많더니.. 올해는 온라인게임이 죽네마네 하는 이야기가 많다... 난 아직도 이 두 분야가 죽었다고 생각하지도 곧 죽을거라고 생각하지 않는다... 단, 시장이 바뀌지 않았단 이야긴 아니다....
게임이란건 어차피 게이머를 따라 가기 마련이다.. 그런면에서 예전에 비해 콘솔게임시장... 그리고 온라인 게임시장의 규모(게이머의 수)가 작아진건 맞다. 그래서 그만큼 온라인게임/콘솔게임시장에서 살아남기가 힘들어졌다. 시장이 좁아져도 여전히 살아남는건 top player들... 즉... AAA 게임들이다... 좀 괜찮거나.. 운이 억수로 좋은 AA게임들도 일부 살아남을거다.. AAA게임이 여전히 살아남는 이유는 그런 게임들을 원하는 코어게이머들이 언제나 존재하고.. 그들의 욕구를 충족시키기 위해서는 콘솔과 PC 정도의 성능이 있어야 하기 때문이다. 모발의 성능이 계속 발전중이어서 콘솔이 결국 필요없을거라 말하는 사람들이 있다... 개인적으론 말도 안되는 이야기라 생각한다... 단순히 물리학적으로 생각해도 배터리 꼽고 돌리는 기계의 성능이 전선 꼽고 돌리는 기계의 성능을 앞지를수는 없다. 콘솔과 PC 하드웨어도 계속 발전하다. 그리고 코어 게이머들의 기대치도 그만큼 발전한다.
인터넷이 없던 시절을 기억하는가..? 우린 인터넷 없이 아무문제 없이 잘 살았다... 근데 이미 인터넷을 맛본이상 더이상 이거 없인 못지낸다. 사람의 기대치는 계속 높아지기 마련이다... 코어게이머들의 기대치도 마찬가지이다.
결국 AAA게임들은 콘솔/온라인 시장에서 살아남는다.(뭔가 크게 말아먹지 않는이상)... 그럼 요즘 많은 게임회사들이 콘솔 및 온라인 시장이 죽었다고 이 분야를 아예 포기한다고 하는 건 무슨 이유일까...?
이건 스스로가 AAA게임 제작사가 아님을 인정하는게 아닌가 한다. 자기가 AAA 제작사가 아니라 이 시장의 경쟁에서 살아남기 힘드니... 좀더 넓어진 시장으로 옮기겠다는 거다... 현명한 판단이다. 하지만 자사의 생존을 위해 사업방향을 바꾸는걸 합리화시키기 위해 시장 자체가 죽었다는 등의 변명은 대지 않았으면 좋겠다. 내가 여기서 하는 말은 아예 콘솔 및 온라인 사업을 접는 회사들을 향한 말이다. 기존 사업을 유지하면서 새로운 분야를 개척하는 건 아주 현명한 방법이라 생각한다.
또다른 이유는 상장된 회사의 경우는 주가 유지 및 상승이 그 무엇보다도 중요하기 때문이다. 결국 투자자들이 "이건 돈 벌 기회다!"라고 생각하는 떡밥들을 던져줘야 한다는건데... 그럴려면 모발이나 소셜이 먹힌다는거지...
결코 난 모발 게임을 얕보지 않는다. 나 스스로도 코어게이머보다는 캐주얼 게이머에 가깝기에 오히려 모발 게임을 더 선호한다. 그냥 기존 콘솔/온라인 게임회사들이 모발로 완전히 전향하면서 대는 핑계들에 좀 질려서 글 쓰는것 뿐.... 이렇게 핑계만 대는 회사보다는 차라리 첨부터 모바일로 시작한 회사들이 더 경쟁력이 있다고 본다.
뭐든간에 콘솔 및 PC 온라인 게임시장은 죽지 않았고.. 죽지도 않을거라 생각한다.. 단 줄어든 고객수를 잡기위한 경쟁이 더 치열해질 뿐이고... 살아남는 게임은 여전히 살아남을거다. 그게 바로 시장경제 아닌가..? (이건 나보단 레아형이 더 잘 설명할만한 철학적인 내용인가..?)
어차피 게임도 소비자를 즐겁게 만들어줘야 돈을 버는 엔터테인먼트 산업... 다른 엔터테인먼트 산업과 비교해보면 대충 답이 나온다... 영화도 수백만불 들인 블럭버스터는 1년에 몇개밖에 개봉안한다.. 나머진 그냥 저예산이지만 스토리가 감동적이고 재밌는 로맨틱 코메디다... 음악도 마찬가지다... 수억씩 들여 제작하고 온갖 오케스트라 동원해서 만든 음악도 극히 일부다... 나머진 그냥 듣기 좋은 음악이다... 그들이 모두 돈을 버는가? 블럭버스터들은 대부분 버는거 같다.. 그외의 것들은 제작비 얼마 들였는지에 따라 다르다....
콘솔과 온라인은 블럭버스터... 모발은 기발한 로맨틱 코메디.. 라고 보는 내가 이상한건가...?
2013년 5월 11일 토요일
포워드 렌더링으로 컴백
사실 예전에 '포워드 렌더링을 다시 고려하는 이유'라는 글을 쓰다가 완성을 못한적이 있었다... 뭐 당연히 다들 아는 그런 이야기들인데..
다시 포워드 렌더링으로 돌아왔다.. 돌아오니 디퍼드 렌더링에서 아주 속썩었던 부분들이 해결되서 참 맘에 든다.. 하지만 또 이렇게 오래 포워드쓰다보면 다시 디퍼드가 그리워지겠지...
하지만 뭐든간에 실시간으로 처리할수 있는 그래픽효과는 한계가 있다... 동적으로 변하는것이 많지 않은 게임이라면 오프라인으로 라이트맵으로 베이크 하는게 최고고... 그러면 굳이 디퍼드가 필요없고.. 그럼 포워드 하면서 하드웨어 앤티애일리어싱 써주면 아주 행복 ^_^
하지만 그럼에도 동적그림자가 필요한 부분이 있으니 샤도우맵을 만들어야 하지만.. 현재 만드는 게임 - FIFA - 는 동적 그림자를 드리워야 할 놈들이 딱 정해져 있으므로 보다 generic하게 만들 필요가 없어서 그림자의 품질 유지가 가능함.. (물론 거기에 PCF니 뭐니 해야하지만...)
생각해보니 처음으로 60FPS로 도는 게임을 만드는거 같다..... 여태까진 디퍼드에 포스트 이펙트 팍팍 넣어서 30FPS로 겨우 돌렸음.. 60 FPS는 사실 게임반응속도가 높아 좋은거고... 화면에 그리는 픽셀수가 많을수록 화면 품질은 좋아지는듯.. 특히 최소한 1080p는 뽑아줘야 하지 않나.. 60 FPS에 1080P.. 추릅...
다시 포워드 렌더링으로 돌아왔다.. 돌아오니 디퍼드 렌더링에서 아주 속썩었던 부분들이 해결되서 참 맘에 든다.. 하지만 또 이렇게 오래 포워드쓰다보면 다시 디퍼드가 그리워지겠지...
하지만 뭐든간에 실시간으로 처리할수 있는 그래픽효과는 한계가 있다... 동적으로 변하는것이 많지 않은 게임이라면 오프라인으로 라이트맵으로 베이크 하는게 최고고... 그러면 굳이 디퍼드가 필요없고.. 그럼 포워드 하면서 하드웨어 앤티애일리어싱 써주면 아주 행복 ^_^
하지만 그럼에도 동적그림자가 필요한 부분이 있으니 샤도우맵을 만들어야 하지만.. 현재 만드는 게임 - FIFA - 는 동적 그림자를 드리워야 할 놈들이 딱 정해져 있으므로 보다 generic하게 만들 필요가 없어서 그림자의 품질 유지가 가능함.. (물론 거기에 PCF니 뭐니 해야하지만...)
생각해보니 처음으로 60FPS로 도는 게임을 만드는거 같다..... 여태까진 디퍼드에 포스트 이펙트 팍팍 넣어서 30FPS로 겨우 돌렸음.. 60 FPS는 사실 게임반응속도가 높아 좋은거고... 화면에 그리는 픽셀수가 많을수록 화면 품질은 좋아지는듯.. 특히 최소한 1080p는 뽑아줘야 하지 않나.. 60 FPS에 1080P.. 추릅...
그때를 기억하는가? [1]
난 그때를 기억하는가...?
반대하시는 부모님에게 성공해서 인정받겠다고 남는시간을 쪼개고 쪼개.. 그리고 밤을 새워가며... 게임을 기획하고 프로그래밍 하던 그 시절을...
하지만 공부를 등한시하면 자기 본분도 안한채 헛꿈만 꾸는 인간 취급을 받을 거 같아.. 공부와 게임제작을 제외한 다른걸 다 포기했던 그시절... 참 빡샜는데.. 가장 열정적이고 즐거웠던 시절임은 분명하다....
내 젊은시절은 뜨거운 피는 아직도 내 몸속을 휘젓고 다니고 있다.. 난 어차피 뭐든간에 적당히 하는걸 모르는 인간... 아니... 첫 게임팀을 말아먹고 나서... 그뒤에 쓸데없이 세상비관만 하며 몇년 지내니... 차라리 빡센게 낫다는 판단을 한거지...
난 차라리 올인하고... 그 올인이 너무 길어져 힘들면 잠시 다 벗어던지고 올아웃(all-out)한 뒤 쉬다가 다시 돌아오는게 내 적성이다....
그래서 난 그때를 기억하는가...? 지금 날 뜨겁게 불타오르게 하는 건 무엇인가?
반대하시는 부모님에게 성공해서 인정받겠다고 남는시간을 쪼개고 쪼개.. 그리고 밤을 새워가며... 게임을 기획하고 프로그래밍 하던 그 시절을...
하지만 공부를 등한시하면 자기 본분도 안한채 헛꿈만 꾸는 인간 취급을 받을 거 같아.. 공부와 게임제작을 제외한 다른걸 다 포기했던 그시절... 참 빡샜는데.. 가장 열정적이고 즐거웠던 시절임은 분명하다....
내 젊은시절은 뜨거운 피는 아직도 내 몸속을 휘젓고 다니고 있다.. 난 어차피 뭐든간에 적당히 하는걸 모르는 인간... 아니... 첫 게임팀을 말아먹고 나서... 그뒤에 쓸데없이 세상비관만 하며 몇년 지내니... 차라리 빡센게 낫다는 판단을 한거지...
난 차라리 올인하고... 그 올인이 너무 길어져 힘들면 잠시 다 벗어던지고 올아웃(all-out)한 뒤 쉬다가 다시 돌아오는게 내 적성이다....
그래서 난 그때를 기억하는가...? 지금 날 뜨겁게 불타오르게 하는 건 무엇인가?
2013년 5월 6일 월요일
캐나다 밴쿠버에서 가장 좋아하는 Barnett Marine 공원
세입자가 빠질때까지 잠시 살게 된 집이 다행히도 제가 밴쿠버에서 가장 좋아하는 Barnett Marine공원 근처에 있습니다. (한 10분 거리..) 그래서 오늘 기분도 우울해서 함 가봤답니다. 몬트리올에서 돌아온 뒤 첨 가보는 거군요...
제가 이곳을 좋아하는 이유는 바다와 산과 잔디가 만나는 곳이기 때문입니다. 아래 두 사진만 봐도 무슨 의민지 알수 있으실 겁니다.
하지만 여기를 다른 사람들이 즐기는 이유는 그 뿐만이 아닙니다. 여긴 사실 BBQ하기 좋은 곳으로 유명해서 오늘같이 날 좋은 주말이면 바베큐하는 사람들이 넘쳐납니다.
하지만 땅덩어리가 넓은 곳이라 젤 위에 보여드린 사진처럼.... 바베큐하는 곳에서 5분만 걸어가면 한적한 곳이 아주 많습니다.
그리고 게잡이도 가능합니다. 단 BC주에서는 게잡이나 낚시를 하려면 정부로부터 라이센스를 사야 합니다. 아마 야생 동물의 개체수를 보존하고자 하는 정책인거 같습니다. 그리 비싸진 않은걸로 알고 있는데 라이센스 하나 가지고 있으면 한번 낚시 나갈때 게는 4마리인가까지 잡아올 수 있습니다. 단 크기가 반드시 어느정도 이상되는 게여야 하고 암컷은 잡아가면 안됩니다. 역시 개체수 보존이 목적이겠죠.
다음은 중간에 걷다가 잠시 앉아서 쉬며 찍은 사진 입니다. 경치하고 인물(?)이 참 이쁘군요 -_-
그리고 그외의 기타등등 사진..... (절대 게을러서 대충 쓰는게.. 아닙니... 아냐아냐.. 그거일지도 -_-)
이렇게 한시간 놀다가... 집에오는길에 동네 근처의 이탈리아 레스토랑에 들려 제가 가장 좋아하는 Stanley Park Amber Ale을 한잔 했습니다... 올리브도 먹어보라고 한그릇 공짜로 주던데... 녹색중에서도 색이 좀 진한 녹색이 젤 맛있더라구요... '_'
그리고 졸 놀라운 놈을 발견했습니다.... 와인 따르는 기계 -_-; 저 냉장고에 와인에 최적인 온도로 맞춰주고... 저 LED들어온곳 밑에보면 1oz, 5oz, 8oz라는 버튼이 있습니다. 저걸 누르면 와인을 냉장고에서 꺼낼 필요없이 알아서 따라주는.. 놀라운 놈 '_'
제가 이곳을 좋아하는 이유는 바다와 산과 잔디가 만나는 곳이기 때문입니다. 아래 두 사진만 봐도 무슨 의민지 알수 있으실 겁니다.
 |
| 저 뒤에 저렇게 보트를 타기도 합니다. |
 |
| 저 멀리 뒤에 눈덮인 산이 보이시나요. 오늘 온도가 영상 26도였지만 저게 엄청 높고 멀리 있는 산이라 눈이 아직도 있습니다. (하늘이 맑아서 끝없이 보이는 것뿐입니다. -_-) |
하지만 여기를 다른 사람들이 즐기는 이유는 그 뿐만이 아닙니다. 여긴 사실 BBQ하기 좋은 곳으로 유명해서 오늘같이 날 좋은 주말이면 바베큐하는 사람들이 넘쳐납니다.
 |
| 바베큐 하는 사람으로 넘쳐납니다... 이.. 이게 넘쳐나는 겁니다... -_- |
하지만 땅덩어리가 넓은 곳이라 젤 위에 보여드린 사진처럼.... 바베큐하는 곳에서 5분만 걸어가면 한적한 곳이 아주 많습니다.
그리고 게잡이도 가능합니다. 단 BC주에서는 게잡이나 낚시를 하려면 정부로부터 라이센스를 사야 합니다. 아마 야생 동물의 개체수를 보존하고자 하는 정책인거 같습니다. 그리 비싸진 않은걸로 알고 있는데 라이센스 하나 가지고 있으면 한번 낚시 나갈때 게는 4마리인가까지 잡아올 수 있습니다. 단 크기가 반드시 어느정도 이상되는 게여야 하고 암컷은 잡아가면 안됩니다. 역시 개체수 보존이 목적이겠죠.
 |
| 이 집은 꽤 잡았습니다... ㅎㅎ |
다음은 중간에 걷다가 잠시 앉아서 쉬며 찍은 사진 입니다. 경치하고 인물(?)이 참 이쁘군요 -_-
 |
| 우울해서 공원 나가서 음악 들으며 찎은 사진입니다.. -_- |
그리고 다시 걸어서 해변가까지 가면서 몇장 더 찎었습니다...
 |
| 오늘의 과제는 water셰이더를 공부... 쿠.. 쿨럭.. 죄송합니다.. 직업병입니다... |
 |
| HDR Bloom 공부도 더불어.. -_- |
그리고 바닷가에 왔으니 당연히 파도를 찍어야겠죠... -_-
 |
| 역시 전 거만한 표정이 잘 어울립니다... -_- 핥으렴 애들아.... -_-;; |
그리고 그외의 기타등등 사진..... (절대 게을러서 대충 쓰는게.. 아닙니... 아냐아냐.. 그거일지도 -_-)
 |
| 개들 물먹으라고 개 물그릇도 있어요. 저기 떨어지는 물 받아주면 되요. 깨끗합니다. 여긴 사람들도 그냥 수돗물 먹고 살아요... |
 |
| 그리고 걷다보니 왠 마녀가 사는듯한 자국이 -_-;; |
이렇게 한시간 놀다가... 집에오는길에 동네 근처의 이탈리아 레스토랑에 들려 제가 가장 좋아하는 Stanley Park Amber Ale을 한잔 했습니다... 올리브도 먹어보라고 한그릇 공짜로 주던데... 녹색중에서도 색이 좀 진한 녹색이 젤 맛있더라구요... '_'
 |
| 좀 짰지만.. 짙은 녹색 올리브가 젤 맛났음.. 그래도 내가 젤 좋아하는 맥주랑 섞어 마시니 좋았다는 ^_^ |
그리고 졸 놀라운 놈을 발견했습니다.... 와인 따르는 기계 -_-; 저 냉장고에 와인에 최적인 온도로 맞춰주고... 저 LED들어온곳 밑에보면 1oz, 5oz, 8oz라는 버튼이 있습니다. 저걸 누르면 와인을 냉장고에서 꺼낼 필요없이 알아서 따라주는.. 놀라운 놈 '_'
 |
| 먼가 졸라 fancy한 와인 기계.... |
그럼 잘 안하는 짓이지만 이걸로 오랜만의... 캐나다 생활기 블로그 포스팅을 종료 -_-/ 포프였습니다...
 |
| Who wanna sit there with me :)? |
p.s. Galaxy Nexus로 찎은 사진입니다.. DSLR 따위는 키우지 않습니다 -_-;
2013년 4월 16일 화요일
블로그 댓글 다 달았습니다.
이사하느라 새 회사 가느라 .. (그리고 심시티 60시간 하느라.... -_-) 방치해놨던 블로그 답글 달기를 다 마무리 지었습니다. 혹시라도 제가 빼먹은게 있다면 다시 댓글 달아주세요...
앞으로는 큰 일이 없는한... 답글은 늦지 않게 달 예정입니다 -_-/
앞으로는 큰 일이 없는한... 답글은 늦지 않게 달 예정입니다 -_-/
분류
잡담
2013년 3월 20일 수요일
4월초까지 댓글 못답니다.
어제 갑자기 블로그에 질문이 두개가 달렸는데... 현재 북미대륙 동쪽끝에서 서쪽끝으로 이사를 진행중이라... 인터넷도 끊겼고... 4월초까진 댓글을 달 정신이 안됩니다.
4월초에 댓글은 다 달도록 하겠습니다.
보통 댓글은 가능하면 빨리달자 주의인데 이번엔 그러지 못할거 같아 여기에 변명을 남기고 전 이만... 총총총
분류
잡담
2013년 3월 11일 월요일
대충근황.. EA 피파팀으로 옮깁니다
오랜만에 제 블로그에 들어와보고 화들짝 놀랐습니다.. 업뎃이 정말 없었구나 하는 맘에...
일단 몬트리올이 맘에 안들고 좀 문화적으로 사람들과 안맞는것도 있어서 다니던 회사(스퀘어 에닉스/아이도스 몬트리올)를 때려치고 밴쿠버로 어찌 돌아갈까 생각을 하다... EA 스포츠 피파팀에서 받아준다기에 거기로 가기로 했습니다. 이사비용이며 뭐며 다 대준다는군요.. 몬트리올 올때와는 달리 아무 걱정없이 이사할수 있을만큼 이사패키지를 줘서 맘편합니다. 근무는 4월 1일부터 시작합니다.
블로그 업뎃도 늦고.. 레아형의 김레아 TV도 재밌게 보고 있고... 알콜코더님의 게개랩도 꽤 즐겁게 청취했던 사람으로써... Video Blogging을 시작해볼까 합니다.. 하지만 정작 시작은 밴쿠버가서 제대로 제 집으로 다시 입주한 뒤... 10월부터 할지도 모릅니다. (세입자가 이사비 줄테니 나가라는데 좋다/싫다 말 없이 그냥 씹고만 있습니다.) 세입자가 곱게 일찍 나가주면 5~6월부터 할수도 있지만 아니면 10~11월이나 할 생각입니다.
어쨋든 지금은 한 3주 놀며 또 백수짓 하고 있습니다.. '_'
대충 근황끝..
일단 몬트리올이 맘에 안들고 좀 문화적으로 사람들과 안맞는것도 있어서 다니던 회사(스퀘어 에닉스/아이도스 몬트리올)를 때려치고 밴쿠버로 어찌 돌아갈까 생각을 하다... EA 스포츠 피파팀에서 받아준다기에 거기로 가기로 했습니다. 이사비용이며 뭐며 다 대준다는군요.. 몬트리올 올때와는 달리 아무 걱정없이 이사할수 있을만큼 이사패키지를 줘서 맘편합니다. 근무는 4월 1일부터 시작합니다.
블로그 업뎃도 늦고.. 레아형의 김레아 TV도 재밌게 보고 있고... 알콜코더님의 게개랩도 꽤 즐겁게 청취했던 사람으로써... Video Blogging을 시작해볼까 합니다.. 하지만 정작 시작은 밴쿠버가서 제대로 제 집으로 다시 입주한 뒤... 10월부터 할지도 모릅니다. (세입자가 이사비 줄테니 나가라는데 좋다/싫다 말 없이 그냥 씹고만 있습니다.) 세입자가 곱게 일찍 나가주면 5~6월부터 할수도 있지만 아니면 10~11월이나 할 생각입니다.
어쨋든 지금은 한 3주 놀며 또 백수짓 하고 있습니다.. '_'
대충 근황끝..
분류
잡담
2013년 1월 17일 목요일
[또자랑] 제 셰이더 서적에 대한 너무나 좋은 평
제 블로그의 셰이더 입문강좌 페이지에 실린 댓글입니다. 이 댓글 받고 나서... '아, 책 쓴 보람이 있구나.' 생각이 들어.. 또 제자랑겸 여기다도 올립니다. 이런 기회를 제가 놓칠리가 없죠 -_-;
----------------------------------------------------------------------------------------
정헌 2013년 1월 14일 오후 11:00
안녕하세요~ 다시 와보니 바로 윗글에 글 남긴 사람이네요 ㅎㅎㅎ
Appendix A 까지 다 보고 코드로 적용해본다음 후기 올리려 왔답니다
지금으로부터 한.. 7일 전, 처음 이 책을 서점에서 목차를 봤던 기억이 나네요 ㅎㅎ
처음엔 그냥 셰이더 책 또 하나 나왔구나 라고 생각을 하고 지나쳤더랬죠
그런데 저 개인적으로 프로젝트를 진행하던 중이였습니다, 그동안 수학,물리를 공부해서
실질적으로 뭔가 보려고 했지만, 막상 시간이 지나다보니 셰이더를 넣어야겠다는 생각에
봉착하게 됐습니다, 그런데 2,3년 전 셰이더를 본적이 있긴 하지만 다시 시작해볼려고
하니깐 막상 주변엔 셰이더 관련 책이 있긴 하지만 셰이더 책들 분량이 대부분 많아
다시 보기에도 귀차니즘이 승리할 것 같아 그냥 필요한 부분만 보면서 넘어가자라는 식으로 하려고 했으나 원래 성격이 그렇지 못한지라 결국 다른 방법이 없을까 생각을 했죠
생각을 하던중 셰이더 프로그래밍 입문 책의 목차가 머리속에 사~~악 지나가더군요,
그때 드는 생각이 그래! 이거다! 라는 생각이 들어 바로 서점으로 튀어가서
한권 구입했더랬죠 ㅎㅎ
처음엔 챕터8 정도까지만 본 다음 다시 본래 프로젝트로 돌아가려 했지만
8 장을 vs로 코딩하던 중 드는 생각이
"어.. 이 책 뭔가 다르다" 는 생각이 들게 되더군요
처음 해본다면 오랜 시간 투자해야되는 여러가지 DX 설정들과 셰이더와의 상호
상태와 값과 그 의미들이 간단 명료하고 잘 연결 되어있다는 느낌을 받게 되더군요
결국 한챕터 더 보까? 더보까? 더 보까? 하다가 끝까지 보게 됐습니다
인터넷 뒤져가며 두꺼운 셰이더 책 뒤져가며 찾아 설정해야 되는 것들에 대한 시간
절약과 셰이더 소스코드들의 간략하면서도 이해가 잘가는 설명은
처음 앞뒤 뭐 대락 소개나 이런 저런것 빼면 2백 50~60 페이지 정도 되는 분량이
좀 적은거 아닌가? 조금 비싼거 아닌가? 라는 생각을 완전히 뒤바꿔 주더군요
기본적인 탄탄한 노하우가 담겨져 있는 책이라는 느낌이 들었습니다
게임관련 많은책을 보긴했지만 이렇게 직접 사이트에 찾아와 후기를 남기는건 처음이네요
또 질문 하나 하고싶어서 글을 남기기도 한건데요
Q:
대부분 프로그래머는 자신이 익힌 것을 잘 공개하려는 마인드를 갖고 있진 않다고
생각 하곤 합니다, 그런데..
사이트에 보면 이 책의 일부 챕터가 올라와있는것도 볼 수 있고 책 또한 기본적인
내용들을 담았다곤 했다고 하셨지만 노하우가 많이 묻어나온 책이라는걸 느낄 수가
있었습니다, 책을 보면서 이렇게 까지 이 한권의 책으로 도움을 받아도 되나
라는 생각을 하게 되었는데요, 왜 이리 적지 않은 부분을 공개한것인지 궁금하네요 ㅎㅎ
p.s 렌더몽키를 소스코드로 옮기는 과정은 감탄이 나오더군요 ㅎㅎ
스승으로 모셔도 될까요?? ㅎㅎㅎㅎ
2013년 1월 10일 목요일
Subversion에서 Private Depot 사용하기(Mercurial을 이용)
Private Depot 얼마나 오랫동안 꿈꾸어 오던 것인지... -_-;
SVN과 같이 중앙 public depot을 사용하면 잘못된 코드를 체크인 했을때 그 때문에 피해를 입는 사람이 많다. 고로 제대로 작동안하는 코드를 집어넣으면 졸 욕을 쳐먹는다 -_-;
그래서 보통 코드가 제대로 돈다고 확인할때까지, 또는 코드를 보기 좋게 잘 다듬을 때까지 check-in을 안하곤 한다..... 이것의 문제는 한 1주일정도 체크인 없이 로컬 컴퓨터에서 계속 작업하는 경우가 있는데.. 그러다가 어느순간...
'아... 3일전에 만들어놨다가 제대로 안돌아서 지워버린 코드를 다시 쓰고 싶은데...'
라는 후회가 드는 경우가 있다는 것.... 이걸 미리 체크인 해놓았다면 단순히 버전 되돌리는 걸로 끝날 일... 중앙 depot시스템 때문에 못한거지... 퉤... - _-;
그래서 git이나 mercurial(hg)등의 DVCS (Distributed Version Control System)이 나름 각광을 받고 있었다. 하지만 게임개발을 하는 나에게 중앙서버가 없는 중구난방식의 분산 방식은 좀 별로였다. 내가 원한 것은 완전한 분산방식이 아니라.... 개인(private) depot에는 아무때나 내 맘대로 체크인 해놓고..... 나중에 준비가 되면 여태까지 해왔던 일들을 한번에 중앙 서버에 집어넣는 거였다. 한마디로 매일밤
"오늘까지 한 일. 어쩌구 저쩌구... 현재 컴파일은 안됨 ㅋㅋ"
이라는 commit log를 작성하고 싶었다고나 할까....
Perforce에서는 perforce sandbox를 사용하여 이 문제를 해결했었다. 하지만 Subversion을 사용할 때는 마땅히 어떻게 할 방법이 없었다. git-svn이라던가 hg-svn 등의 놈들이 있지만 이렇게 그다지 믿음이 가지 않았다. 난 모든간에 단순하고 간단한걸 좋아해서 이렇게 두가지 기능을 대충 합치는 프로그램을 안좋아한다. 사용하다가 말도 안되는 곳에 문제가 생겨서 골치만 아픈 경우가 너무 많거든...
하드디스크에 체크아웃 해둔 SVN 루트 디렉토리에 git이나 mercurial을 local depot를 만드는 법도 한 때 생각해봤으나.. 각 폴더마다 들어가 있던 .svn 폴더때문에 그것도 쉽지 않았다... 그래서 한동안 손을 들고 있었으나... 이게 왠일 SVN 1.7부터 폴더 구조가 바뀌었다. 이젠 루트폴더에 .svn폴더 하나만 넣는다.
이거 때문에 신나서 재빨리 시도해보았다.. 잘된다.. ㅠ_ㅠ
방법은 간단... 난 mercurial(HG)를 사용했다. 윈도우즈에서 git 쓸려면 SSH 설치며 뭐며 머리가 졸라 아픈데.. mercurial은 그냥 TortoiseHg만 깔면 된다.. 다른거 신경쓸거 하나도 없다...
SVN과 같이 중앙 public depot을 사용하면 잘못된 코드를 체크인 했을때 그 때문에 피해를 입는 사람이 많다. 고로 제대로 작동안하는 코드를 집어넣으면 졸 욕을 쳐먹는다 -_-;
그래서 보통 코드가 제대로 돈다고 확인할때까지, 또는 코드를 보기 좋게 잘 다듬을 때까지 check-in을 안하곤 한다..... 이것의 문제는 한 1주일정도 체크인 없이 로컬 컴퓨터에서 계속 작업하는 경우가 있는데.. 그러다가 어느순간...
'아... 3일전에 만들어놨다가 제대로 안돌아서 지워버린 코드를 다시 쓰고 싶은데...'
라는 후회가 드는 경우가 있다는 것.... 이걸 미리 체크인 해놓았다면 단순히 버전 되돌리는 걸로 끝날 일... 중앙 depot시스템 때문에 못한거지... 퉤... - _-;
그래서 git이나 mercurial(hg)등의 DVCS (Distributed Version Control System)이 나름 각광을 받고 있었다. 하지만 게임개발을 하는 나에게 중앙서버가 없는 중구난방식의 분산 방식은 좀 별로였다. 내가 원한 것은 완전한 분산방식이 아니라.... 개인(private) depot에는 아무때나 내 맘대로 체크인 해놓고..... 나중에 준비가 되면 여태까지 해왔던 일들을 한번에 중앙 서버에 집어넣는 거였다. 한마디로 매일밤
"오늘까지 한 일. 어쩌구 저쩌구... 현재 컴파일은 안됨 ㅋㅋ"
이라는 commit log를 작성하고 싶었다고나 할까....
Perforce에서는 perforce sandbox를 사용하여 이 문제를 해결했었다. 하지만 Subversion을 사용할 때는 마땅히 어떻게 할 방법이 없었다. git-svn이라던가 hg-svn 등의 놈들이 있지만 이렇게 그다지 믿음이 가지 않았다. 난 모든간에 단순하고 간단한걸 좋아해서 이렇게 두가지 기능을 대충 합치는 프로그램을 안좋아한다. 사용하다가 말도 안되는 곳에 문제가 생겨서 골치만 아픈 경우가 너무 많거든...
하드디스크에 체크아웃 해둔 SVN 루트 디렉토리에 git이나 mercurial을 local depot를 만드는 법도 한 때 생각해봤으나.. 각 폴더마다 들어가 있던 .svn 폴더때문에 그것도 쉽지 않았다... 그래서 한동안 손을 들고 있었으나... 이게 왠일 SVN 1.7부터 폴더 구조가 바뀌었다. 이젠 루트폴더에 .svn폴더 하나만 넣는다.
이거 때문에 신나서 재빨리 시도해보았다.. 잘된다.. ㅠ_ㅠ
방법은 간단... 난 mercurial(HG)를 사용했다. 윈도우즈에서 git 쓸려면 SSH 설치며 뭐며 머리가 졸라 아픈데.. mercurial은 그냥 TortoiseHg만 깔면 된다.. 다른거 신경쓸거 하나도 없다...
모든간에 졸 간단한 방법:
- SVN checkout이 되어있는 root folder로 간다. SVN 버전이 1.7 미만이라면 1.7이상으로 업글한 뒤 현재 checkout 되어있는 소스트리를 최신버전으로 업데이트 해줘야 한다.
- 빈공간에 오른쪽 버튼을 누르고 TortoiseHg > Create Repository Here를 해준다.
- Init 대화창이 나오면. 뭐 다른 거 손 볼 필요 없다. 그냥 Create를 눌러준다.
- 이제 모든 파일이 제대로 보인다....
- 이제 private depot에 체크인 할때는 Hg Commit을... 중앙 depot에 체크인할때는 SVN Commit을 해주면 된다.
아, 정말 단순하고.. 깔끔한 방법이다.... 맘에 들어.. ㅠ_ㅠ
이 방법의 단점은 mercurial로 private depot에 체크인 했던 것은 changelist description을 자동으로 복사해올 방법이 없다는건데... 음.... 난 차라리 이 방법이 낫다. 매일 일하며 체크인 해 놨던 내용들을 쭈욱 살펴보면서 요약해서 적을 수 있으니까. 중앙서버까지 mercurial로 만들어 놓으면 local depot에 체크인 했던 changelist들이 전부다 개별적으로 submit된다. 맘에 안든다.... 뭐 collapse 익스텐션을 쓰면 이것도 해결 된다지만.. 역시 기본기능이 아닌 건 사람들이 그닥 많이 사용안하니 제대로 검증되지 않아서... 골치아픈 일이 많기 마련.... 따라서 extension은 그닥 쓰고 싶지 않아.....
어쨌든 이 방법 좋다... 만세~
2013년 1월 7일 월요일
XNA의 몰락. 그리고 대안
XNA가 처음 나왔을 때부터 열심히 사용했었다. 첨에는 PC와 Xbox 360용으로 돌 수 있는 게임을 만들 수 있다는게 맘에 들어서였고, 또 Xbox 360에 올리면 수익모델이 있다는 것도 맘에 들었었다. 하지만 불행히도 엑박에서 XNA 게임이 차지하는 비중이 매우 미미한 수준에서 그친 이후 XNA는 여러번 변화를 겪게 된다. XNA 4.0부터던가... 윈폰 7.0용으로 게임을 만들려면 XNA를 써야 했다. 모바일 플랫폼을 지원하려고 노력을 퍼붓다 보니 당연 PC나 엑박용 지원은 미미해졌고 그로 인해 XNA의 입지가 조금씩 애매해져갔다.
물론 그럼에도 난 XNA를 자주 사용했는데... 스크린 스페이스 데칼 프리젠테이션에 사용한 데모 프로그램도 XNA로 만든 거였다. XNA가 가지고 있는 컨텐츠 파이프라인이라던가 C#으로 쉽게 DirectX 기능을 사용할 수 있다는 사실이 프로토타입을 만드는데는 아주 적합했다고 할까...?
하지만 이제 윈폰 8이 XNA 지원을 중지한다고 한다. 그 대신 WinRT를 사용한다고... Visual Studio 2012도 XNA를 지원하지 않는다.. (뭐 어떻게 사용할 수 있는 꼼수는 있다.) 물론 Visual Studio 2010을 사용하며 XNA 4.0을 계속 사용할 수는 있지만 XNA에는 다음과 같은 제약이 있다.
C#을 지원하는(정확히 말하면 어떤 .NET 언어 라도 지원하는) DirectX 로는 SharpDX와 SlimDX가 있다. 둘다 API도 매우 비슷하고 사용법도 거의 같다. 그리고 둘다 64비트를 지원한다. 최근에 64비트용 프로토타입을 만들 일이 있어서 둘다 사용해봤는데... 사용해본 바로는 SharDX가 SlimDX보다 낫다. 이유는 다음의 2개:
물론 그럼에도 난 XNA를 자주 사용했는데... 스크린 스페이스 데칼 프리젠테이션에 사용한 데모 프로그램도 XNA로 만든 거였다. XNA가 가지고 있는 컨텐츠 파이프라인이라던가 C#으로 쉽게 DirectX 기능을 사용할 수 있다는 사실이 프로토타입을 만드는데는 아주 적합했다고 할까...?
하지만 이제 윈폰 8이 XNA 지원을 중지한다고 한다. 그 대신 WinRT를 사용한다고... Visual Studio 2012도 XNA를 지원하지 않는다.. (뭐 어떻게 사용할 수 있는 꼼수는 있다.) 물론 Visual Studio 2010을 사용하며 XNA 4.0을 계속 사용할 수는 있지만 XNA에는 다음과 같은 제약이 있다.
- 64비트를 지원하지 않음
- DirectX 9기능까지만 지원함. (즉 DX11 기능을 쓸 수가 없음)
이제 대안을 찾을 때... 결국 XNA가 좋았던 이유는 다음의 두가지였다.
- C#지원
- 컨텐츠 파이프라인
그러니 이것만 어떻게 해결할 수 있는 대안을 찾으면 되는게 아닌가...?
C# 지원
C#을 지원하는(정확히 말하면 어떤 .NET 언어 라도 지원하는) DirectX 로는 SharpDX와 SlimDX가 있다. 둘다 API도 매우 비슷하고 사용법도 거의 같다. 그리고 둘다 64비트를 지원한다. 최근에 64비트용 프로토타입을 만들 일이 있어서 둘다 사용해봤는데... 사용해본 바로는 SharDX가 SlimDX보다 낫다. 이유는 다음의 2개:
- SharpDX가 속도가 더 빠름 (API 호출의 부하가 적음)
- SharpDX가 설치가 더 쉬움(그냥 DLL파일만 복사해놓으면 끝)
고로 SharpDX를 사용하면 C# 지원문제는 해결..
컨텐츠 파이프라인
사실 이 부분은 딱히 방법이 안보인다. 아직... 물론 C#자체 또는 SharpDX자체에서 텍스처 파일 로딩기능은 거의 다 구현해놨으니 이건 큰문제가 아닌데... 오디오 라던가 메쉬 같은건 여전히 좀 문제다.
하지만 비주얼 스튜디오 2012에 FBX를 이용하는 예제가 이미 포함되어있고, MS에서 WinRT를 더 제대로 지원하려면 컨텐츠 파이프라인을 좀더 낫게 만들어 주지 않을까? 하는 기대만 한다...
아니면 내가 시간이 좀 나면 짬짬이 이런걸 만들어서 공개하고 싶기도 한데... 현재 내 스케줄을 봤을때 그건 거의 불가능할듯...
결론 - SharpDX
난 일단 SharpDX로 갈아타기로 했다. 프로토타입이나 툴에서 필요한 메모리가 32비트에서 지원할수 있는 용량을 이미 넘어섰기때문이다. 컨텐츠 파이프라인은 텍스처나 메쉬정도는 이미 지원되니.. 나머지거야 어떻게든 닥칠때마다 해결하면 되겠지.
2013년 1월 4일 금요일
새해 첫 팬레터 겸 사랑고백....
오늘 집에 와보니.. 어라 우편함에.. 뭔가 심상치 않은 놈이 꼽혀있었습니다...열어보니... 20대초의 어여뿐 여대생이 보낸 새해인사 겸 사랑고백 엽서가 있었습니다... 이뻐요...
앞에는 이렇게 이쁘게 귀엽게 생겼고... ^_^
뒤에는 이렇게 사랑고백이.....
역시 사람은 잘 생기고 볼일입니다.. 아이 설레라 ~ -_-;
앞에는 이렇게 이쁘게 귀엽게 생겼고... ^_^
뒤에는 이렇게 사랑고백이.....
역시 사람은 잘 생기고 볼일입니다.. 아이 설레라 ~ -_-;
2013년 1월 3일 목요일
쓸모없는 회의
정확히 기억은 안나는데 아마도 애플사의 일 진행법을 소개하는 프리젠테이션이었던거 같다. 거기서 한 말중에 기억에 남는 게...
- 모든 회의의 끝에는 결정(액션 플랜)을 내릴 것
- 결정을 내리지 않을 회의는 하지도 말 것
- 결정을 내릴 권한이 없는 직원은 회의에 포함시키지 말 것
원래부터 쓸모없는 회의에 들어가서 시간낭비하는 걸 싫어했던 나에게 참 괜찮게 들리는 이야기였다.
그 후, 어떤 회의에 초대되어 들어갔다. 한두시간에 끝나는 회의가 아니라 한 3일간에 걸쳐서 하는 회의였고 참여자만도 20명정도 되었는데 회의의 주제는 '차세대 그래픽'이었다.
정확히 회의가 어떻게 진행는지 아무도 내게 말해준 적이 없어서...
'대체 무슨 회의지?'
하는 생각에 들어갔는데... 이런 저런 새로운 그래픽 기법들이 있는데 자기 팀에서는 어떤 시도를 해봤는지 그리고 앞으로 어떻게 사용할건지 등을 공유하는 거였다. 뭐 결과적으론 시그래프 등에서 볼 수 있는 내용들을 그냥 반복하는 정도랄까... 차이점이라면
"우린 이거 시도해봤는데 너무 느려서 실제 게임에선 못쓰겠어요."
라고 (주로) 실패한 경험을 공유하는 정도... 이쯤 이야기하면
"아, 대단히 값진 회의였군요."
라고 말할 사람들이 있을지도 모르겠다. 솔직히 말하면 시간낭비였다. 게임쪽에서 차세대 그래픽이 그리 엄청난 도약을 하지 않을 것이라는 건 이제 누구나 아는 이야기이다. 전세대에서 현세대로 넘어올 때 처럼의 엄청난 도약은 없을거란 말...
근데 회의를 마치는 날에 회의 진행자가 갑자기 말하더라. 이 회의의 끝에는 액션 플랜을 만들어야 한다고...
'아, 이 사람도 그 프리젠테이션을 봤구나.'
라는 생각이 들었는데 사실 유쾌하기 보다는 좀 실망스러웠다고 할까? 왜냐면 그 프리젠테이션에서 전하고자 하는 의미를 제대로 이해 못한 채, 어설프게 흉내내며 시간만 더 낭비하는 느낌이었다.
우리가 만든 액션플랜은 한 대 여섯개 되었는데 이건 사실 다음과 같이 한 줄로 요약이 가능했다.
"이런 이런 기법이 있다. 하지만 게임에서 사용하기엔 너무 느림. 도구와 파이프라인의 효율성을 높이는데 더 주력해야 할 것"
이건 회의를 들어가기 전에 회의 세부일정을 보고 이미 생각한 거였다. 나 뿐 아니라 회의 참가자들 모두가 같은 생각을 했을 거라 생각한다. (아니라면 그놈들 실력을 심각히 의심해봐야할 듯...).어차피 뻔히 알고 있는 내용으로 결론을 내릴 것을 20명이나 되는 시니어 그래픽 프로그래머들의 시간을 3일이나 낭비시킬 이유가 있는건지....
위의 프리젠테이션에 다음 내용을 추가해야만 이런 쓸모없는 시간낭비를 막을 수 있을 거 같다.
- 이미 알고 있는 결정을 내릴 회의는 하지도 말 것
피드 구독하기:
글 (Atom)