7.8 เทคนิค Real-Time Rendering

ทุกเทคนิคในบทนี้มีอยู่เพราะกฎข้อเดียวที่หลีกเลี่ยงไม่ได้: เกมต้องวาดภาพใหม่หลายครั้งต่อวินาที ตลอดเวลา โดยห้าม miss deadline เด็ดขาด renderer ของหนังสามารถใช้เวลาสิบนาทีต่อหนึ่งเฟรมของหนัง Pixar ได้ แต่ game engine มีเวลาแค่ไม่กี่มิลลิวินาที บทนี้พูดถึงกลเม็ดที่ engine ที่วางขายจริง — Unreal, Unity HDRP, และ engine ของสตูดิโออย่าง HoYoverse กับ Riot — ใช้เพื่อปลอมเงา, ทำขอบให้เนียน, แสงที่สะท้อนหลายทอด, และภาพสะท้อน ให้ดีพอและเร็วพอจนผู้เล่นไม่ทันสังเกตว่ามันเป็นทางลัด บทก่อนหน้าสอน rendering pipeline และ shader ในภาพรวมไปแล้ว (vertex เข้า pixel ออก) บทนี้จะพูดถึงเทคนิคที่มีชื่อเรียกเฉพาะ ซึ่งสร้างอยู่บน pipeline นั้น และทำให้ภาพ real-time ดูสมจริง

1. "Real-Time" คืออะไร: Frame Budget

เกมที่วิ่งที่ 60 frames per second (FPS, จำนวนภาพทั้งภาพที่แสดงต่อวินาที) ต้องทำเฟรมใหม่ให้เสร็จทุก 16.6 มิลลิวินาที (ms, หนึ่งในพันวินาที) ถ้าอะไรก็ตามในเฟรมนั้น — game logic, physics, animation, การ render — ใช้เวลานานกว่านั้น frame rate จะตกและเกมจะกระตุกให้เห็นชัด ขีดจำกัดเวลานี้เรียกว่า frame budget

#include <cstdio>

int main() {
    double target_fps = 60.0;
    double frame_budget_ms = 1000.0 / target_fps;
    printf("Target FPS: %.1f\n", target_fps);
    printf("Frame budget: %.3f ms\n", frame_budget_ms);
    return 0;
}

Output:

Target FPS: 60.0
Frame budget: 16.667 ms

16.667 ms คือ budget ทั้งหมด — game logic, physics, animation, audio, AI, และ rendering ต้องยัดใส่เข้าไปให้พอในนั้น และตัว rendering เองมักจะกินแค่บางส่วนของ budget นั้นด้วยซ้ำ เกมที่เล็ง 30 FPS จะได้ budget เพิ่มเป็นสองเท่า (33.3 ms) ส่วนเกมยิงแข่งขันที่เล็ง 120 FPS จะเหลือ budget น้อยกว่าครึ่งหนึ่ง (8.3 ms) ทุกเทคนิคในบทนี้คือการแลกเปลี่ยน: ซื้อความสมจริงได้เท่าไรด้วยกี่มิลลิวินาที

ทบทวน pipeline คร่าว ๆ จากบทก่อนหน้า: CPU ตัดสินใจว่าจะวาดอะไรแล้วส่งคำสั่งออกไป, GPU (Graphics Processing Unit) แปลง triangle เป็น pixel ผ่านขั้นตอน vertex shading, rasterization, และ fragment shading แล้วผลลัพธ์ก็ไปโผล่บนจอ

จากนี้ไปทั้งบทคือเรื่องที่เกิดขึ้นในคอลัมน์ GPU นั้น: จะเอาเงา, ขอบเนียน, แสงทางอ้อม, และภาพสะท้อนออกมาจากมันได้อย่างไรโดยไม่ทำ budget แตก

2. Shadow Maps: หา Depth จากมุมมองของแสง

เงาจริง ๆ แล้วคือคำถามเดียวที่ถูกถามซ้ำทุก pixel บนจอ: "มีอะไรกั้นระหว่างจุดนี้กับแสงหรือเปล่า" การเช็คแบบตรง ๆ สำหรับทุกแสงและทุก pixel โดย test กับทุก object อื่นในฉาก ช้าเกินไปสำหรับ frame budget เทคนิคมาตรฐานที่ใช้แก้เรื่องนี้เรียกว่า shadow map มันเปลี่ยนคำถามที่แพงนั้นให้เหลือแค่การเปรียบเทียบตัวเลขตัวเดียว

ไอเดียคือ render สองรอบ (two-pass) รอบแรก เอากล้องไปวาง ที่ตำแหน่งแสง แล้ว render ฉากจากตรงนั้น แต่สนใจแค่ depth (ระยะห่างจากแสง) ไม่สนใจสี อะไรก็ตามที่แสง "เห็น" ก่อนในแต่ละจุดของมุมมองมัน คือ surface ที่ใกล้แสงที่สุดตามทิศทางนั้น — เรียกสิ่งนี้ว่า depth buffer (grid ของระยะห่าง หนึ่งค่าต่อหนึ่ง pixel เรียกอีกชื่อว่า z-buffer) และเมื่อมันถูกใช้แบบนี้ก็คือ shadow map นั่นเอง รอบที่สอง render ตามปกติจากกล้องผู้เล่น และสำหรับทุก pixel ให้ project ตำแหน่งของ pixel นั้นเข้าไปในมุมมองของแสง แล้วเทียบระยะห่างกับสิ่งที่ shadow map บันทึกไว้แล้ว ถ้า pixel นั้นอยู่ไกลจากแสงมากกว่าที่ shadow map บอกว่า surface ที่ใกล้ที่สุดอยู่ตรงไหน แปลว่ามีอะไรบางอย่างกั้นแสงอยู่ — pixel นั้นอยู่ในเงา

นี่คือการเปรียบเทียบนั้นในรูปแบบ simulation เล็ก ๆ ให้มอง shadow map เป็น array ธรรมดา (array แบบเดียวกับที่เรียนไปในบทก่อน ๆ) — หนึ่งแถวของค่า depth ตามที่แสงมองเห็น โดยมีกล่องวางอยู่กลางมุมมองของมัน (texel 3 กับ 4 ใกล้ แปลว่ามีอะไรบางอย่างอยู่ตรงนั้น):

#include <cstdio>

// Depth values captured from the LIGHT's point of view (a tiny shadow map).
// Index = which texel; value = distance from the light to the surface it sees there.
float shadow_map[8] = { 5.0f, 5.0f, 5.0f, 2.0f, 2.0f, 5.0f, 5.0f, 5.0f };

// texel: which shadow-map texel this point projects onto
// dist_from_light: the ACTUAL distance from the light to this surface point
bool is_lit(int texel, float dist_from_light) {
    float bias = 0.01f; // a small offset explained below
    float closest = shadow_map[texel];
    return dist_from_light <= closest + bias;
}

int main() {
    // Point A: on the floor at texel 3, and it IS the closest surface there (2.0)
    printf("Point A lit? %s\n", is_lit(3, 2.0f) ? "yes" : "no");
    // Point B: on the floor under the box, texel 3, but the box (2.0) is closer
    printf("Point B lit? %s\n", is_lit(3, 4.5f) ? "yes" : "no");
    return 0;
}

Output:

Point A lit? yes
Point B lit? no

ระยะจริงของ Point A จากแสง (2.0) ตรงกับที่ shadow map บันทึกไว้ว่าเป็น surface ที่ใกล้ที่สุดที่ texel นั้น เลยไม่มีอะไรกั้น: โดนแสง Point B อยู่ไกลจากแสงมากกว่า (4.5) เมื่อเทียบกับ surface ที่ใกล้ที่สุดที่ shadow map บันทึกไว้ (2.0) — มีอะไรบางอย่าง (กล่อง) กั้นอยู่ระหว่างมันกับแสง เลยอยู่ในเงา การเปรียบเทียบตัวเดียวนี้ ทำซ้ำต่อ pixel ต่อแสง คือ algorithm ทั้งหมดที่ engine จริง ๆ รันอยู่

Shadow Acne และเรื่อง Bias

