Tối ưu số lượng asset để cảnh lớn vẫn chạy mượt

Tối ưu số lượng asset để cảnh lớn vẫn chạy mượt là Bài 40 của chuyên đề Twinmotion trong trực quan hóa và trình bày BĐS. Tối ưu cảnh lớn bằng Statistics: theo dõi FPS, GPU RAM, triangles, textures, meshes, objects và materials; giảm tài nguyên không có vai trò, phân cấp chi tiết theo camera và dùng Nanite/LOD khi phù hợp.

Biên soạn: ThS. Nguyễn Mạnh Hùng
GV. Khoa QLĐĐ&BĐS – ĐH Nông Lâm TP.HCM
Email: nguyenmanhhung@hcmuaf.edu.vn

Cập nhật 01/10/2026: Nội dung được đối chiếu với tài liệu Twinmotion Documentation hiện hành của Epic. Giao diện và tùy chọn có thể thay đổi theo phiên bản; khi có khác biệt, cần kiểm tra tài liệu chính thức của phiên bản đang sử dụng.

Lưu ý sử dụng: các số liệu, vật liệu, kích thước, cảnh quan, mật độ, phương án và tình huống trong bài nếu không nêu nguồn cụ thể đều là tình huống giả lập phục vụ giảng dạy. Twinmotion hỗ trợ trực quan hóa và trình bày; không tự thay thế hồ sơ thiết kế, khảo sát, quy hoạch, pháp lý, giao thông, cảnh quan hoặc quyết định kỹ thuật đã được phê duyệt.

Mục tiêu học tập

Đọc được các chỉ số chính trong Statistics.
Tìm nhóm tài nguyên gây tải.
Tối ưu theo khoảng cách camera thay vì xóa ngẫu nhiên.
Phân biệt giảm dữ liệu với giảm Quality viewport.
Lập bảng QA hiệu năng trước chương ánh sáng.

Vị trí của bài trong mạch 96 bài

Đây là bài khép lại Chương 5. Sau khi đã thêm cây, người, xe, đường chuyển động và bối cảnh, người học phải biết đo tải cảnh và biên tập lại để cảnh đủ thuyết phục nhưng vẫn vận hành ổn định.

Bài thuộc Chương 5 – Cảnh quan, con người và bối cảnh. Khi hoàn thành, sinh viên phải có một sản phẩm kiểm chứng được bằng cảnh Twinmotion, bảng kiểm và ảnh chụp trước–sau; không chỉ ghi lại tên công cụ.

1. Tối ưu phải bắt đầu bằng đo lường

Statistics giúp phân biệt scene nặng do textures, meshes, objects, lights hay GPU RAM thay vì đoán.

Trong tối ưu cảnh, “tối ưu phải bắt đầu bằng đo lường” cần được kiểm bằng số liệu trước–sau thay vì cảm giác. Statistics giúp phân biệt scene nặng do textures, meshes, objects, lights hay GPU RAM thay vì đoán. Một thay đổi chỉ có giá trị khi giảm tải ở đúng nút thắt mà vẫn giữ thông tin cần thiết cho media cuối. Vì vậy nên thay đổi từng nhóm, ghi lại Statistics và kiểm lại các camera quan trọng.

Cách kiểm: Statistics sau tối ưu tốt hơn mốc đầu ở nút thắt chính; camera quan trọng không mất thông tin; cảnh thao tác ổn định hơn và media cuối vẫn đạt mục tiêu.

Bằng chứng nên lưu: chụp một ảnh hoặc ghi một giá trị cho thấy cách xử lý tối ưu phải bắt đầu bằng đo lường trước và sau khi chỉnh. Nếu bài có nhiều phương án, giữ cùng camera và cùng điều kiện hiển thị để kết quả có thể so sánh. Khi làm nhóm, ghi ngắn lý do thay đổi ngay trong bảng kiểm để người sau không phải đoán vì sao cảnh được tổ chức như vậy.

2. FPS là tín hiệu so sánh thao tác

Trên cùng máy và cùng cảnh, FPS giúp đánh giá trước–sau; không nên chạy theo một ngưỡng duy nhất cho mọi cấu hình.

Trong tối ưu cảnh, “fps là tín hiệu so sánh thao tác” cần được kiểm bằng số liệu trước–sau thay vì cảm giác. Trên cùng máy và cùng cảnh, FPS giúp đánh giá trước–sau; không nên chạy theo một ngưỡng duy nhất cho mọi cấu hình. Một thay đổi chỉ có giá trị khi giảm tải ở đúng nút thắt mà vẫn giữ thông tin cần thiết cho media cuối. Vì vậy nên thay đổi từng nhóm, ghi lại Statistics và kiểm lại các camera quan trọng.

