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

Video: tạo camera path mượt thay vì bay máy ngẫu nhiên

Video: tạo camera path mượt thay vì bay máy ngẫu nhiên là Bài 59 của chuyên đề Twinmotion trong trực quan hóa và trình bày BĐS. Thiết kế video BĐS theo storyboard, Parts và Keyframes để camera di chuyển có mục đích, tốc độ hợp lý và kể đúng câu chuyện không gian thay vì bay ngẫu nhiên qua mô hình.

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 đượ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ùy chọ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 đối chiếu tài liệu chính thức của phiên bản đang sử dụng.

Lưu ý sử dụng: các dự án, kích thước, thời gian, thông số máy, bối cảnh 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 hỗ trợ trực quan hóa và trình bày; hình ảnh hoặc video tạo ra không tự thay thế hồ sơ thiết kế, khảo sát, pháp lý, quy hoạch, chiếu sáng hoặc kết luận kỹ thuật đã được phê duyệt.

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

  • Xác định mục tiêu video trước khi tạo đường camera.
  • Lập storyboard và chia video thành các đoạn.
  • Tạo Parts và Keyframes theo lộ trình.
  • Kiểm tốc độ, hướng nhìn và chuyển cảnh.
  • Xuất đoạn thử để duyệt trước video dài.

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

Bài 57–58 làm media tĩnh và 360°. Video thêm thời gian và chuyển động. Một góc camera đẹp không tự tạo video tốt; người học phải thiết kế lộ trình và nhịp kể chuyện.

Bài thuộc Chương 8 – Ảnh, panorama, video và sequence. Kết quả học tập được đánh giá bằng khả năng giải thích lựa chọn, tái tạo thao tác, phát hiện sai lệch và bàn giao trạng thái cho người khác; không chỉ bằng một hình ảnh bắt mắt.

1. Video phải có câu chuyện không gian

Một video BĐS nên trả lời trình tự: bắt đầu ở đâu, giới thiệu điều gì, đi qua đâu, kết thúc ở đâu. Camera bay ngẫu nhiên giữa các điểm đẹp thường làm người xem mất phương hướng.

Storyboard có thể đơn giản bằng 6–10 ô: ngoại cảnh, tiếp cận, sảnh, không gian chính, tiện ích, kết thúc.

Điểm cần kiểm sâu: Để thao tác có thể kiểm chứng, nên giữ một media gốc rồi tạo bản sao trước khi thay đổi. Cách này giúp so sánh trước–sau và quay lại trạng thái an toàn nếu thử nghiệm không đạt.

Quy trình thực hành gợi ý:

  1. Viết mục tiêu video một câu.
  2. Vẽ 6 khung storyboard.
  3. Ghi thời lượng dự kiến mỗi khung.
  4. Chỉ sau đó mở Media > Video.

Cách tự kiểm:

  • Mỗi đoạn có nhiệm vụ.
  • Không có đoạn chỉ để kéo dài.
  • Tổng thời lượng phù hợp kênh.

Lưu ý: Video ngắn nhưng rõ thường hiệu quả hơn video dài thiếu cấu trúc.

Bằng chứng nên lưu: media hoặc ảnh trước–sau, tên trạng thái và một dòng giải thích vì sao thay đổi được giữ lại. Bằng chứng giúp phân biệt quyết định có chủ đích với chỉnh ngẫu nhiên và hỗ trợ kiểm chéo khi dự án thay đổi.

2. Parts chia video thành các đoạn dễ quản lý

Trong Twinmotion, video có thể gồm một hoặc nhiều Parts. Mỗi Part tương ứng một đoạn chuyển động và có thể sắp lại thứ tự.

Chia Part theo không gian hoặc ý: ngoại thất, sảnh, nội thất, tiện ích. Việc này giúp sửa một đoạn mà không phá toàn bộ.

Điểm cần kiểm sâu: Kết quả cần được kiểm ở kích thước sử dụng thực tế. Một chi tiết rất rõ trong Viewport có thể không còn thấy trên điện thoại; ngược lại, lỗi nhỏ ở cạnh khung có thể lộ rõ trên màn hình lớn.

