William F Pokorny <ano### [at] anonymousorg> wrote:

> The images use an 'interior_texture{}' that is green for the "What the
> heck" string. Only matters with the negative thickness on the third and
> fourth sub images. The fourth also using 'inverse'.

This is all pretty interesting - especially using "inverse"  I always forget to
try and use that in things.

I do notice that there is something - a shadow? - present in the two rightmost
images that are not present in the two leftmost.  Significant in any way?

- BW

Post a reply to this message

On 3/19/25 08:04, Bald Eagle wrote:
> I do notice that there is something - a shadow? - present in the two rightmost
> images that are not present in the two leftmost.  Significant in any way?

No. I think they are showing up where they should be(*).

Bill P.

(*) For the moment, let's ignore the fact I often get things wrong. :-)

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:

> (*) For the moment, let's ignore the fact I often get things wrong. :-)

On the topic of assured mutual ignorance, I find your terms acceptable.  ;)

Post a reply to this message

On 3/19/25 02:25, William F Pokorny wrote:
> Playing with the thickness parameter.
> 
> I've always specified values >0, but it works with values at 0 and with 
> negative values. With the latter though, by intent or mistake, only 
> renders the front and back surfaces - and the interior exterior 
> treatments are interesting / different(*).
> 
> Iideally we'd have an 'open' capability with text{}, but the way the 
> negative thickness values are working allows us to somewhat easily add 
> front and back surface textures which are different than the text{} sides.

OK. Attached a sample image for many of the text{} updates coming in 
release R19 of the yuqk fork. Namely, new text{} features 'caps' and 
'open' along with fixes for negative thickness specifications. Negative 
thickness becomes an OK thing to do and not something which only partly 
works.

Bill P.

Post a reply to this message

Attachments:
Download 'caps_open_features.png' (78 KB) Download 'caps_open_features.pov.txt' (5 KB)

Preview of image 'caps_open_features.png'

William F Pokorny <ano### [at] anonymousorg> wrote:

> OK. Attached a sample image for many of the text{} updates coming in
> release R19 of the yuqk fork. Namely, new text{} features 'caps' and
> 'open' along with fixes for negative thickness specifications. Negative
> thickness becomes an OK thing to do and not something which only partly
> works.

This is really cool, and actually very useful.
I often need to apply text to an image, but have to juggle the color depending
upon what color/brightness the background is.  Now we can have 2 contrasting
colors in a single glyph so that it always shows up reasonably well.

It will be interesting to experiment with things like gradients and other
patterns.

Now that you're neck-deep in the font code, can you ramble on about what you've
discovered / know about?

How difficult would it be to access the fundamental Bezier spline control points
for ttf fonts?

Can you make text render a tight spline rather than a thick outline?  A
"center-line" font?

Are these things dependent on how the font is defined in the file?

- BW

Post a reply to this message

ALSO:

If there were an under-the-hood Quadratic Bezier SDF, then you could actually do
real, high-quality text isosurfaces without all of the workarounds.

https://www.shadertoy.com/view/MlKcDD

https://iquilezles.org/articles/distfunctions2d/

and you could probably do some pretty nice in-fill of the text objects as well,
given that you'd have a gradient inside as well.

There are other Bezier SDF shaders as well.
Plus plenty of articles, blogs, etc.

https://astiopin.github.io/2019/01/06/sdf-on-gpu.html
https://vladjuckov.github.io/beziers-sdf/
https://forum.vvvv.org/t/inspirational-links-for-beziers-sdf-text-rendering-math-in-general-and-a-question/19989
https://www.desmos.com/calculator/kgmpkabruq
https://github.com/bio998/Unity-c-sharp-3D-Bezier-SDF/blob/master/BezierSDF.cs

- BW

Post a reply to this message

On 3/25/25 08:19, Bald Eagle wrote:
> Now that you're neck-deep in the font code, can you ramble on about what you've
> discovered / know about?

I'll soon post the first draft of the yuqk text{} documentation to:

   https://news.povray.org/povray.pov4.discussion.general/

> 
> How difficult would it be to access the fundamental Bezier spline control points
> for ttf fonts?

Easy-ish to hack something. To do well, I don't know. Plus, I have 
serious doubts that such font features fit well within POV-Ray. The font 
(and font application) game as a whole is big and messy.

So, it's ttfdump, and similar external tooling for now.

> 
> Can you make text render a tight spline rather than a thick outline?  A
> "center-line" font?
> 
> Are these things dependent on how the font is defined in the file? 

They are. Creating center line / offset splines automatically is not 
easy (or even always possible) to do. IIRC, clipka mentioned 'stroke 
fonts' exist, but I've had no exposure to them.

Your questions touch on an interesting topic. Namely, additional ttf 
fonts designed specifically for POV-Ray use as building block shapes. 
I'd probably start with a square aspect ratio, box character font. 
Adding rounded corner shapes and the like to it too.

Thank you for the references in your follow-on post. I've stored them in 
my BillW directory for later use.

Bill P.


Aside: clipka created a FreeType fork some years back. It had issues 
when I tested it, but it's on my list to dig into that code someday. 
Perhaps, that work a reasonable path to extending the font formats 
POV-Ray supports.

Post a reply to this message