codingfarm

Normal Map 쉐이딩

scarecrow1992 — Sat, 4 Jul 2026 19:36:14 +0900

Noise Texture를 통해 normal map 을 절차적으로 만들기 위해 위와 같이 쉐이더 그래프를 구성하였다.

그리고 노말맵 상태를 확인하기 위해 Material Output 노드에 직접 반영하였다.

파란색을 기본 방향 삼아, 잘 나온것 같지만, 일반적으로 사용되는 노말맵 텍스쳐와는 기본 색상이 다르다.

청보라색이 아닌 완전 파란색으로 보인다.

우선 왜 기본값이 (0.5, 0.5, 1.0) 이 되었는지를 알아야 하는데,

이유는 인코딩/디코딩 때문이라고 한다.

일반적인 탄젠트 공간 노말 벡터 범위는 ~1 ~ 1 이지만, 텍스쳐의 범위 0~1 로 변환하기 위해 보정 작업을 거치며

이로인해 (0, 0, 1) 이 (0.5, 0.5, 1) 로 변환된것이다.

Blender3d의 Normal Map 노드의 기본색상도 (0.5, 0.5, 1)이며, 해당 노드를 그대로 Material Output에 연결해도

완전히 파란색으로 변형됨을 알 수 있다.

0~1만을 지원하는 이미지 파일에 -1~1의 범위를 가지는 벡터를 반영하기 위해

음수를 양수로 바꾸는 offset 및 scaling 작업이 필요했으며,

이로인해 데이터 정규화 과정을 거치며 노말맵의 청보라색이 파란색으로 변형되는것이다.

Texture Baking

scarecrow1992 — Sat, 4 Jul 2026 19:04:19 +0900

1. 개요

Blender3d 에서 모델링된 3d 모델을 어플리케이션에서 사용하기 위해서는 glb 등의 확장자로 export 해야한다.

이때 해당 확장자 파일이 blender3d 의 기능을 요구하지 않는다면, 해당 데이터는 상실되며,

어플리케이션 내에서의 렌더링 결과도 blender3d와 달라지게된다.

glb로 exporting 불가능한, blender3d 자체 기능들은 대표적으로 shader node 가 있다.

https://docs.blender.org/manual/nb/3.6/addons/import_export/node_shaders_info.html

blender3d 는 Node Shader를 import/export 하는 가이드를 안내해주는데,

사실상 Principled BSDF와 Normal Map, Textures를 제외한 나머지 노드나 설정등은

glb로 export 한 순간 데이터를 잃는다는 가정하에 작업하는것이 유용하다.

2. 베이킹

noise texture를 이용한 diffuse map과 normal map 이 적용된 간단한 material 이다.

위 쉐이더를 기준으로 모델에 적용된 Diffuse Map과 Normal Map 을 texture로 베이킹 하는 방법은 아래와 같다.

1) UV-unwrapping

shader node 를 사용하여 절차적으로 material을 만들때는, 좌표들을 3d 공간에서 직접 얻을 수 있지만,

베이킹을 위해선 모델에 map 적용될 uv 좌표를 알아야 하며, 이를 위해 unwrapping을 수행해야한다.

편집모드에서 모든 요소를 선택한 후 단축키 u를 누르면 UV Mapping 컨텍스트 메뉴를 볼 수 있다.

여기서 Smart UV Project를 통해 간단하게 uv mapping 수행이 가능하다.

2) Texture 생성하기

베이킹된 결과가 반영될 texture를 미리 생성한다.

텍스쳐는 Shading Editor 에서 Image Texture 노드를 생성한 후, new 버튼을 눌러 생성할 수 있다.

3) Baking 설정

https://docs.blender.org/manual/en/latest/render/cycles/baking.html

베이킹은 Properties 의 Render 탭에서 설정/수행 가능하다.

매터리얼/조명 결과를 이미지 텍스쳐로 굽는 기능은 Cycles 전용이므로, Render Engine 을 Cycles로 설정한다.

그러면 Bake 아코디언 UI가 활성화됨을 볼 수 있다.

원하는 베이킹 타입을 선택한 후, 상세 설정을 진행하면된다.

Normal

Space는 Tangent와 Object가 제공되는데, Tangent는 각 표면의 접선 좌표계를 기준으로 색상을 만들며,

Object는 오브젝트의 로컬 좌표계를 기준으로 색을 만든다.

즉, 객체의 옆면을 베이킹 할 경우 Tangent 에서는 (0.5, 0.5, 1.0) 색이 설정되지만,

Object는 해당 면이 향하는 실제 좌표를 기준으로 색을 형성하게 된다.

대부분의 경우 Tangent를 쓰면된다

Diffuse

Contributions 항목에서는 3개의 옵션이 주어진다.

Direct / Indirect : 직접광, 간접광에 의한 조명효과 적용 여부
Color : Colorize Pass 적용 여부

Pricipled BSDF의 BaseColor에 적용된 색상이 그대로 베이킹 되길 원한다면, Color 옵션만 살린다.

4) Bake 수행

Layout View에서 모델 선택
Shading UI 에서 Image Texture 선택
Bake 수행

위 작업을 수행하면, 선택된 모델의 베이킹 결과를 Image Texture 노드에 할당된 Texture에 베이킹된다.

주의

https://docs.blender.org/manual/en/latest/editors/image/image_settings.html#bpy-types-colormanagedinputcolorspacesettings-name

Normal, Stencil, Bump 처럼 비색상 텍스쳐는 baking 및 load시 색공간을 sRGB가 아닌 Non-Color로 설정해야한다.

색보정이 발생하면서, 데이터 자체가 변조되는 현상을 막기 위함이며,

three.js에서 Normal 등의 비색상 텍스쳐에 명시적으로 NoColorSpace 를 지정하는것과 유사한 이유이다.

sRGB 적용시

Non-Color 적용시

Blender3d로 이미지를 Image Texture 노드에 로드시, 색공간을 Non-Color로 설정하면

Image Editor 윈도우에서 표시되는 이미지 색상에도 차이가 생긴다.

그러므로 Browser나 뷰어앱을 통해 이미지를 보는것보다 밝은색으로 표현될 수 있다.

베이킹된 텍스쳐 적용하기