Bằng chứng nên lưu: chụp một ảnh hoặc ghi một giá trị cho thấy cách xử lý fps là tín hiệu so sánh thao tác trước và sau khi chỉnh. Nếu bài có nhiều phương án, giữ cùng camera và cùng điều kiện hiển thị để kết quả có thể so sánh. Khi làm nhóm, ghi ngắn lý do thay đổi ngay trong bảng kiểm để người sau không phải đoán vì sao cảnh được tổ chức như vậy.

3. GPU RAM là giới hạn quan trọng

Nhiều texture và asset có thể đẩy GPU RAM cao, làm tăng nguy cơ lag hoặc sự cố khi xuất media.

Trong tối ưu cảnh, “gpu ram là giới hạn quan trọng” cần được kiểm bằng số liệu trước–sau thay vì cảm giác. Nhiều texture và asset có thể đẩy GPU RAM cao, làm tăng nguy cơ lag hoặc sự cố khi xuất media. Một thay đổi chỉ có giá trị khi giảm tải ở đúng nút thắt mà vẫn giữ thông tin cần thiết cho media cuối. Vì vậy nên thay đổi từng nhóm, ghi lại Statistics và kiểm lại các camera quan trọng.

Bằng chứng nên lưu: chụp một ảnh hoặc ghi một giá trị cho thấy cách xử lý gpu ram là giới hạn quan trọng trước và sau khi chỉnh. Nếu bài có nhiều phương án, giữ cùng camera và cùng điều kiện hiển thị để kết quả có thể so sánh. Khi làm nhóm, ghi ngắn lý do thay đổi ngay trong bảng kiểm để người sau không phải đoán vì sao cảnh được tổ chức như vậy.

4. Triangles cần tương xứng kích thước hiển thị

Mesh photogrammetry rất nặng ở hậu cảnh là chi phí khó nhìn thấy. Meshes tab giúp tìm đối tượng có triangle count lớn.

Trong tối ưu cảnh, “triangles cần tương xứng kích thước hiển thị” cần được kiểm bằng số liệu trước–sau thay vì cảm giác. Mesh photogrammetry rất nặng ở hậu cảnh là chi phí khó nhìn thấy. Meshes tab giúp tìm đối tượng có triangle count lớn. Một thay đổi chỉ có giá trị khi giảm tải ở đúng nút thắt mà vẫn giữ thông tin cần thiết cho media cuối. Vì vậy nên thay đổi từng nhóm, ghi lại Statistics và kiểm lại các camera quan trọng.

Bằng chứng nên lưu: chụp một ảnh hoặc ghi một giá trị cho thấy cách xử lý triangles cần tương xứng kích thước hiển thị trước và sau khi chỉnh. Nếu bài có nhiều phương án, giữ cùng camera và cùng điều kiện hiển thị để kết quả có thể so sánh. Khi làm nhóm, ghi ngắn lý do thay đổi ngay trong bảng kiểm để người sau không phải đoán vì sao cảnh được tổ chức như vậy.

5. Texture cần độ phân giải theo vai trò

Texture 4K cho vật nhỏ và xa có thể tốn bộ nhớ mà không tạo khác biệt thấy được.

Trong tối ưu cảnh, “texture cần độ phân giải theo vai trò” cần được kiểm bằng số liệu trước–sau thay vì cảm giác. Texture 4K cho vật nhỏ và xa có thể tốn bộ nhớ mà không tạo khác biệt thấy được. Một thay đổi chỉ có giá trị khi giảm tải ở đúng nút thắt mà vẫn giữ thông tin cần thiết cho media cuối. Vì vậy nên thay đổi từng nhóm, ghi lại Statistics và kiểm lại các camera quan trọng.

Bằng chứng nên lưu: chụp một ảnh hoặc ghi một giá trị cho thấy cách xử lý texture cần độ phân giải theo vai trò trước và sau khi chỉnh. Nếu bài có nhiều phương án, giữ cùng camera và cùng điều kiện hiển thị để kết quả có thể so sánh. Khi làm nhóm, ghi ngắn lý do thay đổi ngay trong bảng kiểm để người sau không phải đoán vì sao cảnh được tổ chức như vậy.

6. Objects và materials cũng cần dọn

Quá nhiều đối tượng rời và material không dùng làm Scene graph, Materials dock và tệp khó quản lý.

Trong tối ưu cảnh, “objects và materials cũng cần dọn” cần được kiểm bằng số liệu trước–sau thay vì cảm giác. Quá nhiều đối tượng rời và material không dùng làm Scene graph, Materials dock và tệp khó quản lý. Một thay đổi chỉ có giá trị khi giảm tải ở đúng nút thắt mà vẫn giữ thông tin cần thiết cho media cuối. Vì vậy nên thay đổi từng nhóm, ghi lại Statistics và kiểm lại các camera quan trọng.

