Bài 85 · Twinmotion trong trực quan hóa và trình bày BĐS

Case study: dự án khu ở – tạo tổng thể nhưng vẫn giữ hiệu năng

Case study: dự án khu ở – tạo tổng thể nhưng vẫn giữ hiệu năng là Bài 85 của chuyên đề Twinmotion trong trực quan hóa và trình bày BĐS. Tổ chức cảnh Twinmotion cho dự án khu ở quy mô lớn bằng phân cấp chi tiết, kiểm Statistics, tối ưu imported geometry, vegetation và asset lặp để giữ khả năng thao tác thời gian thực mà vẫn đủ chất lượng cho media.

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 kỹ thuật được đối chiếu với Twinmotion Documentation hiện hành của Epic. Tên nút, vị trí bảng điều khiển và một số tính năng có thể thay đổi giữa các phiên bản; khi giao diện trên máy khác bài, cần đối chiếu tài liệu chính thức của phiên bản đang sử dụng.

Lưu ý: các công trình, vật liệu, bối cảnh, tiến độ, mật độ người/xe và phương án 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 phục vụ trực quan hóa và trình bày; hình ảnh, video, Phasing, View sets hay Presentation không tự thay thế hồ sơ thiết kế, quy hoạch, khảo sát, tiến độ thi công hoặc thông tin thương mại đã được phê duyệt.

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

  • Phân loại đối tượng theo tầm quan trọng và khoảng cách camera.
  • Dùng Statistics xác định nút thắt hiệu năng.
  • Hiểu khi nào cân nhắc Nanite hoặc LOD cho imported geometry.
  • Tối ưu cây, xe, người và đèn theo camera.
  • Xây quy trình duyệt cảnh lớn trước xuất media.

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

Bài 83 kiểm hiệu năng trong biệt thự; Bài 85 nâng lên khu ở nhiều khối nhà và asset lặp. Mục tiêu là phân bổ tài nguyên đúng nơi người xem nhìn.

Bài thuộc Chương 11 – Ứng dụng trực quan hóa BĐS. Đây là nhóm bài ứng dụng nên tiêu chí đánh giá không dừng ở hình đẹp; tệp nguồn phải có cấu trúc, quyết định phải giải thích được, media phải đúng phiên bản và vòng cập nhật phải có thể kiểm chứng.

1. Near/Mid/Far

Phân cấp độ chi tiết theo camera và screen space. Trong case này, bước đó phải được gắn với mục tiêu đầu ra chứ không thực hiện theo thói quen. Người học cần xác định đối tượng nào chịu tác động, trạng thái nào là mốc gốc và bằng chứng nào chứng minh thay đổi có ích.

Về thực hành, hãy bắt đầu từ một bản đã lưu, chỉnh một nhóm yếu tố, chuyển sang camera hoặc trạng thái đối chứng rồi quay lại kiểm. Nếu thay đổi ảnh hưởng nhiều media, ghi media bị tác động trước khi xuất lại. Cách này tránh việc sửa một chỗ nhưng vô tình làm hỏng một View set, camera hoặc vật liệu đã được duyệt ở phần khác của dự án.

Liên hệ công việc BĐS: trực quan hóa thường đi qua nhiều vòng góp ý. Vì vậy mọi thay đổi cần trả lời ba câu hỏi: nó làm rõ thông tin nào; nó có làm người xem hiểu sai quy mô/bối cảnh/trạng thái không; và khi source thay đổi, nhóm có thể tái tạo kết quả này hay không.

Quy trình kiểm:

  1. Xác định trạng thái gốc liên quan đến near/mid/far.
  2. Tạo bản thử hoặc media đối chứng trước khi chỉnh.
  3. Chỉ thay một nhóm biến và lưu tên/version ngay.
  4. Kiểm trong Viewport và media đã lưu, không chỉ nhìn trạng thái tạm.
  5. Xuất một bản nhẹ hoặc chụp bằng chứng trước–sau.
  6. Ghi quyết định giữ/bỏ cùng lý do.

Tiêu chí đạt:

  • Kết quả có thể tái tạo.
  • Không làm mất thông tin quan trọng.
  • Không gây hiểu sai về thiết kế, hiện trạng hoặc tiến độ.
  • Tên và trạng thái đủ rõ để người khác tiếp tục.
  • Không làm tăng độ phức tạp scene nếu lợi ích không rõ.

Lưu ý: Không mọi khối cùng chi tiết.

2. Statistics

