π Sphere Light β Sun (City)
Want real sunlight in your render? Type a city, pick a time, and let the actual sun do the work
- render
The Manual sphere node is great when you know exactly where the light should come from. But sometimes the point is not to invent the light - it's to match reality. Say you're recreating a scene in Tokyo at 5pm, or you want your image to have the exact golden-hour shadows of a specific place at a specific moment. That's the Sun (City) node: type Tokyo, Japan, set the date and time, and the sphere is lit the way the real sun lit the sky right then.
It's part of the same pack as the Manual node - a set of reference-sphere renderers for the Sun-Direction LoRA on Flux 2 Klein. Where Manual asks for angles, this one does the astronomy for you.
How it works
The sun position isn't computed by Python. The node ships a NOAA solar-position module in JavaScript (js/solar.js), which turns date + time + a location into sun azimuth and elevation. The browser does that math when you queue, renders the lit sphere with Three.js (vendored, so no CDN dependency), and bakes it into the hidden render_b64 widget. The Python side just decodes that image into the 1024Γ1024 render output. It's all local - the "real sun" comes from math, not from any API call.
The city lookup runs offline against a bundled GeoNames-derived dataset covering cities over roughly 15k population, with autocomplete styled like a native ComfyUI widget. A status line on the node shows what resolved (β London, England) or warns when a city isn't found. Timezone and daylight saving are handled automatically - you type local wall-clock time and it figures out the UTC conversion, including DST boundaries.
The inputs that matter
- city (default
Austin, TX) - type it with or without region:London, UKworks, as doesLondon. - hour / minute - local time at the city. This is the fun one to sweep; you can watch the light rotate through a whole day.
- heading (0β360) - which way the camera faces, clockwise from North. It matches EXIF
GPSImgDirection, so it lines up with a real photo's compass reading. A little compass on the preview shows it at a glance. - intensity (0.2β3, default 1.5) - light strength, if the real sun feels too strong or weak for your scene.
- year / month / day - for matching a real date, or just leave them and play with the clock.
Output is a single render (IMAGE) to feed the Sun-Direction LoRA's reference input.
Install
ComfyUI Manager (search Sphere Light Render) or:
cd ComfyUI/custom_nodes/
git clone https://github.com/eric-venti-seeds/Sphere-Light-Render-ComfyUI.git
then restart and grab the Sun-Direction LoRA from HuggingFace (...Flux2Klein9B or ...Flux2Klein4B). No other dependencies - the pack has no requirements.txt.
The gotchas
The whole "render in the browser" design means a couple of things. Driven inputs (wire a Primitive into city, heading, or the time fields) only update on a run made from an open ComfyUI tab - headless/API runs reuse the last baked image, so don't animate by API. And the baked sphere travels inside your workflow JSON, adding 100β400 KB per node; that's expected, not corruption. One more: if the preview ever looks wrong, check the status line first - an unresolvable city just leaves a warning and renders whatever's baked, rather than erroring loudly.
Inputs (9)
| Name | Type | Default | Description |
|---|---|---|---|
| intensity | FLOAT | 1.50.2β3 | Light strength. |
| city | STRING | Austin, TX | City name, optionally with region/country (e.g. 'Austin, TX', 'London, UK'). |
| year | INT | 20251β9999 | β |
| month | INT | 61β12 | β |
| day | INT | 211β31 | β |
| hour | INT | 120β23 | Local time at the chosen city (DST handled automatically). |
| minute | INT | 00β59 | β |
| heading | FLOAT | 0.000β360 | Camera facing, degrees clockwise from North (matches EXIF GPSImgDirection). |
| render_b64 | STRING | Internal: the browser-rendered sphere image (managed automatically). |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| render | IMAGE | β |