Bằng chứng nên lưu: chụp một ảnh hoặc ghi một giá trị cho thấy cách xử lý objects và materials cũng cần dọn trước và sau khi chỉnh. Nếu bài có nhiều phương án, giữ cùng camera và cùng điều kiện hiển thị để kết quả có thể so sánh. Khi làm nhóm, ghi ngắn lý do thay đổi ngay trong bảng kiểm để người sau không phải đoán vì sao cảnh được tổ chức như vậy.

7. Tái sử dụng instance khi đối tượng lặp

Cây, ghế, đèn hoặc tài nguyên giống nhau nên dùng cơ chế tái sử dụng phù hợp thay vì import nhiều bản độc lập.

Trong tối ưu cảnh, “tái sử dụng instance khi đối tượng lặp” cần được kiểm bằng số liệu trước–sau thay vì cảm giác. Cây, ghế, đèn hoặc tài nguyên giống nhau nên dùng cơ chế tái sử dụng phù hợp thay vì import nhiều bản độc lập. Một thay đổi chỉ có giá trị khi giảm tải ở đúng nút thắt mà vẫn giữ thông tin cần thiết cho media cuối. Vì vậy nên thay đổi từng nhóm, ghi lại Statistics và kiểm lại các camera quan trọng.

Bằng chứng nên lưu: chụp một ảnh hoặc ghi một giá trị cho thấy cách xử lý tái sử dụng instance khi đối tượng lặp trước và sau khi chỉnh. Nếu bài có nhiều phương án, giữ cùng camera và cùng điều kiện hiển thị để kết quả có thể so sánh. Khi làm nhóm, ghi ngắn lý do thay đổi ngay trong bảng kiểm để người sau không phải đoán vì sao cảnh được tổ chức như vậy.

8. Nanite và LOD chỉ giải quyết một phần vấn đề

Các công nghệ này giúp quản lý hình học chi tiết nhưng không thay việc dọn texture nặng, object vô ích hay context dư.

Trong tối ưu cảnh, “nanite và lod chỉ giải quyết một phần vấn đề” cần được kiểm bằng số liệu trước–sau thay vì cảm giác. Các công nghệ này giúp quản lý hình học chi tiết nhưng không thay việc dọn texture nặng, object vô ích hay context dư. Một thay đổi chỉ có giá trị khi giảm tải ở đúng nút thắt mà vẫn giữ thông tin cần thiết cho media cuối. Vì vậy nên thay đổi từng nhóm, ghi lại Statistics và kiểm lại các camera quan trọng.

Bằng chứng nên lưu: chụp một ảnh hoặc ghi một giá trị cho thấy cách xử lý nanite và lod chỉ giải quyết một phần vấn đề trước và sau khi chỉnh. Nếu bài có nhiều phương án, giữ cùng camera và cùng điều kiện hiển thị để kết quả có thể so sánh. Khi làm nhóm, ghi ngắn lý do thay đổi ngay trong bảng kiểm để người sau không phải đoán vì sao cảnh được tổ chức như vậy.

9. Giảm Quality viewport không phải tối ưu dữ liệu

Quality thấp có thể giúp thao tác tạm thời nhưng cảnh nặng vẫn tồn tại và có thể lộ khi export.

Trong tối ưu cảnh, “giảm quality viewport không phải tối ưu dữ liệu” cần được kiểm bằng số liệu trước–sau thay vì cảm giác. Quality thấp có thể giúp thao tác tạm thời nhưng cảnh nặng vẫn tồn tại và có thể lộ khi export. Một thay đổi chỉ có giá trị khi giảm tải ở đúng nút thắt mà vẫn giữ thông tin cần thiết cho media cuối. Vì vậy nên thay đổi từng nhóm, ghi lại Statistics và kiểm lại các camera quan trọng.

Bằng chứng nên lưu: chụp một ảnh hoặc ghi một giá trị cho thấy cách xử lý giảm quality viewport không phải tối ưu dữ liệu trước và sau khi chỉnh. Nếu bài có nhiều phương án, giữ cùng camera và cùng điều kiện hiển thị để kết quả có thể so sánh. Khi làm nhóm, ghi ngắn lý do thay đổi ngay trong bảng kiểm để người sau không phải đoán vì sao cảnh được tổ chức như vậy.

10. Tối ưu theo media cuối

Nếu sản phẩm chỉ có vài camera, tài nguyên ngoài vùng nhìn hoặc chi tiết không bao giờ xuất hiện là nơi ưu tiên giảm.