Fps, objects, materials, vram, textures, meshes. Trong case này, bước đó phải được gắn với mục tiêu đầu ra chứ không thực hiện theo thói quen. Người học cần xác định đối tượng nào chịu tác động, trạng thái nào là mốc gốc và bằng chứng nào chứng minh thay đổi có ích.

Về thực hành, hãy bắt đầu từ một bản đã lưu, chỉnh một nhóm yếu tố, chuyển sang camera hoặc trạng thái đối chứng rồi quay lại kiểm. Nếu thay đổi ảnh hưởng nhiều media, ghi media bị tác động trước khi xuất lại. Cách này tránh việc sửa một chỗ nhưng vô tình làm hỏng một View set, camera hoặc vật liệu đã được duyệt ở phần khác của dự án.

Liên hệ công việc BĐS: trực quan hóa thường đi qua nhiều vòng góp ý. Vì vậy mọi thay đổi cần trả lời ba câu hỏi: nó làm rõ thông tin nào; nó có làm người xem hiểu sai quy mô/bối cảnh/trạng thái không; và khi source thay đổi, nhóm có thể tái tạo kết quả này hay không.

Quy trình kiểm:

  1. Xác định trạng thái gốc liên quan đến statistics.
  2. Tạo bản thử hoặc media đối chứng trước khi chỉnh.
  3. Chỉ thay một nhóm biến và lưu tên/version ngay.
  4. Kiểm trong Viewport và media đã lưu, không chỉ nhìn trạng thái tạm.
  5. Xuất một bản nhẹ hoặc chụp bằng chứng trước–sau.
  6. Ghi quyết định giữ/bỏ cùng lý do.

Tiêu chí đạt:

  • Kết quả có thể tái tạo.
  • Không làm mất thông tin quan trọng.
  • Không gây hiểu sai về thiết kế, hiện trạng hoặc tiến độ.
  • Tên và trạng thái đủ rõ để người khác tiếp tục.
  • Không làm tăng độ phức tạp scene nếu lợi ích không rõ.

Lưu ý: Không tối ưu mù.

3. Nanite/LOD

Thử trên imported high-poly geometry và đo lợi ích. Trong case này, bước đó phải được gắn với mục tiêu đầu ra chứ không thực hiện theo thói quen. Người học cần xác định đối tượng nào chịu tác động, trạng thái nào là mốc gốc và bằng chứng nào chứng minh thay đổi có ích.

Về thực hành, hãy bắt đầu từ một bản đã lưu, chỉnh một nhóm yếu tố, chuyển sang camera hoặc trạng thái đối chứng rồi quay lại kiểm. Nếu thay đổi ảnh hưởng nhiều media, ghi media bị tác động trước khi xuất lại. Cách này tránh việc sửa một chỗ nhưng vô tình làm hỏng một View set, camera hoặc vật liệu đã được duyệt ở phần khác của dự án.

Liên hệ công việc BĐS: trực quan hóa thường đi qua nhiều vòng góp ý. Vì vậy mọi thay đổi cần trả lời ba câu hỏi: nó làm rõ thông tin nào; nó có làm người xem hiểu sai quy mô/bối cảnh/trạng thái không; và khi source thay đổi, nhóm có thể tái tạo kết quả này hay không.

Quy trình kiểm:

  1. Xác định trạng thái gốc liên quan đến nanite/lod.
  2. Tạo bản thử hoặc media đối chứng trước khi chỉnh.
  3. Chỉ thay một nhóm biến và lưu tên/version ngay.
  4. Kiểm trong Viewport và media đã lưu, không chỉ nhìn trạng thái tạm.
  5. Xuất một bản nhẹ hoặc chụp bằng chứng trước–sau.
  6. Ghi quyết định giữ/bỏ cùng lý do.

Tiêu chí đạt:

  • Kết quả có thể tái tạo.
  • Không làm mất thông tin quan trọng.
  • Không gây hiểu sai về thiết kế, hiện trạng hoặc tiến độ.
  • Tên và trạng thái đủ rõ để người khác tiếp tục.
  • Không làm tăng độ phức tạp scene nếu lợi ích không rõ.

Lưu ý: Không bật mặc định cho mọi thứ.

4. Asset lặp

Dùng spacing/area/scatter cho hàng cây, đèn, xe. Trong case này, bước đó phải được gắn với mục tiêu đầu ra chứ không thực hiện theo thói quen. Người học cần xác định đối tượng nào chịu tác động, trạng thái nào là mốc gốc và bằng chứng nào chứng minh thay đổi có ích.

