Synchronize: cập nhật hình học mà không dựng lại cảnh từ đầu

Synchronize: cập nhật hình học mà không dựng lại cảnh từ đầu là Bài 12 của chuyên đề Twinmotion trong trực quan hóa và trình bày BĐS. Học cách dùng Synchronize như một vòng cập nhật có kiểm soát: thay đổi ở SketchUp, đồng bộ đúng thời điểm, kiểm hình học và các giá trị ghi đè quan trọng, giữ media/bối cảnh đã dựng và có phương án quay lui.

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 tài liệu Twinmotion Documentation hiện hành của Epic. Giao diện và tùy chọn có thể thay đổi theo phiên bản; khi có khác biệt, cần kiểm tra tài liệu chính thức của phiên bản đang sử dụng.

Ranh giới sử dụng: các số liệu công trình, khu đất, vật liệu, cao độ, vị trí và phương án trong ví dụ nếu không có nguồn riêng đề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; không thay hồ sơ pháp lý, khảo sát, thiết kế được phê duyệt, quy hoạch, định giá hoặc kết luận kỹ thuật chuyên ngành.

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

• Hiểu Synchronize cập nhật nguồn chứ không đồng nghĩa “mọi thứ luôn được giữ nguyên”.
• Thiết kế change set nhỏ để biết chính xác điều gì vừa thay đổi.
• Phân biệt thay đổi hình học, vật liệu, biến đổi và cấu trúc cấu trúc phân cấp.
• Kiểm lại các giá trị ghi đè Twinmotion sau mỗi lần đồng bộ quan trọng.
• Thiết lập nhật ký phiên bản giúp nhóm không dựng lại cảnh từ đầu khi mô hình nguồn thay đổi.

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

Bài 11 tạo Direct Link. Bài 12 tập trung vào vòng đời cập nhật sau khi liên kết đã hoạt động. Bài 13 mới đi sâu quy tắc Reimport/giá trị ghi đè và trường hợp có thể bị thay thế.

Bản chất vấn đề cần hiểu trước khi thao tác

Trong Twinmotion, thao tác nhanh không đồng nghĩa quy trình đúng. Dữ liệu BĐS thường thay đổi qua nhiều vòng thiết kế; vì vậy bài này ưu tiên ba lớp kiểm soát: nguồn nào đang được dùng, trạng thái nào vừa thay đổi và bằng chứng nào chứng minh kết quả đúng. Cách học này giúp sinh viên xử lý dự án thật có nhiều phiên bản thay vì chỉ làm được một tệp mẫu cố định.

1. Đồng bộ theo change set, không theo cảm giác

Mỗi vòng đồng bộ nên có danh sách ngắn: thêm gì, xóa gì, di chuyển gì, đổi vật liệu nguồn nào. Điều này biến một thao tác kỹ thuật thành phép kiểm có nguyên nhân – kết quả.

Cách kiểm chứng: Tạo bảng Before/Change/Expected/Actual cho 3–5 thay đổi. Kết quả phải được ghi thành trạng thái trước–sau, không chỉ mô tả bằng cảm giác. Nếu thao tác có liên quan tệp nguồn, phải ghi phiên bản; nếu liên quan một đối tượng, phải ghi tên/đường dẫn trong Scene graph; nếu liên quan nhập dữ liệu, phải ghi tùy chọn đã dùng.

Sai lầm dễ gặp: Sửa hàng chục chi tiết rồi nhấn Synchronize, sau đó phát hiện một lỗi nhưng không biết do bước nào. Cách sửa tốt nhất là quay lại cổng kiểm gần nhất, thu hẹp phạm vi thử và lặp lại đúng phép kiểm ban đầu. Không nên bù một lỗi nguồn bằng thêm hiệu ứng hoặc thêm biến đổi ở bước sau vì làm chuỗi công việc khó truy nguyên.

2. Giữ trạng thái gốc trước cập nhật

Một cảnh đã có cây, người, đèn, vật liệu và góc nhìn có giá trị công việc lớn hơn tệp mô hình trống. Trước thay đổi quan trọng cần mốc để so sánh.

