Luxar Viewer API Documentation - v2026.9.22
    Preparing search index...

    Module rendering/line-geometry

    Line Geometry Creation for Luxar

    Builds the instanced-quad base geometry used by LineMaterial and LinePickingMaterial, plus the texture-backed per-segment storage (depth-sorting Phase 4 lines migration). Each line segment is rendered as a quad expanded in screen space by the vertex shader.

    Per-segment data lives in an RGBA32F line texture (6 texels/segment — see ./element-texture-layout for the layout authority) sampled by the vertex shader via texelFetch; the only per-instance attribute is aSortedIndex (Uint32), which maps the draw slot to a storage slot so draw order can be permuted without rewriting segment data. The per-texel layout is FIXED regardless of which optional fields the dataset has (pool geometries are reused across nodes, so the layout never varies — this also retires the interleaved era's colormap-toggle spec-set rebuild):

    texel rgba
    0 startPos.xyz, startWidth
    1 endPos.xyz, endWidth
    2 startColor.rgb, startSharpness
    3 endColor.rgb, endSharpness
    4 segmentLength, startJointCode, endJointCode, 0
    5 startScalar (0.0), endScalar (0.0), alphas (1.0, 1.0)

    texel5.xy are the colormap scalars and texel5.zw the per-endpoint opacity alphas (from an RGBA color column — volumetric phase 4); ALL FOUR are written UNCONDITIONALLY — pool textures are reused, so leaving them unspecified would let a previous tenant's values leak through. 0.0 is the no-scalar identity and 1.0 (opaque) the per-element-opacity identity. texel4.w is zero-filled for the same reason (deterministic on reused pool texels, so no previous tenant's value leaks through) even though nothing reads it yet.

    Texture lifetime = geometry lifetime: attachLineStorage registers a dispose listener on the geometry, so every dispose site (pool evictors, pool.dispose(), the non-pool rebuild) frees the texture with the geometry — no site-by-site bookkeeping.

    All source arrays consumed by the texel writer arrive as the worker projection's Float32 output (ProcessedLinesData — endpoint interpolation always emits Float32), the per-endpoint joint codes included: a code is a small exact integer (a sentinel, or a storage slot offset by 1 or 3 with the sign carrying which of the partner's endpoints is the shared one), so Float32 holds it exactly and no widening is needed.

    Mirrors point-geometry.ts / gsplat-geometry.ts so the geometry types share one storage model; the geometry-agnostic helpers live in ./element-storage.

    LineTexelSource
    InstancedLinesMeshConfig
    MAX_EXACT_JOINT_SLOT
    createLineQuadGeometry
    attachLineStorage
    getLineTexture
    clampJointCode
    writeLineTexels
    computeLineBounds
    stampLinePresenceFlags
    createInstancedLinesMesh
    updateInstancedLinesMesh