Daylight modelling software outputs and what to include

A daylight assessment that cannot be checked is not evidence. The test I apply to an appendix is simple: could a competent third party rebuild this model from what is in front of me and get the same numbers. That needs the geometry sources and their accuracy, the model extents, the datum, the window and room window reference schedule, the input assumptions, the software and version, and result tables with both the existing and proposed values rather than only the ratio. Most assessments that fail review fail on one of those seven, and the numerical work is usually sound.

The commonest single defect is a levels error, and it is also the one that changes results most.

Geometry sources and survey accuracy

State where every dimension came from.

A measured topographical survey is the strongest source, and the report should give the surveyor, the date, the datum and the stated accuracy. National mapping gives building outlines in plan with no heights, so a model built from mapping alone has had its heights assumed by someone. Airborne survey data from the national programme gives heights with a published vertical accuracy, which is adequate for distant obstructions and marginal for a building two metres from the assessed window. Photogrammetry sits somewhere between, depending on the control used.

Where a neighbouring building's internal layout is unknown, which is most of the time, assumptions have been made about room depth, room use and window head height. Those assumptions belong in a schedule, with the basis for each. An assumed 4.5 metre room depth behind a window is a reasonable convention and an unstated one is a hole in the evidence.

Where the layout is known, from a planning application, a marketing plan or a site visit, use it. A reviewer will ask whether the assessor checked.

Model extents and which buildings to include

Two questions here, and they are different.

Which obstructions to include. Any building whose mass could reduce sky visibility at an assessed window, which means the judgement is angular rather than a fixed radius. Include the boundary wall, the mature tree canopy where it is evergreen, the neighbouring extension and the lift overrun. Excluding a small obstruction close to a window is a worse error than excluding a large one far away.

Which scenarios to model. At minimum the existing baseline and the proposed scheme. Where a consented but unbuilt scheme sits nearby, or where the application site itself has an extant permission, the assessment needs to say which scenario it treats as the baseline and why, and ideally report both. That choice can change a conclusion entirely, and it is the same consistency problem that arises in a mirror-image massing test.

Include a model extents plan as an appendix drawing, showing every modelled building with the assessed properties marked. It takes one page and answers a whole category of question.

Ground level and datum errors

Everything in the model has to sit on one datum, and the standard choice is Ordnance Datum Newlyn.

The failure mode is mixing sources. A topographical survey to Ordnance Datum, architectural drawings to a site datum set at a finished floor level, and mapping heights relative to ground: combine those without conversion and the proposed massing sits a metre or two too high or too low relative to the neighbouring windows. At close range that is enough to move a Vertical Sky Component result across a threshold.

Three checks a reviewer can run quickly:

• Does the report state the datum, once, explicitly, for the site and for each source.
• Do the finished floor levels in the model match the levels on the architect's sections.
• Are the assessed windows' sill and head heights derived from stated floor levels, or assumed.

The reference conditions matter too. Vertical Sky Component is measured at the centre of the window on the outside face of the wall. The no-sky-line is assessed on a working plane above floor level, conventionally 0.85 metres for residential rooms. Both should be stated rather than left implicit.

Output tables and the fields required

A result table that gives only the ratio of proposed to existing is not enough, because a ratio of 0.75 means something different at a starting Vertical Sky Component of 35 per cent than at 8 per cent.

Report Vertical Sky Component, no-sky-line area, and annual probable sunlight hours split into total and winter figures, each with existing and proposed values. For rooms within the proposed development, report the internal illuminance results with the target illuminance, the proportion of the reference plane achieving it and the proportion of daylight hours, room by room.

And report every assessed window, including the ones that pass comfortably. A table filtered to the failures reads as a summary of someone else's judgement.

Screen images and their usefulness

Model views are worth including and they are not a substitute for tables.

What helps: an axonometric of the model from a viewpoint that shows the assessed elevation, with the assessed windows labelled to match the reference plan. A view from the assessed window showing what the model says is visible. Colour-coded plans showing the no-sky-line position before and after, at the same scale and orientation. Sky-visibility diagrams for the windows where the result is marginal.

What does not help: unlabelled renders, perspective views with no scale reference, and images at a size that makes the annotation illegible. A reviewer cannot check a picture against a table if the references do not match.

Keep every image to the same convention: same colours for existing and proposed, same north point, same scale within each set.

Version control between design revisions

Massing changes during an application, and daylight results do not update themselves.

Keep a version table in the report: model file name and date, the architectural drawing numbers and revisions it was built from, and the date of the results. Then, when the scheme is revised, a reviewer can see at a glance whether the assessment relates to the drawings currently before the authority.

The practice that avoids the worst outcome is re-running the model on every massing revision, however minor it looks, and noting where results did not change. An assessment carrying revision C results against revision F drawings is a finding that can undo a whole submission at committee, and it happens because someone judged a setback of 300 millimetres immaterial without testing it.

Name the assessor and state their qualification. Where the report is submitted by a practice, say who did the modelling and who checked it.

The appendices a reviewer needs

A complete appendix set, in the order a reviewer will use it:

1. Input assumptions schedule: surface reflectances, glazing transmittance, any maintenance factor, assumed room depths and uses, window head and sill heights.
2. Geometry sources: the survey report or reference, the mapping and height data used, dates and stated accuracies.
3. Model extents plan, with assessed properties and modelled obstructions marked.
4. Window and room reference reference plans for every assessed property.
5. Full result tables, unfiltered, for each metric and each scenario.
6. Model views and diagrams, annotated to match the reference plans.
7. Software name and version, calculation method, and the assessor's name and qualification.
8. Version table linking model runs to drawing revisions.

That is eight items and it is not onerous. It is also the difference between a reviewer raising two clarifications and a reviewer recommending that the assessment be redone.

Where the assessment supports a case about amenity rather than about the scheme's own units, the criteria and the framing differ, and the position on when a daylight and sunlight assessment is required is the right starting point. The Daylight and Sunlight Assessment page sets out what the document covers, and an Overshadowing Study handles amenity space rather than windows. Councils usually expect a suitably qualified author for this work, with professional review strongly advised.

PlanScope can produce an AI-assisted draft of the supporting narrative and flag every input that has to come from the modeller, with missing site data marked rather than invented. It does not build or run the model. Reports should be reviewed before submission, and PlanScope does not guarantee planning approval. For specialist technical reports, qualified professional input may be required. Reviewers who sign off drafted documents can be found through the professional directory. This is general guidance, not legal advice; check the position with the local planning authority or a qualified professional before relying on it.