POV-Ray : Newsgroups : povray.beta-test : POV-Ray v3.8.0-x.freetype.1 Server Time: 19 Feb 2019 23:16:03 GMT
  POV-Ray v3.8.0-x.freetype.1 (Message 1 to 10 of 22)  
Goto Latest 10 Messages Next 10 Messages >>>
From: clipka
Subject: POV-Ray v3.8.0-x.freetype.1
Date: 17 Jan 2019 02:22:52
Message: <5c3fe6fc$1@news.povray.org>
Now implementing `text` objects via FreeType and prism primitives:

https://github.com/POV-Ray/povray/releases/tag/v3.8.0-x.freetype.1

Some notes:

- The `cmap` syntax is currently doing nothing.

- Support for various non-TrueType fonts should be included for free, 
provided the font is any outline font (e.g. CFF-flavour OpenType fonts). 
Bitmap fonts will of course not work, nor will colour SVG fonts.

- Performance has degraded a bit, but I'm willing to accept this for the 
sake of extended functionality and easier maintenance.

Also, render results differ in several ways:

- Previously, the text was aligned so that x=0 coincided with the 
/actual/ left side of the first character (i.e. its outline). The new 
implementation instead has x=0 coincide with the first character's 
/nominal/ left side (i.e. its "character box"), leaving a small gap 
typically matching half the distance between characters. Since I expect 
this to give aesthetically more pleasing results with multiple lines, I 
hesitate to invest time and effort to reproduce the old behaviour.

- In some cases (e.g. the German umlaut sequence `äöüÃ` with the 
`arial.ttf` font) horizontal placement of individual characters has 
changed. Since the new behaviour looks cleaner, I have no intention 
whatsoever to reproduce the old behaviour.