Normal Texture의 경우, Normal Map을 통해 이미지 텍스쳐의 데이터를 노말벡터 정보로 정규화 하는 과정을 진행하면된다.

이미지파일을 외부에서 로드할 경우 Color Space를 직접 설정 가능gksep,

앞서 설명한대로 Non-Color로 설정해주면된다.

3. 마무리

본문에서는 당장 필요로한 Bake Type에 대해서만 간략히 정리하였으나,

Blender3d는 매우 다양한 종류의 Bake Type을 지원하며,

렌더링 품질을 올리기 위해서는, 해당 타입들 모두에 대해 면밀하게 학습하고,

import 환경에서도 품질 손실없이 렌더링 할 수 있는 기술들에 대해 부지런히 학습해야겠다.

customDepthMaterial을 이용한 그림자 렌더링

scarecrow1992 — Sat, 27 Jun 2026 23:18:05 +0900

1.소개

https://screen.toys/firewood/

Three.js 메인 페이지에 소개된 장작패기 프로젝트이다.

mp4 동영상 파일과 VideoTexture를 이용하여, 바람에 나무가 움직이는 연출이 인상적이며,

해당 프로젝트를 참고하여, 움직이는 그림자를 렌더링하는 방법을 학습하였다.

const video = document.createElement("video");
video.src = "video/gobo.mp4";
video.loop = true;
video.muted = true;
video.playsInline = true;
video.preload = "auto";
video.crossOrigin = `anonymous`;

video.addEventListener("loadeddata", () => {
  video.play();
});

video.load();

const videoTexture = new THREE.VideoTexture(video);

videoTexture.colorSpace = THREE.SRGBColorSpace;

const colorMaterial = new THREE.MeshBasicMaterial({
  map: videoTexture,
  transparent: true,
  alphaTest: 0.5,
  side: THREE.DoubleSide,
  depthWrite: false,
});

const depthMaterial = new THREE.MeshBasicMaterial({
  map: videoTexture,
  alphaTest: 0.5,
  side: THREE.DoubleSide,
});

Video Texture를 사용하여, colorMaterial과 depthMaterial을 각각 생성한다.

const geometry = new THREE.PlaneGeometry(10, 10);
const mesh = new THREE.Mesh(geometry, colorMaterial);

mesh.customDepthMaterial = depthMaterial;
mesh.visible = true;
mesh.receiveShadow = false;
mesh.castShadow = true;
mesh.material.colorWrite = false;

그리고 plane geometry를 사용하여 mesh를 생성하는데, customDepthMaterial에 앞서 생성한 depthMaterial을 할당한다.

그러면 나무 모양의 그림자가 렌더링됨을 확인할 수 있다.

2. 문제

상 : 나무 그림자 active
하 : 나무 그림자 inactive

하지만 plane mesh 아래에 존재하는 모델의 그림자 생성을 막아버린다.

나무와 장작의 그림자를 동시에 렌더링 하기위해서, three.js가 그림자를 만드는 방법에 대해 간략히 알아보았다.

Light의 시점에서 scene을 한번 렌더링 한다.
각 픽셀마다 라이트에서 가장 가까운 depth를 shadow map에 저장한다.
메인 렌더의 fragment shader에서, 특정 표면이 해당 depth 보다 뒤에 있으면 그림자라고 판단한다.

결국 그림자가 만들어지지 않는 이유는, 광원의 shadow camera 시점에서 plane이 사물보다 앞에 있어 가장 가까운 depth로 기록된. 그 결과 뒤쪽 사물의 fragment는 shadow map에 자신의 depth를 기록할 수 없게된다.

3. 해결

plane을 shadow map에 렌더링 할때, 빛을 통과시켜야하는 영역의 fragment를 discard 시키면 된다.

three.js에서는 material 생성시 alphaTest 수치를 설정할 수 있으며, fragment shader에서 이 alpha 값이 지정된 수치보다 낮다면, discard를 발생시켜 shadow map에 depth를 기록하지 않게 된다.

그리고 three.js는 해당 판정코드를 수월하게 작성 할 수 있도록, alphatest_fragment 청크를 제공하며, 아래와 같이 쉐이더 코드를 삽입하면 된다.

const ALPHA_TEST_FRAGMENT_CHUNK = "#include <alphatest_fragment>";

const GOBO_LUMINANCE_ALPHA_MASK = `
float goboLuminance = dot(diffuseColor.rgb, vec3(0.299, 0.587, 0.114));
diffuseColor.a = 1.0 - goboLuminance;
${ALPHA_TEST_FRAGMENT_CHUNK}
`;

4. 결과

모든 그림자 렌더링된다.

이러한 문제가 발생한 원인은 아래와 같이 정리할 수 있다.

customDepthMaterial에 의 shadow pass에서 어떤 fragment가 유효한 caster로 남을지 결정된다
원본 plane의 형상에 맞춰 shadowMap의 depth가 기록된다.
분명 그림자가 없는 fragment 임에도, discard 판정이 없지만 depth 판정은 발생하는 비직관적인 현상이 발생

결국 시각적으로는 비어 있거나 빛이 통과해야 하는 영역인데도, shadow map에는 plane의 가까운 depth가 기록되어 그림자가 있는 것으로 잘못 판정된 현상이다.

본문에서는 alphaTest와 fragmentShader의 alpha 값을 통한 discard로 해결하는 방법을 사용했지만, rgb값을 통해 마스크를 재해석 하는 방법이 아니라, alphaMap을 사용하는 방식이 더 안정적이라는데, 다음에 테스트 해봐야겠다.

depthMaterial.alphaMap = maskTexture;
depthMaterial.alphaTest = 0.5;

아울러 three.js의 렌더링 파이프라인에 대해서 심도있게 학습하고, Shadow Map, Depth Test, Discard에 대해서도 제대로 정리해야겠다.

4. Principled BSDF

scarecrow1992 — Wed, 10 Jun 2026 13:38:22 +0900

https://docs.blender.org/manual/en/latest/render/shader_nodes/shader/principled.html

Principled BSDF - Blender 5.1 Manual

Previous Metallic BSDF

docs.blender.org

1. 소개

Blender3d에서제일 흔하게 사용되는 표면 셰이더 노드

