How Tos, Scanning Technologies, Training Data

How to Scale Human 3D Scanning Operations (Without Torching Quality or Your Schedule)

Scale human 3D scanning operations without losing quality. Standardize capture, plan throughput, streamline processing, and set clear QA and delivery specs.

The scaling problem: going from “a few scans” to “a program”

Two questions come up in almost every serious conversation:

How do you scale from a few scans to thousands?
What are the bottlenecks in large dataset capture?

Here’s the opinionated answer: scaling is mostly about standardization and throughput management. The capture rig matters, but the bottlenecks usually aren’t the cameras—they’re people, process, and post.

A “few scans” project can survive on hero-level attention. A “program” needs:

Repeatable capture conditions (lighting, distance, poses, wardrobe rules)
A defined deliverables menu (raw vs cleaned vs retopologized vs rigged)
File naming, metadata, and versioning that won’t collapse at 500+ assets
A QA definition that is measurable (not “looks good to me”)

Concrete example: if one team expects OBJ + 16k PBR textures and another expects FBX + rig + LODs, you don’t have one service—you have two pipelines. That’s fine, but only if you acknowledge it before the first scan day.

Volume doesn’t break your rig first. It breaks your assumptions—especially “we’ll fix it in post.

Ivo Yovchev - CEO, Digital Reality Lab

What “human 3D scanning at scale” actually includes (capture + processing)

People use “3D scanning” as shorthand, but buyers usually want one of three outcomes:

Production-ready digital doubles (film/TV/VFX, games, VR/AR)
Dataset-ready assets (AI/ML research, synthetic data pipelines, academic projects)
Operational scanning (repeatable capture of many subjects with consistent deliverables)

At Digital Reality Lab, our offering is end-to-end: capture plus scan processing (cleanup, decimation, retopology, rigging, and photoreal texturing). The difference between “we scanned them” and “you can ship this” is nearly always processing.

Typical processing stages (you should name these in your statement of work):

Cleanup (remove noise/artifacts, fill holes)
Decimation / LOD prep (when assets must run in real time)
Retopology (animation-friendly topology)
Rigging (if required)
PBR texture set output (we reference textures up to 16k+ where needed)
Export to production formats (commonly OBJ/FBX/GLTF)

Constraint/tradeoff: pushing for maximum fidelity (very high-res geometry and 16k textures) raises compute time, review time, and file transfer overhead. For real-time projects, you often want strong source scans, then controlled reduction into LOD tiers.

If your team hasn’t decided whether the “source of truth” is the raw scan or the retopo mesh, decide now. It changes how you version assets and how you handle revisions.

Bottlenecks you’ll hit when you scale (and how to design around them)

Scaling failures are rarely mysterious. They’re the same four bottlenecks, repeated.

1) Casting and scheduling (the human bottleneck)

If you’re capturing actors or a diverse subject pool, you’re operating a logistics engine. You need dependable casting coordination and release/licensing handling.

Concrete example: a dataset program might need demographic coverage (age bands, body types, wardrobe constraints). If the casting brief changes midstream, you’ll create gaps you can’t “compute” your way out of.

Placeholder you should define:

How casting is coordinated globally?
What consent and licensing do you need for the model release?
What are they key selection criterias for the casting?
What is the appoval process?
How long will it take you to cast, review, approve and schedule a capture date for one person?

2) Capture throughput and consistency

The highest-volume teams win on boring discipline:

MOST IMPORTANT: Requirments for the actors that cannot be changed on site (or will take time) – Makeup, facial/body hair, manicure & pedicure.
Pose list locked early (neutral A-pose/T-pose + any required variants)
Wardrobe rules defined (e.g., avoid reflective fabrics, complex patterns)
Lighting and camera settings standardized

Tradeoff: adding “just one more pose” or “we’ll also do facial expressions” can multiply post-processing time and review complexity. It’s not linear.

3) Post-processing capacity (the quiet killer)

Even if you can scan many subjects per day, processing may be the limiting factor—especially if you promise retopology, rigging, or multiple LODs.

What to operationalize:

A queue with defined service levels per deliverable type
Clear “raw vs cleaned vs production-ready” definitions
Review checkpoints (internal QA before client review)

Typical turnaround ranges from the deliverable tier, but to give you an idea of our daily capactiy at the moments is as follows:

RAW: 400 Full-body Scans
Cleaned: 40 Full-body Scans
Retopo: 20 Full-body Scans
Rigged: 2-5 Full-body Scans

4) Data handling, transfer, and security

High-res scans are heavy. If you’re delivering 16k texture sets and multiple formats, you need a transfer plan.

We often get asked about secure transfer and storage and we have created a few robust options for data delivery:

Easiest – AWS S3 Bucket with security protocols for restricted access.
Most Reliable – Our own HSR API service allowing instant and uninterupted access to the data. It is build on Google Storage for redundancy and security with extra api calls for data search, filter and retreaval, that can me added to any pipeline.
Alternative – Clients specific platform, where we can integrate data transfer from our internal secure storage to the clients platform.

If your data transfer plan is “we’ll send a link,” you don’t have a plan. You have a future fire.

Ivo Yovchev - CEO, Digital Reality Lab

Scale human 3D scanning operations with a repeatable capture + delivery process

Here’s the process we recommend you insist on—whether you run scanning internally or hire a partner.

Step 1: Pre-production (where scaling is decided)

Pre-production is where you prevent rework. Lock these items:

Deliverables list: what files, what texture maps, what resolution
Format expectations: OBJ/FBX/GLTF as needed
Naming conventions and versioning rules
Metadata requirements (pose, capture conditions, licensing tags)

Example: For games/real-time, ask for a defined LOD package (e.g., LOD0/LOD1/LOD2) and agreed decimation targets. Also, a lot of game studios process that data internally, to their propriotary specifications, so discuss with them if you even need to process the data.

To make your process bulletproof you can read more in the following pages:

Our services overview is here: 3D Scanning Services.
If you need high-volume support, see our broader Solutions.
For more on metadata and standardization, see Beyond Geometry.
For a deeper look at our human scanning capabilities, see High-Resolution Human 3D Scanning.

Step 2: Capture day (full-body + head/facial, plus metadata)

At scale, you want capture to be predictable.

Full-body capture in standardized pose(s)
Head scanning and facial capture when needed
Capture notes recorded (wardrobe exceptions, hair issues, any occlusions)
While scanning keep a log for each capture what pose/expression it is to help with the processing later.

Tradeoff: facial capture outputs are valuable, but they add complexity—especially if clients need compatibility with an existing animation rig. If you can’t guarantee rig compatibility, define the handoff boundary.

Step 3: Processing pipeline (turn scans into usable assets)

Processing is where you pay for your promises.

Cleanup
Optional decimation / LOD generation
Retopology for deformation
Texture map generation (PBR workflow)
Optional rigging

Digital Reality Lab supports photoreal texturing with PBR textures up to 16k+ for every capture we do.

You can’t “QA in” topology later. If retopo is part of the deliverable, plan it as a real production step, not a checkbox.

Ivo Yovchev - CEO, Digital Reality Lab

Step 4: QA + delivery (prevent downstream pipeline breaks)

QA should be defined in practical terms:

No holes/tears where not intended
Texture alignment consistent (no obvious seams unless expected)
Correct scale and orientation
File opens cleanly in agreed tools
Real-world scale and orientation
Centered in the world coordinates.

Delivery package should include:

Model files in agreed format(s): OBJ/FBX/GLTF
Texture maps (PBR set)
A simple README (what’s included, units/scale, map descriptions)
Metadata files with details about person, pose, clothing, action and anything relevant to the project.
Licensing info (at minimum, reference terms and allowed usage) and model releases

Our QA checklist is split into two stages:

Stage 1 – Automated QA review based on automated renders in pre-defined controlled relistic environment. That cathes 95% of any issues present with processing or file organisation. This is based on custom ML model trained with thousands scans of our own data for maximum quality control.
Stage 2 – Human review to make sure that there was nothing missed on Stage 1 and in cases where we find a miss, we use the case as training data for our Automated QA.