Quy trình thực hành gợi ý:

  1. Tạo Video.
  2. Tạo Part cho từng nhóm cảnh.
  3. Đặt thứ tự.
  4. Xem chuyển tiếp giữa Parts.

Cách tự kiểm:

  • Part có mục tiêu rõ.
  • Không có Part quá dài chứa nhiều câu chuyện.
  • Có thể sửa độc lập.

Lưu ý: Tên hoặc ghi chú nội bộ của Part nên theo storyboard.

Bằng chứng nên lưu: media hoặc ảnh trước–sau, tên trạng thái và một dòng giải thích vì sao thay đổi được giữ lại. Bằng chứng giúp phân biệt quyết định có chủ đích với chỉnh ngẫu nhiên và hỗ trợ kiểm chéo khi dự án thay đổi.

3. Keyframes là các điểm nhìn mà camera phải đi qua

Mỗi Keyframe lưu một điểm nhìn; Twinmotion nội suy chuyển động giữa chúng. Quá ít keyframe có thể làm camera cắt vật thể; quá nhiều keyframe gần nhau có thể tạo đường đi rung hoặc đổi hướng liên tục.

Đặt keyframe ở nơi thực sự cần đổi vị trí, hướng hoặc nhịp.

Điểm cần kiểm sâu: Trong dự án nhóm, tên media và trạng thái duyệt quan trọng không kém tham số. Người khác phải mở file và hiểu ngay đâu là bản gốc, đâu là bản thử, đâu là bản đã duyệt.

Quy trình thực hành gợi ý:

  1. Tạo điểm đầu.
  2. Di chuyển đến điểm tiếp theo.
  3. Thêm keyframe.
  4. Phát lại và chỉ thêm keyframe nếu cần điều chỉnh đường.

Cách tự kiểm:

  • Đường camera không xuyên tường.
  • Không ngoặt gấp ngoài ý muốn.
  • Mỗi keyframe có lý do.

Lưu ý: Bài 60 sẽ đi sâu vào Keyframes; ở đây tập trung xây đường camera tổng thể.

Bằng chứng nên lưu: media hoặc ảnh trước–sau, tên trạng thái và một dòng giải thích vì sao thay đổi được giữ lại. Bằng chứng giúp phân biệt quyết định có chủ đích với chỉnh ngẫu nhiên và hỗ trợ kiểm chéo khi dự án thay đổi.

4. Walkthrough và flythrough cần ngôn ngữ chuyển động khác nhau

Walkthrough mô phỏng người đi nên cao độ, tốc độ và hướng quay ổn định; flythrough có thể cao và rộng hơn để giải thích tổng thể.

Không trộn liên tục hai kiểu trong cùng một Part vì người xem dễ mất cảm giác tỷ lệ.

Điểm cần kiểm sâu: Để thao tác có thể kiểm chứng, nên giữ một media gốc rồi tạo bản sao trước khi thay đổi. Cách này giúp so sánh trước–sau và quay lại trạng thái an toàn nếu thử nghiệm không đạt.

Quy trình thực hành gợi ý:

  1. Tạo một Part walkthrough.
  2. Tạo một Part flythrough riêng.
  3. So tốc độ và cao độ.
  4. Nối bằng chuyển cảnh hợp lý.

Cách tự kiểm:

  • Walkthrough không lơ lửng.
  • Flythrough không được gọi là trải nghiệm đi bộ.
  • Chuyển kiểu có chủ đích.

Lưu ý: Nếu cần nhảy từ ngoài vào trong, có thể tách Part thay vì camera xuyên mái hoặc tường.

Bằng chứng nên lưu: media hoặc ảnh trước–sau, tên trạng thái và một dòng giải thích vì sao thay đổi được giữ lại. Bằng chứng giúp phân biệt quyết định có chủ đích với chỉnh ngẫu nhiên và hỗ trợ kiểm chéo khi dự án thay đổi.

5. Tốc độ phải phù hợp khoảng cách và lượng thông tin

Camera đi nhanh qua khu vực nhiều chi tiết khiến người xem không kịp hiểu; đi chậm quá lâu gây nhàm. Nhịp video nên thay theo nhiệm vụ từng đoạn.

Sảnh lớn có thể cần chậm khi đến điểm nhấn; đoạn chuyển ngoại cảnh có thể nhanh hơn.

