Case study: tạo Presentation cho một dự án có nhiều phương án

Case study: tạo Presentation cho một dự án có nhiều phương án là Bài 94 của chuyên đề Twinmotion trong trực quan hóa và trình bày BĐS. Tổ chức Presentation cho dự án có nhiều phương án bằng View sets, Configurations và alternative versions của media; tách rõ phương án, trạng thái tương tác và media gốc để người xem so sánh mà không bị rối.

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ố giới hạn 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 kiểm tài liệu chính thức của phiên bản đang dùng.

Lưu ý: các công trình, kích thước, phương án, tiến độ, người, xe, cây xanh, thương hiệu và tình huống khách hà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 phục vụ trực quan hóa và trình bày; sản phẩm tạo ra không tự thay thế hồ sơ thiết kế, pháp lý, khảo sát, tiến độ thi công hay cam kết thương mại.

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

Chọn đúng cơ chế cho từng loại phương án.
Dùng alternative versions để gom các media cùng mục tiêu so sánh.
Dùng Configurations khi cần tương tác state trong media.
Giữ camera/Ambience nhất quán khi so sánh.
Tạo Presentation dễ dùng cho Local hoặc Cloud.

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

Bài 72 đã so ba phương án mặt đứng; Bài 94 nâng lên Presentation hoàn chỉnh. Điểm mới là ngoài View sets và Configurations, Twinmotion còn hỗ trợ alternative versions của media trong Presentation để người xem mở các biến thể được nhóm dưới một media gốc.

Bài thuộc Chương 12 – Case study SketchUp → Twinmotion → sản phẩm truyền thông. Ở giai đoạn này, sản phẩm phải được đánh giá đồng thời về hình ảnh, cấu trúc tệp, khả năng cập nhật, tính minh bạch thông tin và khả năng bàn giao.

1. Phân loại phương án trước khi xây Presentation

Geometry A/B/C phù hợp View sets/Visibility; nhiều vật liệu cùng object phù hợp Configuration Material switch; nhiều phiên bản của cùng một Image/Video/Pano có thể được nhóm bằng alternative versions trong Presentation.

Không dùng một cơ chế cho mọi biến thể.

Kiểm theo lớp: Không chỉnh model, vật liệu, ánh sáng, camera và media cùng lúc nếu đang chẩn đoán. Hãy giữ một trạng thái gốc và chỉ thay nhóm biến liên quan. Cách này tạo được bằng chứng và giúp người khác tái tạo quyết định.

Quy trình thực hành:

Lập bảng phương án.
Gắn công cụ.
Chọn media.
Đặt tên.

Cách tự kiểm:

Không trộn ngữ nghĩa.
Công cụ đúng loại thay đổi.
Người xem hiểu.
QA đơn giản.

Lưu ý: Phân loại tốt giúp tránh Presentation trở thành cây trạng thái quá sâu.

Bằng chứng nên lưu: ảnh trước–sau, tên media/state, screenshot Scene graph/Import dock/Ambience/Statistics khi phù hợp, phiên bản và một câu giải thích vì sao quyết định được giữ lại.

2. Xây một tuyến chính trước khi thêm lựa chọn

Presentation vẫn cần câu chuyện chính: tổng quan → tiếp cận → không gian → điểm so sánh → kết. Phương án chỉ xuất hiện ở nơi người xem cần ra quyết định.

Nếu mọi media đều có A/B/C, người xem phải chọn liên tục và mất mạch.

Quản lý phiên bản: Mỗi case nên có source version, Twinmotion version, media status và change log. Khi thiết kế thay đổi, impact list xác định file nào cần tái kiểm thay vì xuất lại theo cảm tính.

Quy trình thực hành:

Tạo Presentation base.
Sắp 8–12 media.
Đánh dấu 2–4 điểm cần so.
Chỉ thêm variants ở đó.

Cách tự kiểm:

Câu chuyện vẫn hiểu nếu không mở variant.
Không quá nhiều điểm lựa chọn.
Mở đầu/kết rõ.
Không lặp media.

Lưu ý: Phương án là nhánh trong câu chuyện, không phải toàn bộ câu chuyện.

3. Alternative versions giúp nhóm nhiều media tương đương

