POV-Ray : Newsgroups : povray.beta-test : POV-Ray v3.8.0-x.freetype.1 Server Time
28 Nov 2021 15:54:19 EST (-0500)
  POV-Ray v3.8.0-x.freetype.1 (Message 11 to 20 of 22)  
<<< Previous 10 Messages Goto Latest 10 Messages Next 2 Messages >>>
From: clipka
Subject: Re: POV-Ray v3.8.0-x.freetype.1
Date: 7 Feb 2019 16:34:28
Message: <5c5ca464$1@news.povray.org>
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

From: William F Pokorny
Subject: Re: POV-Ray v3.8.0-x.freetype.1
Date: 8 Feb 2019 09:35:34
Message: <5c5d93b6$1@news.povray.org>
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

From: Thomas de Groot
Subject: Re: POV-Ray v3.8.0-x.freetype.1
Date: 9 Feb 2019 02:32:04
Message: <5c5e81f4$1@news.povray.org>
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

From: William F Pokorny
Subject: Re: POV-Ray v3.8.0-x.freetype.1
Date: 9 Feb 2019 13:41:07
Message: <5c5f1ec3$1@news.povray.org>
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)

From: clipka
Subject: Re: POV-Ray v3.8.0-x.freetype.1
Date: 10 Feb 2019 05:20:02
Message: <5c5ffad2$1@news.povray.org>
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

From: William F Pokorny
Subject: Re: POV-Ray v3.8.0-x.freetype.1
Date: 10 Feb 2019 08:08:57
Message: <5c602269$1@news.povray.org>
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

From: William F Pokorny
Subject: Re: POV-Ray v3.8.0-x.freetype.1
Date: 10 Feb 2019 08:50:39
Message: <5c602c2f$1@news.povray.org>
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

From: clipka
Subject: Re: POV-Ray v3.8.0-x.freetype.1
Date: 10 Feb 2019 15:36:22
Message: <5c608b46@news.povray.org>
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

From: William F Pokorny
Subject: Re: POV-Ray v3.8.0-x.freetype.1
Date: 10 Feb 2019 18:30:42
Message: <5c60b422$1@news.povray.org>
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

From: clipka
Subject: Re: POV-Ray v3.8.0-x.freetype.1
Date: 10 Feb 2019 22:39:47
Message: <5c60ee83$1@news.povray.org>
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

<<< Previous 10 Messages Goto Latest 10 Messages Next 2 Messages >>>

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