Điểm cần kiểm sâu: Kết quả cần được kiểm ở kích thước sử dụng thực tế. Một chi tiết rất rõ trong Viewport có thể không còn thấy trên điện thoại; ngược lại, lỗi nhỏ ở cạnh khung có thể lộ rõ trên màn hình lớn.

Quy trình thực hành gợi ý:

  1. Xem video ở tốc độ thật.
  2. Bấm giờ từng Part.
  3. Đánh dấu đoạn người xem cần đọc biển hoặc vật liệu.
  4. Điều chỉnh thời lượng.

Cách tự kiểm:

  • Không có đoạn vội.
  • Không có đoạn đứng yên vô cớ.
  • Tổng thời lượng đúng kế hoạch.

Lưu ý: Không đánh giá tốc độ bằng cách kéo scrubber; phải Play toàn đoạn.

Bằng chứng nên lưu: media hoặc ảnh trước–sau, tên trạng thái và một dòng giải thích vì sao thay đổi được giữ lại. Bằng chứng giúp phân biệt quyết định có chủ đích với chỉnh ngẫu nhiên và hỗ trợ kiểm chéo khi dự án thay đổi.

6. Camera nên giữ hướng ổn định và tránh quay đầu đột ngột

Các xoay yaw/pitch/roll đột ngột dễ gây khó chịu. Trong BĐS, camera thường nên chuyển động êm, đường chân trời ổn định và quay hướng vừa đủ.

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

Điểm cần kiểm sâu: Trong dự án nhóm, tên media và trạng thái duyệt quan trọng không kém tham số. Người khác phải mở file và hiểu ngay đâu là bản gốc, đâu là bản thử, đâu là bản đã duyệt.

Quy trình thực hành gợi ý:

  1. Kiểm các góc cua.
  2. Giảm thay đổi hướng lớn giữa hai keyframe.
  3. Giữ horizon.
  4. Xem trên màn hình lớn.

Cách tự kiểm:

  • Không chóng mặt.
  • Không roll ngoài ý muốn.
  • Chủ thể luôn có thời gian xuất hiện.

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

Bằng chứng nên lưu: media hoặc ảnh trước–sau, tên trạng thái và một dòng giải thích vì sao thay đổi được giữ lại. Bằng chứng giúp phân biệt quyết định có chủ đích với chỉnh ngẫu nhiên và hỗ trợ kiểm chéo khi dự án thay đổi.

7. Ambience và trạng thái cảnh phải ổn định theo video

Video có thể mang Ambience, View set, phasing hoặc các trạng thái khác. Nếu thay ánh sáng giữa Parts, cần có ý đồ; nếu không, người xem có thể thấy nhảy sáng hoặc vật thể biến mất.

Đặc biệt khi đồng bộ mô hình sau này, phải xem lại toàn video.

Điểm cần kiểm sâu: Để thao tác có thể kiểm chứng, nên giữ một media gốc rồi tạo bản sao trước khi thay đổi. Cách này giúp so sánh trước–sau và quay lại trạng thái an toàn nếu thử nghiệm không đạt.

Quy trình thực hành gợi ý:

  1. Kiểm đầu/cuối từng Part.
  2. So Exposure/time of day.
  3. Kiểm visibility.
  4. Preview toàn video sau thay model.

Cách tự kiểm:

  • Không nhảy trạng thái vô cớ.
  • Không có người/xe xuất hiện biến mất sai.
  • Phần A/B được giải thích.

Lưu ý: Đừng chèn quá nhiều hiệu ứng thời tiết vào video chỉ để gây ấn tượng.

Bằng chứng nên lưu: media hoặc ảnh trước–sau, tên trạng thái và một dòng giải thích vì sao thay đổi được giữ lại. Bằng chứng giúp phân biệt quyết định có chủ đích với chỉnh ngẫu nhiên và hỗ trợ kiểm chéo khi dự án thay đổi.

8. Xuất thử đoạn ngắn trước bản cuối

Video dài có chi phí lớn. Trước khi 4K hoặc Path tracer, xuất một đoạn 5–10 giây đại diện để kiểm motion blur, DOF, exposure, tốc độ, codec và chất lượng.

