Hi!

I wanted to cut a "pyramid without a top" out of a box. This is for a
backround of a game so I used an orthographic camera.
  But the shading is all wrong. To show the problem, I squeezed the
prism to have a really shallow angle (see the scale-statement in the
prism), so nearly no difference in the shading of the box and the cutted
out surface should be visible. Uncommenting the first three lines in the
camera-statement shows the problem.

On a sidenote, if you change the perspective camera to a location 37000
y-units far away, and an angle of 1, the problem is turned around. (I
guess, this is due to precision issues... - But there are no gigantic
numbers in the orthographic case.)

My POV-Ray Version is 3.6.1.icl8 on WinXPSP2
Any Ideas?
Thank you!
Kalle

//Sourcecode starts here

camera {
//  orthographic
//  right <650,0,0>
//  up <0,490,0>
   location <320,500,240>
   look_at <320,000,240>
}

difference {
   box {<0,-1,0>,<1+1/3,0,1>}
   prism {
     conic_sweep
     1.1,0.8,4
     <-0.5,0.5>,<-0.5,-0.5>,<0.5,-0.5>,<0.5,0.5>
     translate -y
     scale <1,.000005,1>
     translate y
     translate <0.5,-1,.5>
   }
   pigment { green 1 }
   scale 480
}

light_source {
   <240,500,-240>
   color rgb 1
}

Post a reply to this message

Wasn't it KalleK who wrote:
>Hi!
>
>I wanted to cut a "pyramid without a top" out of a box. This is for a
>backround of a game so I used an orthographic camera.
>  But the shading is all wrong. To show the problem, I squeezed the
>prism to have a really shallow angle (see the scale-statement in the
>prism), so nearly no difference in the shading of the box and the cutted
>out surface should be visible. Uncommenting the first three lines in the
>camera-statement shows the problem.

The problem seems to be related to the fact that the camera is pointing
perfectly vertically down. If you change the camera location to
<320,500,239.9> instead of <320,500,240>, then it all looks fine.

When you then remove the temporary scale statement, you can move your
orthographic camera much closer to the vertical <320,500,239.999999>,
easily close enough to be indistinguishable from the true vertical in
terms of the geometry.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

KalleK wrote:
> Hi!
> 
> I wanted to cut a "pyramid without a top" out of a box. This is for a
> backround of a game so I used an orthographic camera.
>  But the shading is all wrong. To show the problem, I squeezed the
> prism to have a really shallow angle (see the scale-statement in the
> prism), so nearly no difference in the shading of the box and the cutted
> out surface should be visible. Uncommenting the first three lines in the
> camera-statement shows the problem.
> 
> On a sidenote, if you change the perspective camera to a location 37000
> y-units far away, and an angle of 1, the problem is turned around. (I
> guess, this is due to precision problems... - But there are no gigantic
> numbers in the orthographic case.)
> 
> My POV-Ray Version is 3.6.1.icl8 on WinXPSP2
> Any Ideas?
> Thank you!
> Kalle
> 
> //Sourcecode starts here
> 
> camera {
> //  orthographic
> //  right <650,0,0>
> //  up <0,490,0>
>   location <320,500,240>
>   look_at <320,000,240>
> }
> 
> difference {
>   box {<0,-1,0>,<1+1/3,0,1>}
>   prism {
>     conic_sweep
>     1.1,0.8,4
>     <-0.5,0.5>,<-0.5,-0.5>,<0.5,-0.5>,<0.5,0.5>
>     translate -y
>     scale <1,.000005,1>
>     translate y
>     translate <0.5,-1,.5>
>   }
>   pigment { green 1 }
>   scale 480
> }
> 
> light_source {
>   <240,500,-240>
>   color rgb 1
> }
> 
> 

You've run into a pitfall with look_at.  Pointing the
camera directly up or down that way gets it confused.
Better to *not* use look_at and do this instead:

camera {
   orthographic
   locatation <0, 0, 0>
   direction <0, 0, 1>
   right <650,0,0>
   up <0,490,0>
   rotate x*90 // point camera down
   translate <320, 500, 240> // move camera where you want it
//  location <320,500,240>
//  look_at <320,000,240>
}


It might be x*-90 ... I always forget.
This way you retain a mathematically "pure"
vertical.

-- 
to all the companies who wait until a large user base becomes
dependant on their freeware, then shafting said happy campers with
mandatory payment for continued usage. I spit on your grave.

Post a reply to this message

