"Bald Eagle" <cre### [at] netscapenet> wrote:
> Also, of course, Friedrich Lohmueller's site.
>
> https://www.f-lohmueller.de/pov_tut/animate/pov_anie.htm
> (near bottom)

How could I forget that!  I used to take my morning coffee and pick a random
link from his site to explore things you can do in POV-Ray and how to do them.
If I had gone back to this, I would have seen the "Orient your object in the +Z
axis" comment, instead of my trial and error that found I had to rotate the text
objects 90 degrees!

-- Chris R

Post a reply to this message

"Chris R" <car### [at] comcastnet> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> > Also, of course, Friedrich Lohmueller's site.
> >
> > https://www.f-lohmueller.de/pov_tut/animate/pov_anie.htm
> > (near bottom)
>
> How could I forget that!

Because there is SO MUCH to take in, that eventually some information starts to
fall of the stack.

https://en.wikipedia.org/wiki/Dunbar%27s_number

And I'm sure that you've written enough code to have forgotten how the code you
wrote 3 days ago works, because it was _obvious_ at the time.  ;)

Glad you're having fun with POV-Ray and coding animations.  Sometimes we learn
new things in the process of revisiting and relearning old things.

And then we add those NEW lessons onto the stack!  :D

- BW

Post a reply to this message

On 3/4/25 10:35, William F Pokorny wrote:
> I started looking at a yuqk version of documentation for the text{} object.

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.

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'.

Bill P.

(*) Jerome contributed fixes to v3.8 which stabilized the interior / 
exterior surface treatments for text{} objects with +z thicknesses. This 
means prior versions will behave differently.

Post a reply to this message

Attachments:
Download 'textthicknessstory.png' (85 KB)

Preview of image 'textthicknessstory.png'

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