OpenPBR Surface shading model을 기반으로 두기 때문에, 업계 표준 PBR 셰이더들과의 호환이 가능하다.

주로 Material Output 노드의 Surface 슬롯과 연결된다.

2. 특징

모델의 표면이 빛과 어떻게 상호작용 할지를 결정한다.

해당 노드로 구현가능한 대표적인 재질들은 아래와 같다.

플라스틱
금속
유리
고무
도자기
피부
페인트
나무
반투명 재질
etc

2-1. BSDF 란?

BSDF는 Bidirectional Scattering Distribution Function의 약자이다.

간단히 말하면, 표면에 들어오는 빛이 어느 방향으로, 얼마나 반사되거나 투과되는지 결정하는 함수 를 칭한다.

그리고 Pricinpled BSDF는 함수를 PBR 방식으로 처리한다.

2-2. PBR 이란?

PBR은 Physically Based Rendering의 약자이며 한국어로 "물리 기반 렌더링" 이라고 칭한다.

과거에는 질감 표현을 위해 Diffuse Color, Specular Color, Shininess 등의 매개변수를 사용했으며, 기본색, 하이라이팅 색, 반짝임 정도를 아티스트가 직접 결정하였다.

반면 오늘날에는 Base Color, Metalic, Roughness, Normal 등의 매개변수가 제공되며, 이는 조명이 바뀌어도 재질의 물성은 유지되며, 비교적 일관되게 보인다는 장점이 있다.

PBR(Physically Based Rendering)을 위한 다양한 매개변수들이 제공되며, GLB 와의 호환성이 높기 때문에, Three.js 나 Unity/Unreal 같은 3d 라이브러리 및 엔진으로의 export/import 가 안정적인 편이다.

3. 레이어

Pricipled BSDF 의 질감표현은 여러 재질 반응들을 층층히 쌓아올려 혼합되는 구조이다.

특히 node 상에서는 각 입력들이 별개로 들어오는것처럼 보이지만, 실제로는 서로 다른 input에 영향을 줄 수 있는 구조이다. 가령 Duffuse와 Subsurface는 Specular의 하위에 있으며, 선택적 광탱 코팅(coat)와 광택층(Sheen)은 다른 모든 레이어 위에 존재하는데, coat는 아주 얇은층을 표현하며, sheen은 먼지/보풀의 표현을 담당한다. Emission은 자체 발광을 담당한다.

실무적으로는 우선 아래 정도로만 이해하자

Base Layer: metalness, roughness 등 기본 재질정보
Specular Layer: 표면이 빛을 어떻게 반사하는가
Coat Layer: 투명 코팅이 있는가
Sheen Layer: 보풀,먼지,섬유감이 있는가
Emission: 스스로 빛을 내는

4. Metallic 과 Roughness

(작성중)

https://www.reddit.com/r/blender/comments/jxz6fk/whats_the_difference_from_the_roughness_and/

3. Displacement Node

scarecrow1992 — Tue, 9 Jun 2026 20:24:47 +0900

1. 소개

https://docs.blender.org/manual/en/latest/render/shader_nodes/output/material.html

Material Output 노드의 Displacement 슬롯에 전달되는 노드이다.

일반적으로 Texture / Noise / Height Map 등의 노드들이 Displacement 노드와 연결된 뒤, Output과 연결된다.

표면에서의 빛과의 상호작용에만 관여하는 Surface, Volume 슬롯과 달리, Displacement는 geometry가 변형되는 방향과 강도등을 결정하며, 이에따른 자연스러운 연출을 위해 Normal 등의 정보를 가공한다.

즉, 모델의 외형에 직접적으로 영향을 주는 노드이다.

2. 사용

왼쪽 : 큐브, 중앙 : subdivde 적용된 큐브, 오른쪽 : subdivision 5 Ico Sphere

geometry의 좌표를 직접 변형하기 때문에, vertex가 많을수록, 섬세하게 나뉘는것을 볼 수 있다.

그러므로 주로 subdivision 및 shade smooth와 함께 사용된다.

이를통해 표면이 울퉁불퉁한 모델도, 쉐이더만으로 질감을 표현할 수 있다.

solid view (edit mode) (subdivision 적용)

displacement scale : 0.001

displacement scale : 0.01

3. Material Setting

Displacement 효과를 올바르게 적용 위해선, Material Setting을 설정해야한다.

해당 옵션을 통해, Material Output의 Displacement 슬롯을 통해 들어온 정보를 렌더러가 어떻게 해석할지 결정한다.

Setting-Surface 카테고리의 Displacement 항목에서 3가지 옵션을 제공하며, 각 옵션의 적용 결과는 아래와 같다.
( displacement scale 0.01 적용)

Bump Only

Displacement Only

Displacement and Bump

Bump는 실제 지오메트리를 변경시키진 않음을 확인 가능하다.

하지만, 표면의 normal 을 변경시키므로, 굴곡 효과를 줄 수 있다.

그러므로 표면의 vertex가 세밀하게 나뉘어진 모델이 아니라면, output material의 displacement는 비워두고, shader nodes에 normal 데이터를 전달하는것이 유용할 수 있다.

4. Render Engine과 Displacement

https://docs.blender.org/manual/en/latest/render/eevee/limitations/limitations.html

공식문서에 의하면, EEVEE 렌더 환경에서는 flat shaded 가 적용된 표면이 삼각형으로 분리될 수 있음을 알려준다.

실제로 아래와 같이 vertex가 충분히 나뉘어지지 않은 모델에 한해서는, displacement 결과가 부정확하게 렌더링 됨이 확인된다.

EEVEE 엔진 & Shade Smooth 적용 전

EEVEE 엔진 & Shade Smooth 적용 후

2. Material Output 노드

scarecrow1992 — Tue, 9 Jun 2026 19:39:09 +0900

https://docs.blender.org/manual/en/latest/render/shader_nodes/output/index.html

1. 소개

Output 노드는 트리의 마지막에 위치하는 노드이며, 출력을 담당
여러개를 추가할 수 있지만, 하나만 사용됨
출력 노드 직전에는 항상 Shader 노드가 오지만, Material Output의 Displacement 는 예외

2. 종류

Material Output
Light Output
World Output
AOV Output

2-1. Material Output

3d 모델의 표면에 덧입혀 재질의 출력을 담당하는 노드이다.

