Chestnut Labs G-code Preview
    Preparing search index...

    Recipes

    Task-focused snippets. All use the shared <GcodePreview> surface unless noted.

    Clip to a layer range and scrub within it — no geometry rebuilds, just draw-range updates:

    <GcodePreview source={file} layerRange={[0, 73]} scrub={0.5} />
    
    <GcodePreview source={file} quality="tubes" colorMode="feature" cameraMode="orthographic" />
    

    colorMode is capability-gated — the stack colors by a feature only when the dialect actually disclosed it (see ToolpathIR & the capability model).

    .gcode.3mf containers can hold several sliced plates. Select one with parseOptions.plate:

    <GcodePreview source={file} parseOptions={{ plate: 1 }} />
    

    By default the adapters create a batteries worker (every dialect adapter + .gcode.3mf) via the bundler-native new Worker(new URL(...)) pattern. Pass createWorker to supply your own — a slim build, custom dialects, or a CSP-friendly setup:

    <GcodePreview source={file} createWorker={() => new Worker(new URL('./my-worker.js', import.meta.url), { type: 'module' })} />
    

    Feed a normalized ProgressObservation and the preview maps it onto the toolpath with honest, tiered confidence — a precise marker when the source position is known, an uncertainty band when it is approximate, and user scrub always winning. See Live progress & motion model and the progress signal contract.

    <GcodePreview source={file} progress={observation} />
    

    renderStill from @chestnutlabs/gcode-renderer-three produces a single non-interactive image from a Worker OffscreenCanvas, an Electron hidden window, or headless Chromium — no interactive viewer required. See the still-render reference.

    Mount multiple <GcodePreview> instances — each owns its own worker and renderer. See the multi-gcode note for the current guidance and its trade-offs.