In an offline email exchange with jr, I drifted off into a discussion 
(OK, it was more of a monologue) about how the text{} object has a 
secrete rotation to avoid axis aligned numerical issues. The rotation is 
the equivalent of a user specifying - always - 'rotate 
<0.001,0.001,0.001>' on text{} objects.

It's something that was added to the parse code at some point. It's 
there in v3.7 - probably earlier versions too. The v3.8 source added a 
TODO note about trying to find some better approach.

For the next release of the yuqk fork (R19) I've currently reduced the 
rotation to: 'rotate <0.0001,0.0001,0.0001>' as a longer trial, but I'm 
having second thoughts (*).

After setting up some more formal test code, I'm left unsure of the best 
way to proceed - in no small part because I don't know what really 
caused the issues for which the patch was applied. If anyone remembers 
anything, please pass it along.

I'm starting to think pulling the patch altogether might be a better 
long trial. A user can always add the rotation. In fact, likely a 
cleaner, more minimal rotation about just the z axis) when artefacts 
show up.

Attached is an image and a yuqk scene file where I've set the thickness 
of the text objects at 1e-6; Artifacts show up even at a thickness of 
1.0. The rotation is effectively another issue that can bite or not 
depending on many things. Centering the text{} object about the origin 
lessons the chance the secret rotation will cause a problem.

The left render shows the result for the current secrete rotation of 
<0.001,0.001,0.001>.

In the middle no secrete rotation is applied.

On the right, the current R19 rotation of <0.0001,0.0001,0.0001>. It 
helps, but I think not in a way that really addresses the issue and, who 
knows, maybe it's not large enough for the situation for which the patch 
was added.

Bill P.

(*) - Another thing I played with was to add a counter / inverse 
rotation in SDL to the secrete one in an attempt to get back to no 
rotation. While it sometimes works, there is too much numerical noise in 
rotating and un-rotating (on combining the two opposing matrices). The 
overall results were less stable.

Post a reply to this message

Attachments:
Download 'textsecreterotation.jpg' (22 KB) Download 'textsecreterotation.pov.txt' (2 KB)

Preview of image 'textsecreterotation.jpg'

William F Pokorny <ano### [at] anonymousorg> wrote:
> Centering the text{} object about the origin
> lessons the chance the secret rotation will cause a problem.

I've certainly learned that you're not spelling that correctly.

> The left render shows the result for the current secrete rotation of
> <0.001,0.001,0.001>.

It must be a small glandular thing.


Thanks for uncovering this and pointing it out.
It explains something that I've noticed and ignored, when messing up text via
the coincident surface phenomenon.  There's always been half of the text visible
in this sort of diagonal partition.  Since the text is actually rotated, albeit
by a small amount, this makes perfect sense.

- BW

Post a reply to this message

On 3/13/25 15:44, Bald Eagle wrote:
>> Centering the text{} object about the origin
>> lessons the chance the secret rotation will cause a problem.
> I've certainly learned that you're not spelling that correctly.
> 
>> The left render shows the result for the current secrete rotation of
>> <0.001,0.001,0.001>.
> It must be a small glandular thing.

Oh my... I laughed out loud. +11  :-)

Bill P.

Post a reply to this message

On 3/13/25 14:05, William F Pokorny wrote:
> I'm starting to think pulling the patch altogether might be a better 
> long trial. A user can always add the rotation. In fact, likely a 
> cleaner, more minimal rotation about just the z axis) when artefacts 
> show up.

For the record.

After some testing where I did not see any axis aligned seams / 
artefacts, I've decided to pull the text{} rotation patch from the 
parser. This no-patch trial will start with release R19 of my yuqk
playpen fork rather than just making the rotation smaller.

---

Question.

Has anyone successfully used a true type collection (.ttc file) with 
recent (V3.7/V3.8) official POV-Ray versions?

These always crash with the .ttc files I have easy access to. Namely, 
large CJK collections. These are also not capturing multiple styles, but 
region specific glyph differences - maybe that is somehow an issue for 
the current code.

The support for .ttc files was always limited to the first packaged .ttf 
font found in the collection. We have no ability to pick which font in a 
collection gets used. I'm considering dropping support for reading true 
type collection files near term in the yuqk fork, but if it is working 
for others, maybe I leave it as is.

Bill P.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> Question.
>
> Has anyone successfully used a true type collection (.ttc file) with
> recent (V3.7/V3.8) official POV-Ray versions?
>
> These always crash with the .ttc files I have easy access to. Namely,
> large CJK collections. These are also not capturing multiple styles, but
> region specific glyph differences - maybe that is somehow an issue for
> the current code.
> ...

'msgothic.ttc' (eg) works for me (alpha.9945627, beta.2) while 'NotoSansCJK.ttc'
crashes, yuqk reports 'Invalid TT font headers...'.  looks like it all depends
on the people putting together the TTF/TTC file(s).


regards, jr.

Post a reply to this message

On 3/19/25 03:52, jr wrote:
> 'msgothic.ttc' (eg) works for me (alpha.9945627, beta.2) while 'NotoSansCJK.ttc'
> crashes, yuqk reports 'Invalid TT font headers...'.  looks like it all depends
> on the people putting together the TTF/TTC file(s).

In an offline discussion, jr helped me work through my own confusion 
with the .ttc support in POV-Ray.

I tried the 'CJK' .ttc fonts blindly on seeing the .ttc suffix.

Well, it turns out OpenType fonts also use the .ttc suffix and POV-Ray 
doesn't support them. I didn't know. My Ubuntu distribution puts the 
OpenType fonts in another directory:

/usr/share/fonts/opentype/noto/NotoSansCJK-Regular.ttc

rather than:

/usr/share/fonts/truetype/

but I didn't notice...

---

If you are on linux and have the .ttc collection in a personal directory 
you can use the 'file' command:

file NotoSansCJK-Regular.ttc

and it will kick out text about the file. Part of which will includes 
detail on the internal font types stored. For example:

NotoSansCJK-Regular.ttc: OpenType font collection data, 1.0, 10 fonts, 
at 0x34 OpenType Font data, 16 tables, 1st "BASE"

or 'file LiberationMono-Regular.ttf' :

LiberationMono-Regular.ttf: TrueType Font data, 18 tables, 1st "FFTM", 
30 names, Macintosh

---

So, I'm leaving the .ttc support in place with yuqk and I'll add yuqk 
documentation that the POV-Ray support for .ttc files is only for 
TrueType collections.

Bill P.

Post a reply to this message