Trong tối ưu cảnh, “tối ưu theo media cuối” cần được kiểm bằng số liệu trước–sau thay vì cảm giác. Nếu sản phẩm chỉ có vài camera, tài nguyên ngoài vùng nhìn hoặc chi tiết không bao giờ xuất hiện là nơi ưu tiên giảm. Một thay đổi chỉ có giá trị khi giảm tải ở đúng nút thắt mà vẫn giữ thông tin cần thiết cho media cuối. Vì vậy nên thay đổi từng nhóm, ghi lại Statistics và kiểm lại các camera quan trọng.

Bằng chứng nên lưu: chụp một ảnh hoặc ghi một giá trị cho thấy cách xử lý tối ưu theo media cuối trước và sau khi chỉnh. Nếu bài có nhiều phương án, giữ cùng camera và cùng điều kiện hiển thị để kết quả có thể so sánh. Khi làm nhóm, ghi ngắn lý do thay đổi ngay trong bảng kiểm để người sau không phải đoán vì sao cảnh được tổ chức như vậy.

11. Tối ưu cũng là biên tập nội dung

Khi bỏ bớt tài nguyên, nhóm phải xác định đâu là thông tin quan trọng. Nhiều cảnh sau tối ưu còn rõ bố cục hơn.

Trong tối ưu cảnh, “tối ưu cũng là biên tập nội dung” cần được kiểm bằng số liệu trước–sau thay vì cảm giác. Khi bỏ bớt tài nguyên, nhóm phải xác định đâu là thông tin quan trọng. Nhiều cảnh sau tối ưu còn rõ bố cục hơn. Một thay đổi chỉ có giá trị khi giảm tải ở đúng nút thắt mà vẫn giữ thông tin cần thiết cho media cuối. Vì vậy nên thay đổi từng nhóm, ghi lại Statistics và kiểm lại các camera quan trọng.

Bằng chứng nên lưu: chụp một ảnh hoặc ghi một giá trị cho thấy cách xử lý tối ưu cũng là biên tập nội dung trước và sau khi chỉnh. Nếu bài có nhiều phương án, giữ cùng camera và cùng điều kiện hiển thị để kết quả có thể so sánh. Khi làm nhóm, ghi ngắn lý do thay đổi ngay trong bảng kiểm để người sau không phải đoán vì sao cảnh được tổ chức như vậy.

Quy trình thao tác đề nghị

Bước 1. Mở Statistics và ghi mốc ban đầu: FPS, GPU RAM, triangles, textures, meshes, objects và materials. Sau bước này cần dừng vài giây để quan sát toàn cảnh và một góc kiểm gần; nếu kết quả làm sai tỷ lệ hoặc che thông tin, sửa ngay trước khi chuyển bước.
Bước 2. Xác định media cuối và camera quan trọng; không tối ưu đồng đều những vùng không bao giờ xuất hiện. Sau bước này cần dừng vài giây để quan sát toàn cảnh và một góc kiểm gần; nếu kết quả làm sai tỷ lệ hoặc che thông tin, sửa ngay trước khi chuyển bước.
Bước 3. Loại bỏ tài nguyên không có vai trò hoặc trùng lặp trước khi giảm chất lượng tài nguyên cần thiết. Sau bước này cần dừng vài giây để quan sát toàn cảnh và một góc kiểm gần; nếu kết quả làm sai tỷ lệ hoặc che thông tin, sửa ngay trước khi chuyển bước.
Bước 4. Giảm độ chi tiết hình học theo kích thước hiển thị; tài nguyên xa không cần số tam giác như tiền cảnh. Sau bước này cần dừng vài giây để quan sát toàn cảnh và một góc kiểm gần; nếu kết quả làm sai tỷ lệ hoặc che thông tin, sửa ngay trước khi chuyển bước.
Bước 5. Kiểm texture có độ phân giải quá cao so với kích thước trên màn hình và giảm ở tài nguyên hậu cảnh. Sau bước này cần dừng vài giây để quan sát toàn cảnh và một góc kiểm gần; nếu kết quả làm sai tỷ lệ hoặc che thông tin, sửa ngay trước khi chuyển bước.
Bước 6. Tái sử dụng instance/nhóm tài nguyên lặp khi phù hợp thay vì tạo nhiều biến thể không cần thiết. Sau bước này cần dừng vài giây để quan sát toàn cảnh và một góc kiểm gần; nếu kết quả làm sai tỷ lệ hoặc che thông tin, sửa ngay trước khi chuyển bước.
Bước 7. Xem xét Nanite hoặc cơ chế LOD khi phiên bản và loại nội dung hỗ trợ, nhưng không coi đó là lý do để giữ mọi tài nguyên nặng. Sau bước này cần dừng vài giây để quan sát toàn cảnh và một góc kiểm gần; nếu kết quả làm sai tỷ lệ hoặc che thông tin, sửa ngay trước khi chuyển bước.
Bước 8. Đo lại Statistics sau từng nhóm thay đổi để biết giải pháp nào thực sự có hiệu quả. Sau bước này cần dừng vài giây để quan sát toàn cảnh và một góc kiểm gần; nếu kết quả làm sai tỷ lệ hoặc che thông tin, sửa ngay trước khi chuyển bước.
Bước 9. Kiểm lần cuối ở chất lượng và độ phân giải gần với media giao nộp, rồi ghi lại mốc sau tối ưu để so sánh. Sau bước này cần dừng vài giây để quan sát toàn cảnh và một góc kiểm gần; nếu kết quả làm sai tỷ lệ hoặc che thông tin, sửa ngay trước khi chuyển bước.