สังเกตตัวแปร bias ที่ใส่เข้าไปก่อนเปรียบเทียบ ถ้าไม่มีมัน surface อาจจะบังเงาตัวเอง (self-shadow) ผิด ๆ ได้ shadow map มี resolution และความละเอียดของ depth จำกัด ทำให้พื้นราบที่โดนแสงในมุมเฉียง ๆ อาจปัดเศษ depth ของตัวเองขึ้นหรือลงต่างกันเล็กน้อยระหว่างสองรอบ render ทำให้บาง pixel เทียบกับ depth จริงของตัวเองแล้ว fail ผลลัพธ์คือลายจุด ๆ ของเงาที่ไม่ควรมีบน surface ที่ควรจะโดนแสงเต็ม ๆ เรียกว่า shadow acne การดันจุดเปรียบเทียบเข้าหาแสงเล็กน้อย (ตัว bias) ให้ surface มีที่ผ่อนปรนนิดหน่อยจนไม่ fail กับตัวเองอีก

3. Cascaded Shadow Maps: เงาในฉากขนาดใหญ่

shadow map หนึ่งอันมีจำนวน texel คงที่ สมมติ 2048x2048 ถ้าต้องครอบคลุมระยะการมองเห็นหลายร้อยเมตร (level แบบ open-world ขนาดใหญ่) แต่ละ texel ก็ต้องครอบคลุมพื้นที่ในโลกจริงก้อนใหญ่ และเงาที่อยู่ใกล้กล้อง — ตรงจุดที่ผู้เล่นกำลังมองใกล้ ๆ พอดี — จะออกมาเป็นก้อน ๆ หยาบ ๆ แต่ถ้าปรับให้ shadow map มีขนาดพอดีกับพื้นที่ใกล้ ๆ เท่านั้น object ที่อยู่ไกลก็จะเสียเงาไปเลยทันทีที่ออกจากพื้นที่แคบ ๆ นั้น

Cascaded shadow maps (CSM) แก้ปัญหานี้ด้วยการไม่ใช้ shadow map แค่อันเดียว view frustum ของกล้อง (ปริมาตรทรงพีระมิดที่กล้องมองเห็น) ถูกหั่นออกเป็นช่วงระยะทางหลายช่วงเรียกว่า cascade — ใกล้, กลาง, ไกล — และแต่ละ cascade มี shadow map เป็นของตัวเอง ขนาดพอดีกับช่วงนั้น cascade ที่ใกล้ครอบคลุมพื้นที่เล็กแต่ texel หนาแน่นสูง (เงาคมชัดใกล้กล้อง ที่ตรงนั้นสำคัญที่สุด) ส่วน cascade ที่ไกลครอบคลุมพื้นที่ใหญ่แต่ texel หนาแน่นต่ำ (เงาหยาบกว่าตอนอยู่ไกล ที่ผู้เล่นจะไม่ทันสังเกต)

วิธีที่นิยมใช้เลือกจุดตัด (split distance) คือผสมสองแบบง่าย ๆ เข้าด้วยกัน: uniform split (ช่วงระยะเท่ากันทุกช่วง ซึ่งเปลืองความละเอียดตรงที่ไกล) กับ logarithmic split (ช่วงที่ยาวขึ้นเรื่อย ๆ ตามระยะทาง ให้เข้ากับที่มุมมอง perspective ทำให้ของที่อยู่ไกลดูเล็กลงอยู่แล้ว) engine จริง ๆ จะผสมสองแบบนี้ด้วยน้ำหนักที่ปรับได้ เรียก lambda:

#include <cstdio>
#include <cmath>

// Compute 4 cascade split distances between the near and far planes,
// blending a logarithmic split and a uniform split.
void compute_splits(float near_p, float far_p, int count, float lambda, float out[]) {
    for (int i = 1; i <= count; ++i) {
        float p = (float)i / (float)count;
        float log_split = near_p * powf(far_p / near_p, p);
        float uniform_split = near_p + (far_p - near_p) * p;
        out[i - 1] = lambda * log_split + (1.0f - lambda) * uniform_split;
    }
}

// Which cascade should shade a pixel at this view-space depth?
int pick_cascade(float view_depth, float splits[], int count) {
    for (int i = 0; i < count; ++i) {
        if (view_depth <= splits[i]) return i;
    }
    return count - 1;
}

int main() {
    float splits[4];
    compute_splits(0.1f, 200.0f, 4, 0.5f, splits);
    for (int i = 0; i < 4; ++i)
        printf("Cascade %d ends at %.2f units\n", i, splits[i]);

    printf("A pixel at depth 12.0 uses cascade %d\n", pick_cascade(12.0f, splits, 4));
    printf("A pixel at depth 150.0 uses cascade %d\n", pick_cascade(150.0f, splits, 4));
    return 0;
}

Output:

Cascade 0 ends at 25.37 units
Cascade 1 ends at 52.26 units
Cascade 2 ends at 89.97 units
Cascade 3 ends at 200.00 units
A pixel at depth 12.0 uses cascade 0
A pixel at depth 150.0 uses cascade 3

สังเกตว่า cascade กว้างขึ้นเรื่อย ๆ ตามระยะทางที่เพิ่มขึ้น: cascade แรกครอบคลุมแค่ประมาณ 25 หน่วย แต่ cascade สุดท้ายครอบคลุมมากกว่า 100 หน่วยด้วยตัวมันเองเลย pixel ที่อยู่ใกล้ (depth 12.0) ตกอยู่ใน cascade 0 ที่แคบและ resolution สูง ส่วน pixel ที่อยู่ไกล (depth 150.0) ตกอยู่ใน cascade 3 ที่กว้างและ resolution ต่ำ แต่ละ cascade ต้องมี shadow-map render pass เป็นของตัวเอง ดังนั้น 4 cascade ก็แปลว่าประมาณ 4 shadow pass ต่อแสงหนึ่งดวง — cascade คือการแลก render pass ที่เพิ่มขึ้นกับคุณภาพเงาที่ยังคมชัดใกล้กล้องไม่ว่าจะมองไปไกลแค่ไหน

4. ทำขอบเงาให้นุ่ม: PCF (Percentage-Closer Filtering)

การ lookup shadow map แค่ครั้งเดียวให้คำตอบ yes/no คมชัดต่อ pixel ซึ่งทำให้ขอบเงาคมกริบเกินจริง — นับเป็น aliasing รูปแบบหนึ่งด้วยเหมือนกัน (section 5 จะพูดเรื่องนี้ในภาพรวม) เพราะขอบเงาจริง ๆ จะค่อย ๆ นุ่มขึ้นเมื่อห่างออกจาก object ที่สร้างมัน PCF (percentage-closer filtering) แก้เรื่องนี้แบบถูก ๆ: แทนที่จะ test แค่ texel เดียวของ shadow map ให้ test หลาย texel ในพื้นที่เล็ก ๆ รอบจุดนั้น แล้วเฉลี่ยว่ากี่ตัวที่บอกว่า "โดนแสง" ผลลัพธ์ที่ได้คือเศษส่วนระหว่าง 0 (มืดเต็มที่) ถึง 1 (โดนแสงเต็มที่) แทนที่จะเป็นคำตอบ binary แบบคม ๆ ซึ่งอ่านออกมาเป็นขอบที่ไล่ระดับนุ่ม ๆ

#include <cstdio>

// Shadow map depths as seen from the light. 2.0 = top of a box, 5.0 = the floor beyond it.
float shadow_map[7][7] = {
    {5,5,5,5,5,5,5},
    {5,5,5,5,5,5,5},
    {5,5,2,2,2,5,5},
    {5,5,2,2,2,5,5},
    {5,5,2,2,2,5,5},
    {5,5,5,5,5,5,5},
    {5,5,5,5,5,5,5}
};

// Percentage-Closer Filtering: sample a 3x3 grid around the texel and
// average how many samples say "lit" instead of trusting a single texel.
float pcf_shadow(int cx, int cy, float dist_from_light) {
    float bias = 0.01f;
    int lit_count = 0;
    for (int dy = -1; dy <= 1; ++dy)
        for (int dx = -1; dx <= 1; ++dx)
            if (dist_from_light <= shadow_map[cy + dy][cx + dx] + bias)
                lit_count++;
    return (float)lit_count / 9.0f;
}

int main() {
    float d = 2.4f; // actual distance from light to this floor point
    printf("Deep inside the box's shadow  (3,3): %.3f\n", pcf_shadow(3, 3, d));
    printf("Right at the shadow's edge    (2,2): %.3f\n", pcf_shadow(2, 2, d));
    printf("Mostly outside the shadow     (1,1): %.3f\n", pcf_shadow(1, 1, d));
    return 0;
}

Output:

Deep inside the box's shadow  (3,3): 0.000
Right at the shadow's edge    (2,2): 0.556
Mostly outside the shadow     (1,1): 0.889

ลึกเข้าไปในเงาของกล่อง ทั้ง 9 texel ที่ sample เห็นตรงกันว่าโดนบัง: 0.000 มืดเต็มที่ ตรงขอบของกล่องพอดี พื้นที่ 3x3 ที่ sample คร่อมทั้งฝั่งที่โดนบังและฝั่งที่โล่ง: 0.556 ค่าเทาผสม — นี่คือขอบนุ่ม ๆ ที่เกิดขึ้น ส่วนที่เกือบพ้นเงาแล้ว มีแค่ texel เดียวที่ยัง disagree: 0.889 เกือบโดนแสงเต็มที่ engine จริง ๆ มักใช้ sample มากกว่านี้ (16 ตัวขึ้นไป มักจัดเรียงแบบหมุน หรือ Poisson-disk แทนที่จะเป็น grid ธรรมดา เพื่อไม่ให้เห็น pattern ซ้ำ ๆ) และสามารถขยาย sample radius ตามระยะห่างจาก object ที่สร้างเงาได้ เรียกว่า PCSS (percentage-closer soft shadows) ซึ่งทำให้เงาที่อยู่ใกล้ตัว caster คมกว่า และเงาที่อยู่ไกลจาก caster นุ่มกว่า — ตรงกับพฤติกรรมเงาจริงภายใต้แสงแบบ area light แนวคิดหลักยังคงเหมือนที่แสดงข้างบน: เฉลี่ยหลาย ๆ test แทนที่จะเชื่อแค่ตัวเดียว

5. ทำไมขอบถึงดูเป็นรอยหยัก: Aliasing และ Point Sampling

ขอบของ triangle ในทางคณิตศาสตร์คือเส้นตรงเป๊ะ ๆ แต่จอเป็น grid ของ pixel สี่เหลี่ยมขนาดคงที่ และ rasterizer (ขั้นตอน hardware ตายตัวของ GPU ที่ตัดสินว่า triangle ครอบคลุม pixel ไหนบ้าง) ปกติตัดสินโดยเช็คจุดเดียว — ปกติคือจุดกึ่งกลางของ pixel — แล้วถามว่า "จุดเดียวนี้อยู่ในหรือนอก triangle" การตัดสินแบบ binary นี้ ทำซ้ำที่ละ pixel เปลี่ยนขอบแนวทแยงหรือขอบโค้งที่เนียนให้กลายเป็นบันได ปัญหาทั่วไปแบบนี้ — รูปทรงต่อเนื่องถูกแทนด้วย grid ของ sample แบบไม่ต่อเนื่องคงที่จนเสียข้อมูลไป — เรียกว่า aliasing และมันคือสาเหตุที่ขอบแนวทแยงกับขอบโค้งในเกมดูเป็น "รอยหยัก" ถ้าไม่ทำอะไรเพิ่มเติม

#include <cstdio>

// A triangle's edge, simplified to the line x + y = 8.
// A pixel counts as "inside" if its CENTER point satisfies the test.
bool inside_triangle(int x, int y) {
    float cx = x + 0.5f;
    float cy = y + 0.5f;
    return (cx + cy) < 8.0f;
}

int main() {
    for (int y = 0; y < 8; ++y) {
        for (int x = 0; x < 8; ++x) {
            putchar(inside_triangle(x, y) ? '#' : '.');
        }
        putchar('\n');
    }
    return 0;
}

Output:

#######.
######..
#####...
####....
###.....
##......
#.......
........

ขอบเขตทางคณิตศาสตร์คือเส้นทแยงตรงเส้นเดียว แต่สิ่งที่ถูกวาดออกมาจริงคือบันได เพราะแต่ละ pixel ถามแค่ "จุดกึ่งกลางของฉันอยู่ในหรือนอก" โดยไม่มีแนวคิดเรื่อง "ฉันถูกครอบคลุม 30%" เลย เทคนิค anti-aliasing (AA) ทั้งสามที่จะพูดถึงต่อไปนี้ คือคำตอบที่ต่างกันของปัญหาเดียวกัน: หาคำตอบที่ดีกว่าการ sample จุดเดียวต่อ pixel โดยไม่ต้องจ่ายราคาเต็ม ๆ อย่างการ render ภาพที่ resolution สูงกว่าปกติ 4 เท่าหรือ 16 เท่าแล้วค่อยย่อลง (เรียกว่า supersampling หรือ SSAA ซึ่งได้ผลจริงแต่แพงเพราะต้องรัน pipeline ทั้งหมด รวมถึง shading ซ้ำหลายรอบต่อ pixel สุดท้ายหนึ่งตัว)

6. MSAA: Multi-Sample Anti-Aliasing

MSAA (multi-sample anti-aliasing) ปรับปรุงจาก test แบบ sample จุดกึ่งกลางเดียวใน section 5 โดยไม่ต้องจ่ายราคาเต็มของ supersampling กลเม็ดคือ: test coverage (จุดย่อยใน pixel นี้อยู่ใน triangle ไหม) ที่หลายตำแหน่งคงที่ภายใน pixel เดียว แต่รัน fragment shader (การคำนวณสี/แสงจริง ๆ) แค่ ครั้งเดียว ต่อ pixel ต่อ triangle สีสุดท้ายของ pixel จะ blend ตามสัดส่วนว่า sample point กี่ตัวที่ถูกครอบคลุม

#include <cstdio>

bool inside_triangle(float x, float y) {
    return (x + y) < 7.0f;
}

// 4x MSAA: test 4 sub-pixel sample points instead of just the pixel center.
float msaa4_coverage(int px, int py) {
    float offsets[4][2] = {
        {0.25f, 0.25f}, {0.75f, 0.25f},
        {0.25f, 0.75f}, {0.75f, 0.75f}
    };
    int covered = 0;
    for (int i = 0; i < 4; ++i) {
        float sx = px + offsets[i][0];
        float sy = py + offsets[i][1];
        if (inside_triangle(sx, sy)) covered++;
    }
    return covered / 4.0f;
}

int main() {
    printf("Pixel (2,3) coverage: %.2f\n", msaa4_coverage(2, 3));
    printf("Pixel (3,3) coverage: %.2f\n", msaa4_coverage(3, 3));
    printf("Pixel (4,3) coverage: %.2f\n", msaa4_coverage(4, 3));
    return 0;
}

Output:

Pixel (2,3) coverage: 1.00
Pixel (3,3) coverage: 0.25
Pixel (4,3) coverage: 0.00

Pixel (2,3) อยู่ในกล่องของ triangle เต็มตัว: ทั้ง 4 sample เห็นตรงกัน coverage 1.00 สีเต็ม Pixel (4,3) อยู่นอกเต็มตัว: coverage 0.00 Pixel (3,3) คร่อมขอบพอดี: มีแค่ 1 ใน 4 sample ที่อยู่ข้างใน coverage 0.25 ดังนั้นสี pixel สุดท้ายจะ blend สีของ triangle 25% กับสีของอะไรก็ตามที่อยู่ข้างหลังมัน — ขอบที่ถูกครอบคลุมบางส่วนแบบนุ่ม ๆ แทนที่จะเป็นการกระโดดแบบคม ๆ เพราะ fragment shader ที่แพงยังรันแค่ครั้งเดียวต่อ pixel (ไม่ใช่ 4 ครั้ง) MSAA จึงถูกกว่า supersampling 4 เท่าแบบเต็ม ๆ มาก ในขณะที่ยังทำให้ขอบทาง geometry เนียนขึ้นได้

7. FXAA: Post-Process Anti-Aliasing แบบเร็ว

MSAA ต้องเข้าถึงข้อมูล geometry และ coverage ตอนที่ฉากกำลังถูก rasterize FXAA (fast approximate anti-aliasing) ใช้วิธีที่ต่างออกไปเลย: มันรัน หลังจาก ภาพทั้งภาพถูก render เสร็จแล้ว เป็น post-processing pass (ขั้นตอนประมวลผลภาพที่ทำกับภาพ 2D สุดท้าย โดยไม่รู้อะไรเลยเกี่ยวกับฉาก 3D ที่สร้างมันขึ้นมา) มันสแกนภาพที่เสร็จแล้วเพื่อหาความสว่างที่กระโดดแบบคม ๆ — high-contrast edge ซึ่งมักหมายถึงขอบ geometry ที่เป็นรอยหยัก — แล้ว blend pixel พวกนั้นกับเพื่อนบ้านเพื่อทำให้นุ่มขึ้น

