Ray tracing vs path tracing: Khác nhau thế nào?

Giới thiệu

Ray tracing và path tracing không phải hai kỹ thuật đối đầu nhau: path tracing là một dạng của ray tracing. Ray tracing cổ điển theo dõi một tập tia nhỏ, cố định (tới gương, xuyên qua kính, hướng về từng đèn), còn path tracing theo dõi nhiều đường bounce ngẫu nhiên cho mỗi pixel rồi lấy trung bình. Nhờ vậy nó bắt được ánh sáng gián tiếp mềm rất thuyết phục, nhưng cũng tốn nhiều tài nguyên tính toán hơn hẳn.

Chi phí đó mới là điều đáng quan tâm trong production. Khi một khung hình mất 40 phút thay vì 4, hoặc trả về đầy noise, nguyên nhân thường nằm ở path tracing: cần bao nhiêu sample, theo dõi bao nhiêu bounce, và phần noise còn lại được xử lý ra sao. Bài viết này giải thích cả hai ý tưởng, cho thấy Arnold, Cycles, Karma, V-Ray và Redshift áp dụng chúng thế nào, và điều đó ảnh hưởng ra sao đến thời gian render.

Bài viết chủ ý chỉ bàn về render offline, từng khung hình, cho phim, hoạt hình, visualization và sản phẩm. Cách game đưa ray tracing vào đồ họa thời gian thực được trình bày trong lịch sử ray tracing thời gian thực trong game, còn sự phân chia rộng hơn giữa render tương tác và render khung hình cuối nằm ở real-time vs offline rendering. Nếu muốn nắm kiến thức nền về việc một renderer làm gì trước khi đi sâu hơn, hãy bắt đầu với rendering là gì.

Sơ đồ so sánh song song: ray tracing cổ điển gửi một tia từ camera, tia này tách thành các tia phản xạ, khúc xạ và bóng đổ cố định, còn path tracing gửi nhiều đường bounce ngẫu nhiên cho mỗi pixel rồi lấy trung bình

Ray tracing là gì

Ray tracing mô phỏng ánh sáng theo chiều ngược lại: thay vì theo dõi ánh sáng từ một bóng đèn cho đến khi nó tình cờ chạm tới camera, renderer bắn một tia từ camera qua từng pixel và hỏi xem tia đó chạm vào cái gì. Ý tưởng này đã có từ lâu. Bài viết của Wikipedia về ray tracing trong đồ họa máy tính (đọc ngày 19 tháng 10 năm 2026) ghi nhận Arthur Appel là người đầu tiên công bố cách dùng nó vào năm 1968, một phương pháp không đệ quy mà ngày nay thường được gọi là ray casting.

Phiên bản mà đa số mọi người nghĩ đến khi nhắc "ray tracing" xuất phát từ Turner Whitted, người có thuật toán đệ quy được trình bày tại SIGGRAPH năm 1979 và công bố năm 1980. Khi một tia camera chạm vào bề mặt, renderer tạo ra các tia mới theo những hướng cụ thể, có thể đoán trước:

một tia bóng đổ (shadow ray) hướng về từng đèn, để kiểm tra xem có vật nào chắn không,
một tia phản xạ (reflection ray) theo hướng gương, nếu bề mặt có tính phản xạ,
một tia khúc xạ (refraction ray) xuyên qua bề mặt, nếu bề mặt trong suốt.

Mỗi tia này lại có thể sinh ra các tia riêng của nó, tạo thành một cây phân nhánh dừng ở độ sâu đặt trước. Kết quả mang tính xác định, mạnh ở phản xạ sắc nét, khúc xạ sạch và bóng cứng, nhưng yếu ở mọi thứ phụ thuộc vào ánh sáng đến từ nhiều hướng cùng lúc: bóng mềm, độ nhòe glossy, color bleeding và ánh sáng ban ngày lan dần vào phía cuối căn phòng.