Tài liệu hiện hành cho phép duplicate Image/Video/Sequence/Panorama, chỉnh bản sao, thêm vào Presentation và đánh dấu As alternative. Khi xem, bản gốc có dấu nhận biết và người xem mở các phiên bản lồng bên dưới.

Cách này phù hợp DAY/DUSK, mặt đứng A/B/C hoặc vật liệu khác nhau khi mỗi phương án đã được tạo thành media riêng.

Kiểm bằng người khác: Người dựng đã biết scene nên dễ bỏ qua lỗi điều hướng, thông tin hoặc cấu trúc. Một người kiểm chéo chưa tham gia dựng giúp phát hiện nhanh tên khó hiểu, media trùng và trạng thái gây nhầm.

Quy trình thực hành:

Tạo media gốc.
Duplicate.
Chỉnh variant.
Add vào Presentation.
Mark As alternative.

Cách tự kiểm:

Các bản cùng mục tiêu.
Camera/khung nhất quán khi so.
Tên rõ.
Không lẫn draft.

Lưu ý: Alternative version là tổ chức media, không phải Configuration state.

4. Configurations phù hợp lựa chọn tương tác bên trong media

Configurations cho phép states và trigger, có thể áp vào media trong Local/Cloud Presentations. Đây là cách tốt khi người xem cần bấm đổi vật liệu, visibility hoặc transform.

Tuy nhiên có các giới hạn hiện hành đối với Visibility/Ambience trên Videos/Sequences và mức áp state; cần test thật.

Quy trình thực hành:

Tạo Configuration.
Áp state cho media.
Bật tương tác trong Presentation theo thiết lập.
Test trigger.

Cách tự kiểm:

Trigger dễ hiểu.
Không state thừa.
Không dùng category không hỗ trợ.
Người mới thao tác được.

Lưu ý: Không hứa tính năng chưa test trên loại media cụ thể.

5. View sets vẫn hữu ích để tạo nguồn media so sánh

View sets giúp tạo nhanh Images/Panoramas A/B/C cùng camera. Các media đó sau đó có thể được gom thành alternative versions.

Đây là cách kết hợp hai lớp: View set tạo trạng thái scene; Presentation tổ chức trải nghiệm so sánh.

Quy trình thực hành:

Tạo View sets.
Nhân media.
Gán A/B/C.
Đưa vào Presentation.

Cách tự kiểm:

Không lẫn object.
Camera khóa.
Ambience khóa.
Variant nested đúng.

Lưu ý: Đừng để người xem phải hiểu 'View set' như thuật ngữ nội bộ.

6. Giữ so sánh công bằng bằng camera và Ambience

Alternative versions hoặc states chỉ có ý nghĩa khi những biến không phải đối tượng so sánh được khóa: camera, FOV, thời điểm, Render mode và context.

Nếu A sáng đẹp hơn B, người xem đánh giá sai thiết kế.

Quy trình thực hành:

Chọn master media.
Duplicate.
Chỉ đổi variant.
Tạo contact check.

Cách tự kiểm:

Camera giống.
Không chênh Exposure vô cớ.
Không context khác.
Không render quality khác.

Lưu ý: So sánh phương án là một phép thử có kiểm soát.

7. Local và Cloud cần test cách mở alternative/configuration

Local Presentation và Cloud Presentation có cách hiển thị media strip/alternative versions và trigger. Người dựng phải test như người nhận, không chỉ trong Editor.

Đặc biệt trên mobile, các lựa chọn nên ít và dễ bấm.

Quy trình thực hành:

Export Local hoặc Cloud.
Mở Presentation.
Mở alternative.
Bấm trigger.
Test mobile nếu cần.

Cách tự kiểm:

Không lạc.
Không nested quá sâu.
Trigger hoạt động.
Có fallback.

Lưu ý: Trải nghiệm cuối mới quyết định cấu trúc có tốt hay không.

8. Feedback phải gắn đúng phương án và đúng media

Khi họp, ghi phản hồi kiểu 'phương án B ở mặt đứng 02' thay vì 'ảnh thứ ba'. Dùng ID giúp quay lại đúng state.

Alternative versions và Configurations càng nhiều càng cần log chặt.

