Rune <run### [at] mobilixnetdk> wrote:
: Specifying the orthographic keyword as the last thing in the camera
: definition has always been a *very* handy feature which meant you didn't
: have to fiddle with the width and height vectors. It's even stated clearly
: in the documentation:

  Who says it will not work like that in the future as well, regardless of
where you put the keyword?
  Why should the camera behave differently depending on where you specify
the camera type keyword? IMO the behaviour of the camera should not depend
on this, and thus requiring it to be the first keyword in the camera block
doesn't change anything.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

"Warp" wrote:
>   Who says it will not work like that in the future
> as well, regardless of where you put the keyword?

Because it doesn't currently?

Specifying the orthographic keyword in the beginning or in the end of the
camera definition gives very different results.

>   Why should the camera behave differently depending
> on where you specify the camera type keyword?

Because if you specify it in the end the up and right vectors are
automatically adjusted to match the specified or implied angle of the
corresponding perspective camera.

> IMO the behaviour of the camera should not depend on
> this, and thus requiring it to be the first keyword in
> the camera block doesn't change anything.

Sorry, but I find usability and backwards compatibility more important than
what your opinion is.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated Nov 5)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

"Rune" wrote:
> Sorry, but I find usability and backwards compatibility
> more important than what your opinion is.

I should have phrased that differently...

Anyway, I'll try to make my point more clear.

It's a well known fact that the order in which the parameters of the camera
is specified is important. If you specify the angle after you specify the
direction, the length of the direction vector is adjusted to match the
angle, but if the direction is specified after the angle, the direction is
what counts. Similarly, if the look_at vector is specified after the
direction vector, the direction vector is adjusted, while if the direction
vector is specified after the look_at vector, then the direction overwrites
the look_at vector specified (or something like that).

There are some other such examples, and in general it's rather difficult to
fully understand how all the parameters in the camera interact (I don't
*fully* understand it myself). The documentation helps a lot though, if you
read it thoroughly.

The orthographic keyword is another such case. If it's specified in the
start, then the angle keyword won't make a difference, and the viewing area
can only be controlled with the up and right vectors. But if it's specified
in the end, it will "convert" the perspective camera to an orthographic
camera and take the former angle (specified or implied) into account. I
almost always use the orthographic camera that way because it's much easier.
I would find it a bad choice to change it.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated Nov 5)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

Rune <run### [at] mobilixnetdk> wrote:
:>   Why should the camera behave differently depending
:> on where you specify the camera type keyword?

: Because if you specify it in the end the up and right vectors are
: automatically adjusted to match the specified or implied angle of the
: corresponding perspective camera.

  Why shouldn't it work so that you specify the 'orthographic' keyword at
the beginning, and subsequent 'angle' or other relevant keywords would change
the right and up vectors as it would be logical?
  That is, if you say 'angle whatever', the right and up keywords are
modified to match that. It you say 'right whatever' after that, then the
right keyword is set to that.

: Sorry, but I find usability and backwards compatibility more important than
: what your opinion is.

  Backwards compatibility has never been an excuse for maintaining bad
features. This is why backwards compatibility in things like 'halo',
'log', etc was not preserved.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Rune <run### [at] mobilixnetdk> wrote:
: It's a well known fact that the order in which the parameters of the camera
: is specified is important.

  I was talking exclusively of the camera type keywords, not the other
parameters.

  I don't understand why 'angle' should have no effect if the keyword
'orthographic' is specified at the beginning, but it should have some
effect if 'orthographic' is specified at the end. Why shouldn't it always
have the same effect regardless of where the 'orthographic' is specified?

: The orthographic keyword is another such case. If it's specified in the
: start, then the angle keyword won't make a difference

  This is exactly what I don't understand why it should be so.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

In article <3c30b4c0@news.povray.org> , "Rune" <run### [at] mobilixnetdk>
wrote:

