Asset 3D do AI tạo: bẫy hiệu năng - quả bomb chờ nổ

Các công cụ tạo sinh AI sinh ra model 3D có những bước tiến bộ đáng kể, từ việc đưa quy trình mô tả ra bản xem trước 2D rồi chỉ với một nút bấm, một model 3D có cả PBR texture được tạo ra, với sự cải thiện lưới khá tốt, rất đáng nể.

Ở đây, khi những model 3D này đưa vào game development, đặc biệt là mobile, nó đang có những vấn đề rất cụ thể và có khi là chí mạng: điều gì xảy ra khi bạn nhét bốn trăm cái ghế đó vào một scene, không kể tới các nhân vật và môi trường, trên một chiếc máy tầm trung mà người chơi của bạn thật sự đang dùng.

Avinash Jaisrani đã viết một bài với góc nhìn khá đầy đủ trên Tech4Gamers về đúng vấn đề đó (bài gốc tiếng Anh, 29/8/2026). Phần dưới đây là cách tôi nhìn cùng vấn đề từ trong studio, cộng thêm vài thứ tôi nghĩ có thể đi sâu hơn.

Nhìn ổn trong Viewport của Gen3D tạo sinh, không đảm bảo mượt mà trên mobile devices.

Đây là sự phân biệt có tính chất nền tảng, và gần như mọi hiểu lầm về công cụ sinh 3D đều bắt đầu từ chỗ không phân biệt được hai thứ này.

Một model 3D ổn theo nghĩa render tĩnh thì chỉ cần đúng shape, texture đủ nét và góc chụp cần thiết không lộ ra những đoạn mesh rối loạn. Tuy nhiên một asset tốt trong game thì nó phải thỏa mãn cả một danh sách dài và các ràng buộc giữa chất lượng và hiệu năng. Vấn đề này sẽ trở nên càng quan trọng nếu game của bạn trên nền tảng mobile và đặc biệt phủ càng rộng càng tốt ở android. Nó sẽ bao gồm VRAM cho texture, các mesh để tính toán và chạm, topology tối ưu và đúng để không biến dạng khi animate.

Công cụ sinh 3D thời điểm bây giờ vẫn tốt cho 3D printing hoặc các asset rendered tĩnh thay vì có thể đáp ứng hoàn hảo cho vế thứ 2 của vấn đề - ingame assets.

Model sinh ra với tốc độ và chất lượng visual ổn, nó không hề sai, chỉ là nó chưa giải được bài toán bạn cần.

Năm bẫy thường gặp khi tạo sinh 3D assets cho game.

1. VRAM và tự sinh 4K texture. Công cụ tạo sinh thường xuất texture ở độ phân giải cao nhất có thể, và xuất đủ bộ map: base color, normal, roughness, metallic, ambient occlusion. Nhân bộ đó với vài trăm asset trong scene là VRAM sẽ cạn kiệt.

2. Material slot và draw call. Mỗi material slot sẽ chiếm một lượt draw call. Do vấn đề về tối ưu hóa chất lượng base mesh. Ta sẽ phải tách cái ghế ra hẳn một material thay vì nó có thể chia sẻ chung UV với cái bàn, bức tranh treo tường và con gà tây béo múp trên đĩa. Đây là một khoản chi phí CPU lẫn GPU hoàn toàn tránh được khi con người thực hiện khi gộp material, hiển nhiên, đây là việc thủ công.

3. Không có chuỗi LOD. Asset sinh ra thường chỉ có đúng một mức chi tiết: mức cao nhất. Trong game, một vật thể ở xa vẫn được vẽ bằng lưới đầy đủ là lãng phí thuần tuý. Chuỗi LOD không tự xuất hiện thế thì ta phải dựng tay. Có lẽ ta sẽ gen ra nhiều lần với mức mesh khác nhau. Nhưng lưới càng thấp thì model càng tệ và xô lệch cấu trúc, do AI không thể biết đường tối ưu những cái que dài 10m chỉ cần 8 vertexies mà vẫn đẹp.

4. Khối va chạm dùng luôn lưới hiển thị. Đây là cái bẫy tốn kém nhất mà cũng dễ sửa nhất. Thông thường ta sẽ dùng bản low cho collision, điều này hiển nhiên cho dù bạn đang làm game chạy trên RTX5090 thì cũng không ai tự hạ performance để dùng lưới hiển thị gốc. Thế là ta lại phải có một bản LOW cho phần va chạm này, lại phải tối ưu bằng tay.