Cách kiểm chứng: Save As hoặc snapshot phiên bản `.tm`; lưu 2–3 ảnh góc nhìn kiểm cố định. Kết quả phải được ghi thành trạng thái trước–sau, không chỉ mô tả bằng cảm giác. Nếu thao tác có liên quan tệp nguồn, phải ghi phiên bản; nếu liên quan một đối tượng, phải ghi tên/đường dẫn trong Scene graph; nếu liên quan nhập dữ liệu, phải ghi tùy chọn đã dùng.

Sai lầm dễ gặp: Chỉ dựa vào Undo trong một tệp dự án dài, trong khi thay đổi có thể xuất hiện sau nhiều thao tác. Cách sửa tốt nhất là quay lại cổng kiểm gần nhất, thu hẹp phạm vi thử và lặp lại đúng phép kiểm ban đầu. Không nên bù một lỗi nguồn bằng thêm hiệu ứng hoặc thêm biến đổi ở bước sau vì làm chuỗi công việc khó truy nguyên.

3. Kiểm hình học trước mỹ thuật

Sau đồng bộ, ưu tiên kiểm đúng/sai hình học, vị trí, số tầng, lỗ mở và kích thước; chưa vội chỉnh màu hay ánh sáng.

Cách kiểm chứng: Dùng 3 góc nhìn kiểm tra chất lượng cố định và một mốc kích thước đã biết từ SketchUp. Kết quả phải được ghi thành trạng thái trước–sau, không chỉ mô tả bằng cảm giác. Nếu thao tác có liên quan tệp nguồn, phải ghi phiên bản; nếu liên quan một đối tượng, phải ghi tên/đường dẫn trong Scene graph; nếu liên quan nhập dữ liệu, phải ghi tùy chọn đã dùng.

Sai lầm dễ gặp: Thấy ảnh “vẫn đẹp” nên bỏ qua việc một cửa đã lệch hoặc một khối bị nhân đôi. Cách sửa tốt nhất là quay lại cổng kiểm gần nhất, thu hẹp phạm vi thử và lặp lại đúng phép kiểm ban đầu. Không nên bù một lỗi nguồn bằng thêm hiệu ứng hoặc thêm biến đổi ở bước sau vì làm chuỗi công việc khó truy nguyên.

4. Theo dõi cấu trúc phân cấp khi nguồn được tái cấu trúc

Đổi Group/Component, explode/nest hoặc đổi cấu trúc nguồn có thể ảnh hưởng danh tính đối tượng các bước phía sau.

Cách kiểm chứng: Nếu thay cấu trúc phân cấp, tách thành một change set riêng và kiểm Scene graph trước/sau. Kết quả phải được ghi thành trạng thái trước–sau, không chỉ mô tả bằng cảm giác. Nếu thao tác có liên quan tệp nguồn, phải ghi phiên bản; nếu liên quan một đối tượng, phải ghi tên/đường dẫn trong Scene graph; nếu liên quan nhập dữ liệu, phải ghi tùy chọn đã dùng.

Sai lầm dễ gặp: Vừa đổi cấu trúc phân cấp vừa đổi vật liệu và vị trí, làm mất khả năng truy nguyên. Cách sửa tốt nhất là quay lại cổng kiểm gần nhất, thu hẹp phạm vi thử và lặp lại đúng phép kiểm ban đầu. Không nên bù một lỗi nguồn bằng thêm hiệu ứng hoặc thêm biến đổi ở bước sau vì làm chuỗi công việc khó truy nguyên.

5. Twinmotion các giá trị ghi đè phải được coi là dữ liệu

Vật liệu thay trong Twinmotion, biến đổi, thuộc tính đối tượng là những giá trị ghi đè có thể quan trọng như hình học.

Cách kiểm chứng: Lập “giá trị ghi đè register”: đối tượng nào đã thay vật liệu/biến đổi và vì sao. Kết quả phải được ghi thành trạng thái trước–sau, không chỉ mô tả bằng cảm giác. Nếu thao tác có liên quan tệp nguồn, phải ghi phiên bản; nếu liên quan một đối tượng, phải ghi tên/đường dẫn trong Scene graph; nếu liên quan nhập dữ liệu, phải ghi tùy chọn đã dùng.

