Hi,
I have the following scene :

camera{orthographic
       location< 0, 20, 0>
       look_at <0,0,0>
       direction -y
       sky z
       up z * 4
       right x * 4}

light_source{<10,10,10>*100000 color srgb 1}

#declare green_col = srgb <8, 59, 4 >/256 ;
#declare brown_col = srgb <82, 62, 9> / 256 ;

#declare T_tent = texture{pigment{ dents color_map{
                                                    [0.0 green_col]
                                                    [0.2 green_col]
                                                    [0.21 brown_col]
                                                    [0.99 brown_col]
                                                    [1.0 green_col]
                                                   }
                                  scale 0.2 rotate 90*x
                                 }
                          normal{agate bump_size 0.25}
                          finish{specular 0.1 roughness 0.9 }
                         }

#declare Pyramid = prism{
                         conic_sweep linear_spline 1,0.5,
                         5 <-1,1>,<1,1>,<1,-1>,<-1,-1>,<-1,1>
                         rotate 180*x translate 1*y}

object{Pyramid texture{T_tent} }

-----------------------------------end of file

I get weird results when rendering. But when I change the camera settings with:

camera{orthographic
       location< 0.00001, 20, 0>
       look_at <0,0,0>
       direction -y
       sky z
       up z * 4
       right x * 4}

I get a render close to what I eventually want.

After a quick research, I found this post:
http://news.povray.org/povray.beta-test/thread/%3C3cd1c5ac%40news.povray.org%3E/

I have a hard time understanding why this is not a bug (the explanation of "
Thorsten Froehlich" especially); my camera isn't 'in' the conic_sweep object.

So , why must I add a small offset in the camera setting to get the expected
result instead of dark slopes for the pyramid ?

Post a reply to this message

On 11/05/2017 07:00 AM, Warren wrote:
> Hi,
> I have the following scene :
> 
>...
> 
> After a quick research, I found this post:
> http://news.povray.org/povray.beta-test/thread/%3C3cd1c5ac%40news.povray.org%3E/
> 
> I have a hard time understanding why this is not a bug (the explanation of "
> Thorsten Froehlich" especially); my camera isn't 'in' the conic_sweep object.
> 
> So , why must I add a small offset in the camera setting to get the expected
> result instead of dark slopes for the pyramid ?
> 
> 

As shown too with an equivalent 'orthographic' user_defined camera in 
the attached version of your scene, the prism issue both in the post you 
referenced, and in your case, has really to do with there being no 
ray/angle offset (x or z) with respect to the sweep sides. Where there 
is no offset the sweep portion of the prism disappears - no roots are 
found - and I do think this a bug(1).

In my experience, orthographic camera rays do start at the 
location/direction plane specified and from that plane in the direction 
given and this is confirmed by the user_defined equivalent camera. I'll 
wait a while to see if others chime in with a clarification to my 
understanding. Otherwise, I'll open up a github issue for this.

Notes to self: 1) Test runs done with Early July 2017 3.8 code. Thinking 
there was a somewhat recent code update related to prism normals by 
Christoph... If so, should verify bug against that update. 2) Wonder if 
some ray/surface orthogonal filtering between the caps is getting in the 
way...

Aside: Your prism is actually inside-out due the clockwise point order. 
I've updated your scene to show both orders with an added 
interior_texture. Oh, and I added the open keyword to eliminate the 
prism caps as these look to me to render correctly with no offset.

Bill P.

(1) - If not, then prism behavior not documented.

Post a reply to this message

Attachments:
Download 'warrennov042017prismissue.pov.txt' (3 KB)

William F Pokorny <ano### [at] anonymousorg> wrote: [...]

Hello / Hi

I didn't know about clockwise point declaration order that turns prism inside
out. And the user defined camera is also new to me.

However, I don't understand the definition you wrote :
// Proves not related to 'plane' of orthographic camera

