OptionalupdateUpdate the absorption coefficient κ (volumetric blending mode). All three geometry-material families implement it (gsplats phase 1, points phase 3, lines phase 4); optional only for exotic/legacy materials (VOLUMETRIC_BLENDING_SPEC.md).
OptionalupdateThe §6.2 mesh appearance knobs: wrapped diffuse, specular, and the
opaque-mode cutout threshold.
Optional, and — unlike updateAbsorption above — genuinely so rather than for
legacy reasons: only the mesh materials implement them, because mesh is the
only geometry type that shades. The other three are emissive per-element sprites
with no surface orientation, so there is no shade term for a floor to lift.
That makes the optional-chained call site in applyMeshAppearance the type gate:
a points material simply has no updateAmbient.
OptionalupdateOptionalupdateOptionalupdateOptionalupdateOptionalupdateOne physically based knob (material="physical" meshes only — the two wrappers
in rendering/materials/mesh-physical/). Same optional-chained gate as the
house knobs above: a house or emissive material simply lacks it.
OptionalupdateLuxar refract_data (physical glass only, spec §3.4 Phase 3): draw the glass
after the emissive data so it refracts it. Same optional-chained gate.
OptionalupdateOptionalupdateOptionalupdateOptionalapplyApply a blending mode to this material in-place.
All four geometry materials implement it today (the optionality is
kept for exotic/legacy materials the generic fallback still covers).
Call this instead of writing mat.blending/mat.blendEquation
directly so type-specific factors, defines (LUXAR_VOLUMETRIC /
LUXAR_MAX_RGB_CONTRIBUTION), and uniforms stay in sync.
Type guard target: does this material have our update* methods?
Deliberately does NOT extend
CameraAwareMaterial, and that is a correction rather than a relaxation. Two independent reasons:updateCameraParams. Camera uniforms are broadcast byMaterialManager, not from here, so requiring the method described a dependency this interface does not have.isLuxarMaterialnever checked for it. The guard testsupdateIntensity+updateGammaonly, andlayer-apply.tscasts toLuxarMaterialon the strength of that — so the type was already over-claiming relative to the check that produces it.Mesh is what surfaced this: it is a real leaf material with the full layer-control surface, but it draws actual geometry and therefore has no screen-space extent to recompute, so it has no
updateCameraParamsat all. The tempting fix was an empty one on the material; that would be a lie, and would also cost a per-frame call per node if it ever joined the broadcast registry. Materials that ARE camera-aware still declare it viaCameraAwareMaterialand are detected withisCameraAwareMaterialwhere it matters (the picking system does exactly this).