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

Quy trình nghiệm thu: model, vật liệu, media, link chia sẻ và file nguồn là Bài 95 của chuyên đề Twinmotion trong trực quan hóa và trình bày BĐS. Xây quy trình nghiệm thu nhiều lớp cho dự án Twinmotion, từ source model và Direct Link đến vật liệu, Scene graph, media, Presentation/Cloud/Local, quyền chia sẻ, file nguồn, phiên bản và khả năng mở lại dự án.

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

Nghiệm thu theo từng lớp thay vì chỉ xem ảnh đẹp.
Kiểm khả năng mở source và tái đồng bộ.
Kiểm vật liệu, Scene graph và tài nguyên phụ thuộc.
Kiểm toàn bộ media và kênh chia sẻ.
Đóng gói hồ sơ bàn giao có version, owner và change log.

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

Các bài 89–94 đã đi từ source đến media và Presentation. Bài 95 là cổng nghiệm thu trước bài tổng kết lỗi: dự án chỉ được xem là hoàn thành khi một người khác có thể mở, hiểu, kiểm, xuất lại và cập nhật được mà không phụ thuộc vào trí nhớ người dựng.

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. Nghiệm thu source model trước Twinmotion

Kiểm file SketchUp/DCC đúng phiên bản, mở được, không mất texture quan trọng, units/scale đúng, Group/Component/Tags có cấu trúc và material names ổn định.

Nguồn sai làm mọi lớp sau mất giá trị.

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:

Mở source.
Kiểm version.
Kiểm mốc kích thước.
Kiểm hierarchy/material names.

Cách tự kiểm:

File mở được.
Không missing assets quan trọng.
Scale đúng.
Tên có cấu trúc.

Lưu ý: Không nghiệm thu Twinmotion nếu source chính đã hỏng.

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. Nghiệm thu Direct Link/Import và khả năng reimport

Kiểm source link còn tìm được, import settings được ghi, DirectLinkTextures/tài nguyên liên quan còn tồn tại và một sync test nhỏ hoạt động.

Không cần sửa production để test; dùng bản sao hoặc thay đổi an toàn.

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:

Kiểm Import dock.
Ghi Collapse/settings.
Test sync nhỏ.
Phục hồi trạng thái.

Cách tự kiểm:

Không broken link.
Sync hoạt động.
Không mất overrides không rõ nguyên nhân.
Có baseline.

Lưu ý: Khả năng cập nhật là một phần của bàn giao.

3. Nghiệm thu Scene graph và cấu trúc dự án

Scene graph cần đủ sạch: container theo công trình/context/vegetation/lights/options; không hàng loạt object test; View sets/Phasing/Configurations có tên và không trạng thái mồ côi.

Người nhận phải tìm được đối tượng mà không cần hỏi.

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:

Rà root containers.
Tìm object ngẫu nhiên.
Kiểm hidden groups.
Kiểm state tools.

Cách tự kiểm:

Không helper thừa.
Không tên vô nghĩa hàng loạt.
Không option cũ active.
Structure hiểu được.

Lưu ý: Scene graph là tài liệu sống của scene.

4. Nghiệm thu vật liệu và mapping

Lập danh sách vật liệu chính, kiểm scale/roughness/kính/emissive và mapping với source. Kiểm cả các vật liệu có nguy cơ mất override khi reimport.

Nếu dùng User library/custom textures, ghi nơi lưu và quyền sử dụng.

Quy trình thực hành:

Sample vật liệu chính.
Kiểm 100% media.
Kiểm mapping.
Ghi custom assets.

Cách tự kiểm:

Không material mặc định sót.
Không missing texture.
Không license/nguồn mơ hồ.
Mapping truy vết.

Lưu ý: Vật liệu phải vừa đẹp vừa quản lý được.

5. Nghiệm thu Ambience và Render mode

