Known limitations
What NameFrame does not do, cannot currently prove, or does differently from what its name suggests. Collected in one place so you can find the wall before you walk into it.
Synthetic data, in general#
- The domain gap is real and unsolved. A render is not a photograph. Sensor noise, lens behaviour, material response and the irregularity of the world are approximated. How much that costs depends on your task, and the only way to know is to train on synthetic and evaluate on real.
- Your scene is your ceiling. A model trained on one map learns that map. Variety in output requires variety in input, and authoring that is real work.
- Consistent labels are unusual labels. Real datasets contain annotator noise and models trained on them learn to tolerate it. Labels this consistent are a different distribution, and occasionally that matters. Consistent is not flawless: see the cross-painting false negatives below.
Capture#
- Re-rendering is not bit-reproducible across machines. Decisions, metadata and everything derived from a dump are reproducible. The pixels are reproducible on the same machine and engine build. GPUs and drivers are not deterministic across hardware, and no configuration changes that.
- Unreal Engine 5.8 is the verified tier. Other versions are not supported merely because the source might compile.
- Depth is expensive. Roughly 8 MB per 1080p frame. Long runs commonly disable it, and that is a decision to make before the run rather than at frame four thousand.
Placement#
- NavMesh placement is projection-based. Sampled positions are projected onto navigation. It is not uniform sampling over navmesh polygon area.
- Poisson spatial placement is deterministic bounded sampling, not a maximal Bridson implementation.
- Footprint spacing uses conservative bounds, not oriented-polygon packing. It errs towards refusing a legal placement rather than accepting an illegal one.
- Relative anchors come from the captured scene. A dependent rule cannot anchor to an object another rule has not materialised.
Annotation#
- Cross-painting produces false negatives. A thin object in front of another can take contested boundary pixels, leaving the neighbour below the QA gates and unannotated. The reference capture lost three of ninety visible people this way, a 3.3% false-negative rate on that class, and the check that finds it runs on every capture.
- Amodal masks are not produced. The full extent of a partly hidden object, including the hidden part, is not written.
- Polygon tracing is lossy at very small sizes. A few instances in a large export carry a box and an empty polygon. The raw identity buffer still has them.
Execution boundaries#
- Dependency rules are planning-only. The native path rejects a job carrying them rather than ignoring them.
- The sensor block is offline. Lens and noise simulation is Python image processing after capture, not a render-time sensor model, and the native path rejects a job carrying it.
- Occlusion policy is a planning and QA contract. Real occlusion comes from geometry and placement.
- ISM and HISM are identity representations, not batching optimisations. Measured benchmarking shows all three representations still carry per-logical-target overhead, and the identity pass is a material scaling cost regardless.
Evidence boundaries#
- Multi-camera and calibration are implemented, and the latest dedicated visual QA run did not exercise a full multi-camera calibration session.
- Built-in NameFrame weather is not the verified visual path. Current visual proof uses Ultra Dynamic Sky and Weather.
- Commercial Preview is not customer-proven production readiness. The engine tier, the evidence and the packaging are pinned and verified. That is a different claim from a track record.
- Tracking datasets are not supported. Objects are reshuffled per frame by design, so consecutive frames are independent samples rather than a sequence.
- Optical flow, surface normals and material maps are not written, even though the engine has them.
Why this page exists#
Every product has a list like this. Most keep it internal, which means each customer rediscovers it at their own expense and concludes the documentation could not be trusted.
Publishing it costs a little credibility once and saves a lot of it repeatedly. If something here is a blocker for your problem, that is worth knowing before a pilot rather than during one.