Sai lầm dễ gặp: Không ghi gì, đến lần đồng bộ sau mới phát hiện vật liệu thay nhưng không biết đó là lỗi phần mềm hay thay đổi nguồn. Cách sửa tốt nhất là quay lại cổng kiểm gần nhất, thu hẹp phạm vi thử và lặp lại đúng phép kiểm ban đầu. Không nên bù một lỗi nguồn bằng thêm hiệu ứng hoặc thêm biến đổi ở bước sau vì làm chuỗi công việc khó truy nguyên.

6. Auto Sync phù hợp vòng thử nhanh, không thay cổng phát hành

Auto Sync có lợi khi thiết kế thay đổi liên tục và người dùng đang theo dõi trực tiếp; trước ảnh/đoạn phim phát hành vẫn cần đóng băng phiên bản và kiểm tra chất lượng.

Cách kiểm chứng: Quy định trạng thái DRAFT_AUTO và RELEASE_MANUAL trong nhóm. Kết quả phải được ghi thành trạng thái trước–sau, không chỉ mô tả bằng cảm giác. Nếu thao tác có liên quan tệp nguồn, phải ghi phiên bản; nếu liên quan một đối tượng, phải ghi tên/đường dẫn trong Scene graph; nếu liên quan nhập dữ liệu, phải ghi tùy chọn đã dùng.

Sai lầm dễ gặp: Xuất media giữa lúc Auto Sync đang nhận thay đổi từ người khác. Cách sửa tốt nhất là quay lại cổng kiểm gần nhất, thu hẹp phạm vi thử và lặp lại đúng phép kiểm ban đầu. Không nên bù một lỗi nguồn bằng thêm hiệu ứng hoặc thêm biến đổi ở bước sau vì làm chuỗi công việc khó truy nguyên.

7. Đồng bộ xong phải cập nhật media có chọn lọc

Camera/media không tự trở thành “đúng” chỉ vì mô hình đã đồng bộ. Góc nhìn có thể bị che, lộ khoảng trống hoặc thay bố cục.

Cách kiểm chứng: Duyệt danh sách ảnh/ảnh toàn cảnh quan trọng sau mỗi đồng bộ lớn; chỉ làm mới media sau khi cảnh đạt kiểm tra chất lượng. Kết quả phải được ghi thành trạng thái trước–sau, không chỉ mô tả bằng cảm giác. Nếu thao tác có liên quan tệp nguồn, phải ghi phiên bản; nếu liên quan một đối tượng, phải ghi tên/đường dẫn trong Scene graph; nếu liên quan nhập dữ liệu, phải ghi tùy chọn đã dùng.

Sai lầm dễ gặp: Refresh toàn bộ ảnh thu nhỏ ngay, vô tình ghi đè trạng thái media tốt bằng cảnh đang lỗi. Cách sửa tốt nhất là quay lại cổng kiểm gần nhất, thu hẹp phạm vi thử và lặp lại đúng phép kiểm ban đầu. Không nên bù một lỗi nguồn bằng thêm hiệu ứng hoặc thêm biến đổi ở bước sau vì làm chuỗi công việc khó truy nguyên.

8. Ghi thời điểm và người thực hiện

Trong nhóm, câu “em vừa đồng bộ rồi” không đủ. Cần phiên bản nguồn, thời điểm, người đồng bộ và kết quả.

Cách kiểm chứng: Dùng nhật ký một dòng: `R05 | 14:20 | Hùng | đổi mái + cửa | sync PASS | 2 media cần cập nhật`. Kết quả phải được ghi thành trạng thái trước–sau, không chỉ mô tả bằng cảm giác. Nếu thao tác có liên quan tệp nguồn, phải ghi phiên bản; nếu liên quan một đối tượng, phải ghi tên/đường dẫn trong Scene graph; nếu liên quan nhập dữ liệu, phải ghi tùy chọn đã dùng.