Những hiệu ứng đó là thứ ngành gọi là global illumination, và bản thân ray tracing cổ điển không tính ra chúng. Các renderer production từ lâu xử lý chúng bằng những hệ thống bổ sung như irradiance cache, photon map và final gather, mỗi thứ có thiết lập và artifact riêng.

Path tracing là gì

Path tracing do Jim Kajiya giới thiệu và đặt tên trong bài báo năm 1986 về rendering equation, theo bài viết về path tracing trên Wikipedia (đọc ngày 19 tháng 10 năm 2026). Nó ước lượng phương trình đó bằng cách lấy mẫu ngẫu nhiên.

Một tia rời camera qua một pixel và chạm vào bề mặt. Thay vì tách thành một tập tia con cố định, nó chọn ngẫu nhiên một hướng mới, có trọng số theo vật liệu (gương gần như chỉ gửi tia đi đúng một hướng, còn tường thạch cao mờ có thể gửi tia đi gần như mọi hướng). Tia nảy tiếp, rồi lại nảy tiếp, cho đến khi chạm tới đèn, rời khỏi scene hoặc đạt giới hạn bounce. Chuỗi bounce đơn lẻ, không phân nhánh đó là một path, và nó mang về một ước lượng về lượng ánh sáng đến pixel theo lộ trình ấy.

Một path là ước lượng kém; một nghìn path đi qua cùng một pixel, lấy trung bình, là ước lượng tốt. Đó chính là lấy mẫu Monte Carlo các đường đi của ánh sáng. Vì mỗi path có thể nảy khỏi bất kỳ thứ gì, path tracing tính ánh sáng gián tiếp, bóng mềm, phản xạ glossy, caustics (về nguyên tắc) và color bleeding trong một quy trình thống nhất, không cần cache riêng cho từng hiệu ứng.

Cái giá phải trả là noise. Cho đến khi đã lấy trung bình đủ số path, các pixel kề nhau không khớp nhau và ảnh trông bị hạt. Đánh đổi đó là phần hiện ra trên hóa đơn render của bạn.

Điểm khác biệt trong một bảng

	Ray tracing cổ điển (kiểu Whitted)	Path tracing
Điều xảy ra ở mỗi điểm chạm	Các tia con cố định: bóng đổ, phản xạ, khúc xạ	Một hướng mới được chọn ngẫu nhiên cho mỗi path
Số tia mỗi pixel	Một cây nhỏ, dễ đoán	Nhiều path độc lập, lấy trung bình
Kết quả	Xác định, không có noise	Ước lượng thống kê, có noise cho đến khi hội tụ
Ánh sáng gián tiếp và color bleeding	Không tính được nếu thiếu hệ thống bổ sung	Được tính sẵn trong phương pháp
Bóng mềm, độ nhòe glossy	Cần thêm tia hoặc mẹo xử lý	Tự xuất hiện từ việc lấy mẫu
Kiểm soát chất lượng chính	Độ sâu của tia	Sample mỗi pixel và giới hạn bounce
Hồ sơ chi phí	Thấp hơn, có giới hạn	Cao, tăng theo mục tiêu chất lượng

Một cách nói gọn hữu ích: ray tracing là công cụ (bắn một tia và tìm xem nó chạm vào đâu), còn path tracing là một chiến lược dùng công cụ đó để giải bài toán chiếu sáng đầy đủ. Mọi path tracer hiện đại đều được xây trên ray tracing. Không phải ray tracer nào cũng là path tracer.

Vì sao path tracing tạo ra noise, và vì sao dọn noise lại tốn kém

Noise trong ảnh path-traced không phải lỗi: mỗi pixel là trung bình của các sample ngẫu nhiên, và giá trị trung bình đó dao động cho đến khi có đủ sample. Bài viết của Wikipedia về tích phân Monte Carlo (đọc ngày 19 tháng 10 năm 2026) cho biết sai số của ước lượng giảm theo 1/√N, trong đó N là số sample. Theo cách nói của rendering: muốn giảm một nửa noise nhìn thấy được, bạn cần khoảng gấp bốn lần số sample mỗi pixel. Muốn giảm một nửa lần nữa, cần gấp mười sáu lần ban đầu. Nếu thời gian render tỷ lệ gần đúng với số sample, như với phần lớn khung hình, thì dọn nốt chút hạt cuối cùng là phần tốn kém nhất của cả lần render.

