Ken <tyl### [at] pacbellnet> wrote:
> This is one of the oldest bugs that I know of. It has something
> to do with the camera being at x+z = 0 while using look_at = 0.

More specifically, the problem is caused by the camera's view direction
being parallel to the sky direction (e.g. location <3, -5, 1> look_at <3,
15, 1> should also cause the problem).  When this occurs, POV-Ray is unable
to determine the up vector of the camera matrix, and the result is often a
program crash.

As Ken detailed, a work-around to avoid this is simply to shift the location
or look at so the view direction is not parallel to the sky direction, which
can also be done by specifying the sky or up vector of the camera directly.

Post a reply to this message

Ken wrote in message <3A232B64.7E9DE15F@pacbell.net>...
>
>This is one of the oldest bugs that I know of. It has something
>to do with the camera being at x+z = 0 while using look_at = 0.
>
>i.e. -
>
>camera {
>        location <0, 3, 0>
>        look_at 0
>        }


I've never had a problem with doing this.  Is it something specific to a
particular version?  I'm using POV-Ray for Windows 3.1e, all versions of
MegaPOV, many versions of the SuperPatch, all versions of UVPov since 4.0a,
and all versions of SkyPOV.

--
Mark

Post a reply to this message

Mark Wagner wrote:

> I've never had a problem with doing this.  Is it something specific to a
> particular version?  I'm using POV-Ray for Windows 3.1e, all versions of
> MegaPOV, many versions of the SuperPatch, all versions of UVPov since 4.0a,
> and all versions of SkyPOV.

It used to be a problem in v2.2 and it happened in v3.0 for Windows.
It guess I have been so strongly influenced by this I doubt I ever
checked it out in v3.1.

-- 
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

"Dawn McKnight" <mck### [at] maccom> wrote in message
news:3A2### [at] maccom...

Well, there have been other suggestions, but, IIRC, hf's do sometimes crash
pov - the general solution is to move the camera slightly.

Post a reply to this message

Dawn McKnight <mck### [at] maccom> wrote:
: Someone recently posted on here that a crash is always an error; that
: the appropriate action for the program to take if there's something
: wrong is to give an error message, not to crash.

  I think that was me. And you are right. Povray should never crash, specially
when we are dealing with the camera location. If the camera location is
illegal, an error should be issued instead of just starting the rendering
and crashing.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

I've only had this problem with heightfields.

--
Peter
http://hertel.no/bigone

> Mark Wagner wrote:
>
> > I've never had a problem with doing this.  Is it something specific to a
> > particular version?  I'm using POV-Ray for Windows 3.1e, all versions of
> > MegaPOV, many versions of the SuperPatch, all versions of UVPov since
4.0a,
> > and all versions of SkyPOV.
>
> It used to be a problem in v2.2 and it happened in v3.0 for Windows.
> It guess I have been so strongly influenced by this I doubt I ever
> checked it out in v3.1.

Post a reply to this message

"Dawn McKnight" <mck### [at] maccom> wrote in message
news:3A2### [at] maccom...

Does the problem occur if you remove the hf? (put something else in scene to
avoid "no objects" warning).

Post a reply to this message

The problem is that the Cartesian system of describing a 3dimensional space doesn't
allow for proper calculations when the
camera points straight down like that. The up vector goes from y to <0,0,0> and
rotations are mathematically impossible. I
don't have all the mathematical details here, but the calculations jump to infinity in
this situation. My brother works with
aerodynamics and he had to work around this by using quaternions.

Josh

Dawn McKnight wrote:

> Someone recently posted on here that a crash is always an error; that
> the appropriate action for the program to take if there's something
> wrong is to give an error message, not to crash.  So I'm posting this
> code, which makes POV do just that.
>
> I am using POV-Ray, version 3.1g for Macintosh, on a G3/300 running OS
> 9.0.4, with 160mb RAM.  I know code shouldn't normally be posted in this
> group, but this is /really/ short, as I was looking at how height fields
> work.  I suspect my slopes are too abrupt or too confused, but here it
> is.  You can find the image I was using to create the height field at
<http://www.coyotesdaughter.com/dawn/newworld.gif>.
>
> #include "colors.inc"
>
> light_source { <0, 10, 0> White }
>
> camera {
>         location <0, 3, 0>
>         look_at 0
>         } // close camera
>
> height_field {
>         gif
>         "newworld.gif"
>         //smooth
>         pigment { Red }
>         }
>
> --
> Dawn McKnight      | "Who cares what the hipbone's connected to? I'm in Neurology!"
> McK### [at] maccom   |                                    -- Justine Devlin, M.D.

--
Josh English -- Lexiphanic Lethomaniac
eng### [at] spiritonecom
The POV-Ray Cyclopedia http://www.spiritone.com/~english/cyclopedia/

Post a reply to this message

On Mon, 27 Nov 2000 19:23:13 -0700, Dawn McKnight <mck### [at] maccom>
wrote:

<snip>

>camera {
>	location <0, 3, 0>
>	look_at 0
>	} // close camera

I am almost certain this appears in the POV-Ray documentation. At
least I am certain I knew it long before I started frequenting this
server. Basically, when the direction vector is parallel to the y
axis, there's a high chance of a division by zero error. This happens
because the default sky vector is +y and POV gets confused when it
tries to determine the transformation matrix to apply to the camera.
Try moving the camera location or look_at just a bit (1E-6 in x or z
is enough), using an up vector of +z (yuck!) or just placing your
object in the xy plane instead of xz, and then using a more common
camera such as camera { location -3*z }


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

Another solution is to not use the look_at keyword
and instead use a direction statement in the camera
block and then rotate/translate the camera as needed.
This also allows more control of the camera.

camera {
  location 0            // leave at 0 so rotation works as expected
  direction <0, 0, 1>   // look along the Z axis in the + direction
  right <640/480, 0, 0> // change depending on output image dimensions
  up <0, 1, 0>
  rotate WHATEVER
  translate WHEREEVER
}


Of course, right, up, and direction must be mutally perpendicular.

Post a reply to this message