Graphics Programming

https://codeonwort.tistory.com/364 1부를 3년 전에 구현했는데 이제서야 2부를 읽고 있다. 맨날 놀다가 질리면 사이드 프로젝트들 중 하나를 골라서 잠깐 하는 것을 반복하니 영 진도가 안 나간다. 모션 블러, 3D 모델 불러오기, BVH 가속, HDR 톤 매핑 로컬 라이트 추가, barycentric 노멀 보간 https://casual-effects.com/data/ 에서 건물 모델들 중 하나를 뽑아서 그려보고 싶었지만 지금 코드로는 BVH를 써도 렌더링이 너무 오래 걸려서 포기했다. Wavefront OBJ 로더를 아직 완성하지 못한 것도 있다. OBJ 로더 완성하고 3부에서 몬테 카를로 적분을 구현하고 나면 그럴 듯한 건물 렌더링을 하나 뽑을 수 있겠다. 그 뒤로는 pbr..

예전에는 컴퓨터 부품을 살 때 CPU, 그래픽카드, 메모리처럼 게임 성능이 올라가는 것에나 신경쓰지 키보드와 마우스는 불필요한 지출처럼 여긴 적이 있다. 그래서 1 ~ 2만원 정도의 멤브레인 키보드만 썼는데, LED가 번쩍이는 게이밍 키보드에 꽃힌 이후로 키보드 쇼핑의 늪에 빠져버렸다. 엄청 예전에 샀고 제품명도 까먹어서 비슷하게 생긴 키보드로 대체했다. 내가 샀던 건 이미 절판되지 않았을까? LED 달린 키보드를 처음 사보고 LED 뽕에 취했으나 몇 년 쓰다보니 LED가 오히려 거슬렸고, 청축이라 밤에 쓰기에는 너무 시끄럽고, 누르는데 힘이 많이 들어서 코딩하다 보면 손가락이 아팠다. 오래 썼더니 마침 고장이 나서 키보드를 교체했다. 그래서 조용하고 품질 좋기로 유명한 레오폴드로 바꿨다. 마음에 쏙 들..

먼 옛날, 아마 대학생일 때 함수형 언어를 배워보겠다고 하스켈을 찍먹한 적이 있다. 논리 언어, 명령형 언어, 함수형 언어 등의 분류가 있다는 걸 알고 함수형 언어를 배워볼까 했던 게 발단이었던 것 같다. 그리고 '순수 함수형'이라는 키워드에 낚여 Closure, F#, OCaml 등 많고 많은 함수형 언어 중에 하스켈을 선택하고 말았다. 다음은 하스켈을 배우는 일환으로 내가 했던 것들이다. 이외에도 몇 개 더 있는데 기억이 안 난다. 위키 번역: https://wikidocs.net/book/204 간단한 웹 애플리케이션 만들기: https://github.com/codeonwort/scrapbook 하스켈로 알고리즘 문제 풀기: http://codeforces.com/blog/entry/48479 하..

목적도 없이 토이 프로젝트를 만드니 진도가 잘 안 나가서 세운 계획이 있는데, 바로 인터넷에서 수집한 사진들을 따라 만들어보는 "렌더링 챌린지"다. 몇 가지 기준에 따라 챌린지에 적합한 사진들을 선택했다. 1. 구하기 힘든 고퀄리티 모델이 사진의 중요 구성 요소여서는 안 된다. 2. 내가 아직 만들지 않은 렌더링 테크닉을 구현하기에 적합해야 한다. 그렇게 챌린지용 사진들을 추려내고 첫번째로 이걸 골랐다. 렌더링 챌린지를 시작하기 전의 내 프로젝트 상태. 갈 길이 멀다. 먼저 하늘 텍스처를 절차적 생성한다. 별과 은하수를 넣고 싶어서 Shadertoy에서 적당한 코드(www.shadertoy.com/view/4ljcz1)를 찾았다. 원본 코드는 2D 버전인데 내 엔진은 하늘을 그릴 때 equirectang..