Bốn ô noise ở 16, 64, 256 và 1.024 sample mỗi pixel, cho thấy noise nhìn thấy được giảm một nửa sau mỗi lần tăng số sample gấp bốn

Một số scene khó hơn những scene khác, và lý do khá dễ đoán:

Nguồn sáng nhỏ hoặc bị che. Ánh sáng ban ngày xuyên qua một khe hẹp nghĩa là rất ít path ngẫu nhiên tìm thấy được đèn, nên ước lượng hội tụ chậm.
Vật liệu glossy và khúc xạ. Kim loại xước, kính mờ và chất lỏng rất khó lấy mẫu hiệu quả.
Nhiều bounce. Nội thất tường trắng phụ thuộc vào nhiều lần bounce; giảm giới hạn sẽ nhanh hơn nhưng làm tối các góc.
Volume và subsurface scattering. Khói, sương mù và da thêm hiện tượng tán xạ bên trong vật liệu, nhân lên khối lượng việc cho mỗi path.
Motion blur và depth of field. Mỗi sample còn chọn một thời điểm và một điểm trên thấu kính, nên cần nhiều sample hơn.

Độ phân giải quyết định có bao nhiêu pixel cần câu trả lời; ánh sáng quyết định mỗi pixel cần bao nhiêu sample trước khi câu trả lời của nó sạch.

Các renderer production dùng path tracing hiện nay như thế nào

Hầu hết renderer production offline hiện nay được xây quanh path tracing, nhưng không phải tất cả theo cùng một cách. Sự phân biệt hữu ích là giữa path tracing mọi bounce và path tracing bounce đầu tiên rồi dùng cache cho phần còn lại.

Arnold. Tài liệu Arnold của Autodesk (đọc ngày 19 tháng 10 năm 2026) mô tả nó là engine ray/path tracing Monte Carlo unbiased, dựa trên vật lý, và nêu rõ rằng nó tránh các thuật toán caching như photon mapping và final gather. Chất lượng chủ yếu được điều khiển qua số sample: khung hình càng sạch thì cần càng nhiều sample, và càng nhiều sample thì càng tốn thời gian.

Cycles. Cycles của Blender là một path tracer, và các thiết lập sampling của nó (sách hướng dẫn Blender 5.2 LTS, đọc ngày 19 tháng 10 năm 2026) cho thấy rõ bộ công cụ hiện đại: số path tối đa được trace cho mỗi pixel, ngưỡng noise để dừng lấy mẫu ở những vùng đã đủ sạch (adaptive sampling), giới hạn thời gian tùy chọn, và nhiều lựa chọn denoiser.

Karma. Chính tài liệu Karma của SideFX (tài liệu Houdini 22.0, đọc ngày 19 tháng 10 năm 2026) gọi nó là path tracer dựa trên vật lý của Houdini.

V-Ray. Chaos chia công việc thành engine global illumination chính (primary) và phụ (secondary). Trong V-Ray GPU cho 3ds Max, trang GPU Global Illumination của Chaos (đọc ngày 19 tháng 10 năm 2026) nêu rằng engine chính luôn là Brute Force (lấy mẫu path-traced thuần túy cho bounce đầu tiên), còn các bounce thứ cấp dùng Brute Force hoặc Light Cache. Light Cache là phép xấp xỉ được tính trước cho các bounce về sau, đánh đổi một chút độ chính xác để tiết kiệm rất nhiều sample.

Redshift. Tài liệu global illumination của Redshift từ Maxon (đọc ngày 19 tháng 10 năm 2026) mô tả Brute Force là engine GI chính xác nhất và chậm nhất, bị noise khi số ray thấp, đồng thời đưa ra Irradiance Point Cloud làm engine thứ cấp giúp Brute Force chính nhanh hơn và sạch hơn trong điều kiện chiếu sáng khó, đổi lại tốn thêm một ít dung lượng lưu trữ.

