Observed failure
AI renders come back with badly wrong scale relative to the source geometry: human figures rendered at several times plausible height, and buildings rendered at heights that ignore the story count clearly present in the source image. Users notice immediately, and it makes output unusable for stakeholder presentations — the exact deliverable people pay for.
What we think is going on
The model is not failing to respect dimensions we gave it; it never had them. It receives a single image with no indication of what kind of view it is, and interprets the scene wrong from the start. Once it has misread an aerial view of mid-rise buildings as, say, a close-up of a model or a street-level view, every downstream size decision follows from that misreading. Scale error is a symptom of misinterpretation, not of insufficient instruction about size.
Explicitly NOT proposed: injecting dimensions into the prompt
The obvious idea is to append known measurements — "buildings are 8-10 stories", "people are 1.7m". We do not think this works. Telling a model a number does not give it the spatial understanding it lacked; it hallucinated the scale because it misread the image, and a numeric assertion in the prompt does not correct a misread image. Recording this so it does not get re-proposed.
Proposed: give the model interpretive context about what the image is
The promising version of the prompting idea is different in kind. Multimodal models orient substantially better when told what they are looking at. We already know all of this and send none of it:
- View type — aerial / oblique / street-level, derivable from camera pitch and altitude
- Locale — the general geographic setting, derivable from scene geo coordinates
- Heading — which cardinal direction the camera faces
- Lighting/time of day — already a scene property
- Source characteristics — whether the base is photogrammetric 3D tiles versus untextured procedural geometry, which changes how the model should read the input
- Target — the conversion being requested (photorealistic, etc.), which is the existing style selection and stays separate from the above
The claim is that "this is an aerial view of an urban district facing northeast in daytime, derived from photogrammetric 3D tiles" anchors the model's reading of the image in a way that "the buildings are 30m tall" does not.
This is a hypothesis, not a known fix. It is cheap to test, which is the main argument for trying it first.
Approach
Interaction with input resolution (#1887)
These are likely compounding. At aerial framing, human figures occupy very few pixels, and #1887 documents source captures arriving at one quarter the expected pixel count. A model that can barely resolve the figures has little to anchor scale on, whatever the prompt says. Worth re-testing scale accuracy after the resolution work lands, since some of this may resolve on its own.
Rejected alternatives
- Depth-map / structure conditioning. Would be the robust fix, but we are not confident the frontier image models we use accept depth input. Revisit if model capabilities change.
- A "preserve geometry" strength control. Same confidence problem, and it misframes the issue: existing geometry is not being destroyed, it is being misunderstood in order to generate new geometry around it.
- Scale-reference figures in the source render. Already possible today, and it does not help at the framing where the problem shows up — at aerial distance, figures are too small relative to the frame to work as an anchor, compounded by the resolution issue above.
Observed failure
AI renders come back with badly wrong scale relative to the source geometry: human figures rendered at several times plausible height, and buildings rendered at heights that ignore the story count clearly present in the source image. Users notice immediately, and it makes output unusable for stakeholder presentations — the exact deliverable people pay for.
What we think is going on
The model is not failing to respect dimensions we gave it; it never had them. It receives a single image with no indication of what kind of view it is, and interprets the scene wrong from the start. Once it has misread an aerial view of mid-rise buildings as, say, a close-up of a model or a street-level view, every downstream size decision follows from that misreading. Scale error is a symptom of misinterpretation, not of insufficient instruction about size.
Explicitly NOT proposed: injecting dimensions into the prompt
The obvious idea is to append known measurements — "buildings are 8-10 stories", "people are 1.7m". We do not think this works. Telling a model a number does not give it the spatial understanding it lacked; it hallucinated the scale because it misread the image, and a numeric assertion in the prompt does not correct a misread image. Recording this so it does not get re-proposed.
Proposed: give the model interpretive context about what the image is
The promising version of the prompting idea is different in kind. Multimodal models orient substantially better when told what they are looking at. We already know all of this and send none of it:
The claim is that "this is an aerial view of an urban district facing northeast in daytime, derived from photogrammetric 3D tiles" anchors the model's reading of the image in a way that "the buildings are 30m tall" does not.
This is a hypothesis, not a known fix. It is cheap to test, which is the main argument for trying it first.
Approach
Interaction with input resolution (#1887)
These are likely compounding. At aerial framing, human figures occupy very few pixels, and #1887 documents source captures arriving at one quarter the expected pixel count. A model that can barely resolve the figures has little to anchor scale on, whatever the prompt says. Worth re-testing scale accuracy after the resolution work lands, since some of this may resolve on its own.
Rejected alternatives