Where should I stand? Import your work-in-progress model, drop cameras in plan, and see the 60° cone of vision drawn where you put each one — so going fisheye is visible rather than theoretical. Eye height is the number nobody thinks about, so it is the first control. Keep a named shot list, check whether your verticals are falling over and by how much, and send the whole set back to Rhino as real named views in a .3dm — or as a RhinoPython snippet for a model you already have open. Isovist asks what you can see from here; Scout asks where you should be.
Nothing is uploaded: the model is read in this browser, and no part of this tool calls an API.
Nothing is uploaded — the file is read in this browser and never leaves it. You can place cameras on empty ground too.
.3dm files say which; everything else is assumed metres until you say otherwise.
The number nobody sets on purpose. A standing adult's eye is about 1.6 m — the bench's default, and the tick on the track; a seated one about 1.2 m; a drone is not a person.
Level means vertical lines stay vertical. Turn it off to tilt, and watch the verticals reading.
Locked to the eye height while the camera is level.
On a 36 × 24 mm full-frame gate — the same number Rhino's viewport prints.
Select a shot (or click the plan to place one) to move it from here.
Where the camera looks, on the site's compass — the north angle is applied.
How far in front of the camera the aim point sits. It sets the tilt, not the lens.
The cone of vision is the frame's diagonal, so the shape of the frame changes it.
Where the slice is taken. 1.2 m is the conventional plan cut — through the openings, under the heads.
Or use the wheel over the plan; drag empty ground to pan.
Click anywhere on the plan to put a camera there at 1.60 m. Open a model first if you want something to look at.
The next camera
Past the cone of vision. This frame spans 63.4° corner to corner — 3.4° beyond the classical 60° limit. The perspective is still geometrically exact; it will simply look wrong, because the corners stretch and round things go oval. A longer lens or a step back fixes it.
- Angle of view
- 54.4° wide · 37.8° tall
- Plan cone
- 54.4° on the ground
- Heading
- 0° N
- Standing at
- 0.00, 0.00 m
- Looking at
- 0.00, -10.00 m · 1.60 m up
- Distance to the aim
- 10.00 m
Verticals
Level. The view axis is horizontal, so vertical lines in the world stay vertical in the frame and there is no third vanishing point. This is the architectural convention, and it is what the shift lens exists to preserve.
- Tilt from level
- 0.00°
- Verticals parallel
- yes
- Shift now
- 0.000
- Shift that corrects
- 0.000
The shot list
Click anywhere on the plan to stand a camera there. Drag the square to move it, drag the small circle to swing where it looks.
The sun
At 14:00 on 21 Jun at 40.11°, -88.24°, the sun stands 68.4° above the horizon at 225° SW.
The sun is behind you. 135° off your view direction — flat, frontal light, and your own shadow may reach into the frame.
- Solar hour
- 13:06
- Declination
- 23.45°
- Equation of time
- -1.5 min
Standard astronomical approximation (Cooper declination + Spencer equation of time), good to about ±0.5°. Not an ephemeris — no refraction, no leap-year correction.
Take it to Rhino
The exports are in the Export menu at the top of the page. The .3dm carries one named view per shot and no geometry — open it beside your model, or use the RhinoPython script on the model you already have open.
Sources & methods
The camera. One camera type, shared with every other tool on this bench (lib/camera): position and target in metres, lens in millimetres on a 36 × 24 mm full-frame gate, angle of view derived as 2·atan(gate ÷ 2f). The frame you choose crops that gate, which is why changing the frame changes the cone. Lens shift is carried in NDC half-frames, the same units the projection uses. Scout adds no camera maths of its own.
The 60° cone. The cone of vision drawn here is a convention, not a law. The classical figure is the frame’s diagonal angle of view, and every perspective text puts the comfortable limit at roughly 60°: past that a linear perspective stays geometrically exact and starts to look wrong, because a flat picture cannot be taken in at that angle by an eye that is not moving. The wedge on the plan is the horizontal half-angle, since a plan can only ever show the horizontal spread — drawing the diagonal in plan would overstate the width of the cone on the ground. Exactly 60° is at the limit, not past it.
The verticals. The correction reported is the architectural photographer’s move, and it is not “tilt less”: level the camera so world verticals have no vanishing point, then rise the lens by tan(tilt) ÷ tanY to put the framing back where the tilt was reaching. The tangent is taken from the same projection basis that draws the frame, so the correction cannot drift from what it is correcting.
The sun is an approximation, and here is how big. Standard astronomical approximation (Cooper declination + Spencer equation of time), good to about ±0.5°. Not an ephemeris — no refraction, no leap-year correction. Cooper’s declination and the Spencer/NOAA equation of time are the formulas printed in every solar-design text — checkable by hand, good to about half a degree at middle latitudes, and far inside the width of the sun’s own disc on a diagram. They are not an ephemeris: no refraction at the horizon, no nutation or aberration, and no leap-year correction. Daylight saving is yours to apply — pass the UTC offset actually in force on that date. Good enough to site a camera; not good enough for a solar-access argument.
What the plan is. The default drawing is a real horizontal cut through the model’s triangles at the cut height, the way a plan is made; the footprint mode drops every triangle edge straight down instead. Very large models are drawn from a sample of their triangles (it says so under the file name) — the plan is a drawing to site a camera on, not a mesh viewer. Thumbnails are flat wireframes projected through the same camera as the plan; edges that cross behind the eye are dropped rather than clipped, so a thumbnail from inside a wall will look sparse.
What the Rhino export carries — and what it does not. The .3dm contains one named view per shot and nothing else: no geometry, no layers, no materials. Each view carries the camera location, direction and up vector converted to Rhino’s Z-up world at the one conversion site in this repo, a perspective projection, the lens length rescaled onto Rhino’s 36 mm gate, and the frustum you framed. It does not carry the lens shift — Rhino’s named views have no shift field, so a shifted camera arrives level and re-centred, and the shift is yours to reapply with a two-point perspective view. Rhino recomputes the lens number in its title bar from the frustum against a fixed 24 mm film height, so it matches exactly at a 3:2 frame and drifts at others; when it drifts, the framing is ours and the readout is Rhino’s. Duplicate shot names are made unique before writing, because Rhino tolerates duplicates and then shows you two entries you cannot tell apart. The RhinoPython script does the same job on a model you already have open, which the file round trip cannot; the camera JSON is the interchange the rest of this bench reads.