Text & font support

[zeeyang]

It would be cool if curv could do text engraving for 3D prints. Font is obviously a deep rabbit hole. I just want to share my research here and see if it's feasible to have some basic text support.

Libfive does text by hardcoding character -> shape lookup into stdlib. This only support very limited character set and doesn't scale to custom fonts. https://github.com/libfive/libfive/blob/master/libfive/stdlib/stdlib_impl.cpp#L1284

SDF atlas seems like the more promising approach. Multi-channel SDF atlas can preserve miter corners. This is exciting since it can be scaled to stencil anything. https://github.com/Chlumsky/msdfgen

To support SDF atlas, I think there are few preprequisites:

• raster import in curv
• update shader to work with stencils https://github.com/Chlumsky/msdfgen#using-a-multi-channel-distance-field

[doug-moen]

I agree that SDF atlas is the most promising approach right now. I had one other idea (https://github.com/dali3d/dali) but it is super ambitious and deferred until Curv is ported to WebGPU.

So raster import is the next step, and this is a feature I want to add to Curv for other reasons as well.

[DejayRezme]

Maybe things like that could also be used to add more brep features like sketches that you can extrude or loft.

[doug-moen]

I've been discussing SVG import with @lf94. He is developing an SVG import tool, see https://github.com/curv3d/svg2curv. @DejayRezme you could try out svg2curv if you want to extrude or loft a sketch.

We have discussed Chlumsky/msdfgen, and noted that while it could be used for importing SVG files and fonts into Curv, it has limitations because it quantizes SDFs into a pixel representation that can't represent details smaller than a pixel, and sometimes there are artifacts produced by the MSDFgen algorithm.

An interesting alternative is Will Dobbie's "vector texture" data structure, which could be used to import bezier-based fonts and SVG paths into Curv using a mathematically exact representation (instead of a quantized approximation). Based on Dobbie's WebGL demo, it looks like the performance should be decent. See the blog post http://wdobbie.com/post/gpu-text-rendering-with-vector-textures/ and the WebGL demo http://wdobbie.com/pdf/.

My plan is to first transition Curv from OpenGL to WebGPU <issue #146>. Then switch from using fragment shaders to compute shaders for rendering SDFs. Then experiment with efficient representations like MSDF and vector texture based SDFs, looking for ways to use compute shaders for processing and rendering them.

[DejayRezme]

Oh wow that vector texture looks brilliant. And WebGPU is awesome, finally an API that can be used both on desktop and mobile and web! I guess that would also mean curv could easily be made to run in browser.

I really just wanted to see if I could code the design for a quadricycle with jscad but then found CascadeStudio and now curve. But now I'm curious what the limitations are if you'd try to use curv for CAD. Theoretically it should allow a lot more freedom to design and generate surface detail and also support physical based lighting.

Maybe another idea might be sparse voxel octrees as a caching / optimization / filtering structure. Instead of using vector textures for the special case of text and for each glyph, you could use SVO that subdivide the distance functions of a compound object. Not sure how that would look like or if that makes sense.

It could also allow to cache signed distance fields, and to then filter that cache at a lower resolution for optimization and lighting. The pdf demo is very resistant to aliasing but once the glyphs become too small you see aliasing. Maybe they could also help with transparency. Not sure just thinking out loud :)

[doug-moen]

Lee (@lf94) is creating CAD models in Curv, and posting about them on Discord.
Creating surface detail (and 3D printing it) is one of the things that Lee has been exploring.
Try this invite link: https://discord.gg/ZSPXaMNWfW

[doug-moen]

There have been experiments in physical based lighting, and there's a low level experimental API for defining your own pixel shader in Curv for defining a lighting model, but you need expertise in CG lighting model math to use it. In the future, I would like to add a high level API for PBR (Physically Based Rendering) based on an existing open source project.

[doug-moen]

If you dig around in Will Dobbie's blog, you'll find another post about how he addressed the aliasing problem, and another demo called War and Peace.

In addition to octrees and vector textures, I am also thinking about BVH (bounding volume hierarchies), tile based rendering, and caching an SDF in a voxel grid, as ways to speed up the rendering of complex SDF scenes. Some of the game developers using voxels to speed up SDFs are using trees of voxel grids, and mipmaps, to make hierarchical structures that reduce memory requirements. So there is a lot of interesting and fresh territory to explore.