Đoạn thử nên chứa một góc cua, một vùng kính và một thay đổi ánh sáng nếu video có.

Điểm cần kiểm sâu: Kết quả cần được kiểm ở kích thước sử dụng thực tế. Một chi tiết rất rõ trong Viewport có thể không còn thấy trên điện thoại; ngược lại, lỗi nhỏ ở cạnh khung có thể lộ rõ trên màn hình lớn.

Quy trình thực hành gợi ý:

  1. Chọn đoạn đại diện.
  2. Xuất 2K thử.
  3. Xem trên thiết bị đích.
  4. Sửa rồi mới xuất toàn bộ.

Cách tự kiểm:

  • Không có giật/hunting.
  • Chất lượng đủ.
  • Đoạn thử được duyệt trước bản cuối.

Lưu ý: Render thử là bước bắt buộc với video nặng.

Bằng chứng nên lưu: media hoặc ảnh trước–sau, tên trạng thái và một dòng giải thích vì sao thay đổi được giữ lại. Bằng chứng giúp phân biệt quyết định có chủ đích với chỉnh ngẫu nhiên và hỗ trợ kiểm chéo khi dự án thay đổi.

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

Tình huống giả lập phục vụ giảng dạy: Video dự án 45 giây ban đầu có camera bay từ ngoài vào xuyên kính, vòng quanh phòng khách rồi lao lên mái. Người xem khó xác định vị trí. Nhóm viết storyboard 6 đoạn, tách ngoại thất, tiếp cận, sảnh, phòng khách, ban công và tổng quan thành Parts. Walkthrough giữ cao độ người, đoạn cuối mới chuyển flythrough. Video ngắn hơn nhưng dễ hiểu hơn.

Khi xử lý tình huống, hãy xác định loại đầu ra, người xem, thông tin bắt buộc phải giữ và những biến cần khóa trước khi thay tham số. Chỉ thay từng nhóm thiết lập, lưu bản thử và đối chiếu với bản gốc. Cách làm này giúp kết quả có thể giải thích và tái tạo thay vì phụ thuộc vào cảm giác.

Ma trận ra quyết định nhanh

Tình huống/nhómThiết lập hoặc cách tiếp cậnMục đíchĐiểm phải kiểm
Mở đầu3–5 sThiết lập bối cảnhChuyển động đơn giản
Tiếp cận5–8 sĐọc lối vàoWalkthrough
Không gian chính8–12 sCho người xem hiểu bố cụcChậm hơn
Chi tiết3–6 sNhấn vật liệu/tiện íchCó thể dừng nhẹ
Chuyển khu3–5 sĐổi không gianPart riêng nếu cần
Kết3–6 sTổng quan/CTA hậu kỳỔn định

Quy trình 10 bước áp dụng trong một dự án thật

  1. Đọc yêu cầu đầu ra và xác định người xem chính.
  2. Chọn đúng mô hình/phiên bản và kiểm Scene graph, vật liệu, ánh sáng cơ bản.
  3. Mở shot list hoặc storyboard; không bắt đầu bằng thử tham số ngẫu nhiên.
  4. Khóa các biến không thuộc mục tiêu bài để phép thử có ý nghĩa.
  5. Tạo bản gốc hoặc media đối chứng trước khi thay đổi.
  6. Thực hiện thay đổi theo từng nhóm nhỏ và đặt tên ngay sau khi tạo biến thể.
  7. Kiểm trong Media dock và ở trạng thái đã lưu, không dựa vào Viewport tạm.
  8. Xuất một bản thử nhẹ và mở file ngoài Twinmotion ở kích thước sử dụng.
  9. Ghi lỗi, sửa đúng lớp và kiểm chéo nếu là media quan trọng.
  10. Chỉ chuyển APPROVED khi nội dung, kỹ thuật và thông tin bàn giao đều đạt.

Quy trình này giữ được nguyên tắc: mỗi quyết định đều có đầu vào, phép thử, bằng chứng và điểm duyệt. Khi dự án đổi mô hình, vật liệu hoặc kênh truyền thông, nhóm có thể cập nhật có kiểm soát thay vì làm lại từ đầu.

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

  • Không storyboard, bay theo cảm hứng.
  • Một Part quá dài xuyên nhiều không gian.
  • Quá nhiều keyframe gây rung.
  • Walkthrough có cao độ như drone.
  • Camera quay đầu gấp.
  • Render toàn video trước khi xuất đoạn thử.