Kiểm DAY/DUSK/NIGHT, Exposure, white balance, lights, Standard/Lumen/Path tracer theo từng media. Không để một ảnh vô tình khác look do người khác chỉnh.

Master look/nhóm media cần có mốc.

Quy trình thực hành:

So contact sheet.
Kiểm media settings.
Kiểm Render mode.
Kiểm đèn.

Cách tự kiểm:

Không lệch màu vô cớ.
Không cháy/tối lớn.
Mode đúng kế hoạch.
Không đèn test.

Lưu ý: Look nhất quán là tiêu chí bàn giao.

6. Nghiệm thu Images/Panoramas/Videos/Sequences

Mỗi media phải có ID, mục tiêu, trạng thái APPROVED và file export kiểm được. Panoramas kiểm 360°; videos/sequences kiểm toàn timeline, không chỉ frame đầu.

Đối chiếu số lượng với shot list.

Quy trình thực hành:

Export batch test.
Mở file.
Check 100% hoặc sampling theo quy mô.
Ghi pass/fail.

Cách tự kiểm:

Không thiếu media.
Không draft.
Không clipping/artefact rõ.
Đúng ratio/resolution.

Lưu ý: Media chỉ hoàn thành sau khi file xuất được mở kiểm.

7. Nghiệm thu View sets, Phasing và Configurations

Chuyển qua từng state, kiểm visibility, timeline, trigger và Modified properties. Không state nào chứa object từ phương án bị loại hoặc ngày giả lập bị trình bày như tiến độ thật.

Kiểm cách áp vào media nếu có.

Quy trình thực hành:

Cycle states.
Preview phasing.
Test triggers.
Kiểm media.

Cách tự kiểm:

Không xung đột.
Tên rõ.
Selected rõ.
Giới hạn được ghi.

Lưu ý: State tools dễ gây lỗi khó thấy nếu chỉ xem media cuối.

8. Nghiệm thu Presentation, Local và Cloud

Presentation phải đúng thứ tự, alternative versions/trigger hoạt động, Local Presenter chạy trên máy nhận và Cloud link/QR/password mở như người nhận. Kiểm mobile nếu QR được dùng.

Không chỉ thử trong Editor.

Quy trình thực hành:

Test Presenter.
Test link ẩn danh.
Quét QR.
Test fallback.

Cách tự kiểm:

Đúng version.
Không quyền sai.
Không link draft.
Fallback mở được.

Lưu ý: Link hoạt động là một phần của nghiệm thu, không phải bước phụ.

9. Nghiệm thu file nguồn và thư mục bàn giao

Gói bàn giao nên có SOURCE, TWINMOTION, EXPORT, PRESENTATION, DOCUMENTATION và các tài nguyên đi kèm theo quy tắc của đơn vị. Không tạo sandbox thiếu file phụ thuộc.

Nếu file lớn, ghi rõ vị trí lưu nội bộ.

Quy trình thực hành:

Tạo cấu trúc.
Copy file.
Mở từ bản bàn giao.
Kiểm đường dẫn.

Cách tự kiểm:

Không chỉ shortcut.
Không file rỗng.
Không missing texture.
Có README.

Lưu ý: File bàn giao phải tự đứng được trong phạm vi đã thỏa thuận.

10. Nghiệm thu version, owner và khả năng phục hồi

ACTIVE_VERSION, ngày, người duyệt, người phụ trách source, người phụ trách Cloud/Local và change log phải rõ. Giả lập một yêu cầu sửa nhỏ để xem dự án có thể tiếp tục.

Đây là phép nghiệm thu quy trình, không chỉ sản phẩm.

Quy trình thực hành:

Kiểm change log.
Chọn owner.
Giả lập change.
Mở archive.

Cách tự kiểm:

Biết bản active.
Biết bản cũ ở đâu.
Biết ai cập nhật.
Không mất lịch sử.