#include <cstdio>
#include <cmath>

// A row of pixel brightness values (0..1), with a hard edge in the middle.
float pixels[8] = {0.9f, 0.9f, 0.9f, 0.9f, 0.1f, 0.1f, 0.1f, 0.1f};

int main() {
    float smoothed[8];
    for (int i = 0; i < 8; ++i) smoothed[i] = pixels[i];

    for (int i = 1; i < 7; ++i) {
        float left = pixels[i - 1];
        float right = pixels[i + 1];
        float contrast = fabsf(left - right);
        if (contrast > 0.3f) {
            // High contrast: likely an edge. Blend this pixel with its neighbors.
            smoothed[i] = (left + pixels[i] + right) / 3.0f;
        }
    }

    for (int i = 0; i < 8; ++i) printf("%.2f ", smoothed[i]);
    printf("\n");
    return 0;
}

Output:

0.90 0.90 0.90 0.63 0.37 0.10 0.10 0.10

แถวเดิมกระโดดจาก 0.9 ไป 0.1 แบบทันทีในก้าวเดียว — ขอบคม ๆ การเช็ค high-contrast จับ pixel ใกล้จุดกระโดดนั้นแล้ว blend กับเพื่อนบ้าน เปลี่ยนการกระโดดทันทีให้กลายเป็นทางลาดสั้น ๆ: 0.9, 0.63, 0.37, 0.1 ตอนนี้ขอบกลายเป็น gradient สองสาม pixel แทนที่จะเป็นเส้นคม ๆ เส้นเดียว ซึ่งเมื่อมองจากระยะปกติจะดูเนียน FXAA เป็นที่นิยมเพราะถูกมาก (แค่ pass เดียวผ่านภาพสุดท้าย ไม่ต้อง render geometry เพิ่ม) และใช้ได้กับ renderer แบบไหนก็ได้ แต่เพราะมันดูแค่ contrast แบบ 2D มันจึงแยกไม่ออกระหว่างขอบ geometry จริง ๆ กับรายละเอียดของ texture ที่ contrast สูง เช่นเส้นที่วาดไว้ หรือตัวหนังสือเล็ก ๆ

8. TAA: Temporal Anti-Aliasing

MSAA ใช้ sample เพิ่มขึ้น ภายใน หนึ่งเฟรม TAA (temporal anti-aliasing) ใช้ sample เพิ่มขึ้น ข้ามเฟรม แทน: ทุกเฟรม ตำแหน่ง sample จะขยับเล็กน้อย (เรียกว่า jitter ค่า offset ระดับ sub-pixel ที่เปลี่ยนไปเรื่อย ๆ) แล้วเฟรมใหม่ที่ jitter แล้วนั้นจะถูก blend เข้ากับ history ที่สะสมมาจากเฟรมก่อน ๆ เมื่อเวลาผ่านไปหลายเฟรม มันจะ converge เข้าใกล้คำตอบเดียวกับที่ multi-sample test แบบทำในเฟรมเดียวจะให้ — แต่กระจายออกไปตามเวลา แทบไม่มีค่าใช้จ่ายเพิ่มต่อเฟรมเลย

การใช้ pixel จากเฟรมก่อนหน้าซ้ำ ต้องรู้ว่า surface point นั้น อยู่ตรงไหนตอนนี้ เพราะกล้องหรือ object อาจจะขยับไปแล้ว engine จะคำนวณ velocity buffer (เรียกอีกชื่อว่า motion vector buffer): สำหรับทุก pixel surface point นี้ขยับไปบนจอเท่าไรตั้งแต่เฟรมที่แล้ว vector นั้นถูกใช้เพื่อ reproject — หาว่า surface point เดียวกันนี้อยู่ตรงไหนในภาพของเฟรมก่อนหน้า — ก่อนจะ blend

นี่คือขอบ triangle เดิมจากตัวอย่าง MSAA แต่ sample จุดที่ jitter แล้วหนึ่งจุดต่อเฟรม แทนที่จะเป็นสี่จุดในเฟรมเดียว แล้ว blend เข้า history ที่วิ่งอยู่ด้วยน้ำหนักคงที่:

#include <cstdio>

bool inside_triangle(float x, float y) {
    return (x + y) < 7.0f;
}

int main() {
    // TAA jitters the sample point to a different sub-pixel offset every
    // frame, then blends the new sample into the accumulated history.
    float jitter_x[4] = {0.25f, 0.75f, 0.25f, 0.75f};
    float jitter_y[4] = {0.25f, 0.25f, 0.75f, 0.75f};
    int px = 3, py = 3;

    float history = 0.5f; // first guess, no history yet
    float alpha = 0.25f;  // how much weight the new frame gets

    for (int frame = 0; frame < 4; ++frame) {
        float sample = inside_triangle(px + jitter_x[frame], py + jitter_y[frame]) ? 1.0f : 0.0f;
        history = history * (1.0f - alpha) + sample * alpha;
        printf("Frame %d: jittered sample=%.1f  accumulated=%.4f\n", frame, sample, history);
    }
    return 0;
}

Output:

Frame 0: jittered sample=1.0  accumulated=0.6250
Frame 1: jittered sample=0.0  accumulated=0.4688
Frame 2: jittered sample=0.0  accumulated=0.3516
Frame 3: jittered sample=0.0  accumulated=0.2637

นี่คือ jitter offset ทั้งสี่ตัวเดียวกันเป๊ะ ๆ กับที่ใช้เป็นสี่ MSAA sample point ใน section 6 ที่ pixel (3,3) ได้ค่า coverage จริงเป็น 0.25 ตรงนี้ กระจายออกไปทีละเฟรมทั้งสี่เฟรมแล้ว blend เข้าด้วยกัน ค่าที่สะสมกำลังค่อย ๆ ลดลงเข้าใกล้ 0.25 เหมือนกัน — TAA สร้างคำตอบแบบเดียวกับ MSAA ขึ้นมาใหม่ โดยใช้เวลาแทนที่จะใช้ sample เพิ่มในเฟรมเดียว ด้วยต้นทุนต่อเฟรมที่น้อยกว่ามาก

9. Forward Shading กับ Deferred Shading

การคำนวณแสงต้องเกิดขึ้นที่ไหนสักที่ใน pipeline: สำหรับทุก pixel ที่มองเห็น ต้องรวม material ของ surface นั้นเข้ากับทุกแสงที่ส่องมาถึงมัน มีสองวิธีที่ต่างกันมากในการจัดระเบียบงานนี้

Forward shading คือวิธีตรงไปตรงมา: สำหรับแต่ละ object สำหรับแต่ละแสงที่อาจส่งผลต่อมัน คำนวณแสงตรงนั้นเลยใน fragment shader ของ object ทีละ triangle มันง่ายและทำงานได้ดีตามธรรมชาติกับ transparency และ MSAA แต่มันมีปัญหา — overdraw (shade pixel เดียวกันบนจอมากกว่าหนึ่งครั้ง เพราะ object ที่อยู่ใกล้กว่าถูกวาดทับ object ที่อยู่ไกลกว่าซึ่งจ่ายค่า shading เต็ม ๆ ไปแล้ว) ยิ่งคูณแย่ลงเรื่อย ๆ เมื่อจำนวนแสงเยอะขึ้น เพราะทุก pixel ที่ถูก overdraw ต้องจ่ายค่าทุกแสงซ้ำอีกรอบ

Deferred shading แยกงานออกเป็นสอง pass แทน pass แรกเรียก geometry pass วาดทุก object แต่ยังไม่คำนวณแสงเลย — มันแค่เขียนข้อมูล material ของแต่ละ pixel (สีของ surface, ทิศทาง normal, depth, roughness) ลงใน texture เต็มจอชุดหนึ่งเรียกว่า G-buffer (geometry buffer) pass ที่สองเรียก lighting pass รันครั้งเดียวต่อ pixel สุดท้ายที่มองเห็นบนจอ อ่าน G-buffer แล้ววนลูปแสงที่ส่องถึง pixel นั้น การคำนวณแสงจะรันเฉพาะ pixel ที่มองเห็นจริง ๆ บนจอเท่านั้น ไม่ใช่ทุก layer ที่ถูก overdraw ข้างใต้มัน