Mô hình cuối cùng đó, path tracing cho bounce bạn thấy nhiều nhất và cache cho phần còn lại, là lý do các từ "biased" và "unbiased" xuất hiện trong các cuộc bàn luận về renderer. Giá trị trung bình của một renderer unbiased hội tụ về đáp án đúng theo vật lý khi số sample tăng. Một renderer biased chấp nhận một sai lệch nhỏ, mang tính hệ thống (từ cache, clamp hoặc giới hạn bounce) để đổi lấy việc hội tụ sớm hơn nhiều. Cách nào cũng không sai. Với animation, cache cần được cân nhắc cẩn thận, vì cache tính riêng cho từng khung hình có thể gây nhấp nháy; với ảnh tĩnh, cache thường là con đường nhanh nhất để có ảnh sạch.

Denoising: ít sample hơn, cùng deadline

Nếu giảm một nửa noise tốn gấp bốn lần sample, lối tắt hiển nhiên là dừng sớm hơn và lọc bỏ phần noise còn lại. Đó là việc các denoiser hiện đại làm.

Hai denoiser mà đa số artist gặp là Intel Open Image Denoise và NVIDIA OptiX. Intel mô tả Open Image Denoise (đọc ngày 19 tháng 10 năm 2026) là một thư viện mã nguồn mở gồm các bộ lọc khử noise cho ảnh được render bằng ray tracing. Trang sampling của Cycles được dẫn ở trên liệt kê cả hai là lựa chọn, ghi chú rằng OptiX chỉ dùng được trên GPU NVIDIA, và mô tả thiết lập tự động là ưu tiên Open Image Denoise hơn OptiX.

Denoiser được huấn luyện để phân biệt noise do lấy mẫu với chi tiết thật, nhưng chúng có tác dụng phụ:

Mất chi tiết nhỏ. Texture mịn, tóc và geometry mỏng có thể bị làm mờ đi nếu đầu vào có quá ít sample.
Nhấp nháy theo thời gian. Denoiser xử lý riêng từng khung hình có thể cho kết quả hơi khác nhau giữa các khung hình liên tiếp, và trong animation điều này hiện ra như hiệu ứng lập lòe.
Compositing pass. Nếu bạn denoise beauty pass nhưng không denoise các AOV (hoặc ngược lại), các pass sẽ không còn cộng lại khớp nhau trong compositing.

Quy tắc thực tế là denoise một khung hình đã hội tụ ở mức tương đối, chứ không phải khung hình phần lớn là noise. Denoiser giúp giảm số sample bạn cần. Nó không thay thế số sample đó.

Path tracing ảnh hưởng thế nào đến thời gian render

Thời gian render của một job path-traced là tích của vài con số: số khung hình, số pixel mỗi khung hình, số sample mỗi pixel, và mức độ khó của từng sample với scene đó.

Một ví dụ giả định, chỉ để minh họa. Một shot dài mười giây ở 24 khung hình mỗi giây là 240 khung hình. Giả sử mỗi khung hình cần 16 phút trên một máy ở số sample cho ra ảnh sạch. Vậy là 64 giờ máy. Bây giờ khách yêu cầu giảm hạt trong vùng bóng. Nếu giảm một nửa noise cần gấp bốn lần sample, và thời gian tỷ lệ với số sample, thì cùng shot đó giờ khoảng 256 giờ máy. Một denoiser tốt có thể lấy lại phần lớn chênh lệch đó, và đó là lý do số sample cùng denoiser được quyết định chung trên một khung hình test.

Phép tính thời gian render cho một shot path-traced: 240 khung hình nhân 16 phút mỗi khung hình bằng 64 giờ máy, và gấp bốn lần sample để giảm một nửa noise cho ra khoảng 256 giờ máy

Ba thói quen giúp kiểm soát phép tính đó:

Đo trên một khung hình đại diện. Khung hình khó nhất của shot (khung có nhiều kính, volume hoặc motion blur nhất) mới là khung cần test, không phải khung đầu tiên.
Dùng adaptive sampling và ngưỡng noise ở nơi renderer có cung cấp, để các vùng đã sạch như bầu trời và tường phẳng dừng lấy mẫu sớm.
Dồn sample vào nơi mắt nhìn tới. Tăng sample cho những đèn hoặc vật liệu cụ thể vẫn còn noise, không tăng cho cả khung hình.

Danh sách đầy đủ các thiết lập ảnh hưởng đến thời gian render, từ giới hạn bounce đến kích thước texture, nằm trong hướng dẫn tối ưu thời gian render của chúng tôi. Việc những sample này chạy nhanh hơn trên CPU hay trên card đồ họa tùy thuộc vào renderer và scene, và được trình bày trong GPU rendering vs CPU rendering.

Chạy job path-traced trên render farm

Mỗi khung hình của một chuỗi path-traced được render độc lập, nên 240 khung hình trải trên nhiều máy sẽ hoàn thành trong thời gian của vài khung, trong khi tổng lượng tính toán, thứ mà một farm tính phí, vẫn không đổi. Nếu khái niệm render farm (hệ thống máy tính kết xuất) còn mới với bạn, hướng dẫn render farm là gì của chúng tôi giải thích mô hình này.

Trên Super Renders Farm, một render farm quản lý toàn diện, bạn tải scene lên và farm lo phần mềm cùng giấy phép render, nên không có phiên remote desktop và không phải cài đặt gì. Phần lớn công việc chúng tôi thấy được render trên CPU (V-Ray và Corona trên 3ds Max, Arnold trên Maya, Cycles trên Blender, Karma và Mantra trên Houdini), chạy trên các CPU node của chúng tôi.

Path tracing GPU chạy trên các GPU node của chúng tôi, mỗi node có 2x card NVIDIA RTX 5090 với 32 GB VRAM mỗi card. Bộ nhớ tính theo từng card và không được gộp chung giữa hai card, nên một khung hình GPU phải vừa trong 32 GB. Redshift chỉ render trên GPU node. Redshift cho Cinema 4D, Maya và Houdini, cùng Cycles trên GPU, chạy ở đó mà không cần gửi yêu cầu thiết lập; phần cứng GPU và các engine được hỗ trợ được liệt kê trên trang GPU cloud render farm của chúng tôi. Nếu một scene không vừa bộ nhớ của một card, path tracer chạy CPU thường là lựa chọn an toàn hơn cho job đó.

Giá hiện hành nằm ở trang bảng giá; chúng tôi không đưa con số vào bài giải thích này vì chúng thay đổi, và vì số sample bạn chốt ảnh hưởng đến chi phí cuối cùng nhiều hơn bất kỳ mức giá theo giờ nào. Tài khoản mới nhận $25 Render Credits miễn phí, bạn có thể dùng để render thử một khung hình đại diện trước khi quyết định cho cả chuỗi, và đội ngũ hỗ trợ của chúng tôi trực live chat 24/7.

Những hiểu lầm thường gặp

"Path tracing và ray tracing là hai công nghệ cạnh tranh nhau." Không phải vậy. Path tracing là một phương pháp được xây trên ray tracing. Một renderer production ngày nay được mô tả là ray tracer thường thực chất là path tracer ở bên dưới.

"Nhiều sample hơn luôn cho ảnh tốt hơn." Qua điểm mà noise không còn nhìn thấy được ở độ phân giải giao hàng, sample thêm chỉ làm tăng thời gian render. Adaptive sampling và ngưỡng noise được thiết kế để tìm ra điểm đó.

"Biased nghĩa là sai." Các kỹ thuật biased như cache hội tụ sớm hơn và là chuyện thường ngày trong production. Lựa chọn đúng tùy vào shot, đặc biệt là shot đó là ảnh tĩnh hay animation.