다른 Output 노드들과 달리, Shader Node 이외에도 Displacement를 입력으로 받을 수 있다.

Surface : 표면에서의 빛 처리
Volume : 객체 내부의 부피에 대한 빛 처리
Displacement : 표면의 위치 정보 처리

1) Surface

물체의 표면과 빛의 상호작용을 담당

주로 Principled BSDF와 같은 Shader Node의 출력을 받는다.

즉, 단순히 색 뿐만 아니라, 빛반사/거칠기/금속/굴절/발광 등의 데이터를 받을 수 있다.

주로 아래의 Shader Node 들과 연결된다.

Pricipled BSDF : 대부분의 PBR 매터리얼을 구현하기 위해 사용됨
Diffuse BSDF : 빛을 여러방향으로 고르게 확산시키는 반사 쉐이더
Glossy BSDF : 거울반사에 사용
Glass BSDF: 유리의 반사와 굴절
Transparent BSDF : 표면을 투명하게 통과시

2) Volume

객체 내부의 부피에 대한 빛 처리를 담당한다.

안개, 연기, 구름, 유리, 수면 내부, 발광 매질(용암, 마법...) 등의 빛 처리를 담당한다.

주로 아래의 Shader Node 들과 연결된다.

Volume Absorption : 빛을 흡수함
Volume Scatter : 빛을 산란시킴
Principled Volume : 흡수, 산란, 방출을 통합적으로 제어

3) Displacement

표면의 위치를 어떤방향으로, 얼마나 밀어낼지 결정하며, 굴곡효과를 주기 위해 Normal 등의 특성도 가한다.

색이나 반사 특성을 결정하는것이 아닌, 표면의 위치 정보를 바꾸는 정보를 전달한다.

일반적으로 Texture / Noise / Height Map 등의 노드들이 Displacement 노드와 연결된 뒤, Output의 Displacement 슬롯으로 연결된다.

왼쪽 : 큐브, 중앙 : subdivde 적용된 큐브, 오른쪽 : subdivision 5 Ico Sphere

geometry의 좌표를 직접 변형하기 때문에, vertex가 섬세하게 나뉘어져 있을수록, 섬세하게 나뉘는것을 볼 수 있으며,

주로 subdivision 및 shade smooth 기능과 함께 사용하면 편리하다.

1. 소개

scarecrow1992 — Tue, 9 Jun 2026 18:16:52 +0900

https://docs.blender.org/manual/en/latest/render/shader_nodes/introduction.html

Introduction - Blender 5.1 Manual

Previous Shader Nodes

docs.blender.org

1. Shader Node 란?

쉐이더 언어나, 컴파일, gpu 자원관리, 선형대수학, 렌더링파이프라인 등, 복잡한 3d 렌더링 지식 없이도 material 이나 특수효과들의 생성/편집을 편리하게 수행하게끔 해주는 기능을 Shader Node라 한다.

3d 모델 위에 덧입혀질 material의 색상이나, 재질, 형상등을 shader node를 통해 설정할 수 있다.

2. 종류

노드는 크게 아래와 같은 범주로 나뉜다.

역할	설명	예시
Input	좌표, 오브젝트 정보, UV, 카메라 정보 등 외부/장면 데이터 제공	Texture Coordinate, Geometry, Object Info, Attribute
Texture	이미지나 절차적 패턴 생성	Image Texture, Noise Texture, Voronoi Texture
Color	색 보정/색 조합	ColorRamp, Hue/Saturation, Mix Color
Vector	좌표/방향/노멀/범프/디스플레이스먼트 조작	Mapping, Bump, Normal Map, Vector Math
Converter	값 변환, 범위 매핑, 분리/결합, 수학 연산	Math, Map Range, Clamp, Separate/Combine
Shader	실제 표면/볼륨/광학 반응 정의	Principled BSDF, Glass BSDF, Emission
Output	최종 머티리얼/월드/라이트 출력	Material Output, World Output

쉐이더 노드의 기본적인 흐름은 아래와 같다는 정도로 이해한다.

1. Input을 통해 입력이 접수됨
2. 여러 노드들을 통해 입력값을 가공
3. Shader Node를 통해, 여러 레이어의 결과를 하나로 합침
4. Output Node로 최종 정보를 출력

3. 엔진

blender3d에서는 주로 EEVEE와 Cycles 2종류의 엔진이 사용된다.

EEVEE는 실시간렌더링에 특화된 래스터라이저 엔진으로, 실시간성이 중요한 게임엔진과 유사하다. 정확한 렌더링 결과보다는 실시간성에 초점을 맞추었다. 최적화를 위해 baking, screen space reflection 등 눈속임이 많다.

Cycles는 레이트레이싱을 사용하며, 물리적으로 정확한 렌더링을 수행하는데 특화되어있다. 하지만 한장의 장면을 렌더링 하기 위한 시간과 자원이 EEVEE 보다 오래 걸리므로, 건축 시각화나 영화처럼 사전 녹화가 가능한 분야에 널리 사용된다.

사용하기에 따라서, EEVEE 도 Cycles 못지 않게 사실적이로 스타일리시한 화면을 렌더링 할 수 있다.

WebGL과 GLSL

scarecrow1992 — Sat, 30 May 2026 14:00:11 +0900

참고

https://webglfundamentals.org/webgl/lessons/ko/webgl-fundamentals.html

https://webgl2fundamentals.org/webgl/lessons/ko/webgl-fundamentals.html

1. 소개

WebGL은 브라우저의 <canvas> context를 통해 GPU를 사용하여 2D/3D 렌더링을 가속하기위한 API 이다. Scene이나 Camera 같은 추상화된 정보 없으며, 점/선/삼각형을 렌더링 하기 위해 GPU 정점, 쉐이더,텍스처, 상태를 전달하고 draw call을 실행하는 저수준기능만을 제공한다. 쉐이더는 GPU의 각 파이프라인에 실행되는 프로그램이며, GLSL은 이 쉐이더를 작성하기 위한 언이다.

