Batch Low Poly Background Generation with the Runner and API

POST one job to the local runner

Generative tool: the request body is just the options. curl against the runner's run endpoint. The runner saves the SVG locally and returns metadata.

curl -s -X POST \
  127.0.0.1:9789/v1/tools/svg-polygon-gen/run \
  -F 'options={"polyPoints":40,"polyWidth":1600,"polyHeight":900,"polyColors":["#0f172a","#1e3a8a","#3b82f6","#93c5fd"]}'

# -> { outputPath, filename: "low-poly-bg.svg",
#      mimeType: "image/svg+xml", sizeBytes, metrics:{Points,Triangles} }

Generate-once, cache-by-key (the right pattern)

Because there is no seed, do NOT regenerate on demand. Generate the first time a key is requested, store the SVG, and serve from cache forever after.

function backgroundFor(key):           # key = userId, pageSlug, ...
    cached = store.get(key)
    if cached: return cached
    svg = runner.run('svg-polygon-gen', {
        polyPoints: 50,
        polyColors: paletteFor(key)        # deterministic palette is fine
    })
    store.put(key, svg)                     # SVG is now stable for this key
    return svg

Anti-pattern: assuming a seed makes it reproducible

This does NOT work. The tool ignores any seed-like field — points are Math.random(). Two identical calls return different meshes.

# WRONG: there is no seed parameter
runner.run('svg-polygon-gen', { seed: hash(userId), polyPoints: 50 })
runner.run('svg-polygon-gen', { seed: hash(userId), polyPoints: 50 })
# -> two DIFFERENT SVGs. 'seed' is silently ignored.
# Fix: generate once and cache (see previous example).

Batch a folder of palettes

Loop over palettes you control, generate one background each, and minify. Each output is unique geometry; the palette is the deterministic part you vary.

for name, palette in palettes:
    svg = runner.run('svg-polygon-gen', {
        polyPoints: 60, polyWidth: 1200, polyHeight: 600,
        polyColors: palette
    })
    write("out/" + name + ".svg", svg)
    # optional: server-safe minify pass
    runner.run('svg-pro-minifier', svg) -> "min/" + name + ".svg"

Self-host with your own seeded triangulation

If you truly need reproducible per-user meshes, re-implement Bowyer-Watson in Node with a seeded PRNG. The algorithm is pure JS with no native deps. The JAD tool's geometry rules are documented in the algorithm guide.

import seedrandom from 'seedrandom'
const rng = seedrandom(userId)            // deterministic points
const pts = anchors(W,H).concat(
  Array.from({length:N}, () => [rng()*W, rng()*H])
)
const tris = bowyerWatson(pts)            // your own copy
// now user X always gets the same mesh

There is no seed parameter. Any seed-like field is silently dropped and points are generated with Math.random(), so repeated calls with identical options return different meshes. Use the generate-once-and-cache pattern instead.

Because the tool is unseeded, you cannot recompute 'the same' background from a user id. Generate it once, store the SVG keyed by the user id, and serve from that store; otherwise the avatar background changes on every load.

The engine validates number options against the schema and throws if polyPoints is below 8 or above 300 (similarly for width/height). Clamp values in your script before sending to avoid failed jobs.

There is no public batch REST service. Automation goes through the local @jadapps/runner's endpoint on 127.0.0.1:9789. The tool being server-safe means it runs in engine mode there — but you still run the runner yourself.

The Pro+ web tool falls back to in-browser processing if the runner is down, which is fine interactively but defeats unattended batching. For scripts, check GET /v1/health first and keep the runner alive.

The engine colours each triangle a flat palette-band colour at fixed 0.92 opacity, whereas the browser blends between swatches and varies opacity by Y. Same algorithm, slightly different colouring — design your palettes to look good banded.

svg-polygon-gen takes no input file. Any uploaded part is irrelevant — the request is defined entirely by the options object. Keep payloads small by sending options only.

Each job is independent and fast (milliseconds in engine mode even near the 300-point maximum), so large batches are practical. Cache results so you never pay the generation cost twice for the same key.