- POV-Ray v3.7 (haven't checked whether this has been fixed already) had 
the inside/outside orientation of the character "sides" the wrong way 
round, giving unexpected results when `interior_texture` is used. This 
has also been changed to be consistent with the character "faces" (*).

- (*) For normal TrueType fonts, that is. Based on the FreeType 
documentation, I totally expect the new implementation to get this 
wrong, and/or to mess up the "holes" (e.g. in characters like `o`), with 
/some/ font file formats or even individual fonts. Please keep your eyes 
peeled, I'm keen to get my hands on any such font specimens.


Post a reply to this message

From: William F Pokorny
Subject: Re: POV-Ray v3.8.0-x.freetype.1
Date: 17 Jan 2019 14:05:50
Message: <5c408bbe$1@news.povray.org>
On 1/16/19 9:22 PM, clipka wrote:
> Now implementing `text` objects via FreeType and prism primitives:
> 
> https://github.com/POV-Ray/povray/releases/tag/v3.8.0-x.freetype.1
> 
> Some notes:
> 
...
> 
> - Performance has degraded a bit, but I'm willing to accept this for the 
> sake of extended functionality and easier maintenance.
> 

Hmm, I'm surprised some by this. Are your test character strings really 
short? In the existing text shape code all the characters ended up more 
or less as one huge glyph as you know. As the string to the text shape 
got large, performance slowed substantially. Your implementing 
internally as a union of prisms should address this shortcoming well - 
providing a lot of room for other code to slow without overall impact. 
Wonder... Is the prism object a lot slower than the text object was? 
(I've never compared)

> Also, render results differ in several ways:
> 
...
> 
> - POV-Ray v3.7 (haven't checked whether this has been fixed already) 

It is fixed in the current 3.8 master. You picked up - or made 
independently - a change quite like one Jérôme made in hgpovray. I know 
because that code change collided on a rebase in a text shape branch 
where I'd made similar updates. I vaguely remember doing some 
verification of the fix too, along with some prism fix - but... maybe / 
maybe not.

> 
> - (*) For normal TrueType fonts, that is. Based on the FreeType 
> documentation, I totally expect the new implementation to get this 
> wrong, and/or to mess up the "holes" (e.g. in characters like `o`), with 
> /some/ font file formats or even individual fonts. Please keep your eyes 
> peeled, I'm keen to get my hands on any such font specimens.

I have somewhere a crude test set up / scene collection I created when I 
did my text shape hacks. I'll put it on my list to run those.

Plus, IIRC, I saw font sites offering fonts in multiple formats. Might 
be we can turn up problems with holes / overlaps or whatever by running 
such format sets and comparing resultant images. I now have a pretty 
good semi-automated testing framework for that sort of scene to sceen 
image testing so shouldn't take too much to get something going - 
provided I'm right about the availability of fonts in multiple formats.

Good stuff Christoph!

However, first up for me is to rebase my branches to the current 3.8 
master with the updated parser so the solver/other personal branch 
testing I'm doing is running the updated parser too.

Bill P.


Post a reply to this message

From: clipka
Subject: Re: POV-Ray v3.8.0-x.freetype.1
Date: 17 Jan 2019 17:03:05
Message: <5c40b549$1@news.povray.org>
Am 17.01.2019 um 15:05 schrieb William F Pokorny:

>> - Performance has degraded a bit, but I'm willing to accept this for 
>> the sake of extended functionality and easier maintenance.
> 
> Hmm, I'm surprised some by this. Are your test character strings really 
> short? In the existing text shape code all the characters ended up more 
> or less as one huge glyph as you know. As the string to the text shape 
> got large, performance slowed substantially. Your implementing 
> internally as a union of prisms should address this shortcoming well - 
> providing a lot of room for other code to slow without overall impact. 
> Wonder... Is the prism object a lot slower than the text object was? 
> (I've never compared)

My strings are roundabout one or two dozen characters.

My first guess was that it was caused by 3rd order vs. 2nd order 
splines, but that doesn't seem to make much of a difference.

Another potential cause for slowdown could be rooted in prism being able 
to support conic sweeps.

My current guess however is that there's some "poor man's bounding" 
hidden in the TrueType code that the prism doesn't have.

What I can say is that the same text strings composed into a single 
prism gave abysmal performance.

What I also can say is that my performance comparisons were only cursory.


>> - POV-Ray v3.7 (haven't checked whether this has been fixed already) 
> 
> It is fixed in the current 3.8 master. You picked up - or made 
> independently - a change quite like one Jérôme made in hgpovray.

Yeah, found text to that effect in the changelog, so it must be true ;)


>> - (*) For normal TrueType fonts, that is. Based on the FreeType 
>> documentation, I totally expect the new implementation to get this 
>> wrong, and/or to mess up the "holes" (e.g. in characters like `o`), 
>> with /some/ font file formats or even individual fonts. Please keep 
>> your eyes peeled, I'm keen to get my hands on any such font specimens.
> 
> I have somewhere a crude test set up / scene collection I created when I 
> did my text shape hacks. I'll put it on my list to run those.
> 
> Plus, IIRC, I saw font sites offering fonts in multiple formats. Might 
> be we can turn up problems with holes / overlaps or whatever by running 
> such format sets and comparing resultant images. I now have a pretty 
> good semi-automated testing framework for that sort of scene to sceen 
> image testing so shouldn't take too much to get something going - 
> provided I'm right about the availability of fonts in multiple formats.

If you would like to pick up that glove some time in the near future, 
I'd very much appreciate it.

Right now, I have found one font where the surface normal orientation is 
broken for at least one character, namely the closing square bracket 
("]") in the "Arial Black" font. I blame FreeType, with the mechanism 
being that the font defines that glyph by scaled reference to the 
opening square bracket glyph ("["), mirroring it horizontally (and thus 
messing up control point order).


Post a reply to this message

From: ingo
Subject: Re: POV-Ray v3.8.0-x.freetype.1
Date: 17 Jan 2019 17:41:34
Message: <XnsA9DABE280A130seed7@news.povray.org>
in news:5c40b549$1@news.povray.org clipka wrote:

> support conic sweeps

interesting feature for fonts ;)

ingo


Post a reply to this message

From: clipka
Subject: Re: POV-Ray v3.8.0-x.freetype.1
Date: 17 Jan 2019 17:52:29
Message: <5c40c0dd@news.povray.org>
Am 17.01.2019 um 18:41 schrieb ingo:
> in news:5c40b549$1@news.povray.org clipka wrote:
> 
>> support conic sweeps
> 
> interesting feature for fonts ;)

Not currently supported; would need extra work to make sure all 
characters converge towards the same apex point.


Post a reply to this message

From: clipka
Subject: Re: POV-Ray v3.8.0-x.freetype.1
Date: 3 Feb 2019 09:04:36
Message: <5c56aea4$1@news.povray.org>
Am 17.01.2019 um 15:05 schrieb William F Pokorny:

>> - Performance has degraded a bit, but I'm willing to accept this for 
>> the sake of extended functionality and easier maintenance.
>>
> 
> Hmm, I'm surprised some by this. Are your test character strings really 
> short? In the existing text shape code all the characters ended up more 
> or less as one huge glyph as you know. As the string to the text shape 
> got large, performance slowed substantially.

Actually, wading through the old code for unrelated reasons, I just 
noticed that this isn't true: The old `text` primitive has actually been 
a CSG union all along, with one child per character.


Post a reply to this message

From: William F Pokorny
Subject: Re: POV-Ray v3.8.0-x.freetype.1
Date: 3 Feb 2019 15:35:27
Message: <5c570a3f$1@news.povray.org>
On 2/3/19 4:04 AM, clipka wrote:
> Am 17.01.2019 um 15:05 schrieb William F Pokorny:
> 
>>> - Performance has degraded a bit, but I'm willing to accept this for 
>>> the sake of extended functionality and easier maintenance.
>>>
>>
>> Hmm, I'm surprised some by this. Are your test character strings 
>> really short? In the existing text shape code all the characters ended 
>> up more or less as one huge glyph as you know. As the string to the 
>> text shape got large, performance slowed substantially.
> 
> Actually, wading through the old code for unrelated reasons, I just 
> noticed that this isn't true: The old `text` primitive has actually been 
> a CSG union all along, with one child per character.

Hmm. Not my recollection or experience. I was focused on inside tests if 
those were perhaps done differently than intersections. The glyph loop 
range testing I added helped regular intersection performance too, but 
less.

Anyway. I'll keep what you saw in mind. Possible the code work I did was 
pointless, and the performance gains seen false, for reasons of 
self-foolery.

I'm maintaining my text branch with the thought the new text object 
might also be too slow for what I want. Means, if motivated, I can again 
do performance comparisons to the 'old' text object as well as your new 
one off master, but, I probably won't so long as the new is fast enough.

Bill P.


Post a reply to this message

From: Alain
Subject: Re: POV-Ray v3.8.0-x.freetype.1
Date: 4 Feb 2019 01:17:18
Message: <5c57929e$1@news.povray.org>
Le 19-02-03 à 04:04, clipka a écrit :
> Am 17.01.2019 um 15:05 schrieb William F Pokorny:
> 
>>> - Performance has degraded a bit, but I'm willing to accept this for 
>>> the sake of extended functionality and easier maintenance.
>>>
>>
>> Hmm, I'm surprised some by this. Are your test character strings 
>> really short? In the existing text shape code all the characters ended 
>> up more or less as one huge glyph as you know. As the string to the 
>> text shape got large, performance slowed substantially.
> 
> Actually, wading through the old code for unrelated reasons, I just 
> noticed that this isn't true: The old `text` primitive has actually been 
> a CSG union all along, with one child per character.

That's coherent with the object count : Adding a long text object really 
increase the number of objects in a scene.


Post a reply to this message

From: Cousin Ricky
Subject: Re: POV-Ray v3.8.0-x.freetype.1
Date: 5 Feb 2019 13:25:00
Message: <web.5c598e8c67ef2bd393ab27150@news.povray.org>
clipka <ano### [at] anonymousorg> wrote:
> - Previously, the text was aligned so that x=0 coincided with the
> /actual/ left side of the first character (i.e. its outline). The new
> implementation instead has x=0 coincide with the first character's
> /nominal/ left side (i.e. its "character box"), leaving a small gap
> typically matching half the distance between characters. Since I expect
> this to give aesthetically more pleasing results with multiple lines, I
> hesitate to invest time and effort to reproduce the old behaviour.

*must go through old scenes to see if/where I make this ASSumption.*


Post a reply to this message

From: William F Pokorny
Subject: Re: POV-Ray v3.8.0-x.freetype.1
Date: 7 Feb 2019 16:31:43
Message: <5c5c5d6f$1@news.povray.org>
On 2/3/19 10:35 AM, William F Pokorny wrote:
> On 2/3/19 4:04 AM, clipka wrote:
>> Am 17.01.2019 um 15:05 schrieb William F Pokorny:
>>
>>>> - Performance has degraded a bit, but I'm willing to accept this for 
>>>> the sake of extended functionality and easier maintenance.
>>>>
>>>
>>> Hmm, I'm surprised some by this. Are your test character strings 
>>> really short? In the existing text shape code all the characters 
>>> ended up more or less as one huge glyph as you know. As the string to 
>>> the text shape got large, performance slowed substantially.
>>
>> Actually, wading through the old code for unrelated reasons, I just 
>> noticed that this isn't true: The old `text` primitive has actually 
>> been a CSG union all along, with one child per character.
> 
> Hmm. Not my recollection or experience. I was focused on inside tests if 
> those were perhaps done differently than intersections. The glyph loop 
> range testing I added helped regular intersection performance too, but 
> less.
> 
...
> 

Trying to avoid sliding too much sideways into work I did almost two 
years ago given I've already got more going than I'll ever finish. Can't 
completely help it I guess. Over the past days, kept asking myself how 
could I see such large performance improvements if the text object was 
already a union (Christoph and Alain being almost certainly right).

- Remembered two years ago I was mostly going after performance using 
hardware counter analysis. I was going after hot spots.

- Remembered a decade ago with the objectAsIso experiments how I looked 
hard at converting other than the simplest csg to a mesh because the 
inside test performance got so slow with larger/complex csg.

- Remembered Lanuhum's Blender hair scene and thinking it shouldn't 
really be that slow, even with super slow sphere_sweeps.

- Remembered thinking on trying it years ago the +bm2 mode should 
provide more performance than it does.

- Remembered learning early last year while finding the cause of a 
particular speckling bug, that POV-Ray does inside tests when it creates 
original rays.

- Remembered thinking fixes to that particular speckling bug and issues 
like: https://github.com/POV-Ray/povray/issues/139 will likely require 
multiple inside tests over one to account for floating point noise no 
matter any improved accuracy.

---
These last two thoughts led me to doing a new performance test with our 
ttf1.pov sample scene. One where all I changed was whether or not AA 
used. My thinking is the performance improvement of my text branch 
should be more or less the same with and without AA. It should be the 
same, unless, the text object is a union and the real performance 
problem is the csg inside test mechanism doing something like just 
trundling through ALL the shapes in a csg.

Results were not similar. This leads me to a new suspicion / unproven 
theory we are sitting on a csg inside test performance issue. One 
perhaps affecting things generally. My code changes to the text object 
only treated another problem.

I've spent zero time in the csg code and I'm working/playing elsewhere 
for the foreseeable future. I'm put digging here on my, maybe, someday 
list - for what little that's worth! My new theory is perhaps wrong too 
- but there is something going on inside test wise which is not very 
efficient.

Aside: Even looking at single shapes of a type, the inside test 
performance is often awful. This is why that isosurface peeling paint 
skin test of Thomas's superellipsoid using the hard/soft object patch 
was so extremely slow. IIRC, a box replacement was more than 20x faster.

Bill P.

--------------------------- Data for those interested.

/usr/bin/time povray ttf1.pov +am2 +a0.1 +r4 +wt1 \
                      -j -cc -fn -d -p +w2000 +h2000

p380
---------
12.39user 0.04system 0:12.71elapsed With +a0.1
12.21user 0.03system 0:12.51elapsed
12.27user 0.03system 0:12.56elapsed
-----
36.87

4.40user 0.03system 0:04.70elapsed  With -a0.1
4.36user 0.05system 0:04.65elapsed
4.40user 0.02system 0:04.66elapsed
----
13.16

p380 + my text shape branch
---------
12.08user 0.04system 0:12.40elapsed With +a0.1
12.08user 0.04system 0:12.36elapsed
12.18user 0.03system 0:12.45elapsed
-----
36.34                               -1.44%

4.39user 0.01system 0:04.64elapsed  With -a0.1
4.32user 0.04system 0:04.59elapsed
4.34user 0.03system 0:04.64elapsed
----
13.05                               -0.84%  (??? Hmm)


----------- Repeating a few previous perf tests for my text branch.

soft_object.pov   p380 + hard/soft object only.
----
345.96user 0.08system 5:46.50elapsed   As 'text union'

64.91user 0.04system 1:05.52elapsed    Individual chars at top (-81.24%)


soft_object.pov   p380 + hard/soft object + my text shape branch.
----
161.22user 0.05system 2:41.78elapsed  As 'text union' -53.40%

69.42user 0.02system 1:09.99elapsed   Individual chars at top  (+6.95%)


Post a reply to this message

Goto Latest 10 Messages Next 10 Messages >>>

Copyright 2003-2008 Persistence of Vision Raytracer Pty. Ltd.