WebGL은 WebGL과 WebGL2 두가지 버전으로 나뉘는데, WebGL1의 번거로움을 해결하기 위한 여러 extension들을 WebGL2에서 표준기능으로 포용한 버전에 가깝다. Three.js의 WebGLRenderer는 WebGL2를 사용중이며, r163 이후의 버전부터 WebGL1을 지원하지 않는다.(링크) 그렇다고 WebGL2가 단순히 WebGL1의 extension들을 공식 기능으로 도입만 한것은 결코 아니다. 특히 UBO나 MRT 관련 기능들을 WebGL1에서 구현하기 위해서는 수많은 draw call이나 복잡한 shader가 필요하며 이는 성능차이로 이어질 수 있다. 즉, WebGL2은 WebGL1의 extension을 단순히 포함하기만하는 래퍼로써의 기능이 아닌, 상위호환격인 별도의 API라고 보는것이 옳다.

GLSL(OpenGL Shading Language)는 OpenGL 계열 그래픽 API에서 GPU Shader를 작성하기 위한 C계열 언어이다. 브라우저라는 한정된 환경에서 효율적인 렌더링을 위해, 경량화된 그래픽 API인 OpenGL ES를 웹에 맞게 설계한것이 WebGL이며, 이에따라 shading 언어도 GLSL을 사용하게되었다. Three.js에서는 GLSL ES를 사용중이며 기본적으로 GLSL ES 1.00을 사용하되, GLSL ES 3.00도 지원한다.

2. 버전별 정보

WebGL1/2와 GLSL ES 1.00/3.00 버전차이에 따른 차이점을 간략히 정리하고자한다.

2-1) WebGL1 / 2

WebGL1의 불편함을 감수하기 위해 제공되던 Extension들을 공식 기능으로 도입한것이 WebGL2이다.

대표적으로 VAO가 있으며, vectex attribute에 대한 데이터 관리를 효율적으로 추상화하는데 유용하다.

더 자세한 정보는 링크에 정리되어 있으며, 주요 차이는 아래와 같이 정리된다.

VAO(Vertex Array Object) 지원
instancing 지원
MRT(Multi Render Target)
텍스쳐 타입 명시
- gl.R8. gl.RGBA8, gl.R32F, gl. DEPTH_COMPONENT24 , gl. DEPTH24_STENCIL8...
UBO(Uniform Buffer Object) 지원
Transform Feedback : vertex shader의 출력을 버퍼에 저장
Texture Array ( gl. TEXTURE_2D_ARRAY)
- 타일맵, sprite atlas, material array
sampler 타입 확대

uniform sampler2D colorMap;
uniform isampler2D idMap;
uniform usampler2D objectIdMap;
uniform sampler2DShadow shadowMap;
uniform sampler3D volumeMap;
uniform sampler2DArray arrayMap;

object picking, clustered lighting, shadow mapping, volume rendering 등에 활용 가능

2-2) GLSL ES 1.00 / 3.00

GLSL ES의 1.00에서 3.00 버전업에 따른 주요 변화는 아래와 같다.

1) 암묵적 인터페이스에서 명시적인 인터페이스로

GLSL ES 1.00은 내장상태에 기대 암묵적으로 포용되던 관용구나 셰이더 언어들이 존재한다.

가령, 1.00 버전의 fragment shader 코드는 기본적으로 아래와 같다.

attribute vec3 position;
varying vec2 vUv;

void main() {
  gl_FragColor = vec4(1.0);
}

이 코드에서는 여러 정보들 언어차원에서 사실상 고정되어있다. 가령 gl_FragColor 또는 gl_FragData이다. 또한 vertex input은 attribute, stage간 전달은 varying, 텍스쳐 샘플링은 texture2D, textureCube 키워드로 정의된다.

하지만 3.00 버전의 shader 코드는 아래와 같다.

#version 300 es
layout(location = 0) in vec3 position;

out vec2 vUv;

#version 300 es
precision highp float;

in vec2 vUv;

layout(location = 0) out vec4 outColor;
layout(location = 1) out vec4 outNormal;

void main() {
  outColor = vec4(1.0);
  outNormal = vec4(0.0, 0.0, 1.0, 1.0);
}

정해진 이름의 내장 변수(gl_FragColor)에 쓰는 방식이 아닌, 셰이더가 자신의 입출력 인터페이스를 직접 선언하는 방식으로 바뀌었음이 확인된다.

GLSL ES 3.00은 고정적이고 관례적인 작성법을 탈피하여, 셰이더코드가 더 많은 GPU리소스 파이프라인 기능을 명확하게 표현하도록 탈바꿈되었음을 알 수 있다.

2) 색 계산이 아닌 데이터 연산 중심으로

1.00은 화면에 표기하기 위한 색상 출력에 집중되어 있다. 그렇기에 fragment shader의 최종 출력값도 사실상 gl_FragColor로 고정되며, 데이터 표현도 float vector 중심이다.
(vec2, vec3, vec4, sampler2D, samplerCube)

3.00은 색상 계산만이 아닌, GPU기반 데이터연산 중심으로 발전하였으며, 보다 다양한 데이터 타입과 연산들을 지원한다.
(uint, uvec2, uvec3, uvec4, isampler2D, sampler3D, sampler2DArray, bitwise Operation, texelFetch, textureSize, uniform blocks...)

즉, 기존 1.00 에서는 색상/좌표/법선과 같은 그래픽 데이터 중심이었다면, 3.00에서는 Id, index, 플래그, 레이어, uniform block 등 다양한 데이터에 대한 연산을 중심으로 확장되었다.

가령 1.00에서는 picking을 위해 id를 vec4 타입의 색상정보로 우회 표기해야했다.

gl_FragColor = vec4(encodedIdColor);

하지만3.00에서는 직접적으로 정수데이터를 다룰 수 있다.

#version 300 es
precision highp float;
precision highp usampler2D;

flat in uint vObjectId;

layout(location = 0) out uint outObjectId;

물론 int형 render target을 쓰기 위해서는 texture/render target 포맷 framebuffer 조건도 맞는 등 여러 조건이 따라오지만, 철학자체는 그래픽 렌더링(float only)에 그치지 않고, 범용 데이터 연산 방식으로 옮겨졌음을 확인할 수 있다.

1.00과 3.00의 주요 차이는 아래와 같이 정리될 수 있다.