povray wrote:
> 
> You've run into a pitfall with look_at.  Pointing the
> camera directly up or down that way gets it confused.
> Better to *not* use look_at and do this instead:
> 
> camera {
>   orthographic
>   locatation <0, 0, 0>
>   direction <0, 0, 1>
>   right <650,0,0>
>   up <0,490,0>
>   rotate x*90 // point camera down
>   translate <320, 500, 240> // move camera where you want it
> }
> This way you retain a mathematically "pure"
> vertical.

Hi!

Thanks to both of you. I tried the "pure" way but there were the same 
black borders... So I will have to take Mike's compromise. But this will 
do for the moment...

Thanks!
Kalle

Post a reply to this message

KalleK wrote:
> povray wrote:
> 
>>
>> You've run into a pitfall with look_at.  Pointing the
>> camera directly up or down that way gets it confused.
>> Better to *not* use look_at and do this instead:
>>
>> camera {
>>   orthographic
>>   locatation <0, 0, 0>
>>   direction <0, 0, 1>
>>   right <650,0,0>
>>   up <0,490,0>
>>   rotate x*90 // point camera down
>>   translate <320, 500, 240> // move camera where you want it
>> }
>> This way you retain a mathematically "pure"
>> vertical.
> 
> 
> Hi!
> 
> Thanks to both of you. I tried the "pure" way but there were the same 
> black borders... So I will have to take Mike's compromise. But this will 
> do for the moment...
> 
> Thanks!
> Kalle

No problem.  :)

I realize thtough that in my posting, I spelled "location" wrong.
Woops.  :o  Sorry.

Post a reply to this message

> I realize thtough that in my posting, I spelled "location" wrong.
> Woops.  :o  Sorry.

I've senn it while copy'n pasting... no problem at all...

Kalle

Post a reply to this message

povray wrote:
> You've run into a pitfall with look_at.  Pointing the
> camera directly up or down that way gets it confused.

POV-Ray does not get confused at all!  The proper use of look_at is clearly 
outlined in the documentation.  there are no workaround necessary, just 
reading the documentation is sufficient :-)

In order to use look_at to determine the orientation of the camera, POV-Ray 
needs to compute cross product with the "sky" vector.  The default direction 
of the "sky" vector is the y-axis.  Consequently, if look_at - location 
yields a direction vectors also on the y-axis, there is no valid cross 
product and thus look_at will not work as expected.

As said, this is all in much more detail explained in the documentation. 
Thus, for the proper use of the "sky" vector, please consult the POV-Ray 
user reference, online for example at "2.3.1.1.2 The Sky Vector" 
<http://www.povray.org/documentation/view/3.6.1/246/>.

	Thorsten

Post a reply to this message

Thorsten Froehlich wrote:
> POV-Ray does not get confused at all!  ...  Consequently, if 
> look_at - location yields a direction vectors also on the y-axis, there 
> is no valid cross product and thus look_at will not work as expected.

Doesn't that constitute confusion, even if the confusion itself is 
completely expected?  If there is no valid cross product, and the 
look_at isn't working as expected, the end result will be the software 
not knowing exactly what to do, i.e. being confused.

-- 
Tim Cook
http://home.bellsouth.net/p/PWP-empyrean

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GFA dpu- s: a?-- C++(++++) U P? L E--- W++(+++)>$
N++ o? K- w(+) O? M-(--) V? PS+(+++) PE(--) Y(--)
PGP-(--) t* 5++>+++++ X+ R* tv+ b++(+++) DI
D++(---) G(++) e*>++ h+ !r--- !y--
------END GEEK CODE BLOCK------

Post a reply to this message

> Doesn't that constitute confusion, even if the confusion itself is 
> completely expected?  If there is no valid cross product, and the 
> look_at isn't working as expected, the end result will be the software
> not knowing exactly what to do, i.e. being confused.
If the software is given invalid input, it is the user that is confused.

-- 
"And  what if  I assign  a  hundred  programmers  to  it?"   The  master
programmer shrugged. "Then the design will never be completed," he said.
http://www.google.com/search?q=%22pgp+singing%22  <-- childish but funny
http://surreal.istic.org/ <-- It's like a DEATH CIRCUS! | keyid 885b170d

Post a reply to this message

Daniel Hulme wrote:
>>Doesn't that constitute confusion, even if the confusion itself is 
>>completely expected?  If there is no valid cross product, and the 
>>look_at isn't working as expected, the end result will be the software
>>not knowing exactly what to do, i.e. being confused.
> 
> If the software is given invalid input, it is the user that is confused.

Very well said.  In future versions the software will attempt to warn the 
user that he/she is confused.

	Thorsten

Post a reply to this message