> Specifying the orthographic keyword as the last thing in the camera
> definition has always been a *very* handy feature which meant you didn't
> have to fiddle with the width and height vectors. It's even stated clearly
> in the documentation:
>
> "If you add the orthographic keyword after all other parameters of a
> perspective camera you'll get an orthographic view with the same image area,
> i.e. the size of the image is the same. In this case you needn't specify the
> lengths of the right and up vector because they'll be calculated
> automatically."
>
> The discussed feature change (not bug fix) would be a *major* brake of
> backwards compatibility and would make it much more annoying to work with
> the orthographic camera in general. Please don't cripple the software like
> that! :(

Calm down.  First of all, you can always use the old style, simply by having
version set to 3.1 when specifying the camera. (**Read the next paragraph**)

Second, and more important, all the issues that I know will result out of
the enforced keyword will be worked out.  However, the camera object and the
side effects of individual keyword within camera are *extremely* complex.
As some bug reports have shown, in some cases they are not desired.  As your
report shows, there are also various cases where a specific order matters or
provides a special feature.

So, let me put it this way:  The current change, which will be either in its
current or in a more advanced form be in the next beta does not mean the
feature is locked for 3.5.  It also does not mean it suddenly breaks all
scenes without workaround.  Old scenes do continue to work with a version
setting.

Even more important:  For a future rewrite it is necessary to have
well-behaved features with deterministic rules.  Right now there are a lot
of implicit assumptions when creating a camera.  These will be replaced with
well specified and homogenous rules that will also make the feature easier
to use - as the current docs point out, it is easy to make mistakes when
creating a camera and POV-Ray will not tell you, it will just not work.
This is what will change, no feature will be removed or inaccessible.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <3c30caf5@news.povray.org> , "Rune" <run### [at] mobilixnetdk>
wrote:

> It's a well known fact that the order in which the parameters of the camera
> is specified is important.

These order dependencies will (and cannot) be removed.  they have not been
removed nor did I imply they have been removed.  Only the camera type has to
be specified at a point so that POV-Ray can take the right action later.
Some of the bug reports regarding camera suggest users magically expect
POV-Ray to guess which of two (both logical) models of thinking they use and
adjust the behavior of the camera.  Obviously POV-Ray has no mind-reading
interface (yet)  :-)

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <3c30caf5@news.povray.org> , "Rune" <run### [at] mobilixnetdk>
wrote:

> There are some other such examples, and in general it's rather difficult to
> fully understand how all the parameters in the camera interact (I don't
> *fully* understand it myself). The documentation helps a lot though, if you
> read it thoroughly.

Honestly, even from the code it isn't all that clear because a few
calculations are done while parsing, while originally everything was done
when rendering.  All the code needs is a bit cleanup.  It will eventually
make the camera fully predictable.  Don't worry about lost features.  And
you old scenes will all continue to work as well!

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <3c30caf5@news.povray.org> , "Rune" <run### [at] mobilixnetdk>
wrote:

> There are some other such examples, and in general it's rather difficult to
> fully understand how all the parameters in the camera interact (I don't
> *fully* understand it myself). The documentation helps a lot though, if you
> read it thoroughly.

Another note regarding this:

It would be good to have a short list of all keywords that are supported by
a specific camera type and if they had to appear before or after the camera
type was specified.  If you could post a draft of such a short summary here
(not the docs, they are too long and contain too much information not
relevant to the keyword order and usage itself) and other would the complete
it so there is a complete list of what behaviors users expect and which they
don't expect (both exist in cameras up to 3.5 beta 9), I would be very happy
to engineer the camera parsing code to exactly match user expectations,
without the nasty side effect that currently exist.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

> > Please also note my recent additions in the Dec 24th list thread.
>
> Regarding:
> job000208
> with orthographic camera objects disappear when "angle" keyword is used
>
> Analysis:
> It turns out this never was a bug. 'angle' works exactly as advertised in
> the manual.  The problem is the user specified the camera type after the
> angle, which assumed it was applied to a perspective camera and
consequently
> changed the direction vector length, which makes it look like the object
> disappears.

I bet you are already fed up with plain users arguing with the real
programmer, but this may be interesting :o)

The scene in the bug report was basically two spheres thrown in front of an
orthographic camera. It rendered *perfectly* until I put a couple of
additional spheres in, after which everything disappeared (no ray/shape
intersections).

This made me believe that the camera setup was correct and what I was
witnessing was a bug. And I'm still not entirely convinced it isn't. I hope
it's not a big sin to drop the slightly modified source in again (a couple
of lines):

camera { location <0,1,-1> look_at <0,1,0> angle 30 orthographic }

sphere { 0,1 texture { pigment {color rgb 1} finish {ambient 1} }  }

/*sphere { <0,1.2,0>,0.18 texture { pigment {color rgb <1,0,0>} finish
{ambient 1} }  }
sphere { <1.2,0,0>,0.18 texture { pigment {color rgb <0,1,0>} finish
{ambient 1} }  }
sphere { <-1.2,0,0>,0.18 texture { pigment {color rgb <0,0,1>} finish
{ambient 1} }  }
sphere { <0,-1.2,0>,0.18 texture { pigment {color rgb <1,1,1>} finish
{ambient 1} }  }*/

sphere { 0,5  texture { pigment {color rgb 1/2} finish {ambient 1} } }

/*plane {y,-100}*/

Here is a new finding: the scene renders perfectly in this form, but if you
bring back any one of the spheres that are currently commented out (or put
any new objects in, like the distant plane), the white sphere disappears.
Which means the camera works as expected as long as there aren't more than
two objects in the scene!

beta9 (but I guess it's the same with any version), w2k
---
Gergely

Post a reply to this message