The goal for this vanilla TS renderer is to have visual diffing on GitHub and a renderer that works without a browser environment. Most 3D renderers focus on realtime speed, not file size and runtime portability. I think in practice we will configure the subdivisions at something like 64 for a good file size tradeoff
This doesn't answer the question. If you're doing all this work in JS to render a static SVG, why not just "do it right" and output a static PNG instead?
The top of the PCB (the lines etc) are computed as an SVG, i would have to have an SVG rasterizer just to begin with that approach, then would be limited by what images I could rasterize. It would also be much much slower than quickly computing matrices
I was going to suggest raylib for server-side rendering, but it adds a non-JS dependency. Apparently it has optional support for rendering SVGs to textures.
Comments
The goal for this vanilla TS renderer is to have visual diffing on GitHub and a renderer that works without a browser environment. Most 3D renderers focus on realtime speed, not file size and runtime portability. I think in practice we will configure the subdivisions at something like 64 for a good file size tradeoff
Why use SVG for this, though? This could be easily implemented as pure JS software rasterizer without all the tessellation workarounds.
This doesn't answer the question. If you're doing all this work in JS to render a static SVG, why not just "do it right" and output a static PNG instead?
The top of the PCB (the lines etc) are computed as an SVG, i would have to have an SVG rasterizer just to begin with that approach, then would be limited by what images I could rasterize. It would also be much much slower than quickly computing matrices
You might find that librsvg works for you.
I was going to suggest raylib for server-side rendering, but it adds a non-JS dependency. Apparently it has optional support for rendering SVGs to textures.
https://github.com/raysan5/raylib/discussions/3741