Bảng quyết định nhanh

#	Vấn đề	Cách hiểu	Dấu hiệu đạt
1	Tối ưu phải bắt đầu bằng đo lường	Statistics giúp phân biệt scene nặng do textures, meshes, objects, lights hay GPU RAM thay vì đoán.	Statistics sau tối ưu tốt hơn mốc đầu ở nút thắt chính; camera quan trọng không mất thông tin; cảnh thao tác ổn định hơn và media cuối vẫn đạt mục tiêu.
2	FPS là tín hiệu so sánh thao tác	Trên cùng máy và cùng cảnh, FPS giúp đánh giá trước–sau; không nên chạy theo một ngưỡng duy nhất cho mọi cấu hình.	Statistics sau tối ưu tốt hơn mốc đầu ở nút thắt chính; camera quan trọng không mất thông tin; cảnh thao tác ổn định hơn và media cuối vẫn đạt mục tiêu.
3	GPU RAM là giới hạn quan trọng	Nhiều texture và asset có thể đẩy GPU RAM cao, làm tăng nguy cơ lag hoặc sự cố khi xuất media.	Statistics sau tối ưu tốt hơn mốc đầu ở nút thắt chính; camera quan trọng không mất thông tin; cảnh thao tác ổn định hơn và media cuối vẫn đạt mục tiêu.
4	Triangles cần tương xứng kích thước hiển thị	Mesh photogrammetry rất nặng ở hậu cảnh là chi phí khó nhìn thấy. Meshes tab giúp tìm đối tượng có triangle count lớn.	Statistics sau tối ưu tốt hơn mốc đầu ở nút thắt chính; camera quan trọng không mất thông tin; cảnh thao tác ổn định hơn và media cuối vẫn đạt mục tiêu.
5	Texture cần độ phân giải theo vai trò	Texture 4K cho vật nhỏ và xa có thể tốn bộ nhớ mà không tạo khác biệt thấy được.	Statistics sau tối ưu tốt hơn mốc đầu ở nút thắt chính; camera quan trọng không mất thông tin; cảnh thao tác ổn định hơn và media cuối vẫn đạt mục tiêu.
6	Objects và materials cũng cần dọn	Quá nhiều đối tượng rời và material không dùng làm Scene graph, Materials dock và tệp khó quản lý.	Statistics sau tối ưu tốt hơn mốc đầu ở nút thắt chính; camera quan trọng không mất thông tin; cảnh thao tác ổn định hơn và media cuối vẫn đạt mục tiêu.

Tình huống ứng dụng BĐS

Tình huống giả lập phục vụ giảng dạy: Cảnh khu căn hộ có nhiều cây, người, xe và context; viewport lag khi xoay quanh sân. Nhóm cần tối ưu mà không thay đổi sáu camera đã duyệt.

Nhóm không được bắt đầu bằng việc kéo tài nguyên hoặc chỉnh thông số ngẫu nhiên. Trước tiên phải xác định camera cần giao nộp, yếu tố nào đang làm người xem hiểu sai hoặc chưa hiểu được không gian, sau đó mới chọn công cụ. Mọi thay đổi lớn đều phải có ảnh trước–sau hoặc số liệu kiểm. Đây là cách biến thao tác phần mềm thành quyết định có thể giải thích.