GLSL ES 1.00	GLSL ES 3.00	목표
attribute	in	stage input 일반화
varying	out / in	stage 간 인터페이스 일반화
gl_FragColor	사용자 정의 out	출력 타겟 명시
texture2D, textureCube	texture	sampler 기반 함수 오버로드
gl_FragData[i]	layout (location) out	MRT 출력 명시

3. WebGL과 GLSL

WebGL은 GPU를 통해 점/선/면을 그리거나 일반 데이터를 연산하기 위한 API 이며, GLSL은 GPU에서 동작하는 프로그램을 작성하는 언어이다.

즉, 둘은 함께 사용되어야만 하는 관계이므로 버전별 호환성이 중요하다.

WebGL과 GLSL 간의 버전 호환은 간단히 아래와 같이 정리될 수 있다.

컨텍스트	GLSL
WebGL1	GLSL ES 1.00
WebGL2	GLSL ES 1.00 & 3.00

사실상 WebGL1은 GLSL ES 1.00 호환되며, WebGL2는 GLSL ES 3.00과 호환된다고 보면 된다.

WebGL2도 GLSL ES 1.00 을 사용 가능하지만, WebGL2의 여러 기능들 (UBO, MRT 등)을 본격적으로 쓰기 위해선 3.00 사용이 권장된다.

3-1) Three.js 환경

Three.js 의 THREE.WebGLRenderer는 WebGL2만을 지원한다. 하지만 three.js에 내장된 MeshStandardMaterial와 MeshPhysicalMaterial 등의 매터리얼등은 GLSL ES 1.00 으로 작성되었다. 또한 THREE.ShaderMaterial과 THREE.RawShaderMaterial도 glslVersion: THREE.GLSL3 옵션을 넘기지 않는다면, 1.00버전으로 컴파일된다.

하지만 ShaderMaterial을 3.00으로 생성하여도, 1.00 과 마찬가지로 기본적인 uniform 이나 attribute 정보들은 Three.js가 직접 전달해준다.

[THREE.ShaderMaterial - 1.00]

const material = new THREE.ShaderMaterial({
  vertexShader: `
    attribute vec3 position;
    attribute vec3 normal;
    attribute vec2 uv;

    uniform mat4 modelViewMatrix;
    uniform mat4 projectionMatrix;

    varying vec2 vUv;

    void main() {
      vUv = uv;
      gl_Position = projectionMatrix * modelViewMatrix * vec4(position, 1.0);
    }
  `,
  fragmentShader: `
    precision highp float;

    varying vec2 vUv;

    void main() {
      gl_FragColor = vec4(vUv, 0.0, 1.0);
    }
  `
});

[THREE.ShaderMaterial - 3.00]

const material = new THREE.ShaderMaterial({
  glslVersion: THREE.GLSL3,

  vertexShader: `
    in vec3 position;
    in vec3 normal;
    in vec2 uv;

    uniform mat4 modelViewMatrix;
    uniform mat4 projectionMatrix;

    out vec2 vUv;

    void main() {
      vUv = uv;
      gl_Position = projectionMatrix * modelViewMatrix * vec4(position, 1.0);
    }
  `,

  fragmentShader: `
    precision highp float;

    in vec2 vUv;
    out vec4 outColor;

    void main() {
      outColor = vec4(vUv, 0.0, 1.0);
    }
  `
});

그렇기 때문에 ShaderMaterial 이나 RawShaderMaterial 을 통해 쉐이더를 직접 생성할 경우, 가급적 ES 3.00 버전으로 생성하고 해당 양식에 맞추어 작성하는것이 권장되나,

built-in material에서 shader chunk를 통해 replace 하는 방식으로 shader 코드를 가공한다면, ES 1.00 버전을 기준으로 작성해야한다.

1. WebGL2 기본 API 정리

scarecrow1992 — Tue, 7 Apr 2026 21:46:21 +0900

https://webgl2fundamentals.org/webgl/lessons/ko/webgl-fundamentals.html

https://webgl2fundamentals.org/webgl/lessons/resources/webgl-state-diagram.html

WebGL2 초기화 및 렌더링 사이클을 위한 기본적인 API 사용방법 및 자주 사용되는 패턴들을 내 나름대로 정리해보았다.

웹/게임을 가리지않고 개발이란 결국 데이터를 읽고, 쓰고, 만들고, 지우는 과정의 반복이라 생각한다.

그렇기에 Webgl2의 주요 리소스들을 CRUD 관점에 맞추어 API를 정리하였다.

	program	shader	vertex array	buffer	texture
생성	createProgram	createShader	createVertexArray	createBuffer	createTexture
바인	linkProgram	attachShader detachShader	bindVertexArray	bindBuffer	bindTexture
작업	uniform1i uniform3fv uniformMatrix4fv uniformMatrix4fv	shaderSource compileShader	vertexAttribPointer	bufferData	texImage2D texParameteri generateMipmap activeTexture
참조	getAttribLocation getUniformLocation
제거		deleteShader

gpu 자원과 cpu 자원을 별도의 함수로 순차적으로 호출하고, 작업을 진행하는 방식이 다소 비직관적이었다.

가령 buffer와 attribute를 한데 묶어서 호출하는 방식이 아니라, 전역 상태에 원하는 리소스를 먼저 바인딩하고(bindBuffer), 이에 대한 작업 함수를 호출하는 방식(bufferData)이라 다소 비직관적이게 느껴젔다.

하지만 global 하게 관리되는 webgl 상태가 존재하고, 해당 상태에 설정된 대상에 대해 작업을 수행한다는 발상으로 접근하니 어느정도 이해가 갔다.

결정적으로 두번째 링크에서 매 코드 라인마다 webgl의 상태를 다이어그램으로 가시화해주었기 때문에 코드를 이해하기 한결 간편했다.

1. Shader와 Program

정점의 위치를 계산하기 위한 vertex shader와 각 픽셀의 색상을 결정하는 fragment shader의 쌍으로 구성된다.

vertex는 각 정점에 대해 수행되며, 이들로부터 보간된 데이터가 fragment shader로 전달된다.

vertex shader는 GPU에 존재하는 데이터만 읽을 수 있으며,

데이터를 보내는 방법은 아래와 같다.

1) Attribute, Buffer, Vertex Array

vertex shader에서 in 예약어로 정의되는 변수에 대응되는 데이터이다.

