// system :  Win98 / Athlon 800 / 512 MHz RAM  / beta10
// A rare prism bug: Following code produced strange behavior of 
illumination/texture of conic prisms.
// If one declares a rotation value smaller than -89.999999994270432
// and bigger -90.0000000057296  the conic sides of the prism are not 
illuminated by the light_source,
// with ambient 1 they are visible. this happens to all spline types (at 
least the examples I tested).  
// (if  necassary, I can post 2 sample render pictures)
//
// 8) SciBorg
// good luck !


#version 3.5
#declare test=texture { pigment { color rgb 1  } finish { ambient 0  
diffuse 1}   }
light_source {  0*x  color rgb 1.0 translate <10, 10, 50> }
camera {  orthographic  location <0,0,4> look_at  <0,0,0>  right 2.1*x  
up 2.1*y  }
// ----------------------------------------
prism {                                
  conic_sweep  // linear_sweep or conic_sweep for tapering to a point
  linear_spline // linear_spline | quadratic_spline | cubic_spline | 
bezier_spline
  1,  0.5,   4, <-1, -1>,< 1, -1>,<1, 1>,<-1,  1>    
  //rotate  -90.0000000057296*x     // visible
  //rotate  -90.0000000057295*x     // invisible
  rotate  -90*x                   // invisible
  //rotate  -89.999999994270433*x   // invisible
  //rotate  -89.999999994270432*x   // visible
  texture { test }  
}

Post a reply to this message

On Fri, 25 Jan 2002 10:11:10 +0100, SciBorg <tck### [at] irrwerkde> wrote:

>// system :  Win98 / Athlon 800 / 512 MHz RAM  / beta10
>// A rare prism bug: Following code produced strange behavior of 
>illumination/texture of conic prisms.

Confirmed with both compile versions.

POV 3.5 b 10 on WinNT Sp 6 PII 233 with 128 MB

ABX

Post a reply to this message

>On Fri, 25 Jan 2002 10:11:10 +0100, SciBorg <tck### [at] irrwerkde> wrote:
>
>>// system :  Win98 / Athlon 800 / 512 MHz RAM  / beta10
>>// A rare prism bug: Following code produced strange behavior of 
>>illumination/texture of conic prisms.
>
>Confirmed with both compile versions.
>
>POV 3.5 b 10 on WinNT Sp 6 PII 233 with 128 MB
>
>ABX

Thorsten says "Not properly confirmed.  Just being able to reproduce the
exact behavior is not enough.  At least a tiny bit of experimentation
should be done to be able to say it is a bug and not a precision
problem."

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

Mike Williams <mik### [at] nospamplease> wrote in 
news:3BA### [at] econymdemoncouk:

> Thorsten says "Not properly confirmed.  Just being able to reproduce the
> exact behavior is not enough.  At least a tiny bit of experimentation
> should be done to be able to say it is a bug and not a precision
> problem."

I'm wondering just what kind of precision he has in mind if blatant 
lighting errors as a result of using rotate x*90 (that's with zero decimal 
places) can be dismissed as a precision problem.  This kind of reasoning is 
getting close to defining -1^(1/2)=3 as correct.

Working with the example scene, it's plainly obvious that the lighting 
calculations break down on the beveled portions of the prism when the prism 
is transformed to face the camera.  This problem depends on the 
orthographic camera and on the prism being transformed to face the camera 
head-on by using either rotate x*90 or a matrix.

The prism is lit correctly if it is rotated by 90.01 or 89.99 degrees (if 
using rotate), if  a shear component is introduced into the second row of 
the matrix (if using a matrix transform), or if the perspective camera is 
used.

Simplified scene, with matrix transform:

light_source {<10, 10, 50> rgb 1}
camera {orthographic location z*4 look_at 0 right x*3 up y*3}

prism
{                                
    conic_sweep
    linear_spline
    1, .5, 5, <-1, -1>, < 1, -1>, <1, 1>, <-1,  1>, <-1,-1>    

    matrix
    <
        1,0,0,
        0,0,-1,
        0,1,0,
        0,0,0
    >

//    rotate  x*-90

    pigment {rgb 2}
}

background {rgb 0.25}

Post a reply to this message

>
>
>>Thorsten says "Not properly confirmed.  Just being able to reproduce the
>>exact behavior is not enough.  At least a tiny bit of experimentation
>>should be done to be able to say it is a bug and not a precision
>>problem."
>>
[Question] Which kind of experimentation should be done to proof, that 
it is not just a silly annoying precision problem ?
I would expect such things not in a simple rectangular rotation. I would 
like to help but how ?

:-) SciBorg

Post a reply to this message

On Fri, 08 Feb 2002 16:50:03 +0100, SciBorg <tck### [at] irrwerkde> wrote:
> [Question] Which kind of experimentation should be done to proof, that 
> it is not just a silly annoying precision problem ?

Unfortunatelly I've experimented with your report and I must say it is
possible it's not a bug. Rotation is internally represented as matrix. Or
rather two matrixes: normal and inverted transformation. This inverted
transformation is applied to ray during intersection test.
Orthogonal camera type sends parallel rays. Note: bug disappeare when camera
is changed to perspective. I have also found strange behaviour for torus in
orthogonal view.

ABX

Post a reply to this message

> Note: bug disappeare when camera
> is changed to perspective. I have also found strange behaviour for torus in
> orthogonal view.
> 
> ABX

Why does it remind me of a problem with the superellipsoid in 3.1g, which
was also obvious with orthographic and well hidden with perspective and AA ?$
It ends up with a bogus code when a rotation of 270*y was applied...
 it has since been corrected.

Did you report the torus & orthogonal ? (Where ?)

-- 
Non Sine Numine
http://grimbert.cjb.net/
Etiquette is for those with no breeding;
fashion for those with no taste.

Post a reply to this message

On Sun, 10 Feb 2002 16:54:48 +0100, L'Harmonieux Forgeron <jgr### [at] freefr>
wrote:
> Why does it remind me of a problem with the superellipsoid in 3.1g, which
> was also obvious with orthographic and well hidden with perspective and AA ?

I don't know

> It ends up with a bogus code when a rotation of 270*y was applied.

IIRC the problem was that superellipsoid returned only one intersection (or
something similiar).

> Did you report the torus & orthogonal ?

Sure.

> (Where ?)

I remember I reported it earlier on some group but perhaps within thread about
something other. But when beta-testing started I posted regular report here:
http://news.povray.org/i344rt8ftt1ctvq3smm5f8salnaeoclpl3%404ax.com
http://news.povray.org/rh44rtoeu5ifj145bv3iu3uirf6jb7ckrj%404ax.com

ABX

Post a reply to this message

Testing the provided scene with 3.1g, I got the mention that the spline is not closed.
No problem with any rotation value.

Post a reply to this message

<jer### [at] atosorigincom> wrote:
>Testing the provided scene with 3.1g, I got the mention that the spline is not
closed.

the same as with 3.5 b11 probably

> No problem with any rotation value.

strange

I have replaced

rotate  -90*x

with pair of rotations

rotate 90*z
rotate -y*90

and parts are still invisible
then I replaced rotations with matrix

matrix <1,0,0,0,0,-1,0,-1,0,0,0,0> 

and discussed parts are still invisible

ABX

Post a reply to this message