Chặng 1: Mở Statistics và ghi mốc ban đầu: FPS, GPU RAM, triangles, textures, meshes, objects và materials. Khi kết thúc chặng, ghi một nhận xét ngắn: giữ, sửa tiếp hay hoàn tác.
Chặng 2: Xác định media cuối và camera quan trọng; không tối ưu đồng đều những vùng không bao giờ xuất hiện. Khi kết thúc chặng, ghi một nhận xét ngắn: giữ, sửa tiếp hay hoàn tác.
Chặng 3: Loại bỏ tài nguyên không có vai trò hoặc trùng lặp trước khi giảm chất lượng tài nguyên cần thiết. Khi kết thúc chặng, ghi một nhận xét ngắn: giữ, sửa tiếp hay hoàn tác.
Chặng 4: Giảm độ chi tiết hình học theo kích thước hiển thị; tài nguyên xa không cần số tam giác như tiền cảnh. Khi kết thúc chặng, ghi một nhận xét ngắn: giữ, sửa tiếp hay hoàn tác.
Chặng 5: Kiểm texture có độ phân giải quá cao so với kích thước trên màn hình và giảm ở tài nguyên hậu cảnh. Khi kết thúc chặng, ghi một nhận xét ngắn: giữ, sửa tiếp hay hoàn tác.
Chặng 6: Tái sử dụng instance/nhóm tài nguyên lặp khi phù hợp thay vì tạo nhiều biến thể không cần thiết. Khi kết thúc chặng, ghi một nhận xét ngắn: giữ, sửa tiếp hay hoàn tác.
Chặng 7: Xem xét Nanite hoặc cơ chế LOD khi phiên bản và loại nội dung hỗ trợ, nhưng không coi đó là lý do để giữ mọi tài nguyên nặng. Khi kết thúc chặng, ghi một nhận xét ngắn: giữ, sửa tiếp hay hoàn tác.

Phân tích sâu tình huống

Điểm dễ sai nhất là tối ưu cho một góc duy nhất. Trong công việc BĐS, cùng một cảnh thường phải phục vụ ảnh tổng, ảnh chi tiết và đôi khi cả video. Một giải pháp tốt phải giữ được logic khi camera thay đổi; nếu chỉ đẹp ở một góc nhưng lộ sai tỷ lệ hoặc xuyên vật thể ở góc khác thì chưa đạt.

Cần phân biệt dữ liệu nguồn với lớp trình bày. Hình học, kích thước, ranh giới và cao độ có nguồn của chúng; Twinmotion bổ sung vật liệu, ánh sáng, tài nguyên và chuyển động để truyền đạt. Không nên dùng một lớp trình bày đẹp để che dữ liệu nguồn chưa chắc chắn.

Khả năng cập nhật quan trọng không kém hình ảnh cuối. Một dự án thực tế luôn thay đổi. Nếu toàn bộ cây, người, xe hoặc vật liệu được đặt không có cấu trúc, lần đồng bộ tiếp theo sẽ tốn công kiểm lại. Tổ chức Scene graph và đặt tên vì vậy là một phần của chất lượng, không phải việc dọn dẹp sau cùng.

Một cảnh tốt luôn có giới hạn. Thêm nhiều chi tiết có thể làm hình ảnh phong phú hơn nhưng cũng làm giảm độ rõ của thông tin, tăng tải GPU và tăng rủi ro lỗi. Quyết định nghề nghiệp là biết dừng ở mức đủ để trả lời mục tiêu trình bày.

Những lỗi thường gặp và cách sửa

