납품은 실수의 대가가 가장 큰 순간입니다. 고객 쪽에서 열리지 않는 파일, 축척이 어긋난 부품, 묶음에 섞여 들어간 이전 버전. 모두 왕복과 지연을 부르고, 때로는 신뢰까지 건드립니다.
3D 모델 폴더를 보내기 전에 하는 체계적인 점검, 그리고 무엇보다 그것이 보장하지 않는 것을 정리합니다.
실제로 사고는 거의 항상 다섯 가지 원인으로 나뉩니다.
2번, 3번, 6번에 공통된 원리는 따로 말해 둘 만합니다. 파일을 하나씩 점검하는 것보다 낫기 때문입니다. 맞는 것을 찾는 게 아니라 튀는 것을 찾는다. 열로 정렬하면 극단값이 양 끝에 모입니다. 무엇을 찾아야 할지 미리 몰라도 이상한 쪽이 스스로 드러납니다.
부품 서른 개짜리 묶음이라면 이십 분짜리 검토가 이 분짜리 점검이 됩니다.
묶음을 확정했으면 표시해 둡니다. 확인한 파일에 상태 태그, 판단이 필요했던 부품에 메모, 실제로 나가는 것에 별점. 이 정보는 파일 옆에 저장되고 안에는 기록되지 않기 때문에 납품물은 보내는 것과 바이트 단위로 동일하게 유지됩니다. 파일을 바꾸지 않고 태그와 별점 매기기를 보세요.
석 달 뒤 고객이 다시 연락해 올 때, 기록은 그대로 남아 있습니다.
한계는 분명히 해 두는 편이 낫습니다.
이 목록이 잡아내는 것은 취급상의 실수입니다. 가장 흔하고 가장 피하기 쉬운 종류이지만, 기술 검토를 대신하지는 않습니다.
몇 분입니다. 대부분은 판단이 필요한 4번과 5번에 쓰입니다. 1번, 2번, 3번, 6번은 열 정렬로 끝납니다.
묶음 내부의 일관성이 기준입니다. 같은 조립에 쓰일 부품들 가운데 자릿수가 다른 것은 의심할 만합니다. 다만 STL에는 단위 정보가 없으므로 표시되는 값은 숫자일 뿐 치수가 아닙니다.
6번과 텍스처 유무를 특히 확인하세요. Finder 태그는 함께 넘어가지 않으며, 정보 전달을 거기에 기대지 말아야 할 이유가 하나 더 생깁니다.
수신자에게 먼저 물어보세요. 추가 형식이 필요하다면 같은 폴더에서 USDZ, OBJ, STL, GLB, glTF로 한 번에 변환할 수 있습니다.
같은 목록이 입고 시에도 적용되며, 오히려 그때 가장 값어치를 합니다. 작업을 시작하기 전에 문제를 잡아낼 수 있기 때문입니다.