Four independent engines, one page: Sun Director solves sun position and inverse light-timing. Moon Director solves moonlight metering and moon alignment. Star Atlas solves star and deep-sky visibility and imaging windows. Architectural Daylighting solves right-to-light, Daylight Factor, and annual sDA/ASE compliance for buildings — the same closed-form philosophy applied to a planning-permission daylighting study instead of a shoot. Everything below is measured against a running engine.
Same buyer — photographers, cinematographers, DPs, location scouts, drone operators, architects, daylighting consultants, event planners, astrophotographers — different math underneath.
Golden hour, blue hour, and exact sun-angle timing — plus the inverse: given the light you want, when do you get it? Band duration, glint timing, henge bearings, continuity across shoot days.
Moonlight metering in real lux — phase, magnitude, ground illuminance — plus inverse moon-window and moon-alignment search for fill light, night exteriors, and landmark "moon-henge" shots.
Star and deep-sky-object catalog lookups, what's visible from a place and time, and imaging-window solving for astrophotography sessions.
Vertical Sky Component, Daylight Factor (BS 8206-2), CIE/Perez sky luminance, and annual sDA/ASE (LEED v4 / EN 17037) compliance — plus native OBJ/glTF/IFC BIM mesh ingestion for real building geometry.
Every sun-tracking app answers "where is the sun right now." Almost none answer the question a shoot actually asks — or the question a planning application actually needs answered.
A location scout doesn't want a sun-position table — they want an answer to "when does the sun sit at 15°, camera-left, for at least 20 minutes?" A DP doesn't want a Kelvin chart — they want to know when the light will actually be 5500K at this exact spot.
Those are inverse problems: desired light in, time/place/duration out. Most tools solve them the way a person would — scan a timeline by eye, or render frame after frame until one looks right. This line solves the inverse directly, in closed form: SUN_BAND_DURATION, SUN_GLINT, SUN_ALIGN, SUN_CONTINUITY, SUN_FIND, MOON_DIRECTOR, MOON_ALIGN — seven inverse verbs across the line, none of them a scan a human has to do by hand.
Photographers checking Saturday-morning golden hour cluster around the same few hours, in the same handful of metros, every week. A render-engine-backed tool pays for that correlated demand in full: V-Ray runs ~72 seconds a frame, Arnold 68–477 seconds. Scale that across a metro's photographers checking the same window and the cost curve is brutal.
Every verb here resolves by closed-form math, not rendering or brute-force scanning — microseconds to low milliseconds, with the one full-year search (SUN_ALIGN) at ~46 ms and cacheable. Unit economics don't degrade when demand clusters, because there's no frame being rendered per request.
A BRE/BS 8206-2 right-to-light study or a LEED v4 sDA/ASE annual daylight run is normally a Radiance or ClimateStudio job — real building geometry, ray-traced sky integrals, minutes-to-hours per iteration, per view, per design option.
The same hemisphere-integral math that drives Sun Director's inverse verbs also drives Vertical Sky Component, Daylight Factor, CIE/Perez sky luminance, and the annual sDA/ASE harness — closed-form, µs-to-ms per call, reading real BIM geometry through native OBJ/glTF/IFC loaders instead of a pre-converted mesh. Documented, not hidden: this is a daylight-coefficient model, not a certified LM-83 ray-traced run — see the honesty line in the Daylighting section below.
Send a date and a location, get back the golden-hour window, the moment the sun crosses a specific altitude, or its full path through the day. Then go further: solve for how long the sun sits in an altitude band, when a surface glints toward a viewer, which dates the sun rises down a bearing, or the moment on another date whose light matches today's — all closed-form, not scanned or rendered.
Pick a tab, fill in a date and place, hit run. Live tabs call the actual gateway; anything not yet exposed over HTTP is clearly marked as a sample.
Every figure here is measured live against the running engine — warm, single core, shared workstation (an upper bound under contention). Warm-minimum is the quoted floor.
| Competitor | Approach | Latency | Inverse query? |
|---|---|---|---|
| NOUS Sun Director | Closed-form solve | 25–1,000 µs | Yes — 5 verbs |
| PhotoPills | Manual timeline + Find button | Not published | Yes (Find button, single bearing) |
| SketchUp Sun Path | Slider + shadow preview | Not published | No — manual scan only |
| V-Ray (render engine) | GPU ray-tracing | ~72 sec/frame | No |
| Arnold (render engine) | GPU/CPU ray-tracing | 68–477 sec/frame | No |
The playground above demos these same calls. All of them are real calls against the same gateway.
Most moon APIs stop at phase percentage. This one meters actual ground illuminance in lux, airmass-corrected for how low the moon sits — then goes further: scan a date span for nights where the moon sits in a chosen altitude/illumination band, or find every date the moon rises or sets on a specific bearing, for a moonrise shot down a street or through a landmark.
These seven verbs are wired onto the HTTP gateway and call the running engine live — every tab below is a live call, not a canned sample. The general Moon API (phase, rise/set, apogee/perigee) is a separate, already-live product.
| Capability | NOUS Moon Director | Typical moon-phase app / API |
|---|---|---|
| Moonlight output | Ground illuminance in lux, airmass-corrected, model named | Illumination percentage only |
| Moon-window search (illum + altitude band, across a span) | Inverse, closed-form scan | Not offered — manual calendar check |
| Moon-henge / bearing alignment search | Inverse, closed-form scan across a date span | Not found as a programmatic offering |
| Local civil-time output | DST-correct wall-clock twin for both inverse verbs | Rarely offered outside a single timezone assumption |
Send a star name, a catalog number, or a sky coordinate, get back positions, magnitudes, and visibility — computed for a real place and moment, not read off a static chart. Stars and deep-sky objects in one API.
Pick a tab, fill in a name, position, or place and time, hit run. Live tabs call the actual gateway; anything not yet exposed over HTTP is clearly marked as a sample.
| Capability | NOUS Star Atlas API | Typical desktop planetarium software |
|---|---|---|
| Access model | Single GET call, JSON response | Full desktop application install |
| Server-side integration | Drop into any app or backend | Not designed for programmatic use |
| Visibility calculation | Computed for your exact time and place, on demand | Requires opening the app locally |
| Catalog scope | Stars and deep-sky objects together | Often split across separate tools or plugins |
The same hemisphere-integral sky math behind Sun Director's inverse verbs, pointed at a building instead of a shoot: Vertical Sky Component and the Daylight Factor sky component (BRE/BS 8206-2 right-to-light), the full three-term Average Daylight Factor (Lynes formula), CIE Standard Sky and Perez all-weather sky luminance, EPW/TMY3 real-weather ingestion, and an annual sDA/ASE (LEED v4 / EN 17037) harness — reading actual building geometry through native OBJ, glTF, and IFC (ISO 10303-21 STEP) loaders with exact ray-triangle occlusion, not a boxes-only approximation. The IFC/STEP loader now reads far more than flat tessellated panels: extruded, revolved, and swept-disk solids (pipes, rails, conduit), boolean CSG cut-outs (union / intersection / difference), and curved composite-curve profiles — the AEC solid-geometry track is complete, verified by 76/76 loader self-test proofs.
Seven verbs below are wired onto the HTTP gateway — every tab is a live call against the running engine, not a canned sample. Four further capabilities (3D-scene VSC, EPW/TMY3 hour lookup, the annual sDA/ASE harness, and BIM mesh ingestion itself) are built and documented but don't have a captured numeric transcript or a gateway route yet, so they're listed honestly in "All verbs" below without a sample.
Every figure here is a real transcript from the running engine, not a marketing estimate. These seven verbs are single measured calls (not yet median-benchmarked over repeated runs like Sun Director's), so latency is quoted per-call rather than as a warm-min/median pair.
| Capability | NOUS Architectural Daylighting | Radiance / DIALux / ClimateStudio-class tools |
|---|---|---|
| Approach | Closed-form hemisphere/Lynes/Perez math | Ray-traced radiance simulation |
| Latency per iteration | 20 µs – 15 ms | Minutes to hours per view/design option |
| Building geometry input | Native OBJ / glTF / IFC (STEP) ingestion — tessellated, extruded/revolved/swept-disk solids, boolean CSG, curved profiles — no offline convert | Usually needs a pre-baked/exported mesh |
| Annual LEED v4 sDA/ASE harness | Built — real EPW/TMY3 weather, orbit_sat per-point/per-hour caching | Standard but compute-heavy (annual climate-based simulation) |
| Programmatic / bulk API access | Plain GET endpoints, usage-based | Desktop tools or plugin licenses, not API-first |
The playground above demos five of these with real captured samples. The other four are built and documented but not yet demoed with a numeric sample — listed honestly below, schema only.
Two glare capabilities landed this week: an exterior solar-glare hazard classification (the ForgeSolar-class green/yellow/red retinal-hazard band) and an interior discomfort-glare (DGP) verdict for visual comfort. Both are cited, both are proven in the engine's self-test gate, and both are now wired as real socket verbs on the running daemon — measured live with real captured transcripts in the Architectural Daylighting Playground above, the same tier as VSC, Average Daylight Factor, and Solar Access. Not yet wired onto the public HTTP gateway, same as every other verb on this page.
The Sandia SGHAT model — the same math behind the FAA-referenced ForgeSolar glare tool — classifies a specular reflection (off glass, PV, or a solar-farm array) as green (low hazard), yellow (temporary after-image / flash-blindness), or red (potential retinal burn), from the retinal irradiance and the source's subtended angle. Cited: Ho, Ghanbari & Diver (SolarPACES 2009/2010; ASME J. Solar Energy Engineering 133(3):031021, 2011); burn/flash thresholds trace to measured biological limits in Sliney & Freasier (1973) and Brumleve (Sandia SAND76-8022, 1977) — not our numbers.
Measured live against the running engine (see Playground above), and verified in the engine's self-test (16/16 proofs): direct-sun retinal irradiance ≈8.0 W/cm² and burn-threshold ratio ≈12.7 both reproduce the paper's own worked example; direct sun classifies "yellow" (after-image), matching the paper exactly. An engineering screening consistent with the SGHAT/ForgeSolar method — not an FAA-certified glare submission.
Daylight Glare Probability (Wienold & Christoffersen 2006) with EN 17037 comfort classes (imperceptible / perceptible / disturbing / intolerable), driven by absolute vertical eye illuminance computed from the same VSC hemisphere-sky math the Daylighting verbs above already use — not a separate invented sky integral.
Measured live against the running engine (see Playground above), and verified in the engine's self-test (9/9 DGP proofs + 12/12 interior-verdict proofs): a bright test case classifies "intolerable," a dim one "imperceptible," and DGP moves monotonically the right direction as sky luminance, source size, and viewing position change. The Guth position-index angular fit and a published worked-example cross-check are honestly deferred, not fabricated — this is "computed from the cited model," not a full validated glare render.
Each capability below exists somewhere in the market. Nobody assembles the four together, and nobody offers the inverse direction — or the closed-form daylighting-compliance direction — as an API.
| Capability | NOUS Photography & Production | Typical market alternative |
|---|---|---|
| Sun timing (forward) | ✓ — plus 5 inverse verbs | PhotoPills, SketchUp — forward only, or manual "Find" scan |
| Colour temperature with named model | ✓ CCT + CIE-1931, model cited in every reply | Not offered, or offered without provenance |
| Moonlight metering (lux, not just phase %) | ✓ ground illuminance, airmass-corrected | Rare — most moon apps stop at phase and rise/set |
| Moon alignment / moon-henge search | ✓ inverse bearing search across a date span | Not found as a programmatic offering |
| Astrophotography imaging windows | ✓ target + place + time → best window | Manual planning across separate star-chart and weather tools |
| Right-to-light / Daylight Factor compliance | ✓ VSC, DF, Perez sky, closed-form | Radiance/DIALux/ClimateStudio ray-traced runs, minutes–hours/iteration |
| Native BIM geometry ingestion | ✓ OBJ / glTF / IFC directly, no convert step | Usually needs IfcOpenShell or a manual glTF export first |
| Programmatic / bulk API access | ✓ plain GET endpoints, usage-based | Most competitors are single-query consumer apps or desktop tools, seat-licensed |
| Render/compute cost under correlated demand | closed-form, µs–ms, flat | render engines: 68–477 sec/frame (Arnold), ~72 sec/frame (V-Ray) |
Golden hour, moon phase, and star visibility for the same shoot day, from purpose-built APIs instead of unrelated tools.
Autonomous flight windows keyed to sun altitude bands or moonlight levels, solved in closed form instead of scheduled by hand.
Daylighting studies, henge-bearing checks against a facade, right-to-light VSC/DF numbers, and annual sDA/ASE runs against real IFC/glTF/OBJ building models — without waiting on a render.
Sun-henge and moon-henge dates down a street or through a landmark, plus staging checks for blinding/backlight at a venue.
True-dark windows, moonlight interference, and imaging-window solving for a target, all from the same date and place.
Vertical Sky Component, Average Daylight Factor, and LEED v4 / EN 17037 sDA/ASE numbers for a proposed obstruction, computed against the actual submitted BIM model.
{
"ok": true,
"fields": {
"golden_hour_morning": "06:12–06:47",
"golden_hour_evening": "19:38–20:13",
"blue_hour_morning": "05:41–06:12",
"blue_hour_evening": "20:13–20:44"
},
"raw": "GH_AM_START 6.20, GH_AM_END 6.78, GH_PM_START 19.63, GH_PM_END 20.22"
}
{
"ok": true,
"fields": {
"vsc_percent": "28.23%",
"sky": "overcast",
"window_tilt_deg": "90° (vertical window)",
"samples": "4,096 hemisphere rays, 1,423 open"
},
"raw": "vsc_percent=28.2303 sky=overcast window_az_deg=180.0000 window_tilt_deg=90.0000 ext_reflectance=0.0000 n_samples=4096 n_open=1423 compute_us=5175"
}
bird1986_clearsky+cie1931+hernandez_andres1999) so colour-critical pipelines can cite it directly.