컴퓨터그래픽스

diff -r assignment1 labs/lab1의 유일한 차이는 labs/lab1/ 쪽에만 명세 PDF가 있다는 것뿐이다. 노트북·.py·PNG 9장(약 1.2 MB)이 그대로 두 번 커밋돼 있다. 과제 제출용 사본과 실습 사본을 분리하려던 의도는 읽히지만, 심볼릭 링크도 .gitattributes도 아닌 물리적 복사다.

Assignment1.ipynb는 코드 셀 26개인데 Assignment1.py는 24번째 셀("Loop for Sequence Types")부터 시작한다. 즉 이 과제의 유일한 검증 지점인 import numpy / import OpenGL / import glfw와 버전 출력 셀이 .py에는 없다. 노트북 전체에서 np.가 나오는 셀은 print (np.__version__) 한 곳뿐이다(명세가 그것만 요구했으니 정상이지만, .py만 보는 사람에게는 이 파일이 왜 "Python/numpy 리뷰"인지 알 방법이 없다).

고정 파이프라인의 기본 행렬 모드는 GL_MODELVIEW다. assignment2/main.py 전체를 grep해도 glMatrixMode는 0건이므로, gluPerspective가 만든 투영 행렬이 모델뷰 행렬에 곱해지고 GL_PROJECTION은 항등 행렬로 남는다. 최종 클립 좌표는 I · (P·V·M) · v로 같으니 이 과제에서는 화면이 정상으로 보인다. 그러나 모델뷰 행렬은 조명 계산이 일어나는 눈 좌표계를 정의하는 행렬이라, 이 코드에 광원을 하나라도 추가하는 순간 조명이 전부 깨진다. 저자도 이 문제를 나중에 알았다: 같은 레포의 labs/lab17(5월 14일)부터 labs/lab19, lab20, lab22, lab23, lab24, 그리고 assignment3/main.py:50–53까지 모두 glMatrixMode(GL_PROJECTION)/glMatrixMode(GL_MODELVIEW) 분리를 제대로 한다. 즉 4월의 assignment2만 고쳐지지 않은 채 남았다.

push/pop 짝은 전부 맞다(28↔39, 54↔57, 69↔84, 74↔82, 76↔80). 그러나 실제로 변환을 격리하는 쌍은 drawHOS 안의 76↔80 하나뿐이다. 나머지는 push와 pop 사이에 행렬을 건드리는 호출이 아예 없다. 특히 drawWing의 54↔57은 날개의 두 번째 레이어(z=.1)를 감싸고 있는데, 여기가 바로 3단계 계층이 들어갈 자리다. 스캐폴딩만 세워 놓고 변환은 넣지 않았다는 뜻이고, 결과적으로 이 "Hierarchical Rendering" 과제의 계층은 육각형 → 날개 3장 2단이 전부다.

표준 Bernstein 기저는 C(n,i)·t^i·(1-t)^(n-i)인데 코드는 t와 (1-t)의 지수를 맞바꿨다. C(n,i) = C(n,n-i)이므로 이는 제어점 순서를 뒤집은 것과 같고, 기저의 합은 여전히 1이다. 내가 drawWing이 실제로 쓰는 제어점으로 확인한 결과 t=0에서 마지막 제어점 (0.60, 0.50), t=1에서 첫 제어점 (0.00, 0.00)이 나왔고, t=0.5에서는 표준식과 소수점 아래까지 일치했다. 곡선의 모양은 같고 진행 방향만 반대다. 안쪽·바깥쪽 곡선이 똑같이 뒤집히므로 띠 폴리곤도 깨지지 않는다. 다만 이 코드를 재사용해 t로 애니메이션을 태우거나 곡선 시작점을 특정 좌표에 맞추려는 순간 조용히 틀린다.

main()의 루프가 매 프레임 counter += 1을 하고(:149), 날개 회전각(:77)과 인트로 줌 스케일(:113–116)이 모두 이 값에서 나온다. glfw.swap_interval 호출이 없어 vsync도 보장되지 않는다. 60 Hz 기기와 144 Hz 기기에서 같은 장면이 2.4배 다른 속도로 재생된다. 참고로 assignment3/main.py:119에서는 glfw.swap_interval(1)을 넣었다 — 여기서도 배운 것이 뒤 과제에만 반영됐다.

obj.py:138은 각 면의 첫 번째 정점의 법선 인덱스(faces[:, 0, 2])만 읽는다. obj.py:143은 그 하나를 np.stack((x,x,x))로 세 번 복사해 삼각형의 세 정점에 똑같이 붙인다. 결과적으로 파일이 아무리 부드러운 정점 법선을 담고 있어도 렌더링은 평면 셰이딩이 된다. 명세 B.ii(40점)가 "vertex positions, vertex normals, faces 정보만으로 메시를 표시하라"고 못박은 바로 그 항목이다.

