Files
solvecraft/docs/render-materials/lighting-guide.md
T
selune 9e6e0b8df1 Render workspace: complete experimental ribbon, resources and effects integration (#5493) (#5494)
* wip(render): reconcile completed material and image pipeline source with 0.20 (#5493)

Source-only integration reference for staged review, not a merge-ready aggregate.
Donor: 0xlillith/solidcraft@aea20b0115.
Upstream: 858e5995d6.

Retain original CPU/material contracts and explicit GPU donor provenance in
docs/render-materials-lab.md (#2067, #2191, #2780, #3306). Preserve released
format migrations and current navigation/startup/shell behavior. New saved
records use pending descriptors. The physical-card descriptor follows the
maintainer's material-engineering-cards naming request, with a legacy-lab
format-29 regression. Replace raw new panel hosts with shared containers.

Repository checks, complete workspace/all-target Clippy, and the independent
physical/resource authoring checks pass for this source. The fresh full local
CI invocation has reached test compilation and is not yet complete. Do not
transfer donor native output or prior test totals to this integration.

Generated review screenshots, video, package ZIP and machine logs remain at
the immutable personal evidence pin. Uncommitted geometric displacement is
backed up separately, not silently included. No kernel/vendor change, direct
main write, release or independent contributor-branch rewrite.

Co-authored-by: Christian Svensson <blue@cmd.nu>

* test(cli): pin the Compact camera-sample admission diagnostic (#5493)

The bounded request still refuses 1024x1024x64 samples before host initialization and writes no output. Update only the stale expected diagnostic to the existing Compact budget wording; production limits and code are unchanged. Exact-tree CLI regression suite: 14 passed, 0 failed. The full repository gate has been invoked separately and is not yet complete.

* Normalize UI container violation paths across platforms

Report repository-relative paths with forward slashes so diagnostics and the existing nested-package regression assertions agree on Windows and Unix. Keep the container detection rules unchanged.

Validation: official ui-containers gate and all seven focused xtask tests passed; rustfmt and diff checks passed. Only xtask/dependencies were compiled; no application build or heavy tests.
(cherry picked from commit 44b58d8e10)

* fix(render): preserve camera contracts and correct acceptance regressions (#5493)

Preserve Design view.apply semantics with a separate strict Render camera command. Retain existing translations when English-only aliases collide; add material-axis entries and camera-specific pitch labels. Compare complete validated engineering cards and retain job handles before cancellation.

Focused and native acceptance is pinned to tree f8a423b21f. Full CI has been invoked separately and is not claimed green. Landing follows the render integration policy in #5493.

* fix(render): resolve showcase licence and upstream resource hygiene (#5493)

Record SychPL's explicit MIT OR Apache-2.0 grant, retaining source/model bytes and the Ubuntu lettering notice. Remove 80 absent attribution rows, personal fork records, dead delivery attributes and three fork/resource-only workflows. Existing xtask assets now performs bounded offline hash checks and rejects orphan render attribution; no parallel draft CI or package installation. Original authoring reproduction remains explicit. Scoped xtask tests, assets, Clippy, formatting and prepared SELENE validation pass; no application or renderer-wide result is inferred.

* fix(render): align saved bounds and progressive sample resolution (#5493)

Address review r4364211669/r4364211677/r4364211681/r4364211691/r4364211695. Persisted light/frame domains respect the existing 1e9 document bound; related LED/rectangle/direction cases use the same bound. Workstation primary resolve shares the 4096 admission cap and film counters use checked conversions. Exact candidate: 485 CPU render tests, 21 render document tests and strict scoped Clippy pass, including positive boundary round trips and 2048/4096 end-to-end checkpoints. No released format/migration edits, relaxed test limits or full-stack acceptance claim.

* wip(render): isolate optional resources and harden sample handling (#5493)

Review work in progress: opt-in encoded render library with reproducible runtime catalog exports; native-only robust dependency through the workspace; checked bloom slices; per-sample point-light diagnostics; independent area-light spatial/film keys. Resource-module binaries in both configurations, generation, Cargo production feature graphs and attribution checks pass. Full engine/render regression and combined acceptance are pending: do not merge this donor as a constituent or treat scoped resource proof as runtime acceptance.

* fix(gpu): preserve donor allocations through the scope-safety repair (#5722)

Port the native-validated #5723 scope-cleanup correction into the experimental donor, retaining its adaptive, volume, aging, photographic and bloom allocations. Same reverse-drain helper and regression cases; the donor combination still needs its own compile/test gate and is not covered retroactively by render-base results.

* claim: #1369

* Reject unknown pending concepts after format folding (#1369)

* test(render): close bounded sampling and bloom review regressions (#5493)

Validate the optional-resource/lighting/dependency donor at its exact tree. Required Vulkan GPU 127/0/3; CPU renderer 487/0; engine Render 72/0; document render 21/0; lean library 7/0; strict scoped Clippy, assets/layers/lists/containers and lean-engine WASM pass. Preserve original failed controller/typing attempts. This is the draft donor/disposition source, not a replacement for constituent render PRs or final main acceptance.

* wip(render): preserve stable aging target validation candidate

Exact staged source from prior review work on donor 3b892eab5e. This is a recovery/review checkpoint, NOT accepted delivery. An actual command-path regression currently fails because the selected executor refuses ordered surface aging. No assertion, capability or admission limit is weakened. Native/UI/full combination acceptance remains pending. Saved/runtime split adds one pending descriptor and retains original file scope; no main/render branch is changed.

* test(render): preserve numeric setup intent at the admitted coordinate bound

Follow up jyviko review on #5494 without weakening the corrected saved-coordinate contract. The positive clicked fixture uses 1e9 instead of inadmissible 2e9; explicit out-of-range cases still refuse, and the full saved setup round-trips through JSON and the native container. Exact-source Render workspace 95/0 and strict all-target UI Clippy pass. This does not incorporate the separately failing stable-aging candidate or claim full current-render acceptance.

* test(render): use the real GPU executor for saved aging

Move successful native cold-reopen Check/Start coverage from the CPU-backed protocol fixture into the production GPU executor tests. Verify capture-index changes preserve the stable target and that enabling aging changes both PNG and raw EXR output. Retain explicit, allocation-free refusal coverage for executors without aging support. Production capabilities and admission checks are unchanged.

* fix(render): persist stable identities for targeted aging (#5493)

Separate saved RenderBodyTarget identities from captured mesh ordinals. Reject legacy ambiguous targets, resolve Check/Start after visibility changes and preserve native reopening, copies and undo. Unsupported executors still refuse; real AMD Vulkan regression completes saved aging after reordered capture.

Source tree 6b84c8ad passes document 23, engine Render 75, GPU effects 5 and Render UI 95 with no failures; scoped strict Clippy, WASM and repository gates pass. Fresh CLI/native reopen and clean/aged GPU exports pass with identical physical totals and inspected actual images. Whole current-render integration is separate.

* fix(render): reconcile combined CPU/GPU contracts on current upstream

Unify captured resources/status and CPU-vs-GPU request schemas after the real two-parent integration; remove obsolete duplicate Vulkan selector and retain combined platform-filter regression. Deduplicate only identical or superseded test definitions, retaining the stronger card metadata and reserved-executor assertions. No assertions, admission limits or feature refusals are weakened.

All targets of render dependencies, GPU, engine, UI, CLI and native app pass cargo check with raytrace-cpu and bundled-render-library at tree c70d00d1. Native executable tests and full current-source acceptance remain pending. This is a private integration rehearsal for subsequent constituent PRs, not an aggregate official render/main merge.

* test(render): retain one complete host lifetime regression set

Deduplicate byte-identical DropProbe/task-lifetime tests and retain the adapted environment/texture ownership regressions with every assertion and complete memory estimate. Keep the registered-geometry admission regression once; only struct field order differed. Replace a one-element diagnostic loop with its equivalent block, preserving all wrap/width assertions.

Test-only integration repair. Formatting and diff checks pass; refreshed executable validation is required. No production behavior, limits, assertions or ignores changed.

* fix(doc): recognize the proven format-29 card descriptor alias

Normalize only the historical format-29 physical-material-cards spelling, and only when material-engineering-cards is registered. Admission and migration de-duplication use the same identity. Unknown concepts, wrong versions and incapable readers still refuse before mutation. Six controlled-history Rust regressions and actual CLI migration/no-clobber acceptance pass. No version, released migration or CI changes. Refs #5793, #1369, #5493.

* test(render): preserve grounding refusal before explicit instance moves

Update the two Render binding fixtures for upstream first-occurrence grounding. Verify grounded movement refuses without changing document/history, then explicitly unground through the public command before the intended move. Retain every target, resource, copy and persistence assertion. Refs #5493.

---------

Co-authored-by: Christian Svensson <blue@cmd.nu>
Co-authored-by: Victor Santos Oliveira <56417388+Vittuu@users.noreply.github.com>
Co-authored-by: cfaulkingham <colin.faulkingham@gmail.com>
2026-10-24 14:21:59 +00:00

13 KiB
Raw Blame History

Lighting catalog and authoring presets — v0.2.0

Scope and status

This package defines 280 concept lighting rigs and 24 numeric authoring presets for the personal render/materials development fork. It preserves the stable identifiers LUZ-001 through LUZ-200 from the original catalog and adds LUZ-201 through LUZ-280.

The lighting catalog has status concept_catalog. Its entries describe intended arrangements, controls, requirements and future validation. The numeric studio package has status specified_unbound: positions, dimensions and source relationships are specified, but a SolidCraft adapter has not been implemented and these presets have not been rendered or calibrated. A capability reference describes a requirement, not proof that an executor supports it.

All recipes are original authoring specifications under provenance identifier ORIGINAL-2026-10-CATALOG. No commercial preset, HDRI, photometric profile, material asset or renderer implementation is embedded. Where a recipe needs IES/LDT data, measured emission or a specialized optical model, that resource must be supplied, licensed and validated separately.

Catalog coverage

The 28 families each contain ten distinct entries:

IDs Family
LUZ-001–010 Essential studio
LUZ-011–020 Catalog and commerce
LUZ-021–030 Metals and reflective surfaces
LUZ-031–040 Glass and optical products
LUZ-041–050 Translucent and soft materials
LUZ-051–060 Plastics and matte finishes
LUZ-061–070 Jewelry and watches
LUZ-071–080 Electronics and small mechanisms
LUZ-081–090 Industrial machinery
LUZ-091–100 Furniture and domestic products
LUZ-101–110 Vehicles and transport
LUZ-111–120 Architectural daylight
LUZ-121–130 Artificial architectural lighting
LUZ-131–140 Solar and sky exteriors
LUZ-141–150 Functional photometry
LUZ-151–160 Visual inspection and validation
LUZ-161–170 Macro and miniatures
LUZ-171–180 Dramatic presentation
LUZ-181–190 Assemblies and exhibitions
LUZ-191–200 Specialized physical scenes
LUZ-201–210 Automotive and mobility details
LUZ-211–220 Industrial robotics and manufacturing
LUZ-221–230 Electronics and additive fabrication
LUZ-231–240 Woodworking and DIY
LUZ-241–250 LED optics and luminaires
LUZ-251–260 Aerospace and spacecraft integration
LUZ-261–270 Physical lunar surface lighting
LUZ-271–280 SELENE arm and sample-handling studies

The costs Low, Medium and High are qualitative estimates of authoring and transport difficulty. They are not performance measurements. Priorities P0, P1 and P2 express product-development order and do not imply current availability.

Ownership boundaries

A lighting rig owns its sources, source groups, source placement, light-target references, and explicitly created flags, reflectors or fixture diffusers. It does not silently edit the product material, CAD dimensions, arm pose, sample-vial contents, camera, tone mapping, output format or environment.

Controls such as “grazing angle to reveal texture” change the source. They do not change bump amplitude. “Backlight to reveal thickness” changes illumination; it does not change absorption or wall thickness. References to another inspector are contextual links. Applying a rig does not apply that inspector's settings.

An environment can own a sun, sky, Earth contribution, room, ground, dust or other scene context. A preset that requires one of these checks the existing state. It must not install a second equivalent source or silently replace environmental data. Choosing a different ownership policy is an explicit scene transaction with undo support.

A screen, LED, luminous panel or solar disk has one energy owner. If an analytical light has a visible mesh representation, the two representations must share a single emission contribution. The visible mesh must not add the same energy again. Passive cards only reflect or block incident light. No negative-energy light is used to implement a flag.

Coordinates, units and fitting

The subject frame is right-handed, with +Z up, −Y front and +X right. Camera motion does not alter this frame. Internal lengths resolve to millimeters and numeric angle fields use radians.

B is the largest positive extent of the selected subject's bounding box. Lights, cards, floors, cameras and backgrounds are excluded. position_b, target_b and size_b contain dimensionless multiples of B; an adapter multiplies by the resolved millimeter value exactly once.

The ordinary origin is the selected subject's bounding-box center. Macro presets can use an explicit region. LED coupling presets instead require the named existing aperture or diffuser-plane center. A region or aperture that cannot be resolved is a blocking error, not an opportunity to guess its location.

Fitting happens once as an explicit authoring operation. The result records actual source dimensions and transforms. Moving the camera, changing a robot pose or switching a selected face does not trigger automatic refitting. Workcell examples use a fixed declared workspace envelope to avoid lighting changes between poses.

For a target-oriented area, its emitting front normal points toward target_b. Local up is the projection of world +Z into the light plane; when that projection is degenerate, use +Y. Apply roll_rad around the emitting normal. Width follows local right and height follows local up. Directional-sun vectors point along incoming photon travel and are unit length.

A numeric starting position is not a collision-free placement guarantee. Before authoring, check actual subject geometry, surrounding guards, optical openings and robot swept volumes. Sources must occupy free space appropriate to their role. A real internal LED is allowed inside a luminaire cavity, but never inside its opaque wall.

Relative contribution and calibration

Studio lights use the quantity reference_contribution_ev. These values are authoring ratios in a calibration scene. They are not measured lumens, watts, candela, lux or a universal conversion between point lights and area emitters.

The proposed CAL-LIGHT-001 scene contains a centered Lambertian sphere with radius 0.25B, linear diffuse reflectance 0.18, and B = 1000 mm. It has no floor, environment emission or additional source. The reference sphere is an idealized calibration object, not a claim about a measured commercial surface.

Measure each source separately using six fixed orthographic views along ±X, ±Y and ±Z. Compute the masked-sphere mean linear luminance for each view and average those six means. Keep camera geometry, sampling and scene version fixed. Use scene-referred linear values before display transforms. The reference fixture uses fixed 0 EV camera exposure; that is not an instruction to overwrite the user's camera.

Zero reference EV defines one arbitrary normalized response unit. A light at −1 EV targets half that reference signal; −2 EV targets one quarter. An adapter must solve and record the appropriate source gain. No such calibration has been performed for this package, and no gain values are invented here.

Resolve normalization at the applied physical scale, then preserve the resulting source state. Different source types have different native quantities; their numerical gains cannot be assumed interchangeable. Passive cards are excluded from per-source calibration and contribute through transport when the final rig is assembled.

For the explicitly editorial lunar fill, CAL-ENV-SUN-001 first measures the existing environment sun in the same reference fixture. That signal becomes the zero-EV reference for the added fill. The sun remains unchanged. If the environment source or its reference signal cannot be resolved, block this preset.

The quantity relative_solar_irradiance is also dimensionless. A value of 1.0 is an illustrative reference, not a measured lunar irradiance. The included solar angular diameter 0.0093 rad is marked approximate and illustrative. Solar direction is an authored input, not a mission ephemeris or a site-specific prediction. Neutral RGB solar color is not a measured spectrum.

The 24 numeric presets

Preset Catalog Mode Purpose
STU-001 LUZ-001 Studio One side softbox and a passive reflector
STU-002 LUZ-003 Studio Key, fill and rim with independent contributions
STU-003 LUZ-013 Studio White product separated by passive dark edge cards
STU-004 LUZ-012 Studio Black housing defined by broad side reflections
STU-005 LUZ-021 Studio Narrow reflection bands on polished metal
STU-006 LUZ-022 Studio Grazing source for existing brushed-metal orientation
STU-007 LUZ-031 Studio Bright-field glass with a rear panel and side flags
STU-008 LUZ-032 Studio Dark-field glass with rear-side strips
STU-009 LUZ-074 Studio External light around an already emissive display
STU-010 LUZ-071 Studio Populated PCB overview and low relief light
STU-011 LUZ-058 Studio Existing FDM layers revealed by a grazing strip
STU-012 LUZ-232 Studio Selected woodworking-joint region
STU-013 LUZ-233 Studio Consistent face-grain and end-grain comparison
STU-014 LUZ-101 Studio Car roof and side reflection bands
STU-015 LUZ-202 Studio Brake hardware lit through an actual wheel opening
STU-016 LUZ-215 Studio Fixed robot workcell and target-tray lighting
STU-017 LUZ-251 Studio Spacecraft integration stage, explicitly not orbital light
STU-018 LUZ-241 Studio Finite LED strip behind an existing diffuser
STU-019 LUZ-245 Studio Finite entrance source for an existing light guide
STU-020 LUZ-261 Lunar physical One rig-owned illustrative solar source
STU-021 LUZ-262 Lunar physical No added lights; existing environment sun
STU-022 LUZ-268 Lunar physical Idealized zero-source night diagnostic
STU-023 LUZ-271 Lunar physical No added lights; fixed-sun SELENE arm comparison
STU-024 LUZ-277 Lunar editorial Declared fill for a SELENE sample-vial communication view

Every preset keeps manual camera exposure fixed during comparisons. That requirement is checked separately from applying the lighting rig. The preset does not set exposure, white balance, tone mapping or the output image configuration.

Physical lunar and editorial modes

lunar_physical adds no atmospheric sky illumination, atmospheric haze or unexplained ambient fill. Terrain, spacecraft surfaces and other real objects may still reflect light. Darkness or occlusion must not be “repaired” with an undisclosed softbox.

STU-020 owns its solar source and therefore conflicts with an already emissive environmental sun unless ownership is explicitly transferred. STU-021 and STU-023 intentionally have empty lights arrays: their sole solar source is already owned by the environment. They require a resolved source before proceeding.

STU-022 is a zero-source diagnostic idealization. It is not a model of every lunar night and does not supply Earthshine or starlight. A black background alone does not establish zero environment illumination. If a physically brighter night study is wanted, its source, visibility, radiance and ownership must be supplied explicitly.

lunar_editorial labels deliberate additional light. STU-024 introduces a finite fill area so that a sample vial and gripper can be read in a presentation. It preserves the environment sun and requires an A/B with fill disabled at identical exposure. Its result must never be described as an unassisted natural-light lunar view.

SELENE poses, arm geometry, mounts, sample contents and actions are external scene inputs. The catalog does not invent robot dimensions or motion planning. A sequence study compares supplied snapshots or animation states under one recorded lighting configuration. An occluded grip or vial interface is allowed to remain dark in physical mode.

Capability checks and authoring workflow

  1. Resolve the selected subject, region or aperture and its coordinate frame.
  2. Read all required_capabilities for the numeric preset, together with the actual scene's material and environment requirements.
  3. Confirm one energy owner for each emitter, especially displays, LED representations and the sun.
  4. Verify external dependencies and source clearance. Confirm manual exposure is locked for comparison.
  5. Resolve normalized coordinates, source normalization and modifier geometry into a reviewable scene transaction.
  6. Apply that transaction only when all checks pass. Preserve undo and the prior scene variant.
  7. Render a small region first, retain an undenoised linear reference and record all resolved inputs.

If a required capability is unavailable, keep the scene unchanged and report its exact CAP-... identifier. Do not silently replace a finite emitter with a point, remove glass thickness, erase caustics, approximate a light guide with an emissive exit or add atmospheric fill. An explicitly chosen lower-fidelity alternative can be a separate, clearly labeled preset.

The validation arrays are future acceptance checks. They do not assert that calibration, renderer parity, image quality, optical engineering, fixture compliance, solder quality, robot safety or material performance has been established.