그때는 맞는 줄 알았다. 어디서 헷갈렸는지 적어 둔다.
writeBuffer로 좌표를 전달한 뒤 JavaScript 배열만 바꾸면 GPU buffer도 바뀔까?
createBuffer()로 크기와 허용 용도를 지정해 저장 공간을 만든다. writeBuffer()로 원본 데이터를 복사해 넣는다. 이후 JavaScript 배열만 바꿔도 GPU buffer는 자동으로 갱신되지 않으므로 변경된 데이터를 다시 전달해야 한다.
배열만 변경하면 GPU 값은 이전 값으로 남는다고 이유와 함께 예측했다. 직접 실습에서 첫 x좌표가 JavaScript 0.4, GPU 0.0인 것을 확인했고, 재전달 뒤에는 GPU도 0.4라고 보고했다. 이번 결과는 데이터 전달에 대한 설명과 관찰이며 삼각형 그리기나 독립 코드 구현을 완료한 것은 아니다.
To update GPU buffer after changes JavaScript array, we have to ship data.
JavaScript 배열을 변경한 뒤 GPU buffer를 갱신하려면 데이터를 다시 전달해야 한다는 내용을 영어로 써 보자.
To update the GPU buffer after changing the JavaScript array, we have to transfer the data again.
after changing으로 표현한다.transfer를 쓰고, 재전달이라는 뜻을 again으로 명시한다.the를 붙인다.To update와 필요를 나타내는 we have to는 첫 시도에서 맞게 사용했다.예문 없는 첫 시도 후 참고 문장을 보며 완성 문장을 다시 썼다. 재작성의 JavaScrip은 JavaScript의 철자 오타로 정정했다. 독립 회상은 이후 확인한다.
adapter와 device를 얻기만 하면 화면에 삼각형이 나타날까?
device를 얻는 것은 GPU 작업을 준비하는 단계다. 그리기를 요청하지 않았다면 삼각형은 나타나지 않는다. GPU가 사용할 데이터 저장 공간을 만드는 작업은 device를 통해 한다.
이 첫 준비 단위에서는 준비만으로 그림이 나타나지 않는 이유를 설명하고, 직접 실행한 화면에서 device 확보 성공을 확인했다. 이후 buffer 생성과 좌표 전달을 이어서 확인했으며, 그리기 명령 제출은 다음 학습이다.
As GPU makes data storage in WebGPU, prepare device first.
GPU가 사용할 저장 공간을 만들려면 먼저 device를 준비해야 한다는 내용을 영어로 써 보자.
To create storage for GPU data in WebGPU, we need to prepare a device first.
To create ...로 쓴다.we need to prepare로 준비하는 주체와 필요를 드러낸다.device 앞에 a를 붙인다.예문 없이 첫 시도를 한 뒤, 참고 문장을 보며 전체 문장을 다시 썼다. 재작성에 남은 sotrage는 storage의 철자 오타로 정정했다. 독립 회상은 이후 확인한다.
JavaScript에서 색을 바꾸면 이미 그린 삼각형도 바로 바뀔까?
이번 예제에서는 색 선택이 JavaScript 변수만 바꾼다. uniform 값 전달과 그리기 요청까지 실행해야 삼각형 색이 바뀐다.
색을 선택한 직후에는 변화가 없고, 전달하고 다시 그리는 버튼을 눌러야 색이 바뀌었다. gl_FragColor = u_color인 shader에서는 모든 fragment가 전달받은 색을 그대로 출력하므로 삼각형 전체가 같은 색으로 채워진다. 다른 shader에서는 전달받은 값을 계산에 사용할 수 있으므로 결과색이 uniform 값과 항상 같지는 않다.
after change value in JavaScript, The value ship the shader and have to rerender.
색 값을 바꾼 뒤 shader에 전달하고 삼각형을 다시 그려야 한다는 내용을 영어로 써 보자.
After changing the color value in JavaScript, we need to pass it to the shader and redraw the triangle.
after changing으로 값을 바꾼 뒤라는 순서를 표현한다.we need to pass it to the shader로 누가 무엇을 어디에 전달하는지 드러낸다.redraw the triangle로 다시 그릴 대상을 명확히 한다.첫 시도 후 참고 문장을 보고 전체 문장을 다시 작성했다. 예문 없는 독립 회상이나 장기 숙달로 기록하지 않는다.
the vertex shader determine 꼭지점's position and the fragment shader calculate each other fragment's color.
vertex shader와 fragment shader의 역할을 영어 한 문장으로 설명해 보자.
The vertex shader determines the position of each vertex, and the fragment shader calculates the color of each fragment.
shader에는 determines, calculates를 쓴다.the position of each vertex로 표현한다.each other는 “서로”라는 뜻이다. 각각의 fragment를 말할 때는 each fragment를 쓴다.예문 없이 첫 문장을 쓴 뒤 피드백과 참고 문장을 보고 전체 문장을 다시 작성했다. 예문 없이 독립적으로 다시 쓸 수 있는지는 이후에 확인한다.
fragment shader는 점 3개가 모여 생기는 삼각형의 색을 계산해.
세 꼭짓점이 삼각형이 되고 내부에 색이 채워질 때 각 단계는 무엇을 할까?
vertex shader는 각 꼭짓점 위치를 결정한다. 그 뒤 WebGL이 꼭짓점을 삼각형으로 조립하고 내부 fragment를 만들면, fragment shader가 각 fragment의 색을 계산한다.
fragment shader가 세 점을 받아 삼각형 전체의 색을 한 번 계산하는 것이 아니다. 삼각형 조립과 래스터화가 먼저 일어나며, fragment shader는 생성된 fragment마다 실행된다.
fragment는 깊이 검사 등 이후 단계를 거쳐야 하므로 최종 픽셀과 항상 일대일로 같다고 단정하지 않는다.
역할을 두 번 다시 표현한 뒤 vertex shader → 삼각형 조립 → fragment 생성 → fragment shader의 순서로 완성 설명을 작성했다.
Canvas 2D와 WebGL은 왜 y축 방향과 원점이 다르게 보일까?
Canvas 2D는 기본적으로 왼쪽 위가 (0, 0)이고 y가 아래로 증가한다. WebGL의 NDC는 중심이 (0, 0)이고 y가 위로 증가하며 범위는 -1~1이다.
WebGL에 처음 전달하는 꼭짓점 데이터의 단위와 좌표계는 개발자가 정한다. vertex shader가 이를 변환해 gl_Position에 클립 공간 위치를 기록하고, 원근 나눗셈 뒤 NDC가 된다.
이번 예제는 a_position을 gl_Position에 그대로 넣었기 때문에 입력 좌표가 NDC처럼 바로 화면에 나타났다.
Canvas 2D 좌표계를 기억해 WebGL 예제와 다른 이유를 질문하고, 원시 입력 좌표와 최종 NDC를 구분했다. 행렬이나 원근 나눗셈 계산은 아직 하지 않았다.
MDN — WebGL model view projectionTexture doesn't replace Material and then It is using data as determining object's surface.
Texture가 Material을 대체하지 않고 표면의 외형을 정하는 데이터라고 영어로 설명해 보자.
A texture does not replace a material. It is data that the material uses to determine the surface's appearance.
a texture, a material이라고 쓴다.data that the material uses라고 쓴다.surface's appearance는 표면에 보이는 색과 무늬를 포함한 “표면의 외형”이라는 뜻이다.예문 없이 첫 문장을 쓴 뒤 표현을 교정하고 참고 문장을 보며 완성 문장을 다시 작성했다. 예문 없이 독립적으로 다시 쓸 수 있는지는 이후에 확인한다.
Texture를 켰을 때 무엇이 바뀌며, Texture와 Material은 어떤 관계일까?
Texture는 Material을 대체하지 않는다. Material이 표면을 계산할 때 사용하는 데이터이며, material.map 같은 속성에 연결할 수 있다.
Texture를 켜자 구체의 모양·위치와 조명 조건은 그대로였고 표면에 보이는 이미지가 달라졌다. 따라서 이 예제에서 Texture가 바꾼 것은 Geometry가 결정하는 모양이 아니라 Material이 표현하는 표면의 외형이었다.
같은 구체에서 Texture만 껐다 켜고 결과를 비교한 뒤 Texture와 Material의 관계를 다시 설명했다. UV 좌표나 여러 종류의 Texture는 아직 다루지 않았다.
Three.js — MeshStandardMaterial.mapRoughness bigger than highlight more softer
Roughness가 커질수록 반사광이 퍼지고 하이라이트가 부드러워진다고 영어로 설명해 보자.
As roughness increases, the reflected light spreads out and the highlight becomes softer.
bigger than은 두 대상을 비교한다. 값이 커지는 변화를 나타낼 때는 as roughness increases를 쓴다.the reflected light, the highlight라고 쓴다.softer가 이미 비교급이므로 more softer처럼 비교급을 겹치지 않는다.반대 방향은 As roughness decreases, ...로 시작할 수 있다.
예문 없이 첫 문장을 쓴 뒤 피드백과 참고 문장을 보고 전체 문장을 다시 작성했다. 예문 없이 독립적으로 다시 쓸 수 있는지는 이후에 확인한다.
거칠기가 높아지면 표면의 빛 반사가 더 잘 일어날 것 같다.
다른 조건을 고정하고 Roughness를 0에서 1로 올리면 하이라이트는 어떻게 달라질까?
Roughness가 작을수록 반사광이 한곳에 집중되어 하이라이트가 선명해지고, 클수록 반사광이 넓게 퍼져 흐리고 둔해진다.
“반사가 더 잘된다”는 표현은 반사의 양이 늘어난다는 뜻으로 오해하기 쉽다. 이번 관찰에서 바뀐 핵심은 반사광의 집중과 분산이었다.
굴곡에 따른 기본 명암은 표면 방향과 Light의 관계에서도 생긴다. Roughness 하나로 모든 음영을 설명하지 않는다.
구체에서 Roughness를 직접 바꾸고 하이라이트의 선명도와 범위를 관찰했다. 환경 맵과 금속성까지 분리한 비교는 아직 하지 않았다.
Three.js — MeshStandardMaterial.roughnessMaterial을 바꿔도 모양과 윤곽은 그대로고 색상 차이만 달라졌어.
같은 기본 색에서 MeshStandardMaterial과 MeshBasicMaterial의 화면 차이는 어디서 생길까?
Material을 바꿔도 Geometry가 같으면 모양과 윤곽은 유지된다. 달라지는 것은 Material이 빛을 계산하는 방식과 그 결과로 생기는 밝기·명암이다.
두 Material에 지정한 기본 색은 같았다. MeshStandardMaterial은 장면의 Light를 이용해 표면의 밝기와 명암을 계산하지만, MeshBasicMaterial은 장면의 Light 영향을 받지 않는다.
따라서 이번 비교에서 본 차이는 새로운 색을 넣은 결과가 아니라 같은 기본 색이 서로 다른 조명 계산을 거친 결과였다.
같은 Geometry에서 Material과 Light를 하나씩 바꾸어 관찰한 뒤, “빛의 계산 여부에 따른 밝기와 명암”이라고 다시 설명했다. Material 전체 종류나 셰이더 구현을 익힌 것은 아니다.
Three.js — MeshStandardMaterial물체 로테이션은 제자리 회전이라면, 카메라 포지션은 위치가 이동하면서 다른면이 보이고있어
상자만 보면 물체를 돌린 것과 카메라를 옮긴 것이 비슷해 보인다. 화면에서 둘을 어떻게 구분할까?
물체를 돌리면 그리드는 가만히 있고, 카메라를 옮기면 그리드도 같이 움직인다.
무엇이 움직였는지(제자리 회전 vs 위치 이동)는 맞았다. 하지만 그건 원인이고, 화면만 보고 구분하는 방법은 아니었다. 상자는 두 경우 모두 "다른 면이 보인다"는 같은 결과를 낸다.
기준이 되는 고정물을 깔고 그쪽을 봐야 갈린다.
box.rotation.y → 그 물체의 변환만 바뀐다. 배경은 제자리.camera.position.x → 장면 전체와의 관계가 바뀐다. 배경까지 전부 움직인다.카메라는 장면 안의 물체가 아니라 장면을 보는 위치라서 그렇다.
화면이 이상할 때 물체가 움직인 것인지 카메라가 움직인 것인지 헷갈리면 GridHelper·AxesHelper 같은 고정물을 깔고 그쪽을 본다. Three.js가 이런 헬퍼를 기본 제공하는 이유다.
예제를 직접 조작해 관찰한 뒤 설명했다. 장면을 처음부터 구성하거나 카메라 행렬의 계산 과정을 다룬 것은 아니다.
HTML 예제를 파일 탐색기에서 바로 열었더니 화면이 비고 CORS 오류가 떴다. 왜일까?
브라우저는 file: URL을 각각 **별개의 보안 출처(unique origin)**로 취급한다. 그래서 <script type="module">이 상대 경로로 다른 파일을 불러오면 교차 출처 요청이 되어 막힌다. 로컬 HTTP 서버로 열면 해결된다.
Access to script at 'file:///.../three.module.js' from origin 'null'
has been blocked by CORS policy
origin 'null'이 단서다. 출처가 없는 것이 아니라, 어느 것과도 같지 않은 출처라는 뜻이다.
모듈 스크립트는 import가 실패하면 본문이 아예 실행되지 않는다. 자기 실패를 알리는 코드조차 그 안에 있으면 돌지 못한다. 그래서 안내는 일반 스크립트로 따로 둔다.
<script>
if (location.protocol === 'file:') showHint();
</script>
코드 결함이 아니라 여는 방법의 문제다. 같은 파일을 http://localhost:포트/로 열면 그대로 동작한다.
dt는 흘러간 시간 같은데?
애니메이션 루프의 dt는 무엇을 담은 값이고, 어느 시점을 기준으로 잰 시간일까?
dt는 직전 프레임부터 현재까지 걸린 시간이다. 시작 시각부터 누적된 경과 시간이 아니다.
"흘러간 시간"은 두 가지로 읽힌다. 시작부터 흘러간 시간인지, 직전부터 흘러간 시간인지. 코드가 답을 준다.
const dt = (now - lastUpdate) / 1000;
lastUpdate = now; // 기준점을 매번 갱신한다
기준점을 바로 다음 줄에서 덮어쓰기 때문에 dt는 항상 한 프레임 구간만 담는다. 누적 경과 시간은 별도의 시작 시각 변수로 따로 잰다.
dt = delta time. d는 그리스 문자 Δ(delta)로 수학·물리에서 변화량·차이를 뜻한다. 이름 자체가 뺄셈의 결과라는 뜻이라 누적값이 아님이 드러나 있다. deltaTime, elapsed로도 쓰고, Three.js의 Clock.getDelta()도 같은 값을 돌려준다.
/1000은 개념이 아니라 단위 맞추기다. rAF가 넘기는 시각이 밀리초라서, 속도를 "초당 몇 px"로 잡았다면 초로 바꿔야 곱이 맞는다.
기준점을 정확히 반영해 다시 설명했다. dt 상한 처리(탭을 오래 가린 뒤 dt가 튀는 경우)는 아직 배우지 않았다.
Multiply movement by elapsed time for object same speed differently frame speed.
프레임 속도가 달라져도 같은 속도로 움직이게 하려면 이동량에 경과 시간을 곱한다는 내용을 영어로 설명해 보자.
Multiply the movement by the elapsed time so that the object moves at the same speed even when the frame rate changes.
the movement, the elapsed time: 앞서 말한 특정 대상이므로 관사를 붙인다.so that the object moves at the same speed: 목적은 명사 나열이 아니라 so that + 주어 + 동사 절로 푼다. for object same speed는 문장이 되지 않는다.even when the frame rate changes: "달라져도"는 양보라서 even when ~ changes로 쓴다. differently frame speed는 부사 뒤에 명사가 와서 연결되지 않는다.frame rate: 초당 프레임 수를 가리키는 관용 표현이다. frame speed라고는 쓰지 않는다.처음에는 예문 없이 작성했고 동사구 Multiply ~ by ~는 맞았다. 피드백 뒤 참고 문장을 보며 완성 문장으로 정확히 다시 썼다. 예문 없이 다시 표현할 수 있는지는 이후에 확인한다.
첫 프레임에서 사각형이 그려지고 이후에 사각형이 사라지게 돼.
첫 실행 예약은 남기고 함수 내부의 다음 예약만 제거하면 그림은 어떻게 될까?
다음 호출이 없으면 clearRect도 다시 실행되지 않는다. 첫 호출에서 그린 사각형은 처음 위치에 그대로 남는다.
처음에는 반복이 멈추면 사각형이 사라질 것이라고 예측했다. 하지만 실행 순서는 지우기 → 그리기 → 다음 위치 준비다. 다음 예약을 제거하면 이 순서를 한 번만 실행한다. x 변수에 새 값을 넣어도 기존 그림 자체가 이동하거나 지워지지 않는다.
설명을 듣고 그림이 남는다고 바로잡은 뒤, 함수가 한 번만 실행돼 지우기도 반복되지 않는다는 이유까지 설명했다. 실제 실행 검증이나 구현 숙달을 확인한 것은 아니다.
It is that request next frame for animation.
애니메이션을 계속하려면 다음 프레임을 다시 요청해야 한다는 내용을 영어로 설명해 보자.
We need to request the next frame to keep the animation running.
We need to request: 주어와 ‘요청해야 한다’는 의미를 명확히 한다.the next frame: 이어지는 다음 프레임을 가리키므로 the를 붙인다.to keep the animation running: 애니메이션이 계속 실행되게 하려는 목적을 표현한다. keep + 대상 + -ing 형태다.처음에는 예문 없이 작성했고, 피드백 뒤에는 참고 문장을 보며 완성 문장으로 정확히 다시 썼다. 예문 없이 다시 표현할 수 있는지는 이후에 확인한다.
Canvas 2D doesn't move Object to destination. Just repeat removing and drawing for change position.
Canvas 2D에서 사각형이 움직이는 것처럼 보이는 이유를 영어 한 문장으로 설명해 보자.
We make an object appear to move by repeatedly clearing the canvas and redrawing it at a new position.
지우고 다시 그리는 과정을 반복한다는 의미는 전달했고 doesn't move도 맞게 썼다. 다음 표현을 다듬었다.
object는 보통명사이므로 소문자로 쓰고, 단수 형태 앞에 an을 붙인다.for change position은 to change its position으로 고칠 수 있다.clear, 다시 그리기는 redraw로 구체화한다.appear to move는 “움직이는 것처럼 보이다”, by + -ing는 방법을 나타낸다.첫 시도는 영어 예문 없이 작성했다. 피드백 이후에는 위 참고 문장을 보며 완성 문장으로 다시 썼다. 같은 원리를 예문 없이 다시 표현할 수 있는지는 다음에 확인한다.
uniforms는 대기의 구체 형태와 크기를 만든다.
구체를 만들고 대기의 색을 바꾼다면, Geometry와 uniforms는 각각 어떤 역할을 할까?
Geometry는 물체의 형상을 나타내는 꼭짓점 등의 데이터를 담고, uniforms는 셰이더에 전달하는 값이다. 구체의 형태는 SphereGeometry 같은 기하 데이터로 만들 수 있다.
크기나 색을 나타내는 값과, 형상 자체의 데이터를 혼동했다. 셰이더가 uniform 값을 이용해 꼭짓점을 움직일 수는 있지만 uniforms 자체가 구체를 만드는 기능은 아니다.
Three.js ShaderMaterialkey는 변경된 부분만 리렌더링하기 위한 값이다.
key가 같은 B서점 위에 새 결과가 추가됐다. 마우스를 움직이지 않고 클릭하면 반드시 B서점이 선택될까?
key는 형제 목록 안에서 항목의 정체성을 구분한다. React는 위치·타입·key를 바탕으로 컴포넌트 상태를 보존하거나 초기화한다. key만으로 리렌더링이나 항목의 화면 이동이 막히지는 않는다.
컴포넌트의 정체성, 렌더링 여부, 화면의 좌표를 하나의 문제로 생각했다. 검색 결과가 위에 추가되면 key가 같아도 포인터 아래의 항목은 달라질 수 있다.
React 상태 보존과 초기화Three.js support 3D web development, as moduling WebGL or WebGPU.
Three.js가 어떤 도움을 주는지, 정답을 보기 전에 영어 한 문장으로 말해 보자.
Three.js supports 3D web development by making WebGL or WebGPU easier to use.
Three.js는 단수 주어라 supports를 쓴다. ‘더 쉽게 사용할 수 있게 해서’라는 방법은 by making … easier to use로 표현한다. by 앞의 쉼표는 이 문장에서는 필요하지 않다.
Three.js, WebGL·WebGPU, GPU를 각각 ‘도구·창구·처리 장치’에 연결해 보자.
WebGL은 OpenGL ES를 웹에 맞춘 그래픽 API다. WebGPU는 W3C에서 여러 회사가 함께 설계하는 API로, 현대 GPU의 그래픽과 일반 계산 기능을 웹에서 이용하도록 한다.
WebGPU를 OpenGL의 단순한 개량판으로 생각하면 명령 준비 방식과 compute 기능의 차이를 놓치기 쉽다. 두 API는 브라우저가 GPU에 작업을 맡기는 창구라는 역할을 공유한다.
WebGPU 설계 설명같은 구체를 나무와 금속처럼 보이게 만들 때, 바꿀 데이터와 속성은 무엇일까?
Texture는 표면에 입힐 이미지나 수치 데이터를 담는다. Material은 색상, 빛에 반응하는 방식, 거칠기와 금속성 등 표면을 표현하는 규칙과 설정을 다룬다. 사용하는 Material 종류에 따라 지원하는 속성이 다르다.
입문 때는 Texture를 표면의 이미지로 기억해도 좋다. 이후 거칠기·법선 같은 정보도 텍스처에 담을 수 있다는 점으로 넓혀 가면 된다.
Three.js MeshStandardMaterial‘다시 설명해 볼 것’은 아직 혼자 설명하는 데까지 확인하지 못한 내용.