Lưu ý: Dự án bàn giao tốt là dự án có thể tiếp tục phát triể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: Một dự án có ảnh đẹp nhưng khi bàn giao, file SketchUp nằm ở máy cá nhân, DirectLinkTextures đã bị xóa và Local Presentation chỉ copy file .exe thiếu thư mục assets. Quy trình nghiệm thu phát hiện ba lỗi trước khi chuyển đội. Nhóm phục hồi texture, đóng gói Presenter đầy đủ và tạo README/ACTIVE_VERSION, nhờ đó người nhận mở và cập nhật được.

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
Source	File DCC	Mở + scale + hierarchy	Bắt buộc
Import/Link	Direct Link/Import dock	Sync test	Bắt buộc
Scene	Scene graph/states	Structure	Bắt buộc
Media	Images/Pano/Video/Seq	Export QA	Bắt buộc
Sharing	Local/Cloud	Link/Presenter/password	Theo đầu ra
Handover	Folders/version/owner	Khả năng tiếp tục	Bắt buộc

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

Chỉ nghiệm thu ảnh cuối.
Không mở lại source.
Không test sync.
Không kiểm panorama 360° toàn vòng.
Không xem video toàn timeline.
Copy thiếu Local assets.
Link Cloud chưa test ẩn danh.
Không có ACTIVE_VERSION.
Không có owner.
Không thử mở gói bàn giao.

Phân tích lỗi 1 – Chỉ nghiệm thu ảnh cuối. 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 – Không mở lại source. 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 – Không test sync. 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 – Không kiểm panorama 360° toàn vòng. 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 xem video toàn timeline. 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 checklist nghiệm thu tối thiểu 50 mục cho một project đã hoàn thành. Nhờ người khác chạy checklist, đánh Pass/Fail/NA, sửa lỗi, sau đó chạy lại và ký trạng thái APPROVED.

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

Checklist 50+ mục.
Bảng Pass/Fail/NA.
Hồ sơ SOURCE/TWINMOTION/EXPORT/PRESENTATION/DOCUMENTATION.
README.
ACTIVE_VERSION.
Biên bản kiểm chéo.

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

Nghiệm thu theo lớp, không chỉ nhìn ảnh.
Source và sync phải còn hoạt động.
Media phải kiểm file xuất thật.
Local/Cloud phải test như người nhận.
Bàn giao phải có version, owner và khả năng tiếp tục.

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/datasmith-direct-link-workflow-in-twinmotion
https://dev.epicgames.com/documentation/en-us/twinmotion/reimporting-content-into-twinmotion
https://dev.epicgames.com/documentation/twinmotion/creating-and-exporting-media
https://dev.epicgames.com/documentation/en-us/twinmotion/twinmotion-local-presentations-overview

Bài tiếp theo

20 lỗi Twinmotion thường gặp trong trực quan hóa BĐS và checklist tự kiểm tra.

Phòng kiểm chứng cuối bài

Phép thử A – chỉ thay một biến

Giữ camera, model và media gốc; chỉ thay đúng biến trọng tâm. Chụp trước–sau và kết luận theo thông tin, không chỉ theo cảm giác đẹp/xấu.

Phép thử B – change request R02

Thay một yếu tố có kiểm soát, cập nhật source/Twinmotion, lập impact list và phát hành R02. Ghi phần nào phải làm lại và phần nào giữ được.

Phép thử C – bàn giao cho người khác

Đưa gói cho người kiểm chéo. Họ phải tìm được source, media APPROVED, active version và cách cập nhật mà không cần người dựng giải thích miệng.

Nhật ký quyết định mẫu

Mốc	Trạng thái	Quyết định	Bằng chứng
BASE	R00	Khóa nguồn	Screenshot/Stats
TEST	Thử nghiệm	Một biến	Before/After
R01	Được duyệt	Media chính	Shot list
CHANGE	Yêu cầu sửa	Impact list	Change request
R02	Tái phát hành	QA hoàn tất	Change log