각각의 vertex 마다 할당 되어야 하는 데이터들이 전달되며, vertex 자체의 위치, 법선, uv 좌표, 색상 등의 정보를 전달한다.

Buffer: GPU에 올라가는 바이너리 데이터 배열이다. 일반적으로 각 정점에 대한 실제 정보들이 전달되며 주로 위치, 법선, uv 좌표, 색상 등이 전달된다.
Attribute: 버퍼에서 데이터를 읽어 오기 위한 일종의 명세이다. 타입, 위치, 이동수치 등의 데이터가 attribute에 보관된다.
VAO(Vertex Array Object) : 각각의 attribute가 사용할 버퍼가 무엇인지, 버퍼로부터 데이터를 어떻게 추출할지, location 정보가 어떻게 되는지 등, attribute의 상태가 저장된다.

버퍼는 랜덤 접근이 불가능하며, attribute에서 지정한 크기만큼 vertex shader에 전달된다.

사실 webgl 코드에서는 attribute는 별도의 create api가 주어지지 않기에 그 실체가 모호한 기분이며, 이름 그대로 속성(Attribute)처럼 다가온다.

실제로 program에서 attribute info는 gl.linkProgram 호출시점에 shader 코드의 상태에 따라 결정되고, 개발자는 해당 info에 맞추어 shader에 전달하기 위한 데이터를 buffer에 담고, 해석 정보를 vertex array에 구현하면 될 뿐이다.

attribute에 데이터를 전달하는 스켈레톤 코드는 아래와 같다.

const positionLoc = gl.getAttribLocation(prg, 'position');

// vertex positions for a cube
const cubeVertexPositions = new Float32Array([
    1, 1, -1, 1, 1, 1, 1, -1, 1, 1, -1, -1, -1, 1, 1, -1, 1, -1, -1, -1, -1, -1, -1, 1, -1, 1, 1, 1, 1, 1, 1, 1, -1, -1, 1, -1, -1, -1, -1, 1, -1, -1, 1, -1, 1, -1, -1, 1, 1, 1, 1, -1, 1, 1, -1, -1, 1, 1, -1, 1, -1, 1, -1, 1, 1, -1, 1, -1, -1, -1, -1, -1,
]);


const cubeVertexArray = gl.createVertexArray();
gl.bindVertexArray(cubeVertexArray);

const positionBuffer = gl.createBuffer();
gl.bindBuffer(gl.ARRAY_BUFFER, positionBuffer);
gl.bufferData(gl.ARRAY_BUFFER, cubeVertexPositions, gl.STATIC_DRAW);
gl.enableVertexAttribArray(positionLoc);
gl.vertexAttribPointer(
    positionLoc,  // location
    3,            // size (components per iteration)
    gl.FLOAT,     // type of to get from buffer
    false,        // normalize
    0,            // stride (bytes to advance each iteration)
    0,            // offset (bytes from start of buffer)
);

앞서 쉐이더 코드를 보면 position 은 vec4로 선언되었고, attribute info 도 분명 FLOAT_VEC4 타입인데, 정작 vertex array에는 size 3으로 설정되었다. 행렬 계산을 위해선, 배열로부터 translate의 영향을 받기 위해 마지막 원소가 자동으로 1로 채워져야 할것같은데, 해당 부분은 정확한 확인이 필요할것같다.

2) Uniform

모든 셰이더 프로그램이 동시 참조하는 전역변수이다.

가령 "각각의 vertex에 대한 좌표" 정보는 vertex마다 다른 정보이므로 attribute로 전달되어야 하지만, "모델의 transform matrix"는 모든 vertex가 동시에 참조해도 충분하므로 Uniform으로 전달하면된다.

uniform 은 데이터가 이진데이터와 비이진데이터로 크게 2가지로 나뉜다,

2-1) binary uniform

이진 배열의 형태로 표현 가능한 데이터. 주로 transform matrix, light intensity, light dir 등의 정보가 전달된다.

다이어그램 상으로는 program 내에 직접 보관되는것으로 보이며,

비교적 간단한 절차로 설정할 수 있다.

const modelViewLoc = gl.getUniformLocation(prg, 'modelView');
gl.uniformMatrix4fv(modelViewLoc, false, modelView);

다이어그램 상으로는 localtion이 안보이지만, getUniformLocation 함수로 봐선 실제 location 자체는 존재하는것으로 고려된다.

절차가 간단한 만큼, 매 렌더링 마다 달라질 수 있는 데이터를 전달하는데에도 적합해보인다.

(transform 데이터 등)

2-2) non-birary uniform (Texture)

이진 배열 형태로 표현 불가능한 데이터들이며, 주로 diffuse, ao, normal 등의 텍스처 정보들이 전달된다.

이러한 특수성 때문에 리소스 자체는 webgl에 의해 직접 관리되며, program에서는 location으로 간접 참조하는 방식으로 접근하는것으로 보인다.

그렇기에 전체적으로 아래와 같이 다소 복잡한 절차를 따른다.

텍스처 생성
webgl에 bind
uniform 로케이션 맵

// 1. 텍스처 생성
const checkerTexture = gl.createTexture();
gl.bindTexture(gl.TEXTURE_2D, checkerTexture);
gl.texImage2D(
    gl.TEXTURE_2D,
    0,                // mip level
    gl.LUMINANCE,     // internal format
    4,                // width
    4,                // height
    0,                // border
    gl.LUMINANCE,     // format
    gl.UNSIGNED_BYTE, // type
    new Uint8Array([  // data
      192, 128, 192, 128,
      128, 192, 128, 192,
      192, 128, 192, 128,
      128, 192, 128, 192,
    ]));
gl.texParameteri(gl.TEXTURE_2D, gl.TEXTURE_MIN_FILTER, gl.NEAREST);
gl.texParameteri(gl.TEXTURE_2D, gl.TEXTURE_MAG_FILTER, gl.NEAREST);
gl.texParameteri(gl.TEXTURE_2D, gl.TEXTURE_WRAP_S, gl.CLAMP_TO_EDGE);
gl.texParameteri(gl.TEXTURE_2D, gl.TEXTURE_WRAP_T, gl.CLAMP_TO_EDGE);

