Back to blog

How to Check a Folder of 3D Files Before Delivering It to a Client

Delivery is the moment when mistakes cost the most. A file that will not open on the client's machine, a part at the wrong scale, an earlier version slipped into the batch: those mean round trips, delay, and sometimes trust.

Here is a systematic check of a folder of 3D models before you send it, and above all what it does not cover.

What breaks a delivery

In practice, incidents almost always fall into five causes:

The six-point checklist

  1. Every file opens. Browse the folder in thumbnails: an unreadable file shows no model. It is the fastest check there is and it removes corrupted files immediately.
  2. Scales are consistent. Switch to list view and sort by bounding box dimensions. A part at the wrong scale jumps out: it sits alone at the top or the bottom of the column.
  3. Density is appropriate. Sort by triangle count. A model ten times heavier than its neighbours deserves a question at the very least, and often a decimation.
  4. It is the right version. Open the old and the new one in side-by-side comparison, with synced cameras, to see what actually changed rather than trusting a file name.
  5. Textures come along. A model that renders grey when it should be textured almost always signals texture files missing from the batch, not a problem with the model.
  6. The folder holds only the deliverable. The file type filter quickly reveals the strays: a working export, a backup, a format nobody asked for.

Spotting the odd one out in a list

The principle shared by points 2, 3 and 6 deserves to be stated on its own, because it beats a file-by-file inspection: you are not looking for what is correct, you are looking for what sticks out. Sorting a column puts the extreme values at both ends. The anomaly announces itself, without you having to know in advance what you are looking for.

On a batch of thirty parts, that turns a twenty-minute review into a two-minute check.

Documenting the delivery

Once the batch is approved, mark it. A status tag on the checked files, a note on the part that needed a judgement call, a rating on what is actually shipping. Because that information is stored beside the files and never inside them, the deliverables stay byte for byte identical to what you send. See tagging and rating without modifying the files.

The day the client comes back three months later, your trail is there.

What this check does not replace

Better be clear about the limits, because they matter:

This checklist catches handling errors, which are the most frequent and the most avoidable. It does not replace a technical review.

FAQ

How long for a batch of fifty files?

A few minutes, most of it spent on points 4 and 5, the only ones that call for judgement. Points 1, 2, 3 and 6 are column sorts.

How do I detect a wrong scale with no reference?

The internal consistency of the batch is your reference: in a set of parts meant for the same assembly, the one outside the others' order of magnitude is suspect. Careful though, STL carries no unit information, so the value shown is a number, not a measurement.

What if the client works on Windows?

Focus on point 6 and on the presence of textures. Finder tags will not make the trip, which is one more reason not to rely on them to carry information.

Should I deliver in several formats?

Ask the recipient instead. If an extra format is needed, conversion to USDZ, OBJ, STL, GLB and glTF is one click away from the same folder.

And if I am receiving a batch rather than sending one?

The same checklist applies on the way in, and that is where it pays off most: you catch the problem before you have started working on it.

All articles