....Since I'm new with :
camera{
       user_defined

I currently use the version 3.7 of POVRay and even if that's not written in my
post above I use the following statements whenever it's possible:

#version 3.7;
global_settings{ assumed_gamma 1.0 }

Thank you. ;-D

Post a reply to this message

Am 05.11.2017 um 13:00 schrieb Warren:

> After a quick research, I found this post:
> http://news.povray.org/povray.beta-test/thread/%3C3cd1c5ac%40news.povray.org%3E/
> 
> I have a hard time understanding why this is not a bug (the explanation of "
> Thorsten Froehlich" especially); my camera isn't 'in' the conic_sweep object.

No surprise you can't make heads or tails of the thread - none of the
replies there have anything to do with the problem you're facing.

(As for the replies by Warp and Rune, I'm not exactly sure what Warp
meant back then; fact is, orthographic camera rays do start in the plane
passing through the camera location and aligned with the effective (*)
`up` and `right` vectors.)

(* Note that when `look_at` is specified, any explicit `up` and `right`
vectors are only relevant for aspect ratio and handedness issues, and
the effective direction of those vectors is instead computed from
`location`, `look_at` and `sky`.)


> So , why must I add a small offset in the camera setting to get the expected
> result instead of dark slopes for the pyramid ?

I have no idea... yet. All I can say is that William is on the right
track, in that POV-Ray apparently fails to find intersections of the
camera ray with the prism's sides for no obvious reason. Presumably this
happens whenever the ray is perpendicular to the "base" plane of the prism.

Might be a misplaced bailout when the ray is parallel to the prism's
sides, which would be ok for standard prisms but out of place for
tapered prisms.

Post a reply to this message

Am 06.11.2017 um 00:09 schrieb clipka:

>> So , why must I add a small offset in the camera setting to get the expected
>> result instead of dark slopes for the pyramid ?
> 
> I have no idea... yet. All I can say is that William is on the right
> track, in that POV-Ray apparently fails to find intersections of the
> camera ray with the prism's sides for no obvious reason. Presumably this
> happens whenever the ray is perpendicular to the "base" plane of the prism.
> 
> Might be a misplaced bailout when the ray is parallel to the prism's
> sides, which would be ok for standard prisms but out of place for
> tapered prisms.

... and that's /exactly/ what's happening. While tapered prisms use
their own dedicated code path for intersection testing, it appears to
have been created using copy-and-paste - with adaptations, obviously,
but there's indeed an "is it parallel to all sides?" bailout test that
someone forgot to strip from the tapered prisms code path.

Preparing a fix.

Post a reply to this message

Fixed in POV-Ray v3.8.0 (currently under development). If you dare, try
the binaries available at:

https://github.com/POV-Ray/povray/releases/tag/v3.8.0-alpha.9387404

(Make sure to name them differently than the original v3.7 binaries. It
should also be possible to extract them to a different directory and run
them from there.)

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Fixed in POV-Ray v3.8.0 (currently under development). If you dare, try
> the binaries available at:
>
> https://github.com/POV-Ray/povray/releases/tag/v3.8.0-alpha.9387404
>
> (Make sure to name them differently than the original v3.7 binaries. It
> should also be possible to extract them to a different directory and run
> them from there.)

Hi,

Yes, I will try to install povray 3.8.0, why not...
I gathered informations with an old file I kept, named 'config.log' that
contains among others, differents variables/values a user can change before
compile time especially when inputing './configure' at the prompt/terminal.

Until someone will tell me I'm wrong , I think that the variables used to name
the final binary are 'PACKAGE' or/and 'PACKAGE_TARNAME' (they both contain
'povray' )but I'm not sure.
If you can give me some advice about that, I'll be glad. :-D

------------------------
I discovered POVRay in 1997 in a magazine that came with a CD-Rom (that was the
2 second version under MS-DOS: v2.x) All I had as a CPU was an Intel 486 SX2
(yes, without a mathematic coprocessor :-( ). For a scene equivalent to the one
above with the conic_sweep, the render took about 6 hours, I quickly gave up
making scenes (I didn't use editor with the Scene description language, but a
software with iron wire interface with 4 windows named 'POVSB' (under windows
3.1) or something like this. I began learning the SDL later in 2007 until now.
Nostalgia... :-D

Post a reply to this message

On 06/11/2017 19:02, Warren wrote:
> I discovered POVRay in 1997 in a magazine that came with a CD-Rom (that was the
> 2 second version under MS-DOS: v2.x) All I had as a CPU was an Intel 486 SX2
> (yes, without a mathematic coprocessor:-(  ). For a scene equivalent to the one
> above with the conic_sweep, the render took about 6 hours, I quickly gave up
> making scenes (I didn't use editor with the Scene description language, but a
> software with iron wire interface with 4 windows named 'POVSB' (under windows
> 3.1) or something like this. I began learning the SDL later in 2007 until now.
> Nostalgia...:-D


It took you long enough to drop in. ;-)

Welcome.

-- 

Regards
     Stephen

Post a reply to this message

Am 06.11.2017 um 20:02 schrieb Warren:
> clipka <ano### [at] anonymousorg> wrote:
>> Fixed in POV-Ray v3.8.0 (currently under development). If you dare, try
>> the binaries available at:
>>
>> https://github.com/POV-Ray/povray/releases/tag/v3.8.0-alpha.9387404
>>
>> (Make sure to name them differently than the original v3.7 binaries. It
>> should also be possible to extract them to a different directory and run
>> them from there.)
> 
> Hi,
> 
> Yes, I will try to install povray 3.8.0, why not...
> I gathered informations with an old file I kept, named 'config.log' that
> contains among others, differents variables/values a user can change before
> compile time especially when inputing './configure' at the prompt/terminal.
> 
> Until someone will tell me I'm wrong , I think that the variables used to name
> the final binary are 'PACKAGE' or/and 'PACKAGE_TARNAME' (they both contain
> 'povray' )but I'm not sure.
> If you can give me some advice about that, I'll be glad. :-D

Oh wait... you're running Linux? Well, then it's a lot simpler: Just
download the tarball and proceed as usual (prebuild, configure, make,
install), this'll give you a POV-Ray installation living in an entirely
separate set of directories (with `3.8` in the name, as opposed to
`3.7`). Unless you're configuring to install in a custom directory anyway.

For Windows it's a bit more complicated since users don't usually build
their own binaries there. So for the users' convenience we provide
pre-built Windows binaries, but for our own convenience we don't provide
complete installer packages. So the binaries need to "piggyback" on an
existing installation.


> 
> ------------------------
> I discovered POVRay in 1997 in a magazine that came with a CD-Rom (that was the
> 2 second version under MS-DOS: v2.x) All I had as a CPU was an Intel 486 SX2
> (yes, without a mathematic coprocessor :-( ). For a scene equivalent to the one
> above with the conic_sweep, the render took about 6 hours, I quickly gave up
> making scenes (I didn't use editor with the Scene description language, but a
> software with iron wire interface with 4 windows named 'POVSB' (under windows
> 3.1) or something like this. I began learning the SDL later in 2007 until now.
> Nostalgia... :-D

I see your 1997 CD-ROM and raise you a ca. 1995 copy obtained via FidoNet.

(I'm cheating a bit though: I never did a lot with POV-Ray back then,
and only re-discovered it in 2008.)

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 06.11.2017 um 20:02 schrieb Warren:
> > clipka <ano### [at] anonymousorg> wrote:

>
> I see your 1997 CD-ROM and raise you a ca. 1995 copy obtained via FidoNet.
>
> (I'm cheating a bit though: I never did a lot with POV-Ray back then,
> and only re-discovered it in 2008.)

After a quick research for the 'ca' term, I see that it means 'approximately'
(circa) and that's true, the magazine and the CD-Rom in question was sold in
december 1995 it was named "Sciences et Vie Micro - Villagina 3". The 24 bits
Targa files rendered with POVRay definitely caught my fancy by comparison with
the 256 colors of the Windows 3.1 standard desktop.
I notice your message about 3.8.0 POVRay setup under Linux. Thank you ;-D

Post a reply to this message