[2.0 beta 1] textToModel adds extra face?

[davepagurek]

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 beta 1

Web browser and version

Firefox

Operating system

MacOS

Steps to reproduce this

I was testing out textToModel here, combining it with a shader to displace vertices: https://openprocessing.org/sketch/2513601

I notice that when the vertices get displaced, sometimes the fills go outside of the strokes in a straight line:

It looks like there's an extra face here, or a face that hasn't been subdivided, so that when the endpoints move, it draws a straight line between them, rather than following the warped curve.

This has something to do with p5.Font.textToModel here probably:

p5.js/src/type/p5.Font.js

Line 120 in 2ec3557

const geom = this._pInst.buildGeometry(() => {

When drawing the front faces, I've called endContour(CLOSE), I wonder if the CLOSE is causing an extra face to be made?

[HarshitaKatariya]

I was looking into the issue related to textToModel and vertex displacement artifacts. The report mentions endContour(CLOSE), but I couldn't find any method in p5.js that accepts CLOSE as an argument.

Could you clarify if this is a mistake in the issue description, or if there's an undocumented feature related to endContour() that I'm missing?

[perminder-17]

I was looking into the issue related to textToModel and vertex displacement artifacts. The report mentions endContour(CLOSE), but I couldn't find any method in p5.js that accepts CLOSE as an argument.

Could you clarify if this is a mistake in the issue description, or if there's an undocumented feature related to endContour() that I'm missing?

Hi @HarshitaKatariya, thanks for the concern. Actually I think we have CLOSE as an argument in endContour() method as you can see here.

p5.js/src/shape/custom_shapes.js

Lines 908 to 910 in 21167f0

	endContour(closeMode = constants.OPEN, _index = this.contours.length - 1) {
	const contour = this.at(_index);
	if (closeMode === constants.CLOSE) {

I think you are correct, it's still undocumented I think.

[davepagurek]

Right, @HarshitaKatariya endContour(CLOSE) is a new p5 2.0 feature that we'll be adding documentation for in the next month or two before we fully release 2.0.

More context: the problem

We've narrowed down the issue, and it's not because there are extra faces it turns out! It's that the default shape mode is actually removing vertices, when they lie on a straight line. So you can start with a contour that looks like the left, but ends up with the triangles on the right:

This is OK in general, except that we're making the side faces, we're using QUAD_STRIP, which does not remove points, so the sides have higher detail than the fronts, which is noticeable when you then try to bend the points in a shader to make a curve, because the higher-subdivided one has the ability to bend while the unsubdivided one can't bend any more:

Potential solutions

@perminder-17 was looking into whether mapbox's earcut has the same simplifying behaviour as our existing triangulator, libtess. It seems like it does unfortunately, but earcut seems to be generally faster anyway, so that change will be good regardless and gives us more wiggle room to address the duplication ourselves somehow.

The core issue is that points on the same line look like they can be simplified with no loss of detail. So maybe a solution here is to generate a new vertex property (see the custom vertex property section here: https://github.com/processing/p5.js/releases/tag/v2.0.0-beta.1), assign it random values per vertex so that these properties no longer can be simplified, and then delete it in the resulting geometry? (A quick way to check if it fixes this issue is to assign random texture coordinates in textToModel because we don't have any to begin with, e.g. vertex(x, y, z, Math.random(), Math.random()), and see if that fixes the sketch.)

Since we probably don't want an extra vertex property in general, we maybe also need to add a way to get/set this behaviour. Maybe we name it simplifyTriangles, defaulting to true, and you can call simplifyTriangles(false) to prevent it?

[davepagurek]

Also, if the random texture coordinates thing works, feel free to make a PR for that right now, and we can make a new issue to address simplifyTriangles in general