A first cut of a configurable lighting API just landed: launch(lights=[...]) and env.set_lights([...]), plus five Light subclasses (AmbientLight, HemisphereLight, DirectionalLight, PointLight, SpotLight) mirroring three.js's own light taxonomy. Deliberately scoped down during design discussion -- logging the deferred parts here so they don't get lost.
What v1 does: a single bulk-replace message ("lights") swaps out every light in the scene at once -- Swift's own default 3-light rig included. No individual light identity, no way to add/remove one light without resending the whole set. Shadow-camera tuning (frustum, bias) stays hidden/hardcoded internally; each light only exposes cast_shadow: bool.
Deferred for a later pass:
- Per-light CRUD --
add_light()/remove_light() with individual ids, integrated into swift_objects the same way shapes are, so show()/env[id] pick lights up automatically. Would let you tweak one light without resending the whole rig.
- Add-on-top-of-defaults semantics -- today
lights=/set_lights() always replaces the entire rig. An "add to the current lights" mode (rather than replace-only) could be useful for tweaking one aspect of the default rig without having to fully reconstruct it.
- Camera-relative auto-follow lighting -- lights are fixed in world space and don't move with
set_camera_pose() (this is documented via .. warning:: on both launch() and set_camera_pose() for now). An opt-in "lights follow the camera" mode, similar to how ground_pattern's recentring already tracks the camera, would remove that footgun for people who move the camera a lot.
- Exposed/tunable shadow-camera parameters -- the shadow frustum and bias are tuned to Swift's own ~1m default scene scale and hidden from the API entirely. A scene at a very different scale (much bigger or smaller than the default) would get a poor-quality or clipped shadow with no way to fix it from Python.
None of these blocks the v1 API from being useful as-is -- just noting the fuller scope discussed but not built.
A first cut of a configurable lighting API just landed:
launch(lights=[...])andenv.set_lights([...]), plus fiveLightsubclasses (AmbientLight,HemisphereLight,DirectionalLight,PointLight,SpotLight) mirroring three.js's own light taxonomy. Deliberately scoped down during design discussion -- logging the deferred parts here so they don't get lost.What v1 does: a single bulk-replace message (
"lights") swaps out every light in the scene at once -- Swift's own default 3-light rig included. No individual light identity, no way to add/remove one light without resending the whole set. Shadow-camera tuning (frustum, bias) stays hidden/hardcoded internally; each light only exposescast_shadow: bool.Deferred for a later pass:
add_light()/remove_light()with individual ids, integrated intoswift_objectsthe same way shapes are, soshow()/env[id]pick lights up automatically. Would let you tweak one light without resending the whole rig.lights=/set_lights()always replaces the entire rig. An "add to the current lights" mode (rather than replace-only) could be useful for tweaking one aspect of the default rig without having to fully reconstruct it.set_camera_pose()(this is documented via.. warning::on bothlaunch()andset_camera_pose()for now). An opt-in "lights follow the camera" mode, similar to howground_pattern's recentring already tracks the camera, would remove that footgun for people who move the camera a lot.None of these blocks the v1 API from being useful as-is -- just noting the fuller scope discussed but not built.