simulation เล็ก ๆ จะทำให้เห็นความต่างชัดขึ้น สมมติฉากหนึ่งมี 50 object แต่ละอันครอบคลุมจอเฉลี่ย 2000 pixel (มี overlap กันบ้าง) มีแสง 40 ดวง และภาพสุดท้ายที่มองเห็นมี 80,000 pixel:

#include <cstdio>

int main() {
    int objects = 50;
    int pixels_per_object = 2000; // average screen coverage, including overlap
    int lights = 40;              // e.g. many small point lights in a level

    // Forward: naively shades EVERY light against EVERY pixel of EVERY
    // object, even pixels that later get drawn over by something closer.
    long forward_ops = (long)objects * pixels_per_object * lights;

    // Deferred: pay the material write once per pixel (geometry pass),
    // then pay the lighting cost once per pixel per light, on the FINAL
    // visible pixels only - overdraw never reaches the lighting pass.
    long screen_pixels = 80000;
    long gbuffer_ops = screen_pixels;
    long lighting_ops = screen_pixels * lights;
    long deferred_ops = gbuffer_ops + lighting_ops;

    printf("Forward shading operations:  %ld\n", forward_ops);
    printf("Deferred shading operations: %ld\n", deferred_ops);
    return 0;
}

Output:

Forward shading operations:  4000000
Deferred shading operations: 3280000

สังเกตว่า objects x pixels_per_object (100,000) มากกว่า screen_pixels สุดท้าย (80,000) — ช่องว่าง 1.25 เท่านั้นคือ overdraw: มี pixel บนจอบางตัวที่ถูก shade มากกว่าหนึ่ง object ที่ซ้อนกันในเวอร์ชัน forward Deferred shading จ่ายค่า material แค่ครั้งเดียวต่อ pixel สุดท้ายจริง ๆ และไม่จ่ายค่า lighting ซ้ำอีกสำหรับ pixel ที่สุดท้ายถูกบังอยู่ ช่องว่างระหว่าง forward กับ deferred จะโตขึ้นเร็วมากเมื่อจำนวนแสงเพิ่มขึ้น นี่คือเหตุผลที่ deferred shading ได้รับความนิยมโดยเฉพาะกับฉากที่มีแสง dynamic เล็ก ๆ จำนวนมาก

10. เทคนิคประมาณ Global Illumination

Global illumination (GI) คือแสงที่กระเด้งมากกว่าหนึ่งครั้งก่อนจะมาถึงตา — กำแพงสีขาวที่โดนแสงแดดตรง ๆ ก็ทำให้ห้องรอบ ๆ มันสว่างขึ้นด้วย พรมสีแดงก็ย้อมสีแดงจาง ๆ ให้กำแพงข้าง ๆ มันได้ การ simulate เรื่องนี้แบบเป๊ะ ๆ ต้องไล่ตามว่าแสงกระเด้งไปทั่วทั้งฉากยังไง ซึ่งช้าเกินไปมากสำหรับ frame budget engine แบบ real-time ใช้การประมาณค่าเฉพาะจุดจำนวนหนึ่งแทน แต่ละอันครอบคลุมส่วนที่ต่างกันของสิ่งที่ GI แบบเต็ม ๆ จะให้ได้

Light Probe: แสงทางอ้อมที่คำนวณล่วงหน้าไว้เป็นจุด ๆ

Light probe คือจุดหนึ่งใน level ที่ล่วงหน้ามาก่อน (ปกติตอนสร้าง level ไม่ใช่ตอนเกมกำลังรัน) engine คำนวณว่าแสงทางอ้อมตรงจุดนั้นหน้าตาเป็นยังไง — แสงที่กระเด้งมาจากกำแพง, พื้น, และ geometry ที่หยุดนิ่งอื่น ๆ probe ถูกวางกระจายไปทั่ว level มักจะถี่กว่าในพื้นที่ที่สำคัญทางสายตา ตอนเกมรันจริง object ที่เคลื่อนที่ได้ (ซึ่งไม่สามารถมี lighting ที่ bake ไว้ล่วงหน้าของตัวเองได้ เพราะมันอยู่ตรงไหนก็ได้) จะหา probe ที่ใกล้ที่สุดแล้ว blend ระหว่างพวกมันตามระยะห่าง เพื่อประมาณแสงทางอ้อมที่กระทบมันตอนนี้แบบถูก ๆ

#include <cstdio>

// Two light probes along a hallway, storing indirect light (simplified to
// one brightness number instead of full RGB for clarity).
float probe_A_light = 0.2f; // near a dark corner
float probe_B_light = 0.8f; // near a bright window

int main() {
    float probe_A_pos = 0.0f;
    float probe_B_pos = 10.0f;
    float object_pos = 7.0f; // a crate somewhere between the two probes

    float t = (object_pos - probe_A_pos) / (probe_B_pos - probe_A_pos);
    float indirect_light = probe_A_light * (1.0f - t) + probe_B_light * t;

    printf("Blend factor t = %.2f\n", t);
    printf("Interpolated indirect light on the crate: %.3f\n", indirect_light);
    return 0;
}

Output:

Blend factor t = 0.70
Interpolated indirect light on the crate: 0.620

ลังอยู่ 70% ของทางจาก probe ที่หรี่ไปยัง probe ที่สว่าง มันเลยรับ 70% ของความต่างความสว่างระหว่างสองอัน: 0.62 สว่างกว่ามุมที่มืดแต่หรี่กว่าตรงข้างหน้าต่างพอดี light probe จริง ๆ เก็บข้อมูลแสงแบบทรงกลมเต็ม ๆ (แสงที่มาจากทุกทิศทาง ไม่ใช่แค่ตัวเลขเดียว) และ engine จริง ๆ blend probe ที่อยู่ใกล้เคียงมากกว่าสองอันพร้อมกัน แต่แนวคิดหลัก — sample จุดที่คำนวณไว้ล่วงหน้าไม่กี่จุดแล้ว interpolate — คือแบบนี้เป๊ะ

Screen-Space Reflections (SSR)

Screen-space reflections เอาข้อมูลที่ renderer มีอยู่แล้วบนจอมาใช้ซ้ำ — color buffer กับ depth buffer — เพื่อประมาณภาพสะท้อนโดยไม่ต้องไล่ ray ผ่านฉาก 3D เต็ม ๆ reflection ray ถูก march (เดินหน้าไปทีละนิด) เริ่มจาก surface ที่สะท้อนแสง และในแต่ละก้าว depth ปัจจุบันของมันจะถูกเทียบกับสิ่งที่ depth buffer บันทึกไว้แล้วที่ตำแหน่งนั้นบนจอ เมื่อ depth ของ ray ตามทันหรือแซง depth buffer ตรงนั้น pixel นั้นจะถูกนับเป็นจุดที่ชน แล้วสีที่ render ไว้แล้วของมันจะถูกใช้ซ้ำเป็นภาพสะท้อน

#include <cstdio>

// Depth buffer for a row of screen pixels the reflection ray crosses.
// (Distance from camera; a crate close to the camera sits at index 4-7.)
float depth_buffer[10] = {5,5,5,5, 2,2,2,2, 5,5};

int main() {
    float ray_depth = 1.0f; // the ray starts close to the camera
    float step = 0.5f;      // and marches away from it, pixel by pixel

    for (int px = 0; px < 10; ++px) {
        printf("pixel %d: ray_depth=%.2f buffer_depth=%.2f", px, ray_depth, depth_buffer[px]);
        if (ray_depth >= depth_buffer[px]) {
            printf("  -> HIT: use color at this pixel as the reflection\n");
            break;
        }
        printf("  (ray is still in front of the surface)\n");
        ray_depth += step;
    }
    return 0;
}

Output:

pixel 0: ray_depth=1.00 buffer_depth=5.00  (ray is still in front of the surface)
pixel 1: ray_depth=1.50 buffer_depth=5.00  (ray is still in front of the surface)
pixel 2: ray_depth=2.00 buffer_depth=5.00  (ray is still in front of the surface)
pixel 3: ray_depth=2.50 buffer_depth=5.00  (ray is still in front of the surface)
pixel 4: ray_depth=3.00 buffer_depth=2.00  -> HIT: use color at this pixel as the reflection