Sai lầm dễ gặp: Hai người đồng bộ hai nguồn khác nhau và không ai biết cảnh hiện theo bản nào. Cách sửa tốt nhất là quay lại cổng kiểm gần nhất, thu hẹp phạm vi thử và lặp lại đúng phép kiểm ban đầu. Không nên bù một lỗi nguồn bằng thêm hiệu ứng hoặc thêm biến đổi ở bước sau vì làm chuỗi công việc khó truy nguyên.

Quy trình thao tác đề nghị

1. Chốt đầu vào: ghi tên tệp nguồn, phiên bản, phiên bản phần mềm và mục tiêu của bài trước khi mở/đổi dữ liệu.
2. Tạo trạng thái gốc: lưu trạng thái tệp dự án hoặc ảnh kiểm trước thay đổi. Với nội dung nhập dữ liệu/đồng bộ, ghi chế độ nhập và nguồn đang liên kết.
3. Thực hiện một thay đổi nhỏ có chủ đích: không thử bằng 20 thay đổi cùng lúc. Một thay đổi nhỏ giúp phát hiện quan hệ nhân–quả.
4. Kiểm trong Scene graph và Viewport: xác nhận đúng đối tượng, đúng đối tượng cha/nhóm chứa, đúng vị trí và trạng thái hiển thị.
5. Kiểm số liệu/hình học nếu có: dùng mốc kích thước, hướng hoặc biến đổi đã biết thay vì nhìn bằng mắt.
6. Kiểm giá trị ghi đè và trạng thái trình bày: vật liệu, cây/người/xe, đèn và media quan trọng phải được xem lại sau thay đổi nguồn lớn.
7. Ghi nhật ký: Đạt/Không đạt, nguyên nhân, cách sửa và phiên bản đầu ra.
8. Chỉ chuyển bước khi cổng kiểm đạt: nếu không đạt, quay về nguồn hoặc cấu hình gần nhất thay vì tiếp tục trang trí để che lỗi.

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

Tình huống giả lập phục vụ giảng dạy. Mô hình căn hộ thay đổi vách phòng ngủ và vị trí cửa. Nhóm lưu `TM_R04_before_sync`, chụp ba góc kiểm tra chất lượng, ghi change set, rồi Synchronize thủ công. Sau đồng bộ, nhóm kiểm đúng hai thay đổi hình học trước; sau đó mới kiểm vật liệu gỗ, rèm và góc nhìn đã dựng. Một ảnh bị cửa mới che góc nhìn nên được bố trí lại, nhưng các ảnh còn lại giữ nguyên.

Yêu cầu của tình huống không phải tạo hình ảnh đẹp nhất. Nhóm phải chứng minh được vì sao lựa chọn của mình phù hợp với vòng đời dữ liệu. Nếu có hai cách đều chạy được, ưu tiên cách dễ kiểm, dễ bàn giao và ít phụ thuộc vào trí nhớ cá nhân.

Ma trận quyết định nhanh

Những lỗi thường gặp và cách xử lý

Khi gặp lỗi không có trong bảng, không đoán menu. Hãy thu hẹp tệp thử, ghi phiên bản Twinmotion/SketchUp, chụp trạng thái Import dock/Scene graph và đối chiếu Documentation hoặc Release Notes hiện hành. Nếu nghi lỗi phần mềm, cần phân biệt rõ lỗi đã biết với lỗi cấu trúc dữ liệu của chính tệp dự án.

Bài thực hành trên lớp

1. Vòng 1 – tái hiện chuẩn: giảng viên cung cấp một mô hình nhỏ. Nhóm thực hiện đúng quy trình của bài và tạo trạng thái gốc có nhật ký.
2. Vòng 2 – gây lỗi có kiểm soát: một thành viên thay đổi một điều kiện thuộc nội dung bài (nguồn, cấu trúc phân cấp, trạng thái hiển thị, biến đổi hoặc tên). Thành viên khác chỉ được chẩn đoán từ bằng chứng.
3. Vòng 3 – yêu cầu thay đổi: thay một yêu cầu trình bày BĐS. Nhóm xác định bước nào cần làm lại, bước nào được giữ và vì sao.
4. Vòng 4 – bàn giao chéo: nhóm khác mở tệp + tệp hướng dẫn và phải tìm được nguồn, trạng thái chính, đối tượng cần chỉnh trong tối đa 5 phút.