Quy trình thực hành:

Gắn ID.
Ghi feedback.
Chốt selected.
Archive rejected.

Cách tự kiểm:

Không nhầm variant.
Selected rõ.
Không xóa lịch sử cần thiết.
Media cuối dùng đúng option.

Lưu ý: Quản lý quyết định là mục tiêu của Presentation nhiều phương án.

9. Sau khi chọn phương án, làm sạch Presentation bán hàng

Presentation thiết kế có thể chứa A/B/C; Presentation sales sau khi chốt thường chỉ cần phương án SELECTED và vài lựa chọn khách hàng thật sự được phép tương tác.

Không đem toàn bộ phương án nội bộ sang khách hàng cuối nếu không cần.

Quy trình thực hành:

Duplicate Presentation.
Xóa/archive variants nội bộ.
Giữ selected.
QA.

Cách tự kiểm:

Không phương án bị loại lọt.
Tên Presentation mới.
Version rõ.
Nguồn vẫn lưu.

Lưu ý: Một project có thể có Presentation REVIEW và SALES khác nhau.

10. Nghiệm thu bằng người xem thử

Đưa Presentation cho người không tham gia dựng. Họ phải nhận biết đâu là bản gốc, cách mở alternative, cách dùng trigger và cách quay lại tuyến chính.

Nếu phải giải thích dài, cấu trúc cần đơn giản hóa.

Quy trình thực hành:

User test.
Quan sát.
Ghi điểm lạc.
Sửa R02.

Cách tự kiểm:

Người mới dùng được.
Không mất hơn vài giây để hiểu lựa chọn.
Không click nhầm.
Câu chuyện vẫn liền.

Lưu ý: Presentation là sản phẩm giao diện, không chỉ tập media.

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

Tình huống giả lập phục vụ giảng dạy: Dự án có ba mặt đứng, hai màu sàn và hai trạng thái cửa. Nhóm đầu tiên tạo 12 View sets và hàng chục media khiến Presentation khó hiểu. Bản sửa dùng View sets để tạo ba mặt đứng dưới dạng alternative versions, Configuration Material switch cho hai màu sàn và Transform cho cửa. Tuyến chính chỉ có 10 media, trong đó ba điểm có lựa chọn.

Khi xử lý tình huống, hãy xác định lớp lỗi trước: source model, import/sync, material, context, camera, media, state, sharing hay handover. Chỉ sau đó mới sửa. Đây là nguyên tắc xuyên suốt toàn chuyên đề và là cách tránh việc dùng một công cụ để che lỗi của lớp khác.

Ma trận quyết định

Nhóm	Công cụ/cách làm	Mục tiêu	Điểm kiểm
Geometry A/B/C	View sets → media alternatives	So phương án	Camera khóa
Nhiều vật liệu	Configuration Material switch	Tương tác	Trigger
Transform	Configuration	Mở/đóng	Không phải animation
DAY/DUSK	Alternative versions	So môi trường	Cùng camera
Presentation REVIEW	Nhiều phương án	Nội bộ	Feedback log
Presentation SALES	Selected only	Khách hàng	Gọn/được phép

Quy trình 12 bước áp dụng

Đọc brief và xác định người xem, kênh sử dụng và phần giả lập.
Khóa source version và tạo baseline.
Kiểm scale, hierarchy, Scene graph và import settings.
Xử lý vật liệu/ánh sáng nền trước tài nguyên trang trí.
Thêm context, vegetation, people/vehicles theo camera.
Chốt camera/shot list hoặc storyboard.
Tạo media theo tên có cấu trúc.
Chạy QA kỹ thuật ở kích thước sử dụng.
Kiểm state tools/Presentation/Cloud nếu có.
Giả lập hoặc tiếp nhận change request.
Tái kiểm impact và phát hành version mới.
Đóng gói source, Twinmotion, export, documentation và owner.

Quy trình 12 bước giúp biến thao tác phần mềm thành quy trình có thể lặp. Sinh viên nên coi khả năng cập nhật R02/R03 là tiêu chí bắt buộc, không phải phần cộng thêm sau khi ảnh đã đẹp.

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