Về thực hành, hãy bắt đầu từ một bản đã lưu, chỉnh một nhóm yếu tố, chuyển sang camera hoặc trạng thái đối chứng rồi quay lại kiểm. Nếu thay đổi ảnh hưởng nhiều media, ghi media bị tác động trước khi xuất lại. Cách này tránh việc sửa một chỗ nhưng vô tình làm hỏng một View set, camera hoặc vật liệu đã được duyệt ở phần khác của dự án.

Liên hệ công việc BĐS: trực quan hóa thường đi qua nhiều vòng góp ý. Vì vậy mọi thay đổi cần trả lời ba câu hỏi: nó làm rõ thông tin nào; nó có làm người xem hiểu sai quy mô/bối cảnh/trạng thái không; và khi source thay đổi, nhóm có thể tái tạo kết quả này hay không.

Quy trình kiểm:

  1. Xác định trạng thái gốc liên quan đến asset lặp.
  2. Tạo bản thử hoặc media đối chứng trước khi chỉnh.
  3. Chỉ thay một nhóm biến và lưu tên/version ngay.
  4. Kiểm trong Viewport và media đã lưu, không chỉ nhìn trạng thái tạm.
  5. Xuất một bản nhẹ hoặc chụp bằng chứng trước–sau.
  6. Ghi quyết định giữ/bỏ cùng lý do.

Tiêu chí đạt:

  • Kết quả có thể tái tạo.
  • Không làm mất thông tin quan trọng.
  • Không gây hiểu sai về thiết kế, hiện trạng hoặc tiến độ.
  • Tên và trạng thái đủ rõ để người khác tiếp tục.
  • Không làm tăng độ phức tạp scene nếu lợi ích không rõ.

Lưu ý: Không copy thủ công hàng trăm lần.

5. Vegetation layers

Tắt lớp khi làm việc, giảm density vùng xa. Trong case này, bước đó phải được gắn với mục tiêu đầu ra chứ không thực hiện theo thói quen. Người học cần xác định đối tượng nào chịu tác động, trạng thái nào là mốc gốc và bằng chứng nào chứng minh thay đổi có ích.

Về thực hành, hãy bắt đầu từ một bản đã lưu, chỉnh một nhóm yếu tố, chuyển sang camera hoặc trạng thái đối chứng rồi quay lại kiểm. Nếu thay đổi ảnh hưởng nhiều media, ghi media bị tác động trước khi xuất lại. Cách này tránh việc sửa một chỗ nhưng vô tình làm hỏng một View set, camera hoặc vật liệu đã được duyệt ở phần khác của dự án.

Liên hệ công việc BĐS: trực quan hóa thường đi qua nhiều vòng góp ý. Vì vậy mọi thay đổi cần trả lời ba câu hỏi: nó làm rõ thông tin nào; nó có làm người xem hiểu sai quy mô/bối cảnh/trạng thái không; và khi source thay đổi, nhóm có thể tái tạo kết quả này hay không.

Quy trình kiểm:

  1. Xác định trạng thái gốc liên quan đến vegetation layers.
  2. Tạo bản thử hoặc media đối chứng trước khi chỉnh.
  3. Chỉ thay một nhóm biến và lưu tên/version ngay.
  4. Kiểm trong Viewport và media đã lưu, không chỉ nhìn trạng thái tạm.
  5. Xuất một bản nhẹ hoặc chụp bằng chứng trước–sau.
  6. Ghi quyết định giữ/bỏ cùng lý do.

Tiêu chí đạt:

  • Kết quả có thể tái tạo.
  • Không làm mất thông tin quan trọng.
  • Không gây hiểu sai về thiết kế, hiện trạng hoặc tiến độ.
  • Tên và trạng thái đủ rõ để người khác tiếp tục.
  • Không làm tăng độ phức tạp scene nếu lợi ích không rõ.

Lưu ý: Không dùng số cây làm thước chất lượng.

6. Lights/Shadows

Day/night groups, tắt đèn/shadow không cần. Trong case này, bước đó phải được gắn với mục tiêu đầu ra chứ không thực hiện theo thói quen. Người học cần xác định đối tượng nào chịu tác động, trạng thái nào là mốc gốc và bằng chứng nào chứng minh thay đổi có ích.