Bài thực hành cá nhân

Chọn một mô hình BĐS nhỏ hoặc mô hình do giảng viên cung cấp. Áp dụng riêng nội dung Bài 12, tạo ít nhất hai trạng thái có thể so sánh và một nhật ký kiểm chứng. Không chấm điểm theo mức “lung linh”; chấm theo khả năng giải thích, tái lập, giữ đúng nguồn và không làm người xem hiểu sai quy mô/trạng thái phương án.

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

• 01 tệp/tệp dự án làm việc đúng phạm vi bài, không chứa tài nguyên thử không giải thích được.
• 01 ảnh tổng quan trạng thái cuối và ít nhất 03 ảnh/bằng chứng cho các cổng kiểm chính.
• 01 bảng nhật ký ngắn: nguồn – phiên bản – thao tác – kết quả – Đạt/Không đạt – cách sửa.
• 01 đoạn 200–300 chữ giải thích một quyết định kỹ thuật quan trọng và một rủi ro nếu quyết định sai.
• Nếu bài liên quan Direct Link/nhập dữ liệu: ghi phiên bản SketchUp Pro, Twinmotion, Datasmith Exporter và chế độ nhập.
• Nếu bài liên quan Scene graph: nộp ảnh cây cấu trúc hoặc sơ đồ nhóm chứa/tên trước–sau.

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

• ☐ Tôi có thể nói mục tiêu bài bằng một câu rõ ràng.
• ☐ Tôi biết tệp/phiên bản nào là nguồn hiện tại.
• ☐ Tôi không bịa tên menu hoặc chức năng không có trên phiên bản đang dùng.
• ☐ Tôi có ít nhất một bằng chứng trước–sau thay vì chỉ nói “đã đúng”.
• ☐ Tôi phân biệt được lỗi nguồn thiết kế với việc bố trí/trình bày trong Twinmotion.
• ☐ Tôi biết đối tượng/nhóm chứa nào đang được tác động trước khi biến đổi/ẩn/reset.
• ☐ Tôi đã kiểm một tình huống sai có chủ đích và biết cách quay lại trạng thái gốc.
• ☐ Tôi đã ghi chế độ nhập hoặc cấu trúc cấu trúc phân cấp nếu điều đó ảnh hưởng kết quả.
• ☐ Tôi đã kiểm media/trạng thái hiển thị quan trọng sau thay đổi lớn.
• ☐ Người khác có thể tiếp tục công việc từ nhật ký và tệp hướng dẫn mà không cần hỏi tác giả.

Câu hỏi phản biện

1. Nếu nguồn thay đổi thêm một lần nữa, phần nào của công việc hôm nay còn dùng được và phần nào phải kiểm lại?
2. Quyết định hiện tại tối ưu cho một ảnh duy nhất hay cho vòng đời tệp dự án nhiều phiên bản?
3. Bằng chứng nào phân biệt lỗi do phần mềm với lỗi do mô hình nguồn?
4. Nếu giao tệp cho người khác, họ có biết đối tượng nào được phép sửa và đối tượng nào phải quay lại SketchUp?
5. Nếu bỏ một nửa số thao tác, bước nào có thể bỏ mà vẫn giữ được khả năng kiểm chứng?
6. Có điểm nào trong cảnh có thể khiến khách hàng hiểu sai tỷ lệ, trạng thái hoàn thiện hoặc mức chắc chắn của phương án không?

Giá trị nghề nghiệp trong công việc BĐS