튜토리얼 보고 만들어놨던 IBL이 metallic, roughness를 조정해봐도 언리얼이랑 너무 달라서 고민한 결과 indirect lighting이 없어서라는 결론이 나왔다. 원래도 로컬 셰이딩 밖에 없었는데 거기다 스카이 라이트 넣어봤자 태양광에 의한 간접광이 없어서 결과가 이상하다. 그래서 간접광을 구현은 해야 하는데... 라이트맵 굽는 방법은 개념만 대충 알고 오픈월드는 워낙 크니 아마 실시간으로 생성할 거 같은데 둘 다 바닥부터 구현할 생각을 하니 막막하다. 어떻게 할까 고민하다가 일단 scene capture를 만들었다. 생각해둔 걸 만들려면 어차피 단순히 큐브맵 이미지만 써서는 안되고 씬에 내가 로드한 물체들을 그 큐브맵에 포함할 수 있어야 한다. 또한 간접광, 리플렉션, 투명 재질 같은 ..

https://deplinenoise.files.wordpress.com/2015/03/gdc2015_afredriksson_simd.pdf 이거 보고 첫번째 예제 간단히 코딩해서 시간을 측정해봤다. (내 코드는 여기) 테스트1 디버그 빌드 Scalar: 0.7278700 seconds SSE2: 0.0579500 seconds (12.56x faster) AVX2: 0.0306839 seconds (23.72x faster) 릴리즈 빌드 Scalar: 0.0435770 seconds SSE2: 0.0015728 seconds (27.70x faster) AVX2: 0.0006350 seconds (68.62x faster) SIMD만으로 이렇게 극적으로 빨라지는 건 아니고 AOS를 SOA로 바꿔서 캐시..

UE4에서 프로젝트를 진행하면 이런저런 플러그인을 쓰게 된다. 엔진에 내장된 것도 있고, 구매하는 것도 있고, 직접 만드는 것도 있다. 플러그인의 소스 컨트롤을 메인 프로젝트의 소스 컨트롤과 묶어서 프로젝트 저장소에서 플러그인 수정도 관리하는 게 가장 직관적이고 관리하기도 편하다. 하지만 여러가지 이유로 다른 저장소를 파서 별도의 테스트 프로젝트에서 플러그인을 개발하고, 플러그인만 메인 프로젝트로 복사해올 수도 있다. UE4의 설계 의도상 어떤 프로젝트에 있는 플러그인 폴더만 복사해서 다른 프로젝트에 붙여넣어도 제대로 동작해야 한다. 그리고 이렇게 옮긴 플러그인이 제대로 작동해야 모듈화가 제대로 되어있다는 뜻이기도 하다. 프로젝트가 거대할 경우 이터레이션(컴파일/쿠킹/패키징/테스트 사이클)이 굉장히 길어..

한창 GPU 최적화를 알아볼 때 대충 이렇게 요약을 했었다. GPU에는 분기라는 게 없다. 둘 다 실행하고 참인 분기의 결과를 선택한다. 따라서 한 분기에 인스트럭션이 많으면 다른 분기에 인스트럭션이 적어도 길게 걸리는 쪽을 기다려야 한다. GPU의 셰이더 유닛은 매우 단순하다. GLSL이나 HLSL에서 정의한 함수도 모두 인라인화된다. CPU는 두 분기를 동시에 실행하고 한쪽이 참이면 다른쪽을 바로 취소한다. 인접한 픽셀들에 대한 셰이더들은 같은 분기를 타는 게 퍼포먼스에 좋다. 그런데 잘못 알고 있었나보다. https://www.quora.com/Why-dont-GPUs-have-branch-predictors 2017년 답변인데다 답변자가 엔비디아, 애플에서 GPU 컴파일러 엔지니어였다니 지금도 유..