"Thorsten Froehlich" wrote:
> Of course one could change it to some extend at the
> serve penalty of *much* slower rendering.

I don't think it's worth it. The user can always intersect the text object
with a plane to avoid the problem.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated Nov 5)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

Wasn't it Francois Labreque who wrote:
>
>
>Thorsten Froehlich wrote:
>
>> In article <3c304eaf@news.povray.org> , "Felix Wiemann" 
>> <Fel### [at] gmxnet> wrote:
>> 
>> 
>>>But the left part of the letter "P" is cut of. It seems to be a
>>>bounding problem.
>>>
>> 
>> You may want to check if the font comes with correct bounds for its
>> charaters in a font editor.
>
>
>As mentioned in my other post, this happens with other fonts as well.  I 
>dont think it is dues to the bounding of the font itself as the problem 
>is in the Z direction.  Testing with a modified scene shows that the 
>problem is that the text isn't "straight".  See image in p.b-t.b.
>
>#include "colors.inc"
>camera{
>     location < 10, 15, -20 >
>     look_at < 10, 0 0 >
>     }
>plane{
>     y, 0
>     pigment{ White }
>     }
>union{
>     box{
>         < -5, -1, 0 > < 25, 20, 20 >
>         pigment{ Gray50 }
>         }
>     text{
>         ttf "timrom" "POV" 0.1 0
>         scale < 10, 10, 100000 >
>         pigment{ Red }
>         }
>     }
>light_source{
>     < -15, 50, -15 >
>     White
>     }
>
>
>

I see that Thorsten now claims that this is a coincident surfaces
problem. I must say it doesn't look like that to me.

I've checked all the other pov primitives, and nothing else is tilted in
this way.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

To me it just seems to be some accuracy problem. The accuracy problem gets
more visible when scaling with a huge number.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

In article <DyP3zCAt$5W8EwL9@econym.demon.co.uk> , Mike Williams 
<mik### [at] nospamplease>  wrote:

> I see that Thorsten now claims that this is a coincident surfaces
> problem. I must say it doesn't look like that to me.

Given the description of the original bug without having the font, this was
the only possible conclusion.  Essentially these two problems need to be
treated as two distinct problems.  The only one that can be reproduced is the
one using timrom.ttf because if or if there is not a problem with the original
font cannot be determined without having the font.  I can only explain
something I can actually test.

Investigating the given example with the timrom.ttf font revealed that at
least in that case it is.  It has to do with the scale, which, lets say has
'some effects on the ray' that basically make a difference of about 10e-5,
which for the text object is enough to cause problems.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

> Investigating the given example with the timrom.ttf font revealed that at
> least in that case it is.  It has to do with the scale, which, lets say
has
> 'some effects on the ray' that basically make a difference of about 10e-5,
> which for the text object is enough to cause problems.

As Rune said, it is possible to avoid the overlapping letters problem by
intersecting the text with a plane, but the tilted text problem appears
still when it's intersected. Even if it is only a coincident surfaces
problem, why do you say that it's not a bug? There is no proper workaround
except less scaling (and that's not a workaround but a restriction IMHO).

Post a reply to this message

In article <3c5bd62a@news.povray.org> , "Felix Wiemann" 
<Fel### [at] gmxnet> wrote:

> Even if it is only a coincident surfaces
> problem, why do you say that it's not a bug?

The coincident surface problem is not a bug...

> There is no proper workaround
> except less scaling (and that's not a workaround but a restriction IMHO).

Whatever you call it, floating-point number precision is the way it is and
there is nothing anybody can do about it.

BTW, a much better solution to this is to split the text into two/three
sections.  Simply make one/both ends out of a text scaled by 1, and then place
the a extremely scaled version in the middle (so it overlaps a bit) and merge/
union the whole thing together.  It will of course slow down rendering a bit,
but it won't be as much as using a plane and CSG (without manual bounding).

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message