Do I need to take care of Definitely Typed/three? Is it automatic? Will another contributor take care of it?

Do I need to take care of Definitely Typed/three? Is it automatic? Will another contributor take care of it?

DefinitelyTyped should inherit the JSDoc types. There's typically no need to make a separate PR for DefinitelyTyped/three unless it's a special case or you encounter type errors after your code has been implemented.

Temporary live example:

https://raw.githack.com/Glypse/three.js/moreAsciiEffectFeatures/examples/webgl_effects_ascii.html

In general, it's not recommended to add too many features at once to an addon. This makes it less likely the PR is merged since the review process tends to be long and sometimes the PR just gets lost. How about focusing on a single feature for now?

@Mugen87 understood and agreed. Would love to know what you think should be prioritized?

Added fontFamily, fontWeight, fontSize and letterSpacing options. fontFamily and fontWeight are because they're the main goal of this PR, but it turns out that monospace fonts' characters are rarely fitting in a perfect square: if the user adds a custom fontFamily, they'll want to customize letterSpacing, otherwise the output might be squished/stretched.

How about this one? Using custom font settings sounds interesting.

First commit of these two is to simplify the commit back to only font-features. Second is to address the XSS concern that DeepScan had, with minimal performance impact. I don't know much about cross-site scripting but the solution, pretty simple, was partially made by Claude Sonnet 4.

This commits adds two things:

• A major optimization to the rendering: if the asciiEffect resolution is set to a low value (0.15 by default), there is no need to render the canvas at full pixel density. Setting it to have a pixelRatio equal to the resolution of the asciiEffect greatly saves on ressources. I don't see why a user would want the canvas to be rendered at a high resolution, for it to then only be rendered in ascii at a fraction. Please correct me if I'm wrong.
• Added stats and controls.

The propositions I'm making to the font customisation seem to have broken the Scale and String Resolution, but I frankly still do not understand their original purpose. I propose to get rid of them.

Live example at https://raw.githack.com/Glypse/three.js/moreAsciiEffectFeatures/examples/webgl_effects_ascii.html

Converting this to draft because the current system is too unstable and I spotted quite a few bugs. Will work on an auto-detection function for letter spacing, instead of having to deal with letter spacing manually.

This commit:

• Adds a dispose method.
• Replaces the previously implemented manual spacing for automatic spacing management. The user now can properly choose any truly monospace font and the effect will compute the proper letter spacing for perfectly square pixel (the previous implementation had 2 letters per pixel horizontally). I believe the current implementation to be much better for getting a good result fast.
• Adds the updateVisualSettings function that allows for changing options of the effect without needing to completely recompute all values, just what's needed. This is a big performance upgrade compared to last commit.
• Removes the scale and strResolution options as they would interfere with the current implementation.

I guess maybe I should add an optional parameter to output 2 characters per horizontal pixel, like the effect previously did? Currently, the computed render has a 2* higher pixel density than the ascii output, but each character occupies a perfect square, whereas they previously occupied a 1:2 rectangle.

Would love to have your thoughts.

Just noticed this only behaves correctly on desktop Firefox. Switching to draft again until I figure this out.

This is in a state that I believe has good performance, useful options, and fully working. Would love your input. As usual, find it at https://raw.githack.com/Glypse/three.js/moreAsciiEffectFeatures/examples/webgl_effects_ascii.html

Safari does render the line-height weirdly, but I'll blame that on them, except if anyone has a potential fix.