Case study: tạo video walkthrough không gây chóng mặt

Case study: tạo video walkthrough không gây chóng mặt là Bài 93 của chuyên đề Twinmotion trong trực quan hóa và trình bày BĐS. Thiết kế walkthrough BĐS có chuyển động êm, cao độ hợp lý, ít xoay gấp, tốc độ đọc được và đường camera có mục đích; dùng Parts/Keyframes hoặc Sequence Action camera, easing và path control thay vì bay ngẫu nhiê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

Lập storyboard trước khi tạo đường camera.
Chọn eye level, FOV và tốc độ phù hợp walkthrough.
Giảm xoay gấp, thay đổi cao độ và tốc độ đột ngột.
Dùng Parts/Keyframes hoặc Sequence Action camera có kiểm soát.
Xuất đoạn test để đánh giá chuyển động trước bản cuối.

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

Bài 59–61 đã học Video, Keyframes và Sequence. Bài 93 biến các kỹ thuật đó thành một case trải nghiệm: walkthrough phải giúp người xem hiểu không gian mà không bị mất phương hướng hoặc khó chịu vì camera quay, tăng tốc và thay cao độ liên tụ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. Storyboard phải mô tả hành trình, không chỉ danh sách góc đẹp

Walkthrough nên mô phỏng một hành trình có đầu–cuối: cửa vào → không gian chính → điểm dừng → chuyển phòng → kết. Nếu chỉ nối các góc đẹp, camera có thể xuyên tường hoặc quay ngược liên tục.

Với căn hộ, 20–40 giây thường đủ cho một tuyến ngắn tùy mục tiêu.

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:

Vẽ 5–7 khung.
Ghi vị trí camera.
Ghi thời lượng.
Đánh dấu điểm dừng.

Cách tự kiểm:

Không đoạn vô mục đích.
Không quay lại cùng nơi.
Tuyến hiểu được.
Tổng thời lượng phù hợp.

Lưu ý: Video dài hơn không tự tốt hơn.

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. Giữ cao độ gần trải nghiệm người đi bộ

Walkthrough nên giữ camera ở cao độ gần tầm mắt người dùng; thay đổi cao độ nhỏ, có lý do. Bay lên–xuống liên tục làm mất cảm giác đang đi trong không gian.

Nếu cần flythrough tổng quan, tách thành Part riêng.

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:

Khóa eye level.
Tạo Part WALK.
Tạo Part FLY nếu cần.
Không trộn liên tục.

Cách tự kiểm:

Không camera lơ lửng.
Không đột ngột nâng/hạ.
Tên Part rõ.
Người xem hiểu kiểu chuyển động.

Lưu ý: Walkthrough và flythrough là hai ngôn ngữ khác nhau.

3. FOV/Focal length vừa phải giúp giảm méo khi di chuyển

FOV quá rộng làm mép hình kéo giãn mạnh khi camera tiến hoặc quay, tăng cảm giác chuyển động. Chọn mức vừa đủ để đọc không gian; nếu phòng quá nhỏ, cân nhắc đổi vị trí/đường đi trước khi mở cực rộng.

Khóa FOV trong một đoạn trừ khi có ý đồ rõ.

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 test FOV vừa/rộng.
Phát toàn đoạn.
So mép khung.
Chọn.

Cách tự kiểm:

Không méo mạnh.
Không thay zoom bất ngờ.
Không cửa/tường phóng đại.
Cùng Part ổn định.

Lưu ý: Đừng dùng FOV để bù đường camera xấu.

4. Số keyframe vừa đủ giúp đường mượt hơn

Quá nhiều keyframe gần nhau thường làm camera lắt léo và khó chỉnh. Bắt đầu bằng đầu–cuối và các điểm đổi hướng thực sự cần.

Kiểm đoạn giữa các keyframes, không chỉ thumbnail.

Quy trình thực hành:

Tạo ít điểm.
Play.
Thêm điểm khi cần.
Giảm điểm thừa.

Cách tự kiểm:

Không zigzag.
Không xuyên vật thể.
Sửa một điểm không phá cả đoạn.
Chủ thể vào khung đúng lúc.

Lưu ý: Ít keyframe đúng chỗ thường tốt hơn mật độ cao.

5. Action camera trong Sequence cho phép kiểm path và tension

Tài liệu hiện hành cho Action camera trong Sequence khả năng quản lý camera path, tension, tangents và tốc độ; phù hợp khi walkthrough cần tinh chỉnh hơn Video cơ bản.

Không cần chuyển sang Sequence nếu Video Parts đã đủ; dùng công cụ phức tạp hơn khi có lợi thật.

Quy trình thực hành:

Tạo một Action camera part.
Kiểm path.
Chỉnh tension/tangent nếu cần.
Preview.

Cách tự kiểm:

Đường không cắt tường.
Góc cua mềm.
Không path vòng vô lý.
Có lợi so Video cơ bản.

Lưu ý: Sequence là công cụ, không phải tiêu chuẩn bắt buộc.

6. Easing giúp tránh tăng/giảm tốc đột ngột

Creating Sequences hiện có các chế độ như Linear, Ease in/out, Strong ease in/out, Linear ease out và Ease in linear để quản tốc độ camera trên path. Walkthrough thường cần vào/ra chuyển động êm hơn camera đổi tốc đột ngột.

Chọn easing theo nhịp storyboard và xem ở tốc độ thật.

Quy trình thực hành:

Thử Linear.
Thử Ease in/out.
So đầu/cuối Part.
Chọn.

Cách tự kiểm:

Không giật khi bắt đầu.
Không phanh bất ngờ.
Điểm dừng tự nhiên.
Tổng thời lượng hợp lý.

Lưu ý: Easing không sửa một path hình học xấu.

7. Hạn chế pan/tilt/roll mạnh trong khi tiến

Khi camera vừa tiến vừa quay nhiều, chuyển động thị giác tăng mạnh. Trong BĐS, thường nên giữ horizon ổn định và xoay vừa đủ để dẫn mắt.

Nếu cần đổi hướng lớn, cân nhắc tách Part hoặc dừng ngắn.

Quy trình thực hành:

Kiểm góc cua.
Giảm roll.
Chia Part nếu cần.
Play full screen.

Cách tự kiểm:

Không quay 180° đột ngột.
Không roll trang trí.
Không pitch lên/xuống liên tục.
Chủ thể đọc được.

Lưu ý: Chuyển động điện ảnh không đồng nghĩa càng nhiều xoay càng tốt.

8. DOF và Auto focus cần dùng rất thận trọng trong walkthrough

Đổi nét liên tục hoặc bokeh mạnh khi camera di chuyển có thể gây phân tâm và làm mất thông tin. Với walkthrough mô tả không gian, vùng rõ tương đối rộng thường dễ xem hơn.

Nếu dùng Auto focus, phải xem toàn đoạn để phát hiện focus hunting.

Quy trình thực hành:

Tắt DOF baseline.
Thử DOF nhẹ.
Kiểm focus.
Xuất test.

Cách tự kiểm:

Không hunting.
Không mờ lối đi.
Không bokeh che chủ thể.
Có lý do dùng.

Lưu ý: Không dùng DOF để tạo cảm giác 'cinematic' nếu giảm khả năng hiểu không gian.

9. Xuất test 5–10 giây là bước bắt buộc

Viewport playback có thể khác cảm nhận file xuất. Chọn đoạn có cua, cửa, kính và thay ánh sáng để render thử ở kích thước vừa.

Xem trên màn hình/điện thoại đích trước khi render toàn video.

Quy trình thực hành:

Chọn đoạn đại diện.
Export test.
Xem tốc độ thật.
Ghi lỗi.

Cách tự kiểm:

Không giật.
Không motion gây khó chịu.
Codec/file ổn.
Thời gian render ước được.

Lưu ý: Đừng chờ đến bản 4K cuối mới phát hiện camera quá nhanh.

10. User test bằng người chưa biết đường camera

Người dựng đã thuộc đường nên ít bị mất phương hướng. Hãy cho người khác xem và hỏi họ đang ở đâu, đi về đâu, đoạn nào khó chịu hoặc không kịp đọc.

Phản hồi này đáng tin hơn việc tự xem lặp nhiều lần.

Quy trình thực hành:

Chọn 2 người thử.
Không giải thích trước.
Ghi timestamp.
Sửa R02.

Cách tự kiểm:

Ít điểm mất phương hướng.
Không ai báo xoay/tốc độ khó chịu.
Tuyến dễ hiểu.
R02 cải thiện.

Lưu ý: Walkthrough được đánh giá bằng trải nghiệm người xem.

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 walkthrough 35 giây có 16 keyframes, camera vừa đi vừa xoay 90–120°, hai lần nâng lên cao rồi hạ xuống. Sinh viên thấy 'năng động', nhưng người thử cảm thấy khó theo. Bản R02 giảm còn 7 keyframes, tách một đoạn flythrough, dùng Ease in/out, giữ eye level và giảm FOV. Video ít hiệu ứng hơn nhưng người xem hiểu căn hộ tốt hơ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
Storyboard	5–7 khung	Tuyến	Không bay ngẫu nhiên
Eye level	Walkthrough	Ổn định	Không lơ lửng
FOV	Vừa phải	Giảm méo	Không cực rộng
Keyframes	Tối thiểu cần thiết	Đường mượt	Không zigzag
Easing	Ease in/out khi phù hợp	Tốc độ êm	Test thực
User test	Người mới	Trải nghiệm	Timestamp lỗi

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

Quá nhiều keyframes.
Camera lên xuống liên tục.
FOV cực rộng.
Vừa tiến vừa quay mạnh.
Roll để tạo hiệu ứng.
DOF hunting.
Không render test.
Chỉ người dựng tự xem.

Phân tích lỗi 1 – Quá nhiều keyframes. 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 – Camera lên xuống liên tục. 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 – FOV cực rộ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 4 – Vừa tiến vừa quay mạnh. 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 – Roll để tạo hiệu ứ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.

Bài thực hành

Tạo walkthrough 25–40 giây. Bản R01 dùng đường camera ban đầu; sau user test, tạo R02 giảm điểm/điều chỉnh easing hoặc FOV. Nộp bảng timestamp phản hồi.

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

Storyboard.
Video R01/R02.
Sơ đồ keyframes/Parts.
Đoạn test.
Bảng user test.
Ghi thông số camera/easing.

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

Walkthrough kể một hành trình.
Giữ eye level và FOV ổn định.
Ít keyframe đúng chỗ giúp mượt.
Easing quản tốc độ, không sửa path xấu.
User test quyết định trải nghiệm.

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/videos
https://dev.epicgames.com/documentation/twinmotion/creating-sequences-in-twinmotion
https://dev.epicgames.com/documentation/en-us/twinmotion/sequences-in-twinmotion
https://dev.epicgames.com/documentation/twinmotion/export-settings-for-videos-in-twinmotion

Bài tiếp theo

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

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