"Path tracing GPU luôn nhanh hơn." Thường là nhanh hơn trên mỗi khung hình, nhưng chỉ khi scene vừa bộ nhớ của card và renderer hỗ trợ mọi tính năng mà scene dùng. Các scene archviz lớn và volume nặng thường render ổn định hơn trên CPU.

FAQ

Q: Sự khác biệt giữa ray tracing và path tracing là gì? A: Ray tracing cổ điển theo dõi một tập tia cố định từ mỗi điểm chạm (về phía đèn, theo hướng gương và xuyên qua bề mặt trong suốt) và cho kết quả xác định, không có noise, nhưng không có ánh sáng gián tiếp. Path tracing theo dõi nhiều path bounce ngẫu nhiên cho mỗi pixel rồi lấy trung bình, nhờ đó tính ánh sáng gián tiếp, bóng mềm và color bleeding một cách tự nhiên, nhưng tạo ra noise cho đến khi đã lấy trung bình đủ sample.

Q: Path tracing là gì, nói đơn giản? A: Path tracing gửi một tia từ camera vào scene và để nó bounce theo hướng ngẫu nhiên ở mỗi bề mặt cho đến khi tìm thấy ánh sáng, rồi lặp lại nhiều lần cho mỗi pixel và lấy trung bình các kết quả. Phương pháp này do Jim Kajiya giới thiệu trong bài báo năm 1986 về rendering equation và là nền tảng của hầu hết renderer production offline hiện nay.

Q: Path tracing có phải một loại ray tracing không? A: Có. Path tracing dùng ray tracing để tìm xem mỗi tia chạm vào đâu, rồi áp dụng lấy mẫu Monte Carlo để quyết định tia tiếp theo đi về đâu. Mọi path tracer đều là ray tracer, nhưng không phải ray tracer nào cũng là path tracer.

Q: Vì sao ảnh path-traced bị noise? A: Mỗi pixel là trung bình của các sample ngẫu nhiên, và giá trị trung bình đó chưa chắc chắn cho đến khi có đủ sample. Sai số giảm tỷ lệ với một trên căn bậc hai của số sample, nên giảm một nửa noise cần khoảng gấp bốn lần số sample và, với đa số scene, khoảng gấp bốn lần thời gian render.

Q: V-Ray, Arnold, Cycles và Redshift có dùng path tracing không? A: Có, nhưng theo các cách khác nhau. Arnold, Cycles và Karma là path tracer điều khiển chất lượng chủ yếu qua số sample. V-Ray và Redshift cung cấp engine Brute Force path trace bounce đầu tiên và có thể ghép với cache cho các bounce sau (Light Cache trong V-Ray, Irradiance Point Cloud trong Redshift), giúp hội tụ sớm hơn, đổi lại một bias nhỏ.

Q: Denoising có thay thế được việc tăng số sample không? A: Không hoàn toàn. Các denoiser như Intel Open Image Denoise và NVIDIA OptiX cho phép bạn dừng ở số sample thấp hơn, nhưng chúng hiệu quả nhất trên những khung hình đã khá sạch. Quá ít sample có thể làm mất chi tiết nhỏ ở ảnh tĩnh và gây nhấp nháy trong animation.

Q: Path tracing nhanh hơn trên GPU hay CPU? A: Còn tùy renderer và scene. Path tracing GPU thường nhanh hơn trên mỗi khung hình khi scene vừa bộ nhớ của card, còn path tracing CPU xử lý được các scene rất lớn, volume nặng và những tính năng mà engine GPU chưa hỗ trợ. Trên farm của chúng tôi, GPU node có 2x RTX 5090 với 32 GB mỗi card, không gộp chung giữa các card.

Q: Render farm có thể tăng tốc path tracing không? A: Một farm không làm giảm lượng tính toán mà một khung hình cần, nhưng nó render nhiều khung hình cùng lúc, nên một chuỗi hoàn thành trong một phần nhỏ thời gian thực tế. Tổng thời gian máy, vốn phụ thuộc nhiều vào số sample bạn chọn, mới là thứ quyết định chi phí.