Lỗi	Hậu quả	Cách sửa
Bỏ qua bước “Tối ưu phải bắt đầu bằng đo lường” hoặc chỉ kiểm bằng mắt.	Cảnh có thể đẹp ở một góc nhưng sai tỷ lệ, khó cập nhật, khó bàn giao hoặc làm người xem hiểu sai vai trò không gian.	Quay lại kiểm tối ưu phải bắt đầu bằng đo lường bằng mốc đo, camera cố định, Scene graph hoặc Statistics tùy nội dung của bài; lưu bằng chứng trước–sau.
Bỏ qua bước “FPS là tín hiệu so sánh thao tác” hoặc chỉ kiểm bằng mắt.	Cảnh có thể đẹp ở một góc nhưng sai tỷ lệ, khó cập nhật, khó bàn giao hoặc làm người xem hiểu sai vai trò không gian.	Quay lại kiểm fps là tín hiệu so sánh thao tác bằng mốc đo, camera cố định, Scene graph hoặc Statistics tùy nội dung của bài; lưu bằng chứng trước–sau.
Bỏ qua bước “GPU RAM là giới hạn quan trọng” hoặc chỉ kiểm bằng mắt.	Cảnh có thể đẹp ở một góc nhưng sai tỷ lệ, khó cập nhật, khó bàn giao hoặc làm người xem hiểu sai vai trò không gian.	Quay lại kiểm gpu ram là giới hạn quan trọng bằng mốc đo, camera cố định, Scene graph hoặc Statistics tùy nội dung của bài; lưu bằng chứng trước–sau.
Bỏ qua bước “Triangles cần tương xứng kích thước hiển thị” hoặc chỉ kiểm bằng mắt.	Cảnh có thể đẹp ở một góc nhưng sai tỷ lệ, khó cập nhật, khó bàn giao hoặc làm người xem hiểu sai vai trò không gian.	Quay lại kiểm triangles cần tương xứng kích thước hiển thị bằng mốc đo, camera cố định, Scene graph hoặc Statistics tùy nội dung của bài; lưu bằng chứng trước–sau.
Bỏ qua bước “Texture cần độ phân giải theo vai trò” hoặc chỉ kiểm bằng mắt.	Cảnh có thể đẹp ở một góc nhưng sai tỷ lệ, khó cập nhật, khó bàn giao hoặc làm người xem hiểu sai vai trò không gian.	Quay lại kiểm texture cần độ phân giải theo vai trò bằng mốc đo, camera cố định, Scene graph hoặc Statistics tùy nội dung của bài; lưu bằng chứng trước–sau.
Bỏ qua bước “Objects và materials cũng cần dọn” hoặc chỉ kiểm bằng mắt.	Cảnh có thể đẹp ở một góc nhưng sai tỷ lệ, khó cập nhật, khó bàn giao hoặc làm người xem hiểu sai vai trò không gian.	Quay lại kiểm objects và materials cũng cần dọn bằng mốc đo, camera cố định, Scene graph hoặc Statistics tùy nội dung của bài; lưu bằng chứng trước–sau.
Bỏ qua bước “Tái sử dụng instance khi đối tượng lặp” hoặc chỉ kiểm bằng mắt.	Cảnh có thể đẹp ở một góc nhưng sai tỷ lệ, khó cập nhật, khó bàn giao hoặc làm người xem hiểu sai vai trò không gian.	Quay lại kiểm tái sử dụng instance khi đối tượng lặp bằng mốc đo, camera cố định, Scene graph hoặc Statistics tùy nội dung của bài; lưu bằng chứng trước–sau.
Bỏ qua bước “Nanite và LOD chỉ giải quyết một phần vấn đề” hoặc chỉ kiểm bằng mắt.	Cảnh có thể đẹp ở một góc nhưng sai tỷ lệ, khó cập nhật, khó bàn giao hoặc làm người xem hiểu sai vai trò không gian.	Quay lại kiểm nanite và lod chỉ giải quyết một phần vấn đề bằng mốc đo, camera cố định, Scene graph hoặc Statistics tùy nội dung của bài; lưu bằng chứng trước–sau.

Sáu cổng kiểm chất lượng trước khi chuyển bước

Cổng	Điều kiện
Đúng mục tiêu	Mỗi thay đổi phải hỗ trợ ít nhất một camera, một quyết định hoặc một thông tin cần truyền đạt.
Đúng tỷ lệ	Kích thước và vị trí phải hợp với mốc thật; tránh đánh giá chỉ theo cảm giác phối cảnh.
Đúng cấu trúc	Đối tượng được đặt tên/gom nhóm đủ để tìm, bật tắt và cập nhật.
Đúng hiệu năng	Statistics được kiểm ở cảnh lớn; không để tài nguyên không cần thiết làm giảm khả năng thao tác.
Đúng giới hạn	Không biến dữ liệu trực quan thành kết luận pháp lý, khảo sát, giao thông hay thiết kế đã phê duyệt.
Đúng đầu ra	Ảnh/video cuối được kiểm ở đúng camera, khung hình và chất lượng gần với bản giao nộp.

Bài thực hành

Sử dụng chính tình huống của bài: Cảnh khu căn hộ có nhiều cây, người, xe và context; viewport lag khi xoay quanh sân. Nhóm cần tối ưu mà không thay đổi sáu camera đã duyệt. Sinh viên phải tạo một bản trước và một bản sau, giữ ít nhất hai camera kiểm cố định và ghi lại quyết định ở từng bước. Không chấm điểm dựa trên việc cảnh chứa nhiều tài nguyên; trọng tâm là tính hợp lý, khả năng giải thích và khả năng cập nhật.

Mở Statistics và ghi mốc ban đầu: FPS, GPU RAM, triangles, textures, meshes, objects và materials.
Xác định media cuối và camera quan trọng; không tối ưu đồng đều những vùng không bao giờ xuất hiện.
Loại bỏ tài nguyên không có vai trò hoặc trùng lặp trước khi giảm chất lượng tài nguyên cần thiết.
Giảm độ chi tiết hình học theo kích thước hiển thị; tài nguyên xa không cần số tam giác như tiền cảnh.
Kiểm texture có độ phân giải quá cao so với kích thước trên màn hình và giảm ở tài nguyên hậu cảnh.
Tái sử dụng instance/nhóm tài nguyên lặp khi phù hợp thay vì tạo nhiều biến thể không cần thiết.
Xem xét Nanite hoặc cơ chế LOD khi phiên bản và loại nội dung hỗ trợ, nhưng không coi đó là lý do để giữ mọi tài nguyên nặng.
Đo lại Statistics sau từng nhóm thay đổi để biết giải pháp nào thực sự có hiệu quả.

