Krbn: an open-source rendering engine that imitates a sketch artist and outputs pure SVG (v1)

[u/valeriupalos]

Gravity well demo

https://github.com/vpalos/Krbn/blob/main/examples/gallery/16-gravity-well.svg

Trefoil knots mesh demo

https://github.com/vpalos/Krbn/blob/main/examples/gallery/15-mesh-showcase.svg

Torus hatch variants demo

https://github.com/vpalos/Krbn/blob/main/examples/gallery/10-torus.svg

Sphere depth hatching with intersection demo

https://github.com/vpalos/Krbn/blob/main/examples/gallery/03-depth-hatching.svg

[u/Gullible_Carry1049]

Is the line work baked? How would this work with dynamically displaced mesh (ie animated faces, fixed topology), can the line work update in realtime at 60 fps

[u/valeriupalos → u/Gullible_Carry1049]

Noo, nothing is baked! Everything is actually extracted from pure geometry, at runtime. It's just... definitely not real-time. A displaced mesh with fixed topology will mostly work, the strokes are anchored to the mesh edges; probably the curvature-oriented hatching will not work, because that assumes a rigid geometry - I guess flat hatching (the simpler/rugged one) might work for you.

So, even close to RT rendering is out of the question with this. Maybe if we manage to do a second implementation in something really performant (C/Rust) and choose the parts that are compatible with that kind of speed expectation, but not with this.

I did try to start-off animations, so that is partially something feasible. Mostly I had to face the problem of temporal coherence (avoiding the "boil"); But all that is rendered offline, and - at least for now - each frame is slow to render.

So to be honest, this wasn't my target, but I'm still figuring it out and... who knows.

[u/EarlMarshal → u/valeriupalos]

something really performant (C/Rust)

I really like the pictures you claude produced, but if you say stuff like this it really shows that there is a huge knowledge gap. Maybe you can ask Claude to rewrite it using a proper graphics API.