ray march ไปข้างหน้า อยู่ "ข้างหน้า" กำแพงไกล (depth 5.00) ตลอดสี่ pixel แรก แล้วที่ pixel 4 depth ของมันเอง (3.00) ตามทัน depth ของลังที่อยู่ใกล้ (2.00) แล้ว — ชน สีที่ render ไว้แล้วที่ pixel 4 จะถูกใช้ซ้ำเป็นสีของภาพสะท้อน จุดติดขัดอยู่ในชื่อของมันเลย: screen-space ถ้าสิ่งที่ควรจะสะท้อนอยู่นอกจอ หรือถูกบังจากมุมมองของกล้อง สีของมันไม่เคยถูก render ไว้ตั้งแต่แรก ray march เลย fail ที่จะหาจุดชน — engine จะ fallback ไปใช้ reflection probe ที่ bake ไว้ล่วงหน้า (คล้าย ๆ light probe แต่เก็บภาพ 360 องศาเต็ม ๆ แทนที่จะเป็นค่าความสว่างค่าเดียว) เมื่อไรก็ตามที่ SSR หาอะไรไม่เจอ

Screen-Space Ambient Occlusion (SSAO)

Ambient occlusion (AO) คือความมืดนุ่ม ๆ ที่เห็นตามมุม, รอยพับ, และตรงที่ surface สองอันมาชิดกันใกล้ ๆ — รอยแยกจะได้รับ ambient light น้อยกว่า surface ราบเรียบที่เปิดโล่ง เพราะ geometry ที่อยู่ใกล้ ๆ บังแสงจากท้องฟ้า/สิ่งแวดล้อมบางส่วนที่ปกติจะส่องมาถึง SSAO ประมาณค่านี้โดยใช้แค่ depth buffer: สำหรับแต่ละ pixel sample depth ของ pixel ใกล้เคียง ถ้าเพื่อนบ้านตัวไหนอยู่ใกล้กล้องกว่าที่ควรอย่างเห็นได้ชัด นับว่ามันบังแสงบางส่วน

#include <cstdio>

// Scene depth (distance from camera) looking into a narrow crevice.
// The crevice walls (4.0) are close to the camera; the back of the
// crevice (7.0) is farther away and partly boxed in by the walls.
float depth[5][5] = {
    {10,10,10,10,10},
    {10, 4, 4, 4,10},
    {10, 4, 7, 4,10},
    {10, 4, 4, 4,10},
    {10,10,10,10,10}
};

// SSAO: check nearby depth samples. A neighbor that is noticeably CLOSER
// to the camera than this pixel blocks some of the ambient light that
// would otherwise reach it.
float ssao(int cx, int cy) {
    float center = depth[cy][cx];
    int occluders = 0, samples = 0;
    for (int dy = -1; dy <= 1; ++dy) {
        for (int dx = -1; dx <= 1; ++dx) {
            if (dx == 0 && dy == 0) continue;
            float neighbor = depth[cy + dy][cx + dx];
            if (neighbor < center - 0.5f) occluders++;
            samples++;
        }
    }
    return 1.0f - (float)occluders / (float)samples; // 1.0 = open, 0.0 = dark
}

int main() {
    printf("AO on the crevice wall (1,1): %.3f\n", ssao(1, 1));
    printf("AO at the crevice back (2,2): %.3f\n", ssao(2, 2));
    return 0;
}

Output:

AO on the crevice wall (1,1): 1.000
AO at the crevice back (2,2): 0.000

จุดที่ขอบของรอยแยก (1,1) ไม่มีเพื่อนบ้านตัวไหนใกล้กว่าตัวมันเองเลย AO เลยยังเป็น 1.000 เปิดโล่งเต็มที่ จุดที่อยู่ลึกสุดของรอยแยก (2,2) ถูกล้อมรอบทั้ง 8 ด้านด้วยกำแพงรอยแยกที่ใกล้กว่า ทุกเพื่อนบ้านเลยนับเป็นตัวบัง: AO ตกลงมาที่ 0.000 มืดเต็มที่ เอาค่านี้ไปคูณกับ ambient/indirect light term ใน lighting ของเรา มุมกับรอยพับก็จะมืดลงเองโดยธรรมชาติ

11. GPU-Driven Rendering และ Culling

การ render object ที่กล้องมองไม่เห็นเลยเสียเวลา pipeline ทั้งหมดไปเปล่า ๆ Culling คือการตัดสินใจ ก่อนที่จะทำงานที่แพงนั้น ว่า object ไหนสามารถข้ามไปได้เลย

รูปแบบที่ง่ายและใช้บ่อยที่สุดคือ frustum culling: test bounding volume ของแต่ละ object (รูปทรงง่าย ๆ อย่าง sphere หรือ box ที่ครอบ mesh จริงไว้ทั้งหมด ถูกกว่าการ test ทุก triangle) กับ frustum ของกล้อง (ปริมาตรทรงพีระมิดที่กล้องมองเห็น ถูกจำกัดด้วย near plane, far plane, และขอบของ field of view) อะไรก็ตามที่อยู่นอก frustum ทั้งหมดจะถูกข้ามไปก่อนที่แม้แต่ vertex เดียวของมันจะถูกส่งไปที่ GPU

#include <cstdio>
#include <cmath>

struct Sphere { float x, z, radius; };

// A simplified 2D frustum: camera at the origin looking down +z,
// with a field-of-view half-angle, and near/far clip distances.
bool in_frustum(Sphere s, float near_d, float far_d, float half_angle_rad) {
    if (s.z + s.radius < near_d) return false; // fully behind the near plane
    if (s.z - s.radius > far_d) return false;  // fully beyond the far plane

    // Distance the frustum's side plane is from the view axis at this depth.
    float side_limit = s.z * tanf(half_angle_rad);
    if (fabsf(s.x) - s.radius > side_limit) return false; // outside the side plane
    return true;
}

int main() {
    float near_d = 0.5f, far_d = 100.0f, half_angle = 0.6f; // about 34 degrees

    Sphere crate    = {2.0f, 20.0f, 1.0f};   // near the camera's path
    Sphere far_rock = {5.0f, 200.0f, 3.0f};  // way past the far plane
    Sphere off_side = {90.0f, 20.0f, 1.0f};  // way off to the side

    printf("crate visible?    %s\n", in_frustum(crate, near_d, far_d, half_angle) ? "yes" : "no");
    printf("far_rock visible? %s\n", in_frustum(far_rock, near_d, far_d, half_angle) ? "yes" : "no");
    printf("off_side visible? %s\n", in_frustum(off_side, near_d, far_d, half_angle) ? "yes" : "no");
    return 0;
}

Output:

crate visible?    yes
far_rock visible? no
off_side visible? no

ลังผ่านทั้งสามการเช็คและถูกวาด หินไม่ผ่านการเช็ค far-plane ไปเลย — มันไกลเกินไปอยู่ดี ไม่ว่ามุมจะเป็นยังไงก็ตาม object ที่อยู่ข้าง ๆ ผ่านการเช็ค near/far แต่ไม่ผ่านการเช็ค side-plane — มันอยู่ในระยะที่วาดได้ แต่อยู่นอก field of view ของกล้องไปมาก การวาดมันจึงเสียงานเปล่า

Frustum culling จับได้แค่ object ที่อยู่นอก view volume ของกล้อง Occlusion culling จับกรณีที่ต่างออกไป: object ที่อยู่ใน frustum เต็ม ๆ แต่ถูกบังมิดจากอะไรที่อยู่ใกล้กว่า — เช่นห้องที่อยู่หลังกำแพง เทคนิคที่นิยมใช้คือ Hi-Z (hierarchical depth buffer): สร้าง pyramid แบบ mipmap ของ depth buffer (แต่ละ level เก็บ depth ที่ไกลที่สุดของกลุ่ม pixel จาก level ข้างล่าง) ทำให้การ test ว่า bounding volume ของ object ถูกบังมิดหลัง geometry ที่มีอยู่แล้วหรือเปล่า ทำได้ด้วยการ lookup แบบหยาบ ๆ ไม่กี่ครั้ง แทนที่จะเทียบกับทุก pixel ที่มันอาจครอบคลุม

