[p5.js 2.0 Bug Report]:When drawing using textToModel, depending on the font, the face normals may not be very clean.

[inaridarkfox4231]

Most appropriate sub-area of p5.js?

• Accessibility
• Color
• Core/Environment/Rendering
• Data
• DOM
• Events
• Image
• IO
• Math
• Typography
• Utilities
• WebGL
• Build process
• Unit testing
• Internationalization
• Friendly errors
• Other (specify if possible)

p5.js version

2.0.5

Web browser and version

Chrome

Operating system

Windows11

Steps to reproduce this

Steps:

1. Create a model of the letter "H" using textToModel().
2. No strokes are used, only fills and lighting.
3. The appearance of the top and bottom by lighting doesn't look very clean.

Snippet:

demo

let font;
let geom;

async function setup() {
  createCanvas(400, 400, WEBGL);

  // Using Source Serif for this example:
  font = await loadFont('https://inaridarkfox4231.github.io/assets/fonts/SourceSerif4.ttf');

  geom = font.textToModel("H", 320, 0, { sampleFactor: 2, extrude: 1 });
  geom.clearColors();
  geom.normalize();
}

function draw() {
  background(0);
  noStroke();
  orbitControl();
  fill("white");
  noStroke();
  ambientLight(128);
  const s = TAU*frameCount/360;
  const t = TAU*frameCount/240;
  directionalLight(255,255,255,cos(s),sin(s)*cos(t),sin(s)*sin(t));
  scale(min(width, height) / 300);
  model(geom);
}

This is more of an aesthetic issue than a bug, so it may be inappropriate, but I thought I'd bring it up because it bothered me.

[inaridarkfox4231]

I think it would be nice if both the top and bottom surfaces were displayed nicely like this.

demo

2025-09-08.23-46-12.mp4

textToModel:

demo(textToModel)

2025-09-08.23-50-41.mp4

[inaridarkfox4231]

This is completely unrelated, but the bug in question hasn't been fixed, so if I try to check it on My smartphone, I have to be careful not to swipe at outside the canvas.

[davepagurek]

I haven't debugged this sketch yet, but based on your recording it looks like there's some z-fighting going on as if there are two faces directly on top of each other. If this is the same font as you're using here #8079 (comment), then it looks like that's because this font is drawing letters using multiple shapes, and those shapes have slightly different normals because we're smoothing them independently. So luckily this doesn't seem to be an across-the-board problem, but still one worth figuring out. Seems very related to your suggestion in that same comment about wanting to get the combined outline rather than the separate shapes the font defines.

I think (but would need to confirm) that libtess resolves the overlaps already when drawing the front face? So one option could be to tesselate the front face, and then extract the boundary edges from those triangles to get a combined outline and extrude those rather than using the font's contour lines directly, which contain multiple shapes. This probably also would fix #7474, which is caused because the side faces are constructed in a different way from the front faces. This would be no less efficient than we currently do as we are already using libtess on the front faces.

The downside of the above is that this would only apply to textToModel, and wouldn't immediately address your comment about textToContours. Since that one also works in 2D mode, we don't currently have access to libtess there, so we'd have to be OK adding to the 2D mode file size to include it. Alternatively, we could explore using a different library (I mentioned polybooljs earlier) to get a combined shape, but that also adds a new dependency. Anyway I think it's still beneficial to address textToModel even if we don't solve it for all the other text methods immediately.

[VANSH3104]

@davepagurek Can I give it a try and look into it?

[davepagurek]

Sure thing, thanks @VANSH3104! Feel free to let me know here or on Discord if you need any pointers on how to go about doing this.