실측: obj/sphere-tri.obj는 정점 482개에 법선 482개를 가진 매끄러운 구이고, 파일 안의 면 960개 전부가 서로 다른 vn 인덱스 3개를 지정한다(f 478//1 21//2 479//3). 그런데 로더가 만든 배열에서는 삼각형 960개 전부의 세 법선이 동일하다. 방출된 법선과 구의 참 법선(원점 기준 반지름 방향) 사이 각도는 평균 7.81°, 최대 15.86°였다.

더 나쁜 것은 git 이력이다. 5월 26일 버전은 면의 각 정점마다 자기 법선을 조회하고 있었다. 6월 11일 커밋 3af4365 "Update lib.obj to correct normal and arange"가 그 코드를 지우고 지금 형태로 바꿨다. 법선을 고쳤다는 커밋이 정확히 법선을 망가뜨린 커밋이다. 대회 마감 이틀 전 리팩터링을 육안 확인 없이 밀어 넣으면 이렇게 된다.

obj.py:85은 리스트에서 point(튜플)를 지우려던 자리에 p(numpy 배열)를 넘긴다. 바로 윗줄의 조건은 point in vertex인데 삭제 인자만 다르다. list.remove가 ndarray와 튜플을 ==로 비교하면서 원소별 불린 배열이 나오고 파이썬이 그 진리값을 판단하지 못해 예외를 던진다.

이 분기는 볼록 다각형에서는 도달하지 않는다. 볼록 다각형은 모든 꼭짓점이 귀(ear)라서 "귀였던 점이 더 이상 귀가 아니게 되는" elif가 실행될 일이 없기 때문이다. 그래서 레포의 샘플 6개(사각형만 섞인 구·실린더·정육면체)는 전부 통과한다. 반대로 말하면 삼각화가 실제로 필요한 유일한 경우 — 오목 다각형 — 에서만 죽는다. XY 평면의 L자 육각형 하나로 재현했다.

obj.py:106은 f 줄의 각 토큰을 /로 쪼개 그대로 튜플로 만든다. _type(:92–95)이 빈 문자열을 0으로 바꿔 주므로 f v//vn과 f v/vt/vn은 길이 3의 튜플이 되어 잘 동작한다. 그러나 f v는 길이 1, f v/vt는 길이 2가 되고, :138의 faces[:, 0, 2]가 존재하지 않는 축을 인덱싱한다. OBJ 명세에서 법선이 선택 항목이라는 점을 감안하면 이것은 예외가 아니라 흔한 입력이다.

결정적으로, 이 레포 자신이 그런 파일을 갖고 있다. labs/lab14/cube.obj는 f 1 2 3 4 형식의 평범한 큐브다. 그 파일을 자기 뷰어에 드래그앤드롭하면 로더가 예외를 던진다. 드롭 콜백(main.py:97–104)에 try/except가 없으므로 사용자에게는 아무 메시지도 없이 콜백이 터진다.

음수(상대) 인덱스도 마찬가지다. OBJ 명세가 허용하는 f -3//-1 -2//-1 -1//-1을 넣으면 :137의 무조건적인 -1 보정이 -3을 -4로 만들어 IndexError가 난다.

ear clipping은 2D에서만 성립하므로 3D 다각형을 평면에 투영해야 한다. 올바른 방법은 면 법선의 절댓값이 가장 큰 성분에 해당하는 축을 버리는 것이다. 이 코드는 대신 "세 좌표 중 값이 모든 정점에서 동일한 축"을 찾고, 못 찾으면 or [0]로 무조건 X축을 버린다(:124–128). 즉 축에 정렬된 평면만 제대로 처리한다.

다행히 대부분의 기울어진 평면은 YZ 투영으로도 볼록성이 보존되어 살아남는다(기울어진 정오각형으로 확인: 삼각형 3개, 면적 합 2.3776 = 참값 2.3776). 그러나 평면이 X축을 포함하는 경우 — 예를 들어 법선이 (0, 1, 1)인 평면 — YZ 투영은 다각형을 직선으로 뭉갠다. 이때 trianglize는 예외 없이 빈 배열을 돌려주고, 그 면은 newface에 아무것도 남기지 않으며, 몇 줄 뒤 :137이 1차원이 된 배열을 3차원으로 인덱싱하다 죽는다. 침묵 실패가 두 단계 뒤 엉뚱한 줄의 IndexError로 나타나는 최악의 형태다.

또한 np.where(...)[0] or [0] 자체가 위태롭다. 일정한 축이 두 개 이상이면(퇴화한 선분 면) ndarray의 진리값 판정에서 ValueError가 난다. 마침 축 0이 유일한 일정 축일 때는 array([0])이 falsy라 or가 [0]을 돌려주고 결과적으로 같은 축을 버리게 되어 우연히 맞는다.

Light._render()는 광원마다 GL_AMBIENT·GL_DIFFUSE·GL_SPECULAR를 모두 설정한다(light.py:39–41). 그런데 재질 쪽은 light.py:56 한 줄이 전부이고, 거기서 설정하는 것은 GL_AMBIENT_AND_DIFFUSE뿐이다. 레포 전체에 GL_SHININESS나 재질 GL_SPECULAR를 설정하는 코드는 없다(grep으로 확인). 고정 파이프라인의 기본 재질 정반사색은 (0,0,0,1), 기본 shininess는 0이므로 정반사 항은 항상 0이다. 광원 쪽 specular 값 네 벌은 계산에 전혀 기여하지 못한다.

같은 맥락에서 Light.objectColor()(:43–47)는 ambient·specular 인자를 받아 저장하지만 그 둘은 어디서도 읽히지 않는다. 그리고 glMaterialfv(GL_FRONT, ...)만 호출하므로 후면은 GL 기본 재질로 그려진다 — 컬링을 켜지 않았고 다운로드한 메시가 워터타이트하다는 보장이 없으므로 실제로 보이는 면이다.

명세 A.ii는 "카메라를 원점 쪽으로 이동(zoom in) 또는 멀어지게 이동(zoom out)"이라고 적혀 있다. 구현은 gluLookAt의 eye 위치를 고정한 채 물체에 glScalef를 건다. 원근 투영에서 결과가 비슷해 보일 뿐 같은 연산이 아니다 — 클리핑 평면(1~10)과의 관계가 달라지고, 무엇보다 법선이 함께 스케일된다.

고정 파이프라인은 법선에 모델뷰 상단 3×3의 역전치를 곱해 주므로 방향 자체는 균등 스케일에서 보존된다. 그러나 길이는 1/s배가 되고, GL은 GL_NORMALIZE나 GL_RESCALE_NORMAL이 켜져 있을 때만 다시 정규화한다. 레포 전체 grep 결과 둘 다 0건이다. 따라서 A/S 키로 줌할 때마다 확산광 세기가 함께 변한다 — 줌아웃하면 모델이 밝아지고 줌인하면 어두워진다. 게다가 cam.zoom에는 하한이 없어(main.py:92–93) S를 열 번 누르면 0, 더 누르면 음수가 되어 모델이 뒤집힌다.

tests/test_obj.py는 obj._vertices, obj._normals, obj._texcoords, obj._faces를 단언한다. OBJ 인스턴스의 실제 속성은 filename, array, index, indexes, faces, values, buffer, face_info이고 밑줄 접두 이름은 하나도 없다. 이 테스트는 6월 2일 커밋(60bc26f "Update tests.obj for load object")에 들어온 뒤 lib/obj.py가 세 번 갈아엎히는 동안 단 한 번도 갱신되지 않았다. 즉 한 번도 실행되지 않았다. 그리고 이 테스트가 살아 있었다면 위의 법선 붕괴는 잡혔을 것이다.

obj.py:139은 faces[:, 0, 0], 즉 정점 인덱스 자리를 읽어 텍스처 좌표 배열을 만든다. vt 인덱스는 슬롯 1에 있다. 레포의 Sylvanas.obj·Varianwrynn.obj는 면이 f 1/1/1 2/2/2 3/3/3 형태라 세 인덱스가 항상 같아 잘못된 값이 나오지 않고, render()가 texcoord를 쓰지도 않는다. 명세도 vt를 무시하라고 했으니 실질 피해는 없다. 다만 슬롯 0을 슬롯 1로 착각한 것은 사실이고, 세 줄 연속(:137–139)에서 [:, :, 0], [:, 0, 2], [:, 0, 0]이 나열되는 구조 자체가 어느 축이 무엇인지 헷갈리기 딱 좋게 생겼다.

mode.py:7의 index = index or self.index는 명시적으로 넘긴 0을 falsy로 보고 버린다. 실측: Mode(['A','B','C'], starts=2).get(index=0)이 'C'를 돌려준다. 현재 호출부 중 index=0을 넘기는 곳이 없어 잠복 버그지만, 이 클래스는 광원 슬롯(GL_LIGHT0~7)과 폴리곤 모드 양쪽에서 재사용되는 공용 유틸이다. 덧붙여 except:로 모든 예외를 삼키고 Exception('index out of range')로 바꿔 던지는 것(:10–11)과, finally에서 실패한 호출도 인덱스를 증가시키는 것도 같은 성질의 문제다.