การทำ culling ทั้งหมดนี้บน CPU ทีละ object กลายเป็นคอขวดของตัวมันเองเมื่อฉากมี object เป็นแสนตัว — แม้แต่ test ที่ถูกต่อ object ก็สะสมกันจนหนัก และทุก draw call ที่ CPU ตัดสินใจส่งออกไปก็เสียเวลาข้ามไปหา GPU GPU-driven rendering ย้ายการตัดสินใจไปไว้บน GPU เอง: compute shader (โปรแกรม GPU แบบทั่วไป ไม่ผูกกับ vertex หรือ pixel ตัวใดตัวหนึ่ง) test visibility ของ object ทั้งหมดพร้อมกันแบบขนาน แล้วเขียนตัวที่รอดลงใน buffer ของ indirect draw call (คำสั่ง draw ที่ parameter ของมัน เช่นว่าจะวาด object ไหน ถูกอ่านจาก GPU memory แทนที่จะถูกระบุไว้ล่วงหน้าโดย CPU) CPU แค่ต้องสั่ง dispatch ครั้งเดียว GPU ตัดสินใจเองว่าจะวาดอะไรแล้ววาดมันเลย โดย CPU เข้ามาเกี่ยวข้องน้อยลงมากต่อ object

12. รวมทุกอย่างเข้าด้วยกัน: หนึ่งเฟรมสมัยใหม่ ทีละ Pass

ไม่มีเทคนิคไหนที่รันแยกโดด ๆ เลย หนึ่งเฟรมทั่วไปใน deferred renderer สมัยใหม่รัน pass ของมันตามลำดับที่แน่นอน เพราะแต่ละ pass มักจะขึ้นอยู่กับข้อมูลที่ pass ก่อนหน้าสร้างไว้

อ่านจากซ้ายไปขวา: shadow pass render shadow map ของแต่ละแสงก่อน (section 2-4) เพราะ pass หลักของฉากจะต้อง sample มันทีหลัง depth prepass มักจะ render แค่ depth ของ object ทึบก่อนอย่างอื่นทั้งหมด เพื่อให้ pass ทีหลังข้าม pixel ที่สุดท้ายถูกบังโดยอะไรที่อยู่ใกล้กว่าได้ ตัด overdraw ตั้งแต่ก่อน G-buffer pass จะเริ่มด้วยซ้ำ G-buffer pass (section 9) เขียนข้อมูล material ครั้งเดียวต่อ pixel ที่มองเห็น SSAO (section 10) รันต่อจากนั้นเพราะมันต้องการแค่ข้อมูล depth/normal ที่ G-buffer เพิ่งสร้างเสร็จ lighting pass อ่าน G-buffer, shadow map, และผล SSAO พร้อมกันเพื่อสร้างภาพที่โดนแสงแล้ว SSR (section 10) รันหลัง lighting เพราะมันต้องการ color buffer ที่ shade แล้วเพื่อ sample ภาพสะท้อน forward pass แยกต่างหากจัดการ transparent object เป็นลำดับสุดท้ายในบรรดา geometry 3D เพราะมันต้อง blend กับทุกอย่างที่วาดไว้ข้างหลังมันแล้ว TAA (section 8) resolve เฟรมที่ jitter แล้วเทียบกับ history ใกล้ ๆ ตอนท้าย ก่อน tonemapping (แปลงค่าความสว่างที่ render ไว้ให้เป็นสีที่แสดงผลได้จริง) และ post-processing อื่น ๆ เพื่อให้ขั้นตอนสุดท้ายเหล่านั้นทำงานกับภาพที่นิ่งและ anti-alias แล้ว ไม่ใช่ภาพที่ยัง jitter อยู่

engine ของแต่ละสตูดิโอปรับลำดับนี้แตกต่างกันไปบ้าง และบาง pass (อย่าง SSR หรือ SSAO) บางทีก็ถูกตัดออกเลยบน hardware ระดับล่างเพื่อประหยัด budget แต่รูปทรงโดยรวม — เงาและ depth ก่อน แล้วข้อมูล material แล้วแสง แล้ว screen-space effect ที่ใช้สิ่งที่วาดไว้แล้วซ้ำ แล้ว temporal resolve แล้วสุดท้าย color grading — เกือบจะเป็นสากลในบรรดา engine ที่วางขายจริง

13. จะเรียนเรื่องพวกนี้ให้ได้จริง ๆ ต้องทำยังไง

บทนี้ให้แนวคิดและ simulation เล็ก ๆ ที่ลองทำมือให้กับแต่ละเทคนิค นั่นพอสำหรับจำไอเดียพวกนี้ได้และคิดเรื่อง trade-off ของมันได้ แต่การ implement มันจริง ๆ ใน renderer ที่ทำงานได้จริงเป็นทักษะที่ลึกกว่าและต่างออกไป และตรงนั้นแหละที่ความเข้าใจจะติดอยู่จริง ๆ เส้นทางที่ใช้ได้จริง:

• เลือกเทคนิคเดียวจากบทนี้ ไม่ใช่ทำทุกอันพร้อมกัน — shadow mapping กับ PCF พื้นฐานเป็นตัวเลือกเริ่มต้นที่สมเหตุสมผล เพราะมันจบในตัวเองและเราเห็นผลลัพธ์ได้ทันที
• หา primary source หา conference talk หรือ course ที่เขียนจริงจังว่า engine ที่วางขายจริง implement มันยังไง — course "Advances in Real-Time Rendering in Games" ของ SIGGRAPH จัดมาหลายปีแล้วและครอบคลุมเทคนิคระดับ production แบบนี้เป๊ะ ๆ, GDC (Game Developers Conference) talk เป็นอีกแหล่งที่ดี และหลายอันดูฟรีได้ source code ของ engine ก็เป็น primary source เหมือนกัน: Godot กับบางส่วนของ Unreal Engine เป็น open source การอ่านโค้ด shadow-mapping หรือ SSAO จริง ๆ ของพวกมันจะให้เห็นการตัดสินใจที่บทนี้แค่สรุปให้ฟังคร่าว ๆ เท่านั้น
• Implement เวอร์ชันเล็กที่สุดที่ทำงานได้ toy renderer ที่ใช้ graphics API ที่เรารู้จักอยู่บ้างแล้ว (หรือ compute-shader playground) ก็พอแล้ว — ไม่ต้องมี engine เต็มรูปแบบเพื่อพิสูจน์ว่า shadow map หรือ SSAO pass ของเราทำงานได้
• ตรวจสอบด้วย graphics debugger เครื่องมืออย่าง RenderDoc (ฟรี ใช้ได้หลาย platform), PIX (Windows/Xbox), หรือ Nsight Graphics (NVIDIA) ให้เรา capture หนึ่งเฟรมจาก application DirectX, Vulkan, หรือ OpenGL ตัวไหนก็ได้ — รวมถึงเกมที่เราไม่ได้เขียนเองด้วย — แล้วไล่ดูทีละ pass เห็นทุก texture ระหว่างทาง: shadow map จริง ๆ, แต่ละ channel ของ G-buffer, ผล SSAO ดิบ ๆ ก่อนที่มันจะถูกใช้ นี่เปลี่ยน diagram ที่เป็นนามธรรมให้กลายเป็นสิ่งที่เรามองเห็นได้จริง ทีละ pixel
• เทียบกับ reference แล้วปรับจูนด้วยการวัด ไม่ใช่การเดา ถ้าเรา render (หรือหา) เวอร์ชันที่ช้ากว่าแต่ "ถูกต้องชัดเจน" ได้ — brute-force shadow test, ภาพ reference แบบ path-traced เต็ม ๆ — เอา approximation ที่เร็วของเรามาเทียบข้าง ๆ กัน ปรับ parameter อย่าง shadow bias หรือ SSAO radius โดยดูว่าอะไรเปลี่ยนไปจริง ๆ วินัยการ debug แบบเดียวกับที่เรียนไปในบทก่อนหน้า: ตั้งสมมติฐาน, ตรวจ state จริง (ด้วย gdb กับ AddressSanitizer สำหรับโค้ด CPU, ด้วย graphics debugger สำหรับตรงนี้), แล้วยืนยันหรือปฏิเสธมัน แทนที่จะเปลี่ยนตัวเลขมั่ว ๆ จนกว่ามันจะดูดีขึ้น

14. Glossary