This process guarantees that every scan that comes our of us is flawless.

Technical specs that matter when you’re buying (or building) at scale

If you’re scaling a scanning program, specs are not trivia—they’re how you avoid pipeline mismatch.

Geometry: polygon counts, LODs, and retopology expectations

The evidence pack does not provide standard polygon counts or file sizes, so we won’t invent them. Use placeholders in your spec sheet until you can publish real targets:

Raw scan density: 5 million polygons
LOD0 target: 1 million polygons
LOD1 targets: 100k polygons
LOD2 targets: 10k polygons

Tradeoff: higher density helps with film-quality closeups and future-proofing, but it costs in storage, transfer, and review time. Many teams do best with a high-fidelity source plus controlled LOD exports.

Textures: what “16k+ PBR” implies in practice

We reference 16k+ PBR textures as a quality option. The operational question is: do you need it for every subject?

Example: For a hero digital double, 16k textures can be justified. For a 1,000-subject training dataset, you might prefer a consistent, lower resolution to speed processing and standardize inputs—unless your model training demands max detail.

Minimum you should specify:

Map set required (e.g., albedo/base color, normal, roughness; others as needed)
UV layouts – single UV vs UDIMs
Displacement – If needed, 32 bit displacement gives the best result, but its also time/resource consuming.
File formats – TIFF/EXR/PNG the file format matters as due to compressions we might lose some detail, however very case specific and map specific. Many cases even a JPEG would not make a difference from PNG.

Formats: pick the handoff formats early

The evidence pack lists common formats: OBJ/FBX/GLTF.

Constraint: every additional format increases export/testing overhead. If you want two formats, say why (e.g., FBX for animation, GLTF for review in a web viewer).

Metadata: the difference between “assets” and “a usable dataset”

Concrete example fields you may need:

Pose identifier
Capture conditions (lighting notes, any deviations)
Subject descriptors appropriate to your project. Read more about our approrch in our Metadata Guide
Licensing tags (academic/commercial scope, expiry if applicable)

For a common real-time delivery format, see the Khronos glTF overview: https://www.khronos.org/gltf/

A dataset without metadata is just a folder of meshes. It might look impressive. It won’t train well.

Ivo Yovchev - CEO, Digital Reality Lab

When to scan, when to license from a library, and how to think about rights

At scale, you have two common paths:

Commission custom scanning (you control the brief, the deliverables, and the subject requirements)
License existing scans/datasets (you trade some specificity for speed and predictable scope)

Digital Reality Lab offers both: custom scanning services and a 3D human model library/datasets approach (with public mention of 25,000+ scans).

Internal links you should use when evaluating:

Library/datasets: 3D Human Models for Academic Research
Service capture: 3D Scanning Services

Ready to Plan With Experts?

We’ve built production-grade datasets for AI, gaming, digital fashion, and more—scanning thousands of humans with precision and care.

Whether you’re prototyping a research model or deploying at enterprise scale, we help you plan and execute every step of your 3D dataset pipeline.

We bring deep expertise and precision to the art of capturing real people in digital form. Whether you're creating lifelike characters for games and films, or training AI with high-fidelity human datasets, we guide you through every step—from casting and scanning to metadata structuring and delivery.

Our mission is to help you build better products and smarter models by turning physical humans into richly detailed digital assets—ready for any pipeline.

View All Posts

About Us

At Digital Reality Lab, we bring deep expertise and precision to the art of capturing real people in digital form. Whether you’re creating lifelike characters for games and films, or training AI with high-fidelity human datasets, we guide you through every step—from casting and scanning to metadata structuring and delivery.

Our mission is to help you build better products and smarter models by turning physical humans into richly detailed digital assets—ready for any pipeline.

How to Scale Human 3D Scanning Operations (Without Torching Quality or Your Schedule)

The scaling problem: going from “a few scans” to “a program”

What “human 3D scanning at scale” actually includes (capture + processing)

Bottlenecks you’ll hit when you scale (and how to design around them)