// 2. webgl 등록
const diffuseLoc = gl.getUniformLocation(prg, 'diffuse');
let texUnit = 6;
gl.activeTexture(gl.TEXTURE0 + texUnit);
gl.bindTexture(gl.TEXTURE_2D, checkerTexture);

// 3. uniform location 맵핑
gl.uniform1i(diffuseLoc, texUnit);

webgl2fundamentals 문서에서는 각각 uniform과 texture라는 별도의 방법으로 안내해주긴 하지만,

shader 코드상에서는 uniform으로 전달되고, 코드상에서도 간접적으로나마 참조되기 때문에 하나의 범주로 묶어 정리하였다.

3) varying

한마디로, vertex shader(out)에서 fragment shader(in)로 보내는 값이다.

해당 데이터는 해당 픽셀이 속한 폴리곤을 구성하는 3개의 vertex로부터 보간되어 내려보내진다.

WebGL 1.0 에서는 varying 을 사용하지만, 최신 OpenGL/ WebGL2.0 에서는 in/out 키워드로 대체되었다.

사용법은 그냥 직관적으로 shader내에서 사용하면된다.

대신 vertex/fragment 양측 쉐이더에서 동일한 이름과 형식을 사용해야한다.

// 버텍스 셰이더
varying vec3 vColor; // 프래그먼트로 전달할 변수
attribute vec3 aColor;

void main() {
    vColor = aColor; // 속성값을 varying에 할당
    gl_Position = ...;
}

// 프래그먼트 셰이더
varying vec3 vColor; // 버텍스에서 보간된 값을 받음

void main() {
    gl_FragColor = vec4(vColor, 1.0); // 보간된 색상 적용
}

Feature-Sliced Design (FSD)

scarecrow1992 — Sat, 14 Feb 2026 20:43:09 +0900

https://feature-sliced.design/

1. 소개

Feature-Sliced Design(FSD)는 대규모 프론트엔드 애플리케이션을 기능 중심(Feature-Driven) 으로 구조화 하는 아키텍쳐 방법론이다.

핵심 철학
파일을 기술(components, hooks) 기준이 아니라 비즈니스 기능 기준으로 나눈다.

아래와 같이 기술 중심으로 설계할 경우

/components
/hooks
/pages
/utils
/store

이 구조는 프로젝트가 커질수록 아래의 문제가 발생한다.

컴포넌트 하나를 구성하는 요소들이 여러 폴더에 산재됨
기능 하나를 수정하기 위해 여러 폴더를 오가야함
재사용 경계가 모호
기능 단위 분리가 어려움

대규모 프로젝트의 핵심은 갈수록 복잡해지는 의존성 문제를 어떻게 풀어낼것인가에 있다.

FSD는 이를 해결하기 위해

상위에서 하위로 순방향 참조를 가진 레이어를 구성하고
기능 중심으로 구조를 설계하여
구조를 무너뜨리지 않고, 순환참조를 방지하며, 확장성을 유지할 수 있다.

2. 구조

FSD는 레이어(Layer), 슬라이스(Slice) 그리고 세그먼트(Segments)으로 프로젝트를 구성한다.

2-1. 레이어(Layer)

각 레이어는 의존성이 단방향이다.

아래 레이어는 상위 레이어를 몰라도 되지만,

상위 레이어는 하위 레이어를 사용할 수 있다.

즉, 상위 레이어는 하위 레이어를 포함한다.

app → pages → widgets → features → entities → shared

종류

총 7개로 구성된다.

App - 앱을 실행하는 모든것 (라우팅, 진입점, 글로벌 스타일, provider 등)
Process(deprecated) - 복잡한 페이지 내부 시나리오
Pages - 전체 페이지 또는 중첩된 라우팅 방식의 페이지 일부
Widgets - 큰 독립형 기능 덩어리나 UI, 전체 use case를 제공
Features - 사용자에게 비즈니스 가치를 제공하는 행동 단위
Entities - 비즈니스 엔티티 (User, Product 등)
Shared - 재사용 가능한 기능

1) app - 앱 초기화 레이어

역할

라우팅 설정
전역 스타일
전역 Provider
스토어 세팅

예:

app/
  providers/
  router/
  index.tsx

2) pages - 페이지 단위

URL 단위 화면
여러 widget을 조합하여 페이지를 구성한다.

예:

pages/
  login/
  profile/
  dashboard/

3) widgets - 복합 UI 블록

여러 feature + entity를 조합 하여 UI 블록을 구성한다.
독립적인 화면 블록

예:

widgets/
  header/
  sidebar/
  post-list/

4) features - 사용자 액션 단위

사용자가 할 수 있는 동작 단위

예:

로그인 하기
게시글 좋아요 누르기
댓글 작성하기

features/
  auth/
  add-comment/
  like-post/

5) entities - 비즈니스 도메인 객체

실제 데이터 모델 단위

예:

User
Post
Comment

6) shared - 공통 코드

UI kit
유틸 함수
API 클라이언트
공통 타입

shared/
  ui/
  lib/
  api/
  config/

2-2. Slices (슬라이스)

각각의 레이어를 기능 단위(Slice)로 나눈것
코드를 비즈니스 도메인별로 분할함으로써, 폴더명을 자유롭게 설정 가능
Slice 간에는 상호 참조가 불가능해야한다. (높은 응집력, 낮은 결합)

예 : features 레이어의 auth 슬라이스

features/
  auth/
    ui/
    model/
    api/
    lib/

2-3. Segments(세그먼트)

세그먼트 상위 레이어들은 파일을 기능(feature) 단위로 분류했지만, 세그먼트는 기술 단위로 분류한다.
세그먼트끼리는 상호 참조가 가능하다.
사실상 레이어를 구성하는 최소 단위이며, 분류는 표준화되어있다.

세그먼트 종류

ui : UI 디스플ㄹ레이와 관련된 모든것 (UI 컴포넌트, 날짜 포맷터, 스타일 등)
api : 백엔드 상호작용 코드
model : 데이터 모델 (스키마, 인터페이스, 저장소, 비즈니스 로직)
lib : 이 슬라이스의 다른 모듈들이 필요로 하는 라이브러리 코드
config : 구성 파일과 기능 플래

대부분의 앱에서는 위 세그먼트만으로 충분하지만, 필요에 따라 추가구성을 할 수 있다.