@pmndrs/bvh
    Preparing search index...

    Interface BvhBoundsTreeOptions

    Options of computeBoundsTree and new BvhBoundsTree(geometry, options): three-mesh-bvh's MeshBVH options, mapped to ours where they map (docs/internals/three.md, "Build options").

    interface BvhBoundsTreeOptions {
        builder?: TinyBvhBuilder;
        indirect?: boolean;
        layout?: GpuLayoutMeshBvh;
        maxDepth?: number;
        maxLeafSize?: number;
        maxLeafTris?: number;
        onProgress?: (progress: number) => void;
        range?: unknown;
        setBoundingBox?: boolean;
        snapshot?: BvhGeometrySnapshot;
        strategy?: number;
        targetLeafSize?: number;
        type?: BvhBoundsTreeType<unknown>;
        useSharedArrayBuffer?: boolean;
        verbose?: boolean;
    }
    Index
    builder?: TinyBvhBuilder

    The tinybvh builder; default the one prepareBoundsTrees loaded.

    indirect?: boolean

    Accepted and ignored. The tree never reorders the geometry's index (its triangle records are copies carrying their original index), which is what three-mesh-bvh's indirect: true does. resolveTriangleIndex maps a tree position.

    A tree already built for this geometry, in our layout (from generate, a worker pool or deserializeLayout): the build is skipped. It must hold the geometry's triangles, numbered in index order. Records or indexed: an indexed tree stays indexed (16 bytes per triangle, corners read from the geometry's positions, CpuMeshBvh's corners: 'positions').

    maxDepth?: number

    Accepted, not honoured: tinybvh decides the depth (boundsTree.depth), and a value below the built tree's depth logs a warning once. The ray walk's stack holds 64 entries, and a raycast on a deeper tree throws a RangeError (a tinybvh tree that deep takes a degenerate mesh). The box walk (traverse) has no such limit.

    maxLeafSize?: number

    Largest leaf, in triangles; larger leaves are cut in half. Our layout holds 1 to 8 triangles per leaf: a larger value (three-mesh-bvh's default is 10) gives 8, and one below 1 gives 1. tinybvh's SAH makes smaller leaves where they pay. Default 8.

    maxLeafTris?: number

    three-mesh-bvh's deprecated name for maxLeafSize.

    onProgress?: (progress: number) => void

    Called with 0 before the build and 1 after it. tinybvh builds in one call and reports nothing between.

    range?: unknown

    Not supported: the tree holds every triangle, and raycasts follow the draw range instead. Throws when set.

    setBoundingBox?: boolean

    Sets geometry.boundingBox from the tree when the geometry has none. Default true, as three-mesh-bvh. boundsTree.refit() keeps a box set this way current; a box three computed (or you set) is left alone.

    The geometry as layout was built from it (snapshotGeometry, taken before the build started; GenerateMeshBvhWorker does this). The tree counts as built from those versions, so edits made while the build ran make it stale (raycasts fall back to three's until refit). Default: the geometry as it is now.

    strategy?: number

    Accepted for three-mesh-bvh code; every value builds the same tree: tinybvh's default builder (binned SAH over a grid of cells, "SIMD Bonsai"), whose trees have a lower SAH cost than a centre or average split. There is no CENTER or AVERAGE builder here. Values other than 0, 1 and 2 throw.

    targetLeafSize?: number

    three-mesh-bvh 0.9's name for maxLeafSize. Wins over the other two names.

    type?: BvhBoundsTreeType<unknown>

    three-mesh-bvh's ComputeBVHOptions.type, for computeBoundsTree: the tree class to build. Default BvhBoundsTree (MeshBVH); PointsBVH, LineSegmentsBVH, LineLoopBVH and LineBVH build trees for Points and the line objects (src/three/points-lines.ts).

    useSharedArrayBuffer?: boolean

    Accepted and ignored: no SharedArrayBuffer is needed (docs/internals/PARITY.md, 4.8).

    verbose?: boolean

    Accepted and ignored.