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

>>
>> 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

Well, I'm still confused, after reading the section about the sky-Vector.
I introduced a few lines in my camera-statement, but still, the black 
borders appear:

   up <0,0,490> // this changed, to get the right view, before the camera
                // is rotated due to look_at
   direction <0,-1,0> // to get the right direction first
   sky <0,0,1>        // this should be "up" in my case...

So I still don't get any solution without adding a tiny delta to the 
cameras location or look_at...

Post a reply to this message

KalleK wrote:
> Well, I'm still confused, after reading the section about the sky-Vector.
> I introduced a few lines in my camera-statement, but still, the black 
> borders appear:
> 
>   up <0,0,490> // this changed, to get the right view, before the camera
>                // is rotated due to look_at
>   direction <0,-1,0> // to get the right direction first
>   sky <0,0,1>        // this should be "up" in my case...
> 
> So I still don't get any solution without adding a tiny delta to the 
> cameras location or look_at...

If you the look_at and location as in you original post and the sky you 
provide here, note that your "up" vector will face down.  Using up together 
with look_at, again as documented, POV-Ray only considers the *length* of 
the up and right vector (similar for direction of look_at is used).  So, a 
negative direction vector still has a length of one, and does not change the 
look_at direction sign as you seem to want it to.  Depending on what you 
want to do, swapping your look_at and location vectors will be sufficient 
(that certainly turns the camera around).

I would strongly recommend you carefully read the camera tutorial in the 
documentation if you still have problems.  It is well written, and if you 
start from the beginning (rather than in the middle), you will learn 
everything you need to know about handling the camera.

	Thorsten

Post a reply to this message