5. Topology. Bài của Anivash nói sơ lược. Công bằng mà nói smartmesh trên Tripo hay Meshy cũng khá ổn khi chọn các mức 20K polygons. Tuy vậy, theo tôi đây cũng là chỗ mang lại nỗi đau dài lâu. Lưới sinh tự động thường dày đặc và không có luồng cạnh (edge flow) theo cấu trúc. Với một vật thể tĩnh thì không quan trọng. Với bất cứ thứ gì phải biến dạng — nhân vật, vải, khớp nối — lưới không có edge flow đúng sẽ nát bét khi làm chuyển động. Trong quy trình của chúng tôi, base mesh gen bởi AI chỉ giúp Concept artist có thể nhìn thấy nhân vật của họ ở 3 chiều một cách nhanh nhất, còn khi đi vào sử dụng, base đó vẫn chỉ là để tham chiếu.

Vì sao chỉ số trung bình đánh lừa bạn

Đây là phần tôi muốn nhấn mạnh, vì nó là lý do khiến 5 bẫy trên hay lọt qua khâu kiểm tra.

Bạn nhét asset vào, chạy thử, nhìn FPS trung bình: vẫn ổn. Kết luận: dùng được. Nhưng trải nghiệm tệ trong game không phải lúc nào cũng đến từ FPS trung bình tụt — nó đến từ những cú giật lag khựng hình đột ngột. Khi VRAM bị full, hệ thống bắt đầu hoán đổi tài nguyên, và cái người chơi cảm thấy là một đoạn giật khi quay góc nhìn, chứ không phải là con số đo trung bình nhỏ đi trong thông kê ban đầu.

Chi phí không biến mất mà nó dời chỗ.

Công cụ tạo sinh rút thời gian tạo hình từ vài ngày xuống vài phút. Đó là sự tiết kiểm rất rõ ràng trong quy trình phát triển game, không thể phủ nhận điều đó. Nhưng phần lớn công sức làm một asset game không nằm ở khâu tạo hình — nó nằm ở khâu biến hình đó thành thứ chạy ổn định: retopo, UV, gộp material, dựng LOD, gán collider, kiểm tra trong engine ở đúng mật độ.

Các khâu đó giờ nằm trong một cái hộp đen tạo sinh mà bạn không kiểm soát được quy trình ở giữa. Nên cái xảy ra không phải là chi phí giảm, mà là chi phí dời — từ khâu artist tạo hình sang khâu technical artist phải dọn dẹp. Studio nào tính vào ngân sách chỉ phần đầu và quên phần sau sẽ gặp đúng một kịch bản: giai đoạn đầu dự án chạy nhanh bất thường, rồi tắc nghẽn ở khâu tối ưu vào đúng lúc gần release, đây mới thực sự ác mộng, đặc biệt nếu những người lãnh đạo không thực sự hiểu vấn đề cả về nghệ thuật lẫn kỹ thuật đằng sau.

Đây cũng chính là điều tôi đã viết trong bài về AI tạo sinh trong pipeline mỹ thuật — phần “đẹp và nhất quán” đã giảm giá hẳn trong khi phần “lắp được vào engine” thì chưa.

Một danh sách kiểm tra có tính ứng dụng.

Nếu chúng ta đang cân nhắc đưa công cụ sinh 3D vào pipeline, tôi đề nghị hãy tìm cách chốt những thứ này trước:

Nhiều công cụ cho phép đặt tham số theo nền tảng đích như Tripo hay Meshy đều có target polygon, hãy luôn sử dụng nó. Giới hạn từ đầu luôn rẻ hơn dọn dẹp về sau.

Kết

Chúng ta biết rất rõ, tối ưu hóa không được phép là một thứ làm cuối cùng trong quy trình làm game, mà nó là thứ diễn ra song song trong mọi khâu. Việc 3D tạo sinh đang khiến cho quá trình đó trượt đi một cách rất nguy hiểm. Việc của chúng ta, những người có sự thấu hiểu đúng đắn với quy trình làm game chính là tận dụng tối đa tốc độ của AI, nhưng cũng nắm chắc những điểm nghẽn mà ta đã biết trước. Và quan trọng hơn thế, bạn phải cho những người có trách nhiệm hiểu rõ vấn đề này, trước khi sự hào hứng và quyền lực của họ kéo sản phẩm vào một hồi refractor khốn khổ.

Câu hỏi cho studio không phải “có nên dùng công cụ sinh 3D không”. Câu hỏi thực tế ở đây là “chúng ta đã có đủ kỷ luật kỹ thuật để hấp thụ tốc độ mà nó tạo ra chưa”. Nếu chưa, thì công cụ tạo sinh 3D không giúp bạn đi nhanh hơn — nó chỉ giúp bạn tạo ra những quả bom hẹn giờ về rác kỹ thuật.

Nguồn dữ liệu

• Avinash Jaisrani, “AI-Generated 3D Assets: Performance Traps”, Tech4Gamers, 29/8/2026 — bài gốc, nguồn của phần liệt kê các bẫy kỹ thuật: https://tech4gamers.com/ai-generated-3d-assets-performance-traps/
• Phần phân tích về topology, chỉ số frame-time / 1% low, và luận điểm “chi phí dời chỗ” là quan sát riêng của người viết.