Tạo View set cho mọi tổ hợp.
Mọi media đều có variants.
Nhầm alternative version với Configuration.
Camera variant khác nhau.
Không test Local/Cloud.
Feedback không có ID.
Giữ phương án bị loại trong Sales Presentation.
Trigger quá nhiều.

Phân tích lỗi 1 – Tạo View set cho mọi tổ hợp. Tạo một bản sao an toàn, xác định nguyên nhân trực tiếp, sửa một lớp và so với baseline. Nếu lỗi xuất hiện sau sync/export, ghi chính xác bước và phiên bản để người khác tái hiện.

Phân tích lỗi 2 – Mọi media đều có variants. Tạo một bản sao an toàn, xác định nguyên nhân trực tiếp, sửa một lớp và so với baseline. Nếu lỗi xuất hiện sau sync/export, ghi chính xác bước và phiên bản để người khác tái hiện.

Phân tích lỗi 3 – Nhầm alternative version với Configuration. Tạo một bản sao an toàn, xác định nguyên nhân trực tiếp, sửa một lớp và so với baseline. Nếu lỗi xuất hiện sau sync/export, ghi chính xác bước và phiên bản để người khác tái hiện.

Phân tích lỗi 4 – Camera variant khác nhau. Tạo một bản sao an toàn, xác định nguyên nhân trực tiếp, sửa một lớp và so với baseline. Nếu lỗi xuất hiện sau sync/export, ghi chính xác bước và phiên bản để người khác tái hiện.

Phân tích lỗi 5 – Không test Local/Cloud. Tạo một bản sao an toàn, xác định nguyên nhân trực tiếp, sửa một lớp và so với baseline. Nếu lỗi xuất hiện sau sync/export, ghi chính xác bước và phiên bản để người khác tái hiện.

Bài thực hành

Tạo Presentation REVIEW gồm 8–12 media, tối thiểu một nhóm alternative versions và một Configuration tương tác. Sau user test, tạo bản SALES đã rút gọn theo phương án selected.

Yêu cầu bắt buộc: phải có trạng thái trước–sau hoặc R01/R02; ít nhất ba quyết định kỹ thuật được giải thích; một lỗi được phát hiện qua kiểm chéo; và một bảng xác định nội dung nào là dữ liệu thật, nội dung nào là minh họa nếu case có yếu tố giả lập.

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

Presentation REVIEW.
Presentation SALES.
Một nhóm alternative versions.
Một Configuration.
Feedback log.
User test R01/R02.

Phiếu tự kiểm

Source model có đúng version và mở được không?
Scale/hierarchy/import settings có được kiểm và ghi lại không?
Scene graph có đủ rõ để bàn giao không?
Vật liệu có đúng tỷ lệ và không dùng để bù ánh sáng không?
Context/cây/người/xe có tạo hiểu nhầm không?
Camera/FOV/eye level có mô tả không gian trung thực không?
Media có được đặt tên và kiểm ở file xuất thật không?
Statistics/hiệu năng có được kiểm nếu scene nặng không?
State tools/Presentation có đúng phương án không?
Cloud/Local có được test như người nhận không?
ACTIVE_VERSION/change log có cập nhật không?
Một người khác có thể mở và tiếp tục dự án không?

Ghi nhớ trong 30 giây

Phân loại phương án trước khi chọn công cụ.
Alternative versions tổ chức media biến thể.
Configurations tạo state tương tác.
Giữ camera/Ambience công bằng khi so.
REVIEW và SALES có thể là hai Presentation khác nhau.

Nguồn tham khảo

Nguồn kỹ thuật ưu tiên là Epic Games – Twinmotion Documentation. Các tính năng và giới hạn có thể thay đổi theo phiên bản, vì vậy khi áp dụng dự án thật cần đối chiếu tài liệu hiện hành.

https://dev.epicgames.com/documentation/twinmotion/modifying-presentations
https://dev.epicgames.com/documentation/twinmotion/configurations
https://dev.epicgames.com/documentation/twinmotion/applying-configurations
https://dev.epicgames.com/documentation/en-us/twinmotion/viewing-twinmotion-local-presentations

Bài tiếp theo

Quy trình nghiệm thu: model, vật liệu, media, link chia sẻ và file nguồn.