Lỗi 1 – Không storyboard, bay theo cảm hứng. Khi gặp lỗi này, không sửa đồng thời camera, ánh sáng và vật liệu. Hãy tạo bản sao media, xác định biến trực tiếp gây sai lệch, sửa một bước rồi so với bản gốc. Nếu lỗi chỉ xuất hiện sau Export, kiểm thêm kích thước, định dạng, Render mode và giới hạn của tính năng trong phiên bản đang dùng.

Lỗi 2 – Một Part quá dài xuyên nhiều không gian. Khi gặp lỗi này, không sửa đồng thời camera, ánh sáng và vật liệu. Hãy tạo bản sao media, xác định biến trực tiếp gây sai lệch, sửa một bước rồi so với bản gốc. Nếu lỗi chỉ xuất hiện sau Export, kiểm thêm kích thước, định dạng, Render mode và giới hạn của tính năng trong phiên bản đang dùng.

Lỗi 3 – Quá nhiều keyframe gây rung. Khi gặp lỗi này, không sửa đồng thời camera, ánh sáng và vật liệu. Hãy tạo bản sao media, xác định biến trực tiếp gây sai lệch, sửa một bước rồi so với bản gốc. Nếu lỗi chỉ xuất hiện sau Export, kiểm thêm kích thước, định dạng, Render mode và giới hạn của tính năng trong phiên bản đang dùng.

Lỗi 4 – Walkthrough có cao độ như drone. Khi gặp lỗi này, không sửa đồng thời camera, ánh sáng và vật liệu. Hãy tạo bản sao media, xác định biến trực tiếp gây sai lệch, sửa một bước rồi so với bản gốc. Nếu lỗi chỉ xuất hiện sau Export, kiểm thêm kích thước, định dạng, Render mode và giới hạn của tính năng trong phiên bản đang dùng.

Lỗi 5 – Camera quay đầu gấp. Khi gặp lỗi này, không sửa đồng thời camera, ánh sáng và vật liệu. Hãy tạo bản sao media, xác định biến trực tiếp gây sai lệch, sửa một bước rồi so với bản gốc. Nếu lỗi chỉ xuất hiện sau Export, kiểm thêm kích thước, định dạng, Render mode và giới hạn của tính năng trong phiên bản đang dùng.

Bài thực hành

Lập storyboard cho video 30–45 giây gồm tối thiểu 5 Parts. Tạo video với đường camera không xuyên mô hình, có ít nhất một walkthrough và một đoạn tổng quan. Xuất đoạn thử 5–10 giây, sửa theo phản hồi rồi mới xuất bản hoàn chỉnh ở chất lượng phù hợp.

Yêu cầu thực hiện: lưu cả trạng thái trước và sau, đặt tên media có quy tắc, ghi tối thiểu ba quyết định kỹ thuật và giải thích vì sao chọn chúng. Không chấm cao sản phẩm chỉ vì bắt mắt nếu quy trình không thể lặp lại hoặc làm người xem hiểu sai tỷ lệ, bối cảnh hay trạng thái phương án.

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

  • Storyboard 6–10 khung.
  • Video có tối thiểu 5 Parts.
  • Bảng thời lượng từng Part.
  • Đoạn test render và bản sửa.
  • Bảng tự kiểm chuyển động/camera/ánh sáng.

Phiếu tự kiểm trước khi nộp

  • Tôi đã xác định rõ mục tiêu và kênh sử dụng của media chưa?
  • Camera và trạng thái mô hình có đúng phiên bản cần trình bày không?
  • Tôi có thay quá nhiều biến cùng lúc khiến không thể giải thích kết quả không?
  • Tên media/trạng thái có đủ rõ để người khác tiếp tục không?
  • Vật liệu, ánh sáng, người, xe, cây và phản xạ có lỗi dễ thấy không?
  • Tôi đã kiểm cả Viewport và media đã lưu chưa?
  • Tôi đã mở file sau Export ở kích thước sử dụng thực tế chưa?
  • Có chi tiết nào làm người xem hiểu sai quy mô, công năng, bối cảnh hay tình trạng dự án không?
  • Nếu là tình huống giả lập, trạng thái giả lập đã được ghi rõ trong quy trình bàn giao chưa?
  • Tôi có lưu bằng chứng trước–sau cho thay đổi quan trọng không?
  • Sản phẩm có thể được người khác cập nhật mà không cần hỏi lại toàn bộ không?
  • Nguồn kỹ thuật và phiên bản phần mềm đã được kiểm khi có khác biệt giao diện không?

