I quickly searched the newsgroups for this, but didn't find anything.  Is 
it a known bug that the normal returned by trace() for a text object is 
reversed?

Quick example:
// ---- START ----
// Blue lines are traces from x=0 towards the objects
// Red lines are the normals returned by trace()
// reference sphere works as expected
// text doesn't
#version 3.5;

global_settings {
  assumed_gamma 1.0
}
default { texture { 
  pigment { color rgbt <1,1,1,0.5> }
  finish { specular 0 roughness 1 } } }
camera { location  <0, 0, -3> }
light_source { <-2,2,-4> color rgb 1 }

#declare Sphere = sphere { 0, 0.5
  translate <-1,0,0>
}
Sphere

#declare Text = text {
  ttf "arial.ttf" "O" 1, <0,0,0>
  scale 2
  translate <0.5,-0.75,-0.5>
}
Text

cylinder { <0,-2,0>, <0,2,0>, 0.025 }
cylinder { <-2,0.2,0>, <0,0.2,0>, 0.025 pigment { color rgb <0,0,1> } }
cylinder { <0,-0.2,0>, <2,-0.2,0>, 0.025 pigment { color rgb <0,0,1> } }

#declare TN = <0,0,0>;
#declare TH = trace(Sphere,<0,0.2,0>,-x,TN);
cylinder { TH, TH+TN, 0.025 pigment { color rgb <1,0,0> } }

#declare TH = trace(Text,<0,-0.2,0>,x,TN);
cylinder { TH, TH+TN, 0.025 pigment { color rgb <1,0,0> } }
// ---- END ----

Post a reply to this message

Wasn't it Alain who wrote:

>I quickly searched the newsgroups for this, but didn't find anything.  Is 
>it a known bug that the normal returned by trace() for a text object is 
>reversed?

I see that it's only the sides of the text characters that show this
effect. If the trace() ray hits the front or back face of a letter, then
the normal is correct. (To see this, rotate the text like this in your
scene
  #declare Text = text {
    ttf "arial.ttf" "O" 1, <0,0,0>
    scale 2
    translate <-0.5,-0.3,0>
    rotate y*45
    translate <1,0,0>
  }


It looks like the sides of the characters are inside out. If we paint a
text with a red texture and a green interior_texture we can see that the
sides are interior and the faces are exterior.

#version 3.5;
global_settings {assumed_gamma 1.0}
camera { location  <0, 0, -2> }
light_source { <-2,2,-4> color rgb 1 }

text {ttf "arial.ttf" "O" 1, <0,0,0>
  texture { pigment { color rgb x }}
  interior_texture {pigment {rgb y}}
  translate <-0.5,-0.3,0>
  scale 2
  rotate y*20
}

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

Mike Williams <nos### [at] econymdemoncouk> wrote:
> It looks like the sides of the characters are inside out. If we paint a
> text with a red texture and a green interior_texture we can see that the
> sides are interior and the faces are exterior.

  That sounds like a genuine bug.

  Normally the direction of the normal vectors don't matter because POV-Ray
flips them as necessary. It's only with features which rely on the direction
of the normal vector, such as interior_texture and trace(), where the
difference can be seen. Such features were added long after the text object
was added to POV-Ray and thus it's logical that such "bug" was never caught
(because it never affected rendering in versions previous to 3.5).

  I wonder if there are other primitives with inverted normal bugs...
Perhaps someone should check. :)

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

Mike Williams <nos### [at] econymdemoncouk> wrote in
news:9qTjkCAqBMm$EwRW@econym.demon.co.uk: 

> [...]
> I see that it's only the sides of the text characters that show this
> [...]

Thanks for confirming and elaborating.  I came across this because I was 
trying to use text with my ball sim code.  Really wasn't working right and 
I couldn't figure out what I was doing wrong at first.  Then I was thinking 
I could simply make a special case for text and reverse the normal, but 
since it's only the sides that are inverted, it won't be that simple.

Post a reply to this message

Alain <noe### [at] onca> wrote:
> Thanks for confirming and elaborating.  I came across this because I was 
> trying to use text with my ball sim code.  Really wasn't working right and 
> I couldn't figure out what I was doing wrong at first.  Then I was thinking 
> I could simply make a special case for text and reverse the normal, but 
> since it's only the sides that are inverted, it won't be that simple.

  A workaround (read: kludge) would be to take the intersection point and
advance it a tiny bit in the direction of the normal vector and see
with inside() whether this point is inside the text object. If it is,
then simply negate the normal vector.

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote in news:3f992701@news.povray.org:

>   A workaround (read: kludge) would be to take the intersection point
> [...]

Sounds good.  I was thinking of basing myself on the text's orientation.  
Since the front and back of the text should always (I think) be flat, then 
a collision with a text trace normal that is parallel with the front normal 
would be used as is, all others would be negated.  This would mean that I 
would need to keep track of the text orientation, but I think it might also 
mean less computation in the sim loop.

Post a reply to this message

In article <Xns### [at] 204213191226>,
 Alain <noe### [at] onca> wrote:

> Sounds good.  I was thinking of basing myself on the text's orientation.  
> Since the front and back of the text should always (I think) be flat, then 
> a collision with a text trace normal that is parallel with the front normal 
> would be used as is, all others would be negated.  This would mean that I 
> would need to keep track of the text orientation, but I think it might also 
> mean less computation in the sim loop.

This is a good idea...the normals are either perpendicular to the face 
axis or parallel to it, making them quite easy to distinguish.
Another possibility is to trace against an intersection of a text object 
and two planes or a box for the normal computation.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Christopher James Huff <cja### [at] earthlinknet> wrote in
news:cja### [at] netplexaussieorg: 

> [...]
> Another possibility is to trace against an intersection of a text
> object and two planes or a box for the normal computation.

Thanks but I just tried an intersection between text and a box or plane and 
the normals remain the same.  Unless I'm not understanding correctly.  Why 
two planes?

Post a reply to this message

In article <Xns### [at] 204213191226>,
 Alain <noe### [at] onca> wrote:

> Thanks but I just tried an intersection between text and a box or plane and 
> the normals remain the same.  Unless I'm not understanding correctly.  Why 
> two planes?

Actually, I don't think what I was thinking of is expressible in POV, so 
just ignore that.
If the text object is untransformed, you could just check the z 
component of the returned points and use that to decide whether to flip 
the normal. You could do it even if the text is transformed, though it 
would be a little more complex.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote in news:3f990a8c@news.povray.org:

> [...]
>   I wonder if there are other primitives with inverted normal bugs...
> Perhaps someone should check. :)

Looks like the lathe also has it's normal inside out.  I haven't tested all 
types of lathes.

Post a reply to this message