Về thực hành, hãy bắt đầu từ một bản đã lưu, chỉnh một nhóm yếu tố, chuyển sang camera hoặc trạng thái đối chứng rồi quay lại kiểm. Nếu thay đổi ảnh hưởng nhiều media, ghi media bị tác động trước khi xuất lại. Cách này tránh việc sửa một chỗ nhưng vô tình làm hỏng một View set, camera hoặc vật liệu đã được duyệt ở phần khác của dự án.

Liên hệ công việc BĐS: trực quan hóa thường đi qua nhiều vòng góp ý. Vì vậy mọi thay đổi cần trả lời ba câu hỏi: nó làm rõ thông tin nào; nó có làm người xem hiểu sai quy mô/bối cảnh/trạng thái không; và khi source thay đổi, nhóm có thể tái tạo kết quả này hay không.

Quy trình kiểm:

  1. Xác định trạng thái gốc liên quan đến lights/shadows.
  2. Tạo bản thử hoặc media đối chứng trước khi chỉnh.
  3. Chỉ thay một nhóm biến và lưu tên/version ngay.
  4. Kiểm trong Viewport và media đã lưu, không chỉ nhìn trạng thái tạm.
  5. Xuất một bản nhẹ hoặc chụp bằng chứng trước–sau.
  6. Ghi quyết định giữ/bỏ cùng lý do.

Tiêu chí đạt:

  • Kết quả có thể tái tạo.
  • Không làm mất thông tin quan trọng.
  • Không gây hiểu sai về thiết kế, hiện trạng hoặc tiến độ.
  • Tên và trạng thái đủ rõ để người khác tiếp tục.
  • Không làm tăng độ phức tạp scene nếu lợi ích không rõ.

Lưu ý: Không bật tất cả trong mọi trạng thái.

7. Work quality vs export

Viewport có thể nhẹ hơn nhưng media cuối phải kiểm riêng. Trong case này, bước đó phải được gắn với mục tiêu đầu ra chứ không thực hiện theo thói quen. Người học cần xác định đối tượng nào chịu tác động, trạng thái nào là mốc gốc và bằng chứng nào chứng minh thay đổi có ích.

Về thực hành, hãy bắt đầu từ một bản đã lưu, chỉnh một nhóm yếu tố, chuyển sang camera hoặc trạng thái đối chứng rồi quay lại kiểm. Nếu thay đổi ảnh hưởng nhiều media, ghi media bị tác động trước khi xuất lại. Cách này tránh việc sửa một chỗ nhưng vô tình làm hỏng một View set, camera hoặc vật liệu đã được duyệt ở phần khác của dự án.

Liên hệ công việc BĐS: trực quan hóa thường đi qua nhiều vòng góp ý. Vì vậy mọi thay đổi cần trả lời ba câu hỏi: nó làm rõ thông tin nào; nó có làm người xem hiểu sai quy mô/bối cảnh/trạng thái không; và khi source thay đổi, nhóm có thể tái tạo kết quả này hay không.

Quy trình kiểm:

  1. Xác định trạng thái gốc liên quan đến work quality vs export.
  2. Tạo bản thử hoặc media đối chứng trước khi chỉnh.
  3. Chỉ thay một nhóm biến và lưu tên/version ngay.
  4. Kiểm trong Viewport và media đã lưu, không chỉ nhìn trạng thái tạm.
  5. Xuất một bản nhẹ hoặc chụp bằng chứng trước–sau.
  6. Ghi quyết định giữ/bỏ cùng lý do.

Tiêu chí đạt:

  • Kết quả có thể tái tạo.
  • Không làm mất thông tin quan trọng.
  • Không gây hiểu sai về thiết kế, hiện trạng hoặc tiến độ.
  • Tên và trạng thái đủ rõ để người khác tiếp tục.
  • Không làm tăng độ phức tạp scene nếu lợi ích không rõ.

Lưu ý: Không nhầm chất lượng làm việc và đầu ra.

8. Shot-list optimization

Chỉ giữ chi tiết có giá trị cho media. Trong case này, bước đó phải được gắn với mục tiêu đầu ra chứ không thực hiện theo thói quen. Người học cần xác định đối tượng nào chịu tác động, trạng thái nào là mốc gốc và bằng chứng nào chứng minh thay đổi có ích.

Về thực hành, hãy bắt đầu từ một bản đã lưu, chỉnh một nhóm yếu tố, chuyển sang camera hoặc trạng thái đối chứng rồi quay lại kiểm. Nếu thay đổi ảnh hưởng nhiều media, ghi media bị tác động trước khi xuất lại. Cách này tránh việc sửa một chỗ nhưng vô tình làm hỏng một View set, camera hoặc vật liệu đã được duyệt ở phần khác của dự án.