Sản phẩm sinh viên phải nộp

Tệp Twinmotion đã tổ chức Scene graph rõ ràng, không để các nhóm chính ở trạng thái khó nhận biết.
Một bảng kiểm ngắn ghi mục tiêu, thay đổi đã thực hiện, lý do và kết quả kiểm.
Ít nhất hai ảnh trước–sau dùng cùng camera để chứng minh tác động của quyết định.
Ít nhất một ảnh tổng và một ảnh chi tiết; nếu bài liên quan chuyển động thì nộp thêm đoạn media ngắn hoặc chuỗi ảnh kiểm.
Ảnh chụp Statistics khi bài có thêm nhiều tài nguyên hoặc khi hiệu năng là một phần của quyết định.
Một đoạn 150–250 từ giải thích điều gì đã được giữ lại, điều gì đã loại bỏ và vì sao.

Phiếu tự kiểm trước khi nộp

☐ Đã kiểm: Tối ưu phải bắt đầu bằng đo lường.
☐ Đã kiểm: FPS là tín hiệu so sánh thao tác.
☐ Đã kiểm: GPU RAM là giới hạn quan trọng.
☐ Đã kiểm: Triangles cần tương xứng kích thước hiển thị.
☐ Đã kiểm: Texture cần độ phân giải theo vai trò.
☐ Đã kiểm: Objects và materials cũng cần dọn.
☐ Đã kiểm: Tái sử dụng instance khi đối tượng lặp.
☐ Đã kiểm: Nanite và LOD chỉ giải quyết một phần vấn đề.
☐ Đã kiểm: Giảm Quality viewport không phải tối ưu dữ liệu.
☐ Đã kiểm: Tối ưu theo media cuối.
☐ Đã kiểm: Tối ưu cũng là biên tập nội dung.
☐ Đã ghi rõ dữ liệu nào chỉ là giả lập/minh họa và dữ liệu nào có nguồn chính thức.
☐ Đã kiểm lại ít nhất hai camera thay vì chỉ một góc đẹp.
☐ Đã mở Statistics nếu cảnh có dấu hiệu nặng hoặc bài yêu cầu đánh giá tải.
☐ Đã đặt tên nhóm/đối tượng chính đủ rõ để một thành viên khác tiếp tục công việc.

Câu hỏi phản biện

Nếu bỏ 30% số tài nguyên trong cảnh, thông tin nào mất đi và thông tin nào không thay đổi?
Điều gì trong kết quả hiện tại là dữ liệu nguồn, điều gì chỉ là lớp trình bày?
Nếu camera chính thay đổi, quyết định nào của bạn còn đúng và quyết định nào phải kiểm lại?
Nếu mô hình nguồn cập nhật ngày mai, phần việc nào của bài có thể giữ lại nhờ cấu trúc hiện tại?
Yếu tố nào có thể khiến người không chuyên hiểu sai quy mô, hoạt động hoặc chất lượng của BĐS?
Bạn có bằng chứng trước–sau nào cho thấy thay đổi vừa thực hiện tốt hơn, thay vì chỉ khác đi?

Ghi nhớ trong 30 giây

Tối ưu phải bắt đầu bằng đo lường.
FPS là tín hiệu so sánh thao tác.
GPU RAM là giới hạn quan trọng.
Triangles cần tương xứng kích thước hiển thị.
Texture cần độ phân giải theo vai trò.
Luôn kiểm bằng camera và bằng chứng; không chỉ dựa vào cảm giác trong Viewport.
Tổ chức cảnh để có thể cập nhật và bàn giao, không chỉ để hoàn thành một ảnh.

Nguồn tham khảo

Statistics – Epic Games, Twinmotion Documentation.
Optimizing 3D Models for Real-Time Rendering – Epic Games, Twinmotion Documentation.
Optimizing Geometry with Nanite – Epic Games, Twinmotion Documentation.
GPU RAM Diagnostics – Epic Games, Twinmotion Documentation.

Tài liệu phần mềm thay đổi theo phiên bản. Khi vị trí menu, tên tùy chọn hoặc hành vi khác với bài, ưu tiên tài liệu chính thức tương ứng với phiên bản đang cài.

Bài tiếp theo

Bài 41: “Ambience: nơi điều khiển ánh sáng, trời, thời tiết và không khí của cảnh”.