• Frame budget — เวลาสูงสุดที่มีให้สร้างหนึ่งเฟรมที่ frame rate เป้าหมาย เช่น 16.6 ms ที่ 60 FPS
• Depth buffer (z-buffer) — grid ของค่าระยะห่างจากกล้อง (หรือจากแสง) หนึ่งค่าต่อหนึ่ง pixel หรือ texel
• Shadow map — depth buffer ที่ render จากมุมมองของแสง ใช้ test ว่าจุดหนึ่งถูกบังจากแสงนั้นหรือเปล่า
• Shadow acne — การบังเงาตัวเองแบบผิด ๆ เป็นลายจุด ๆ เกิดจากความละเอียด depth ที่จำกัด แก้ด้วย bias เล็ก ๆ
• Peter-panning — เงาที่ลอยออกจาก object ของมันอย่างเห็นได้ชัด เกิดจากใช้ bias มากเกินไป
• Cascaded shadow maps (CSM) — การหั่น frustum ของกล้องออกเป็นช่วงระยะทาง แต่ละช่วงมี shadow map ของตัวเอง เพื่อให้ shadow resolution คมชัดใกล้กล้องแม้ระยะการมองเห็นจะไกลมาก
• PCF (percentage-closer filtering) — เฉลี่ย shadow-map sample หลายตัวรอบจุดหนึ่ง เพื่อให้ได้ขอบเงานุ่มแทนที่จะเป็นขอบคม
• PCSS (percentage-closer soft shadows) — PCF ที่ sample radius โตขึ้นตามระยะห่างจาก object ที่สร้างเงา
• Aliasing — artifact ทางภาพ (เช่นขอบเป็นรอยหยัก) ที่เกิดจากการแทนรูปทรงต่อเนื่องด้วย grid ของ sample แบบไม่ต่อเนื่องคงที่
• Rasterization — ขั้นตอนของ GPU ที่แปลง triangle ให้เป็น pixel ที่มันครอบคลุมบนจอ
• Supersampling (SSAA) — render ที่ resolution สูงกว่ามากแล้วย่อลง วิธีลด aliasing ที่แพงแต่ตรงไปตรงมา
• MSAA (multi-sample anti-aliasing) — test geometric coverage ที่หลายจุดย่อยต่อ pixel แต่ shade แค่ครั้งเดียว ถูกกว่า supersampling
• FXAA (fast approximate anti-aliasing) — post-process pass ที่ทำให้ขอบ contrast สูงในภาพ 2D สุดท้ายเนียนขึ้น
• TAA (temporal anti-aliasing) — ขยับตำแหน่ง sample (jitter) ทุกเฟรมแล้ว blend กับ history ที่ reproject มาจากเฟรมก่อนหน้า
• Jitter — offset ระดับ sub-pixel เล็ก ๆ ที่เปลี่ยนไปเรื่อย ๆ ใช้กับตำแหน่ง sample ทุกเฟรมใน TAA
• Velocity buffer / motion vector — ข้อมูลต่อ pixel ที่บันทึกว่า surface point ขยับไปบนจอเท่าไรตั้งแต่เฟรมที่แล้ว
• Reprojection — ใช้ velocity vector หาว่า surface point อยู่ตรงไหนในภาพของเฟรมก่อนหน้า
• Ghosting — รอยเปื้อนลากยาวใน TAA เกิดจากการ blend ข้อมูล history ที่ไม่ตรงกับเฟรมปัจจุบันแล้ว
• Disocclusion — surface ที่เพิ่งถูกเปิดเผยบนจอ เพราะสิ่งที่บังมันขยับออกไปแล้ว
• Neighborhood clamping — จำกัด history sample ของ TAA ให้อยู่ในช่วงสีที่เห็นใกล้เคียงในเฟรมปัจจุบัน เพื่อลด ghosting
• Forward shading — คำนวณแสงตรง ๆ ต่อ object ต่อแสง ระหว่าง render geometry
• Deferred shading — แยก rendering เป็น geometry pass (เขียน G-buffer) กับ lighting pass แยกที่อ่านมัน
• G-buffer — ชุด texture เต็มจอ (albedo, normal, depth, roughness/metallic ฯลฯ) ที่ geometry pass ของ deferred renderer เขียนไว้
• Overdraw — shade pixel เดียวกันบนจอมากกว่าหนึ่งครั้ง เพราะ object ที่ใกล้กว่าถูกวาดทับ object ที่ไกลกว่า
• Forward+ / clustered shading — แบบผสมที่ shade ใน pass เดียวเหมือน forward shading แต่จัดเรียงแสงลงใน grid cell แบบ screen-space ก่อน ให้แต่ละ pixel test แค่แสงที่อยู่ใกล้ ๆ
• Global illumination (GI) — แสงที่กระเด้งมากกว่าหนึ่งครั้งก่อนถึงตา รวมแสงทางอ้อม/แสงที่กระเด้งมา
• Light probe — จุดใน level ที่คำนวณแสงทางอ้อมไว้ล่วงหน้า ใช้ให้แสงกับ dynamic object ที่อยู่ใกล้จุดนั้นตอนเกมรัน
• Screen-space reflections (SSR) — ประมาณภาพสะท้อนโดย march ray ผ่าน depth/color buffer ที่มีอยู่แล้ว แทนที่จะไล่ ray ผ่านฉาก 3D เต็ม ๆ
• Screen-space ambient occlusion (SSAO) — ประมาณ ambient occlusion โดยเช็คว่า depth-buffer sample ใกล้เคียงอยู่ใกล้กล้องกว่า pixel ปัจจุบันหรือเปล่า
• Frustum culling — ข้าม object ที่ bounding volume ของมันอยู่นอก view volume ของกล้องทั้งหมด
• Occlusion culling — ข้าม object ที่ถูกบังมิดโดย geometry อื่นที่อยู่ใกล้กว่า
• Hi-Z (hierarchical depth buffer) — pyramid แบบ mipmap ของ depth buffer ใช้เร่งความเร็ว occlusion test
• GPU-driven rendering — ทำการตัดสินใจเรื่อง visibility/culling บน GPU เองผ่าน compute shader แทนที่จะทำบน CPU ทีละ object
• Indirect draw call — คำสั่ง draw ที่ parameter ของมันถูกอ่านจาก GPU memory แทนที่จะถูกระบุไว้ล่วงหน้าโดย CPU
• Graphics debugger — เครื่องมือ (RenderDoc, PIX, Nsight Graphics) ที่ capture หนึ่งเฟรมที่ render แล้วให้เราตรวจดู buffer และ draw call ระหว่างทางทั้งหมดได้

15. Exercises

#include <cstdio>

float shadow_map[7][7] = {
    {5,5,5,5,5,5,5},
    {5,5,5,5,5,5,5},
    {5,5,2,2,2,5,5},
    {5,5,2,2,2,5,5},
    {5,5,2,2,2,5,5},
    {5,5,5,5,5,5,5},
    {5,5,5,5,5,5,5}
};

float pcf_shadow(int cx, int cy, float dist_from_light) {
    float bias = 0.01f;
    int lit_count = 0;
    for (int dy = -1; dy <= 1; ++dy)
        for (int dx = -1; dx <= 1; ++dx)
            if (dist_from_light <= shadow_map[cy + dy][cx + dx] + bias)
                lit_count++;
    return (float)lit_count / 9.0f;
}

int main() {
    printf("PCF at (4,3): %.3f\n", pcf_shadow(4, 3, 2.4f));
    return 0;
}

PCF at (4,3): 0.333

#include <cstdio>

bool inside_triangle(float x, float y) {
    return (x + y) < 7.0f;
}

int main() {
    float jitter_x[4] = {0.25f, 0.75f, 0.25f, 0.75f};
    float jitter_y[4] = {0.25f, 0.25f, 0.75f, 0.75f};
    int px = 3, py = 3;

    float history = 0.5f;
    float alpha = 0.25f;

    for (int frame = 0; frame < 8; ++frame) {
        int j = frame % 4; // cycle through the same 4 jitter offsets again
        float sample = inside_triangle(px + jitter_x[j], py + jitter_y[j]) ? 1.0f : 0.0f;
        history = history * (1.0f - alpha) + sample * alpha;
        printf("Frame %d: jittered sample=%.1f  accumulated=%.4f\n", frame, sample, history);
    }
    return 0;
}

Frame 0: jittered sample=1.0  accumulated=0.6250
Frame 1: jittered sample=0.0  accumulated=0.4688
Frame 2: jittered sample=0.0  accumulated=0.3516
Frame 3: jittered sample=0.0  accumulated=0.2637
Frame 4: jittered sample=1.0  accumulated=0.4478
Frame 5: jittered sample=0.0  accumulated=0.3358
Frame 6: jittered sample=0.0  accumulated=0.2519
Frame 7: jittered sample=0.0  accumulated=0.1889