Bài 12 tập trung vào khả năng duy trì tính nhất quán khi mô hình thiết kế và cảnh trực quan hóa thay đổi. Trong dự án BĐS, phương án hiếm khi cố định từ đầu đến cuối. Người làm tốt không chỉ biết kéo tài nguyên hoặc kết xuất; họ biết giữ nguồn, phiên bản, cấu trúc và bằng chứng để một thay đổi nhỏ không làm hỏng hàng giờ công việc các bước phía sau.

Kỹ năng này cũng giúp phối hợp giữa người dựng SketchUp, người trực quan hóa Twinmotion và người dùng sản phẩm truyền thông. Khi ranh giới vai trò rõ, lỗi được gửi về đúng nơi: lỗi thiết kế sửa ở nguồn; tổ chức cảnh và bối cảnh xử lý ở Twinmotion; quyết định pháp lý/kỹ thuật chuyên ngành không được suy ra từ hình ảnh trực quan hóa.

Ghi nhớ trong 30 giây

• Đồng bộ theo change set, không theo cảm giác.
• Giữ trạng thái gốc trước cập nhật.
• Kiểm hình học trước mỹ thuật.
• Theo dõi cấu trúc phân cấp khi nguồn được tái cấu trúc.
• Twinmotion các giá trị ghi đè phải được coi là dữ liệu.

Nguồn tham khảo

Ưu tiên tài liệu chính thức của Epic để xác nhận hành vi phần mềm, tùy chọn import, đồng bộ và quản lý cảnh. Release Notes được dùng để nhận diện giới hạn hoặc thay đổi theo phiên bản; không dùng lỗi của một phiên bản cũ để mặc định rằng mọi phiên bản đều có cùng lỗi.

Bài tiếp theo

Bài 13: Reimport: những thay đổi nào được giữ và những gì có thể bị thay thế?. Bài hiện tại phải được hoàn tất với tệp, bằng chứng và phiếu tự kiểm trước khi chuyển bước; mục tiêu là giữ mạch học tích lũy thay vì học rời từng nút.

Thực hành kiểm chứng

Bài kiểm 1: Đồng bộ theo change set, không theo cảm giác

Nhiệm vụ: tạo một bản sao tệp dự án thử và chứng minh hoặc bác bỏ nhận định sau bằng thao tác thực tế: Mỗi vòng đồng bộ nên có danh sách ngắn: thêm gì, xóa gì, di chuyển gì, đổi vật liệu nguồn nào. Điều này biến một thao tác kỹ thuật thành phép kiểm có nguyên nhân – kết quả.

Bằng chứng yêu cầu: Tạo bảng Before/Change/Expected/Actual cho 3–5 thay đổi. Ngoài ảnh chụp, phải có một dòng nhật ký nêu phiên bản, nguồn, đối tượng hoặc nhóm chứa liên quan và kết luận ĐẠT/KHÔNG ĐẠT/KHÔNG ÁP DỤNG. Nếu Không áp dụng, giải thích vì sao phép kiểm không áp dụng.

Tình huống gây lỗi: cố ý tái hiện sai lầm “Sửa hàng chục chi tiết rồi nhấn Synchronize, sau đó phát hiện một lỗi nhưng không biết do bước nào.”. Sau đó quay về trạng thái gốc và sửa theo quy trình. Mục đích là học cơ chế chứ không chỉ nhớ chuỗi bấm.

Bài kiểm 2: Giữ trạng thái gốc trước cập nhật

Nhiệm vụ: tạo một bản sao tệp dự án thử và chứng minh hoặc bác bỏ nhận định sau bằng thao tác thực tế: Một cảnh đã có cây, người, đèn, vật liệu và góc nhìn có giá trị công việc lớn hơn tệp mô hình trống. Trước thay đổi quan trọng cần mốc để so sánh.

Bằng chứng yêu cầu: Save As hoặc snapshot phiên bản `.tm`; lưu 2–3 ảnh góc nhìn kiểm cố định. Ngoài ảnh chụp, phải có một dòng nhật ký nêu phiên bản, nguồn, đối tượng hoặc nhóm chứa liên quan và kết luận ĐẠT/KHÔNG ĐẠT/KHÔNG ÁP DỤNG. Nếu Không áp dụng, giải thích vì sao phép kiểm không áp dụng.

