 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
in news:5c40b549$1@news.povray.org clipka wrote:
> support conic sweeps
interesting feature for fonts ;)
ingo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymous org> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 07.02.2019 um 17:31 schrieb William F Pokorny:
> 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.
Welcome to the world of POV-Ray development ;)
> - 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.
Let's play a game of "shapes that could benefit from internal bounding
but don't have any" ;)
> - 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.
Just a spontaneous thought here: Would it be worth it to cache the
result of the camera ray origin inside test, and only re-do it if the
origin changes (due to special camera or focal blur)?
> 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'm not so sure it's a CSG thing you're seeing. By default, POV-Ray
"flattens" CSG unions wherever possible, promoting all children to
top-level objects - presumably this is also the case with implicit
unions like the text primitive. So unless you took some measure to
specifically prevent this, you're not actually testing a CSG object.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2/7/19 4:34 PM, clipka wrote:
> Am 07.02.2019 um 17:31 schrieb William F Pokorny:
>
...
>
> Let's play a game of "shapes that could benefit from internal bounding
> but don't have any" ;)
On doing the solver work I'm - a while now - very aware of the internal
bounding issues with the sphere_sweep(1). However, if memory serves,
what Lanuhum had was hundreds of thousands of short sphere_sweeps/hairs.
Why would this be so much slower than one, or several, equally screen
filling ones, if bounding is working well(2). A possible answer is the
inside test on setting up original rays is for some reason doing the
test on all the hairs.
(1) - I've made a changes to the inside test of the sphere_sweep as
currently updated for my solver changes. Specifically a change to break
out of the test loop on the first segment where the point tests inside
true. Today the test runs through all the segments no matter. It's not a
change necessary for the solver changes - just something I noticed.
(2) - His textures looked to be simple.
>
...
>
> Just a spontaneous thought here: Would it be worth it to cache the
> result of the camera ray origin inside test, and only re-do it if the
> origin changes (due to special camera or focal blur)?
>
Maybe, yes. Globally turning the inside testing off when it's not
necessary perhaps another idea, but that would add some bookkeeping to
the parser.
>
...
>
> I'm not so sure it's a CSG thing you're seeing. By default, POV-Ray
> "flattens" CSG unions wherever possible, promoting all children to
> top-level objects - presumably this is also the case with implicit
> unions like the text primitive. So unless you took some measure to
> specifically prevent this, you're not actually testing a CSG object.
Agree. It's a theory until proven.
Will say, a reason I chose the shipped ttf1.pov for the AA and not-AA
testing is there are just two top level text objects in that scene. If
any text objects will hierarchically flatten into the prime/top level
seems like those would.
Do you know offhand what sorts of measures prevent flattening? Merge
pops to mind as suppose we'd need to remember the grouping there. The
two ttf1 text objects are textured and transformed - things almost
always the case with the text /csg - but that's it.
Another test which could be done pretty quickly, I guess, would be to
hack the code to eliminate the inside test on ray initialization for
ttf1.pov testing as it really isn't needed in that scene. I might try
that later today as I'm now curious. But, I'm off to do some other stuff
at the moment.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8-2-2019 15:35, William F Pokorny wrote:
>
> Agree. It's a theory until proven.
>
[pedantic mode]
That is an /hypothesis/ then. A /theory/ covers all the known and
accepted proofs and is generally being strengthened along the way by
'falsifications' which may, in the end, disprove it.
[/pedantic mode]
;-)
--
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2/8/19 9:35 AM, William F Pokorny wrote:
> On 2/7/19 4:34 PM, clipka wrote:
> ...
>>
>> I'm not so sure it's a CSG thing you're seeing. By default, POV-Ray
>> "flattens" CSG unions wherever possible, promoting all children to
>> top-level objects - presumably this is also the case with implicit
>> unions like the text primitive. So unless you took some measure to
>> specifically prevent this, you're not actually testing a CSG object.
>
> Agree. It's a theory until proven.
>
...
>
> Another test which could be done pretty quickly, I guess, would be to
> hack the code to eliminate the inside test on ray initialization for
> ttf1.pov testing as it really isn't needed in that scene. I might try
> that later today as I'm now curious. But, I'm off to do some other stuff
> at the moment.
>
>
Only got to trying the above this morning and perhaps my - hypothesis -
is wrong... If I hacked correctly there was not a difference I'd
consider large enough not to be noise. Tried a couple other things, then
decided why not just see whether the new freetype branch is fast enough
for what I want to do with the hard and soft objects. Also measured
ttf1.pov and it was a little over 3% faster with the freetype branch.
Characters move some so exact scene to scene comparisons not all that easy.
I then merged my hard/soft_object branch into the freetype one
(experimental/freetype at commit 30308ed). Tried the soft_object.pov
scene part of the merged branch where each text object only one
character up through the isosurface to the top. It's quite a lot faster
and I'll post an image to p.b-t.b showing mostly how the characters
shift as expected.
I then tried the version where "Water" all in one text object.
Unfortunately this hangs immediately in a way which only the kill
command can stop.
In other words, the single character W works below while the comment two
character string does not.
#declare Text00 = text {
ttf "timrom.ttf" "W" 0.05, 0.001 translate <0.02,0.02,0>
// ttf "timrom.ttf" "Wa" 0.05, 0.001 translate <0.02,0.02,0>
}
---------------- Repeating a few previous perf tests for the branch.
soft_object.pov p380/freetype + hard/soft object only.
----
345.96user 0.08system 5:46.50elapsed As 'text union'
??? Immediately hangs freetype (???)
64.91user 0.04system 1:05.52elapsed Individual chars at top (-81.24%)
48.33user 0.02system 0:48.91elapsed freetype (-25.54%)
This indirectly calls into question much of my thinking. If the
initialization of the ray is calling the inside test, why doesn't it
hang too... I don't know what's going on.
---
To start though find attached two scene files of a form I've been using
to test solver/inside related changes using media. The results of
Text.pov should quite closely match Text_I.pov results if everything is OK.
They do for the freetype branch where we have just on character W.
Results do not match when the text object string is Wa in the freetype
branch. At master things work OK - well except for the speckling
differences. Perhaps doesn't explain the hang, but something wrong and
fixing that a start. Again see p.b-t.b for image results / compares.
Bill P.
Post a reply to this message
Attachments:
Download 'text_i.pov.txt' (1 KB)
Download 'text.pov.txt' (1 KB)
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 09.02.2019 um 19:41 schrieb William F Pokorny:
> I then tried the version where "Water" all in one text object.
> Unfortunately this hangs immediately in a way which only the kill
> command can stop.
Is that with your own merged version only, or with the "pure" freetype
branch as well?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2/10/19 5:20 AM, clipka wrote:
> Am 09.02.2019 um 19:41 schrieb William F Pokorny:
>
>> I then tried the version where "Water" all in one text object.
>> Unfortunately this hangs immediately in a way which only the kill
>> command can stop.
>
> Is that with your own merged version only, or with the "pure" freetype
> branch as well?
Merged. Give me a little to get coffee, download the freetype branch
straight up, compile and run it.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2/10/19 8:08 AM, William F Pokorny wrote:
> On 2/10/19 5:20 AM, clipka wrote:
>> Am 09.02.2019 um 19:41 schrieb William F Pokorny:
>>
>>> I then tried the version where "Water" all in one text object.
>>> Unfortunately this hangs immediately in a way which only the kill
>>> command can stop.
>>
>> Is that with your own merged version only, or with the "pure" freetype
>> branch as well?
>
> Merged. Give me a little to get coffee, download the freetype branch
> straight up, compile and run it.
>
> Bill P.
Well... Sip or two of coffee and I think I probably originally missed
the point of your question or reading it again.
The hang is happening only when I merge both the freetype branch AND my
soft/hard object branch where there are two or more characters in the
string used in the soft_object pattern -> function -> isosurface.
The soft_object.pov demo scene has both single text object of "Water"
through the isosurface to the top and individual character text objects,
through individual isosurfaces to the top given coded up as the former
is so much faster. Something true even with my text branch performance
improvements merge in too.
---
Anyway, I download the freetype branch directly off github (no github
merge into master), compiled and ran it. The text_i.pov results with two
or more characters are still scrambled (also very slow) compared to the
current master (v38) branch on github. (master 5.27sec -> freetype 18.539)
Possible I guess I'm just not waiting long enough for the first
non-black square to show, but doubt it. I've not done a debug compile
and tried to attach gdb to the running process to verify I've "really"
got a hang.
My thinking was given something is wrong in the freetype branch itself,
as shown by text_i.pov with two or more characters, that should be fixed
first. If lucky that fix fixes my "hang" issue too.
In short run text_i.pov with master and again with the freetype branch.
Results should match and they don't when I run it.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 09.02.2019 um 19:41 schrieb William F Pokorny:
> To start though find attached two scene files of a form I've been using
> to test solver/inside related changes using media. The results of
> Text.pov should quite closely match Text_I.pov results if everything is OK.
I'm wondering whether we're seeing an inside test problem caused by y
coordinates matching a horizontal line (or maybe even just an on-curve
control point).
The old TrueType implementation was apparently prone to such issues, and
added a tiny "random" rotation to try and avoid them. I had hoped the
prism primitive would be more robust in this respect, but maybe that is
not the case.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2/10/19 3:36 PM, clipka wrote:
> Am 09.02.2019 um 19:41 schrieb William F Pokorny:
>> To start though find attached two scene files of a form I've been
>> using to test solver/inside related changes using media. The results
>> of Text.pov should quite closely match Text_I.pov results if
>> everything is OK.
>
> I'm wondering whether we're seeing an inside test problem caused by y
> coordinates matching a horizontal line (or maybe even just an on-curve
> control point).
>
> The old TrueType implementation was apparently prone to such issues, and
> added a tiny "random" rotation to try and avoid them. I had hoped the
> prism primitive would be more robust in this respect, but maybe that is
> not the case.
As an issue - might exist. I've occasionally had to tweak prism point
positions to eliminate artifacts. The opposite of what you're saying -
I've not had such trouble with text objects. Due luck perhaps.
I doubt it's what's happening here. Why does the single character text
string work?
For the inside test as used by the object pattern, it's as if an
internal structure/mechanism is corrupted in the freetype branch once
there is more than one character in the text string. Once a
"text-union" is necessary internally(1) perhaps?
I'm light on text and prism test cases compared to some others. Wasn't
looking much at the text shape at all previously for the solver work
because it has/had its own. Had planned to move text to the common
solvers in part at least, but no longer necessary.
Bill P.
(1) - I'll go now and create a <union>.pov and <union>_i.pov pair using
spheres or something. Not something I have today for the text vs text_i
form of inside test verification. And... looks like I never did a prism
pair. Hmm, maybe this is a prism problem that's been sitting there all
along. Slip, sliding away....
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 11.02.2019 um 00:30 schrieb William F Pokorny:
> For the inside test as used by the object pattern, it's as if an
> internal structure/mechanism is corrupted in the freetype branch once
> there is more than one character in the text string. Once a
> "text-union" is necessary internally(1) perhaps?
That doesn't convince me at all. Remember, all we're using FreeType for
is constructing prisms at parse time; if FreeType were to screw up, it
would manifest as control points being out of whack, which should also
show in regular scenes. (*)
This is not what we're seeing; instead, the problem is specific to
situations where insideness tests are performed.
Single-character and multi-character test objects do indeed differ in
one important aspect, namely that single-character text objects are
instantiated as pure prisms, whereas multi-character text objects are
instantiated as unions of prisms.
I may have screwed up the way the prisms are assembled into a union -
maybe I forgot to call some important post-processing step - and I
wouldn't be too surprised if this manifested in insideness tests getting
messed up. Reference to parent object not getting set, maybe?
ATM I'm busy with other stuff; I'll look back into this issue if you
don't beat me to it.
(* The only other thing how FreeType could conceivably screw up without
immediately showing in regular renders would be by getting the
"handedness" of the prisms wrong; and as a matter of fact I'm aware of
one issue that can lead to glyphs getting flipped "inside out"; but the
"a" is not a candidate for this issue - it is more likely to be
associated with glyphs that have mirror twins.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2/10/19 10:39 PM, clipka wrote:
> Am 11.02.2019 um 00:30 schrieb William F Pokorny:
>
>> For the inside test as used by the object pattern, it's as if an
>> internal structure/mechanism is corrupted in the freetype branch once
>> there is more than one character in the text string. Once a
>> "text-union" is necessary internally(1) perhaps?
>
...
> That doesn't convince me at all. Remember, all we're using FreeType for
> is constructing prisms at parse time; if FreeType were to screw up, it
...
Up early to shovel snow... Agree. I wasn't trying to point at the
FreeType library, rather only at something being wrong in the freetype
branch.
>
> Single-character and multi-character test objects do indeed differ in
> one important aspect, namely that single-character text objects are
> instantiated as pure prisms, whereas multi-character text objects are
> instantiated as unions of prisms.
>
> I may have screwed up the way the prisms are assembled into a union -
> maybe I forgot to call some important post-processing step - and I
> wouldn't be too surprised if this manifested in insideness tests getting
> messed up. Reference to parent object not getting set, maybe?
>
This is my bet at the moment too - unless something has long been wrong
in how "union" handles prisms. I did get to some unions of simpler
shapes last night and those all work OK in all the recent active branches.
> ATM I'm busy with other stuff; I'll look back into this issue if you
> don't beat me to it.
>
OK. Thanks. I'm first going to flush out my media inside-test test cases
like the one I created here for the text shape and already had for other
simpler shapes touching the solver effort. I'd not previously done the
more complicated shapes like lathe and prism which have multiple spline
types and so balloon into a lot of work.
>
...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2/11/19 5:09 AM, William F Pokorny wrote:
> On 2/10/19 10:39 PM, clipka wrote:
>> Am 11.02.2019 um 00:30 schrieb William F Pokorny:
>>
...
>
> OK. Thanks. I'm first going to flush out my media inside-test test cases
> like the one I created here for the text shape and already had for other
> simpler shapes touching the solver effort. I'd not previously done the
> more complicated shapes like lathe and prism which have multiple spline
> types and so balloon into a lot of work.
>
I've done this over that past day and a half or so. Everything prism
related looks fine with respect to the inside testing. Decided to flush
out this form of testing with other base shapes too and I turned up
cases where the inside testing (via the object pattern) looks to be
wrong. See p.b-t.b for details.
Sometime want to mention adding sturm to text. It's an option for prisms
so should probably be for text as prisms and unions of prisms too.
Busy the remainder of today at least with real life.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