Phòng kiểm chứng: ba phép thử bắt buộc

Phép thử A – khóa biến

Tạo hai media có cùng camera, mô hình, vật liệu và môi trường. Chỉ thay đúng biến trọng tâm của bài. Ghi khác biệt bằng ảnh trước–sau và một câu kết luận.

Sau phép thử, ghi kết quả – nguyên nhân – quyết định giữ/bỏ; không chỉ ghi “đẹp hơn” hoặc “xấu hơn”.

Phép thử B – đổi kênh sử dụng

Giữ nội dung chính nhưng chuyển đầu ra sang một kênh khác, ví dụ ảnh dọc hoặc màn hình nhỏ. Kiểm xem lựa chọn ban đầu còn phù hợp không.

Sau phép thử, ghi kết quả – nguyên nhân – quyết định giữ/bỏ; không chỉ ghi “đẹp hơn” hoặc “xấu hơn”.

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

Nhờ một thành viên khác mở lại chỉ dựa vào tên media, shot list và ghi chú. Người đó phải tìm đúng trạng thái, biết media nào đã duyệt và biết cần sửa ở đâu.

Sau phép thử, ghi kết quả – nguyên nhân – quyết định giữ/bỏ; không chỉ ghi “đẹp hơn” hoặc “xấu hơn”.

Ghi nhớ trong 30 giây

  • Storyboard trước camera path.
  • Parts chia câu chuyện, Keyframes định đường.
  • Walkthrough và flythrough có ngôn ngữ khác nhau.
  • Xem video ở tốc độ thật.
  • Luôn render thử đoạn ngắn.

Nguồn tham khảo

Nguồn kỹ thuật ưu tiên là Epic Games – Twinmotion Documentation. Khi giao diện khác bài, kiểm đúng phiên bản đang dùng.

  • https://dev.epicgames.com/documentation/en-us/twinmotion/videos
  • https://dev.epicgames.com/documentation/twinmotion/creating-videos
  • https://dev.epicgames.com/documentation/twinmotion/export-settings-for-videos-in-twinmotion
  • https://dev.epicgames.com/documentation/twinmotion/creating-and-exporting-media

Bài tiếp theo

Keyframes: kiểm soát vị trí, thời gian và chuyển động camera.

Phân tích sâu khi dự án có nhiều vòng chỉnh sửa

Media trong dự án thực tế hiếm khi được làm một lần rồi kết thúc. Thiết kế có thể đổi cửa, vật liệu, cảnh quan, nội thất, biển hiệu hoặc phương án vận hành. Vì vậy thiết lập của bài cần được đánh giá theo khả năng sống cùng thay đổi. Một lựa chọn tốt không chỉ tạo kết quả đẹp hôm nay mà còn giúp người khác nhận biết trạng thái, cập nhật đúng media và phát hiện ảnh/video nào cần xuất lại.

Hãy mô phỏng một change request sau khi media đã duyệt: thay vật liệu sàn, di chuyển một cửa hoặc thay cụm cây. Đồng bộ mô hình, mở lại từng media liên quan, đánh dấu media bị ảnh hưởng, kiểm lại camera/ánh sáng/trạng thái rồi xuất R02. So sánh thời gian với cách làm không có shot list và không có quy tắc đặt tên.

Lưu một bảng CHANGE LOG gồm ngày, yêu cầu, media bị ảnh hưởng, người sửa, kết quả kiểm và trạng thái phát hành. Trong BĐS, ảnh cũ có thể tiếp tục lưu hành sau khi phương án đã thay đổi nếu nhóm không kiểm soát phiên bản.

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