Tình huống gây lỗi: cố ý tái hiện sai lầm “Chỉ dựa vào Undo trong một tệp dự án dài, trong khi thay đổi có thể xuất hiện sau nhiều thao tác.”. Sau đó quay về trạng thái gốc và sửa theo quy trình. Mục đích là học cơ chế chứ không chỉ nhớ chuỗi bấm.

Bài kiểm 3: Kiểm hình học trước mỹ thuật

Nhiệm vụ: tạo một bản sao tệp dự án thử và chứng minh hoặc bác bỏ nhận định sau bằng thao tác thực tế: Sau đồng bộ, ưu tiên kiểm đúng/sai hình học, vị trí, số tầng, lỗ mở và kích thước; chưa vội chỉnh màu hay ánh sáng.

Bằng chứng yêu cầu: Dùng 3 góc nhìn kiểm tra chất lượng cố định và một mốc kích thước đã biết từ SketchUp. Ngoài ảnh chụp, phải có một dòng nhật ký nêu phiên bản, nguồn, đối tượng hoặc nhóm chứa liên quan và kết luận ĐẠT/KHÔNG ĐẠT/KHÔNG ÁP DỤNG. Nếu Không áp dụng, giải thích vì sao phép kiểm không áp dụng.

Tình huống gây lỗi: cố ý tái hiện sai lầm “Thấy ảnh “vẫn đẹp” nên bỏ qua việc một cửa đã lệch hoặc một khối bị nhân đôi.”. Sau đó quay về trạng thái gốc và sửa theo quy trình. Mục đích là học cơ chế chứ không chỉ nhớ chuỗi bấm.

Bài kiểm 4: Theo dõi cấu trúc phân cấp khi nguồn được tái cấu trúc

Nhiệm vụ: tạo một bản sao tệp dự án thử và chứng minh hoặc bác bỏ nhận định sau bằng thao tác thực tế: Đổi Group/Component, explode/nest hoặc đổi cấu trúc nguồn có thể ảnh hưởng danh tính đối tượng các bước phía sau.

Bằng chứng yêu cầu: Nếu thay cấu trúc phân cấp, tách thành một change set riêng và kiểm Scene graph trước/sau. Ngoài ảnh chụp, phải có một dòng nhật ký nêu phiên bản, nguồn, đối tượng hoặc nhóm chứa liên quan và kết luận ĐẠT/KHÔNG ĐẠT/KHÔNG ÁP DỤNG. Nếu Không áp dụng, giải thích vì sao phép kiểm không áp dụng.

Tình huống gây lỗi: cố ý tái hiện sai lầm “Vừa đổi cấu trúc phân cấp vừa đổi vật liệu và vị trí, làm mất khả năng truy nguyên.”. Sau đó quay về trạng thái gốc và sửa theo quy trình. Mục đích là học cơ chế chứ không chỉ nhớ chuỗi bấm.

Bài kiểm 5: Twinmotion các giá trị ghi đè phải được coi là dữ liệu

Nhiệm vụ: tạo một bản sao tệp dự án thử và chứng minh hoặc bác bỏ nhận định sau bằng thao tác thực tế: Vật liệu thay trong Twinmotion, biến đổi, thuộc tính đối tượng là những giá trị ghi đè có thể quan trọng như hình học.

Bằng chứng yêu cầu: Lập “giá trị ghi đè register”: đối tượng nào đã thay vật liệu/biến đổi và vì sao. Ngoài ảnh chụp, phải có một dòng nhật ký nêu phiên bản, nguồn, đối tượng hoặc nhóm chứa liên quan và kết luận ĐẠT/KHÔNG ĐẠT/KHÔNG ÁP DỤNG. Nếu Không áp dụng, giải thích vì sao phép kiểm không áp dụng.

Tình huống gây lỗi: cố ý tái hiện sai lầm “Không ghi gì, đến lần đồng bộ sau mới phát hiện vật liệu thay nhưng không biết đó là lỗi phần mềm hay thay đổi nguồn.”. Sau đó quay về trạng thái gốc và sửa theo quy trình. Mục đích là học cơ chế chứ không chỉ nhớ chuỗi bấm.