Liên hệ công việc BĐS: trực quan hóa thường đi qua nhiều vòng góp ý. Vì vậy mọi thay đổi cần trả lời ba câu hỏi: nó làm rõ thông tin nào; nó có làm người xem hiểu sai quy mô/bối cảnh/trạng thái không; và khi source thay đổi, nhóm có thể tái tạo kết quả này hay không.

Quy trình kiểm:

  1. Xác định trạng thái gốc liên quan đến shot-list optimization.
  2. Tạo bản thử hoặc media đối chứng trước khi chỉnh.
  3. Chỉ thay một nhóm biến và lưu tên/version ngay.
  4. Kiểm trong Viewport và media đã lưu, không chỉ nhìn trạng thái tạm.
  5. Xuất một bản nhẹ hoặc chụp bằng chứng trước–sau.
  6. Ghi quyết định giữ/bỏ cùng lý do.

Tiêu chí đạt:

  • Kết quả có thể tái tạo.
  • Không làm mất thông tin quan trọng.
  • Không gây hiểu sai về thiết kế, hiện trạng hoặc tiến độ.
  • Tên và trạng thái đủ rõ để người khác tiếp tục.
  • Không làm tăng độ phức tạp scene nếu lợi ích không rõ.

Lưu ý: Không giữ asset nhỏ vì 'có thể cần'.

Tình huống tổng hợp BĐS

Tình huống giả lập phục vụ giảng dạy: Khu ở giả lập có 20 block, 1.200 cây và hàng trăm xe. FPS giảm mạnh nhưng camera chỉ tập trung trục chính. Nhóm chia near/mid/far, giảm asset vùng xa, dùng Spacing/Area, tắt đèn ban ngày, thử LOD/Nanite trên model nặng và theo dõi Stats.

Để giải tình huống, sinh viên phải tách pipeline thành source → import/sync → materials/context → camera/media → phát hành. Mỗi lớp được kiểm độc lập trước khi chuyển sang lớp tiếp theo. Khi có lỗi, quay về lớp gần nhất đã ổn định thay vì sửa ngẫu nhiên toàn scene.

Ma trận quyết định

Hạng mụcCông cụ/cách làmMục tiêuĐiểm kiểm
NearChi tiết caoCamera chínhGiữ chất lượng
MidChi tiết vừaBối cảnhGiảm asset nhỏ
FarSilhouetteNềnLOD/proxy
Imported heavyNanite/LODTối ưuĐo FPS
VegetationLayer + PopulateCảnh quanGiảm far density
LightsDAY/NIGHTHiệu năngTắt không cần

Quy trình 12 bước cho một vòng làm việc

  1. Nhận brief và xác định người xem, kênh sử dụng, trạng thái dữ liệu.
  2. Khóa version source trước khi thao tác.
  3. Kiểm scale, hierarchy, material names và Scene graph.
  4. Lưu baseline bằng screenshot, Statistics hoặc media kiểm.
  5. Xử lý nhóm thay đổi quan trọng nhất trước.
  6. Giữ camera và trạng thái đối chứng khi cần so sánh.
  7. Đặt tên media/variant theo quy tắc.
  8. Kiểm hiệu năng nếu scene có nhiều imported geometry hoặc assets.
  9. Xuất bản thử nhẹ và mở file ngoài Twinmotion.
  10. Thực hiện kiểm chéo bởi người khác nếu media quan trọng.
  11. Nhận hoặc giả lập change request và cập nhật có kiểm soát.
  12. Phát hành R02 cùng change log và danh sách media bị ảnh hưởng.

Những lỗi thường gặp

  • Chi tiết cao toàn site.
  • Bật Nanite cho mọi object.
  • Không dùng Statistics.
  • Cây/xe lặp bằng copy thủ công.
  • Tất cả đèn bật ban ngày.
  • Tối ưu xong không kiểm media.

Phân tích lỗi 1 – Chi tiết cao toàn site. Khi gặp lỗi này, không nên sửa đồng thời camera, vật liệu, ánh sáng và source. Hãy tạo bản sao an toàn, xác định lớp gây lỗi, sửa một lớp rồi kiểm lại bằng cùng camera/media. Nếu lỗi liên quan Direct Link/Reimport, ghi source change, Twinmotion override và import option để truy nguyên.

