* 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 commit44b58d8e10) * 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 treef8a423b21f. 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 donor3b892eab5e. 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 tree6b84c8adpasses 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 treec70d00d1. 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>
13 KiB
SolidCraft material concept catalog 0.2.0
Scope and status
This catalog defines 600 original conceptual visual-appearance recipes in 60 families of 10. It is planning data, not a downloadable shader library, a set of measured optical properties, or a material-selection certificate. MAT-001 through MAT-200 keep the semantic identities of the original catalog. MAT-201 through MAT-600 add 40 focused families for automotive, industrial, electronics, additive manufacturing, woodworking, DIY, LED, aerospace, space and SELENE work.
Every record has an English name, family, domains, description, use cases, optical model, editable controls, scale policy, proposed authoring method, renderer dependencies, content priority, relative cost, proposed validation checks and original-authoring provenance. Names describe intended appearances. They do not certify the underlying alloy, polymer grade, mineral composition, coating process or flight readiness.
Some recipes describe a composite surface, a cut section, a process state or an overlay. They are intentionally more than a single colour or roughness setting. An overlay must preserve the host material; a section may require several material regions; an open mesh, pore network, fibre bundle or optical facet may need real render geometry.
New families
| ID range | Family | Recipes |
|---|---|---|
| MAT-201–MAT-210 | Automotive paint stacks and correction states | 10 |
| MAT-211–MAT-220 | Automotive exterior trim and films | 10 |
| MAT-221–MAT-230 | Automotive brakes and contact surfaces | 10 |
| MAT-231–MAT-240 | Automotive tyres and sealing profiles | 10 |
| MAT-241–MAT-250 | Automotive glazing and optical covers | 10 |
| MAT-251–MAT-260 | Automotive cabin and soft trim | 10 |
| MAT-261–MAT-270 | Industrial machining signatures | 10 |
| MAT-271–MAT-280 | Industrial protective treatments | 10 |
| MAT-281–MAT-290 | Industrial wear and service overlays | 10 |
| MAT-291–MAT-300 | Industrial belts meshes and packing | 10 |
| MAT-301–MAT-310 | PCB constructions and fabrication regions | 10 |
| MAT-311–MAT-320 | Electronic bonding and contact finishes | 10 |
| MAT-321–MAT-330 | Electronic packages and encapsulants | 10 |
| MAT-331–MAT-340 | Electrical insulation and cable constructions | 10 |
| MAT-341–MAT-350 | Battery and thermal-management surfaces | 10 |
| MAT-351–MAT-360 | Additive feedstock appearances | 10 |
| MAT-361–MAT-370 | FDM surface pathways and post-processing | 10 |
| MAT-371–MAT-380 | Resin-printing process appearances | 10 |
| MAT-381–MAT-390 | Powder-printing and sintered states | 10 |
| MAT-391–MAT-400 | Printer hotends motion parts and build plates | 10 |
| MAT-401–MAT-410 | Additional timber and bamboo appearances | 10 |
| MAT-411–MAT-420 | Wood cuts joinery and assembled patterns | 10 |
| MAT-421–MAT-430 | Woodworking and DIY finishes | 10 |
| MAT-431–MAT-440 | DIY panels adhesives and joint surfaces | 10 |
| MAT-441–MAT-450 | LED emitters and conversion layers | 10 |
| MAT-451–MAT-460 | LED diffusers and light guides | 10 |
| MAT-461–MAT-470 | LED lenses reflectors and optical hardware | 10 |
| MAT-471–MAT-480 | Aerospace composite constructions | 10 |
| MAT-481–MAT-490 | Aerospace cores and lightweight sections | 10 |
| MAT-491–MAT-500 | Aerospace protective and functional skins | 10 |
| MAT-501–MAT-510 | Space thermal blankets and films | 10 |
| MAT-511–MAT-520 | Space solar-array and optical-device appearances | 10 |
| MAT-521–MAT-530 | Space harness and mechanism interfaces | 10 |
| MAT-531–MAT-540 | Lunar mare-style ground and rock concepts | 10 |
| MAT-541–MAT-550 | Lunar highland-style rocks and ground concepts | 10 |
| MAT-551–MAT-560 | Lunar dust deposition overlays | 10 |
| MAT-561–MAT-570 | SELENE rover mobility and structural appearances | 10 |
| MAT-571–MAT-580 | SELENE arm gripper and sampling-tool appearances | 10 |
| MAT-581–MAT-590 | SELENE transparent sample containment and viewing | 10 |
| MAT-591–MAT-600 | SELENE opaque sample cassettes caps and seals | 10 |
SELENE component mapping
These are candidate appearance assignments for design discussion, not final engineering material selections. Apply them to distinct CAD components or face regions. Keep sample identities, engineering materials and the bill of materials independent of appearance changes.
| SELENE area | Candidate material IDs | Intended distinction |
|---|---|---|
| Mare-style terrain and collected fragments | MAT-531–MAT-540 | Packing, disturbance, basalt-like fractures, glass-like shards and breccia-like mixtures; no site-specific identification. |
| Highland-style terrain and samples | MAT-541–MAT-550 | Fracture, cut surface, clast structure and granular assemblies; no mineral percentages or measured reflectance. |
| Dust on hardware and containment | MAT-551–MAT-560 | Sparse, dense, recessed, transferred, cleaned and internally settled deposits; all preserve their host. |
| Wheel rim, shell and grousers | MAT-561, MAT-562, MAT-563 | Machining, forming and localized contact finishes remain separate. |
| Candidate compliant wheel constructions | MAT-564, MAT-565, MAT-566 | Spring wire, woven mesh and sheet flexure geometry; no validated mobility performance. |
| Chassis, hub covers and joints | MAT-567, MAT-568, MAT-569, MAT-570 | Anodized faces, sealing lands, articulated components and sensing-cover regions. |
| Arm tube and wrist | MAT-571, MAT-572 | Composite orientation versus machined-metal operation marks. |
| Gripper jaws and contact pads | MAT-573, MAT-574 | Geometric contact teeth versus separate dielectric pad inserts. |
| Scoop, abrasive tip and transfer funnel | MAT-575, MAT-576, MAT-577 | Formed surfaces, mixed abrasive regions and polished internal transfer faces. |
| Arm routing, capture liner and identification | MAT-578, MAT-579, MAT-580 | Cable-guide body, removable liner and original tool markings. |
| Rigid transparent vessels and windows | MAT-581, MAT-582, MAT-583, MAT-587, MAT-588 | Ampoule, vial, crystalline-looking window, capillary and double-wall interfaces. |
| Transparent liner, bag and inspection mount | MAT-584, MAT-585, MAT-586 | Independent inner liner, folded film and embedding-medium concepts. |
| Inspection witness and coated cassette lid | MAT-589, MAT-590 | Original etched markings versus an explicitly modelled antireflection stack. |
| Metal sample bodies | MAT-591, MAT-592, MAT-593 | Aluminium-like machining, titanium-like brushing and stainless-like polished interiors. |
| Sample insert and opaque cassette | MAT-594, MAT-595, MAT-600 | Separate insert material, polymer-body candidate and individually identified machined cells. |
| Cap and sealing candidates | MAT-596, MAT-597, MAT-598, MAT-599 | Threaded cap, plated metal gasket, fluoropolymer-like ring and alternative elastomer ring. |
| Thermal blankets and films | MAT-501–MAT-510 | Layer order, folds, spacer mesh, seams and exposed multilayer edges. |
| Solar arrays and optical devices | MAT-511–MAT-520 | Optical cover, cell-like regions, interconnects and reference-device concepts. |
| Harnesses and mechanism interfaces | MAT-521–MAT-530 | Braids, films, insulators, bellows, joining regions and original labels. |
Lunar visual constraints
- Use a vacuum scene. Regolith and dust are particles, packed ground or surface deposits; they are not terrestrial atmospheric haze, smoke or fog.
- Track relief, scoop disturbance and transferred dust are authored scene states unless a separate validated granular simulation produces them.
- Do not bake illumination or a bright edge into a dust texture. Preserve direct-light shadow structure and the selected environment's actual illumination.
- Lunar-inspired names do not establish sample provenance, mineralogy, maturity, albedo or a measured bidirectional reflectance function. Any later measured dataset needs its own source and conditions.
- Dust-covered solar cells, optics and seals are visual comparisons only. They do not provide power loss, optical throughput, contamination, friction or sealing measurements.
Renderer dependencies and representation choices
The capability_requirements entries refer to the shared CAP-001 through CAP-104 registry. Content priority describes authoring priority, not a guarantee that the required renderer feature already exists. A P1 content item can depend on a P2 engine feature. Compatibility checks must inspect the full dependency list.
| Requirement | Relevant capabilities | Consequence for the catalog |
|---|---|---|
| Base material, Fresnel, physical texture scale and colour handling | CAP-017, CAP-018, CAP-033, CAP-040, CAP-057 | Maintain a common calibrated-or-declared baseline; keep data maps out of colour transforms. |
| Directional manufacturing and fibre finishes | CAP-020, CAP-034 | Brushing, turning, extrusion, winding and grain need stable local coordinates. |
| Coatings and non-destructive surface states | CAP-021, CAP-038, CAP-039 | Keep substrate, film, printing, wear and deposit masks independently editable. |
| Real refractive thickness and nested media | CAP-025, CAP-026, CAP-027 | Containers, films, lenses, bubbles and liquid/sample boundaries need correct interfaces. |
| Subsurface and bulk scattering | CAP-028 | Diffusers, filled resins, translucent polymers and liquids require scale-aware scattering. |
| Metal flakes and specialized optical structures | CAP-023, CAP-031, CAP-098 | Sparkle, thin-film interference and multilayer interference are distinct mechanisms. |
| Diffraction, retroreflection and spectral conversion | CAP-099, CAP-100, CAP-101 | These are not ordinary roughness, a camera bloom filter, or constant RGB emission. |
| Excitation history and saved temporal emission state | CAP-102 | Phosphorescence requires a state; static renders must record the state they depict. |
| Lenslets and optical microgeometry | CAP-103 | Facets and micro-lenses must actually redirect rays when physical behaviour is claimed. |
| Fibre, mesh, pore and particulate geometry | CAP-036, CAP-044, CAP-104 | A normal map cannot create real openings, silhouette changes or internal interfaces. |
| Robust CAD assignment and precision | CAP-090, CAP-097 | Keep appearance attached to stable component/face references; do not change the engineering B-rep. |
Emission from an LED or display can be an authored steady source without simulating semiconductor physics. A physical phosphor-conversion model is a different capability: it must respond to excitation through CAP-101. Likewise, RGB spectral-looking colour, wavelength-dependent transport, polarization, interference and diffraction are not interchangeable. A sapphire-like window using a scalar approximation must not claim birefringent accuracy; that requires specialized optical support such as CAP-032 within its documented scope.
Units, data and clean-room boundaries
- Use mm for scene lengths, radians for stored angles and Z-up coordinates. If an optical control is entered in another unit, convert it explicitly; never silently mix optical-film units and model dimensions.
- No numerical IOR, conductivity, friction, thermal, structural or emissivity values are fabricated in these recipes. Add measured values only with source, grade, conditions, spectral range where relevant and uncertainty or applicability information.
- Engineering material selection remains separate from appearance. No recipe certifies flight readiness, vacuum compatibility, outgassing, sample cleanliness, sealing, electrical performance or a manufacturing result.
- Descriptions and proposed procedural recipes are original authoring under
ORIGINAL-2026-10-CATALOG. No commercial material presets, proprietary CAD extraction, GPL/LGPL/AGPL source code or copied artwork were used to create this catalog. - Optional later reference capture, measured data, photographs or external assets require their own provenance and redistribution review. AI-assisted image creation would remain authored imagery, not automatically a measured BSDF or validated physical texture set.
- The authoring script is an offline data/document-generation aid, not application runtime code. It introduces no Python dependency into SolidCraft's Rust application.
Validation and publication gate
The script verifies counts, ID sequence, name uniqueness, complete English-field structure, accepted priority/cost values, capability-ID bounds and original provenance. Per-recipe physical and visual checks remain proposed, not completed.
Before publishing an executable preset, implement its recipe, resolve required capabilities, render a neutral coupon/curved-part/edge set, check physical scale and filtered detail, validate CPU/GPU behaviour within declared tolerances, record any approximations, and preserve source and resource versions. Show one of three states in the UI: available with supported model, available with an identified approximation, or not yet implemented. Never replace an unsupported model silently.
Treat materials.json as the canonical planning data. Future importers must validate the schema, required capabilities and provenance before applying a recipe.