Bài kiểm 6: Auto Sync phù hợp vòng thử nhanh, không thay cổng phát hành

Nhiệm vụ: tạo một bản sao tệp dự án thử và chứng minh hoặc bác bỏ nhận định sau bằng thao tác thực tế: Auto Sync có lợi khi thiết kế thay đổi liên tục và người dùng đang theo dõi trực tiếp; trước ảnh/đoạn phim phát hành vẫn cần đóng băng phiên bản và kiểm tra chất lượng.

Bằng chứng yêu cầu: Quy định trạng thái DRAFT_AUTO và RELEASE_MANUAL trong nhóm. Ngoài ảnh chụp, phải có một dòng nhật ký nêu phiên bản, nguồn, đối tượng hoặc nhóm chứa liên quan và kết luận ĐẠT/KHÔNG ĐẠT/KHÔNG ÁP DỤNG. Nếu Không áp dụng, giải thích vì sao phép kiểm không áp dụng.

Tình huống gây lỗi: cố ý tái hiện sai lầm “Xuất media giữa lúc Auto Sync đang nhận thay đổi từ người khác.”. Sau đó quay về trạng thái gốc và sửa theo quy trình. Mục đích là học cơ chế chứ không chỉ nhớ chuỗi bấm.

Bài kiểm 7: Đồng bộ xong phải cập nhật media có chọn lọc

Nhiệm vụ: tạo một bản sao tệp dự án thử và chứng minh hoặc bác bỏ nhận định sau bằng thao tác thực tế: Camera/media không tự trở thành “đúng” chỉ vì mô hình đã đồng bộ. Góc nhìn có thể bị che, lộ khoảng trống hoặc thay bố cục.

Bằng chứng yêu cầu: Duyệt danh sách ảnh/ảnh toàn cảnh quan trọng sau mỗi đồng bộ lớn; chỉ làm mới media sau khi cảnh đạt kiểm tra chất lượng. Ngoài ảnh chụp, phải có một dòng nhật ký nêu phiên bản, nguồn, đối tượng hoặc nhóm chứa liên quan và kết luận ĐẠT/KHÔNG ĐẠT/KHÔNG ÁP DỤNG. Nếu Không áp dụng, giải thích vì sao phép kiểm không áp dụng.

Tình huống gây lỗi: cố ý tái hiện sai lầm “Refresh toàn bộ ảnh thu nhỏ ngay, vô tình ghi đè trạng thái media tốt bằng cảnh đang lỗi.”. Sau đó quay về trạng thái gốc và sửa theo quy trình. Mục đích là học cơ chế chứ không chỉ nhớ chuỗi bấm.

Bài kiểm 8: Ghi thời điểm và người thực hiện

Nhiệm vụ: tạo một bản sao tệp dự án thử và chứng minh hoặc bác bỏ nhận định sau bằng thao tác thực tế: Trong nhóm, câu “em vừa đồng bộ rồi” không đủ. Cần phiên bản nguồn, thời điểm, người đồng bộ và kết quả.

Bằng chứng yêu cầu: Dùng nhật ký một dòng: `R05 | 14:20 | Hùng | đổi mái + cửa | sync PASS | 2 media cần cập nhật`. Ngoài ảnh chụp, phải có một dòng nhật ký nêu phiên bản, nguồn, đối tượng hoặc nhóm chứa liên quan và kết luận ĐẠT/KHÔNG ĐẠT/KHÔNG ÁP DỤNG. Nếu Không áp dụng, giải thích vì sao phép kiểm không áp dụng.

Tình huống gây lỗi: cố ý tái hiện sai lầm “Hai người đồng bộ hai nguồn khác nhau và không ai biết cảnh hiện theo bản nào.”. Sau đó quay về trạng thái gốc và sửa theo quy trình. Mục đích là học cơ chế chứ không chỉ nhớ chuỗi bấm.

Bảng kiểm bàn giao nhanh cho đồng đội