Phân tích lỗi 2 – Bật Nanite cho mọi object. Khi gặp lỗi này, không nên sửa đồng thời camera, vật liệu, ánh sáng và source. Hãy tạo bản sao an toàn, xác định lớp gây lỗi, sửa một lớp rồi kiểm lại bằng cùng camera/media. Nếu lỗi liên quan Direct Link/Reimport, ghi source change, Twinmotion override và import option để truy nguyên.

Phân tích lỗi 3 – Không dùng Statistics. Khi gặp lỗi này, không nên sửa đồng thời camera, vật liệu, ánh sáng và source. Hãy tạo bản sao an toàn, xác định lớp gây lỗi, sửa một lớp rồi kiểm lại bằng cùng camera/media. Nếu lỗi liên quan Direct Link/Reimport, ghi source change, Twinmotion override và import option để truy nguyên.

Phân tích lỗi 4 – Cây/xe lặp bằng copy thủ công. Khi gặp lỗi này, không nên sửa đồng thời camera, vật liệu, ánh sáng và source. Hãy tạo bản sao an toàn, xác định lớp gây lỗi, sửa một lớp rồi kiểm lại bằng cùng camera/media. Nếu lỗi liên quan Direct Link/Reimport, ghi source change, Twinmotion override và import option để truy nguyên.

Phân tích lỗi 5 – Tất cả đèn bật ban ngày. Khi gặp lỗi này, không nên sửa đồng thời camera, vật liệu, ánh sáng và source. Hãy tạo bản sao an toàn, xác định lớp gây lỗi, sửa một lớp rồi kiểm lại bằng cùng camera/media. Nếu lỗi liên quan Direct Link/Reimport, ghi source change, Twinmotion override và import option để truy nguyên.

Bài thực hành

Tạo cảnh khu ở hoặc mô phỏng bằng nhiều block. Ghi Stats baseline, thực hiện ít nhất bốn biện pháp tối ưu, so FPS/VRAM và xuất 4 media trước–sau.

Yêu cầu: bài nộp phải có ít nhất một trạng thái trước–sau, một vòng thay đổi R01→R02 hoặc phép kiểm đối chứng, ba quyết định kỹ thuật có lý do và một nhận xét về rủi ro gây hiểu nhầm trong trực quan hóa BĐS.

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

  • Camera map near/mid/far.
  • Bảng Stats 3 mốc.
  • 4 biện pháp tối ưu.
  • 4 cặp media trước/sau.
  • Ghi chú Nanite/LOD.
  • Scene graph tối ưu.

Phiếu tự kiểm

  • Source có đúng version và đúng tỷ lệ không?
  • Scene graph có đủ rõ để người khác tiếp tục không?
  • Các material/asset/context có đúng phạm vi brief không?
  • Camera có làm tỷ lệ không gian bị hiểu sai không?
  • Yếu tố giả lập đã được phân biệt với dữ liệu thật chưa?
  • Statistics/hiệu năng đã được kiểm nếu scene lớn chưa?
  • Media có cùng phương án và version không?
  • Sau sync/reimport, overrides đã được kiểm chưa?
  • File xuất đã được mở kiểm chưa?
  • R01/R02 và change log có thể truy vết không?

Ghi nhớ trong 30 giây

  • Tối ưu theo camera và tầm quan trọng.
  • Statistics giúp chẩn đoán đúng.
  • Nanite/LOD dùng có kiểm chứng.
  • Vegetation/lights cần phân lớp.
  • Hiệu năng tốt mà media không mất thông tin mới là tối ưu tốt.

Nguồn tham khảo

Nguồn kỹ thuật ưu tiên là Epic Games – Twinmotion Documentation. Khi áp dụng dự án thật, cần đối chiếu phiên bản Twinmotion và plugin Datasmith hiện hành.

  • https://dev.epicgames.com/documentation/en-us/twinmotion/statistics-in-twinmotion
  • https://dev.epicgames.com/documentation/twinmotion/optimizing-3d-models-for-realtime-rendering-in-twinmotion
  • https://dev.epicgames.com/documentation/en-us/twinmotion/optimizing-geometry-with-nanite-in-twinmotion
  • https://dev.epicgames.com/documentation/twinmotion/automatic-lod-generation-in-twinmotion
  • https://dev.epicgames.com/documentation/en-us/twinmotion/placing-tools-in-twinmotion

Bài tiếp theo

Case study: cải tạo nội thất – trình bày trước/sau bằng View sets.

📚 Xem toàn bộ 96 bài trong series Twinmotion trong trực quan hóa và trình bày BĐS