The support of the "shortcut" orthographic camera is broken in beta 10. It
used to be possible to control the field of view of the orthographic camera
by specifying the orthographic keyword in the end of the camera definition.
This feature has only partly been preserved. Moving the orthographic keyword
to the start does *not* give the same results!

Before, the field of view could be controlled by moving the camera location
back and forth. That has no effect in beta 10. Changing the angle works, but
only if the angle is specified after the look_at vector (it seems).
Otherwise it has no effect and no error is generated either.

My most common way of using the orthographic camera was like this:

camera {location -5.5*z orthographic}

By now there's no way to control the viewing area that simple as far as I
can see.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated Jan 2)
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 in message
news:3c488e98@news.povray.org...
> The support of the "shortcut" orthographic camera is broken in beta 10. It
> used to be possible to control the field of view of the orthographic
camera
> by specifying the orthographic keyword in the end of the camera
definition.
> This feature has only partly been preserved. Moving the orthographic
keyword
> to the start does *not* give the same results!
>
> Before, the field of view could be controlled by moving the camera
location
> back and forth. That has no effect in beta 10. Changing the angle works,
but
> only if the angle is specified after the look_at vector (it seems).
> Otherwise it has no effect and no error is generated either.
>
> My most common way of using the orthographic camera was like this:
>
> camera {location -5.5*z orthographic}
>
> By now there's no way to control the viewing area that simple as far as I
> can see.

orthographic is meant to use right and up keywords to set field of view; in
fact, any other way would seem like the wrong way to me, seeing as how the
projection type is parallel.  Just more logical that the projection type be
stated in one place and not change anything dependant upon place stated,
IMHO anyhow.

bob h

Post a reply to this message

"bob h" wrote:
> orthographic is meant to use right and up keywords
> to set field of view

That's one way to do it. But it was also meant to allow setting it the way I
mentioned, just like the documentation says. It's not exactly strictly
logical, but very simple and intuitive to use, and the preferred method of
many. And as I understood Thorsten, support for this trick was supposed to
be kept, only, the orthographic keyword should be moved to the beginning,
but it would still work the same way. However, that doesn't seem to be the
case.

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

Post a reply to this message

Seems now angle must go after look_at.  And I have a feeling you already
said so too.  Yes, checking original post you did say that.  I have a couple
scenes using orthographic opened into the editor and I put angle after
look_at and got a strange render, a isosurface that appparently is cut off
about midway down the render window.  So I agree somethings very different
now.
As I said before, I never use angle in orthographic.  Weird thing is,
yesterday I couldn't get angle to go anywhere but after look_at in a default
camera.  Today I checked and can.  But I never trust these things until I
experience again and again and again.

bob h

"Rune" <run### [at] mobilixnetdk> wrote in message
news:3c48bda0$1@news.povray.org...
> "bob h" wrote:
> > orthographic is meant to use right and up keywords
> > to set field of view
>
> That's one way to do it. But it was also meant to allow setting it the way
I
> mentioned, just like the documentation says. It's not exactly strictly
> logical, but very simple and intuitive to use, and the preferred method of
> many. And as I understood Thorsten, support for this trick was supposed to
> be kept, only, the orthographic keyword should be moved to the beginning,
> but it would still work the same way. However, that doesn't seem to be the
> case.

Post a reply to this message

Rune wrote:

> That's one way to do it. But it was also meant to allow setting it the way I
> mentioned, just like the documentation says. It's not exactly strictly
> logical, but very simple and intuitive to use, and the preferred method of
> many. And as I understood Thorsten, support for this trick was supposed to
> be kept, only, the orthographic keyword should be moved to the beginning,
> but it would still work the same way. However, that doesn't seem to be the
> case.


Maybe there could be a new keyword to switch to either behaviour.
("orthographic_adjust", "orthographic_auto",...)

I for one would also miss greatly the intuitive method.

Fabien.

Post a reply to this message

> Maybe there could be a new keyword to switch to either behaviour.
> ("orthographic_adjust", "orthographic_auto",...)

My humble opinion is that more words just add complexity but not simplicity
for the users. It's best to have just a few words with much freedom. A
strict way of expressing a camera is okay if it protects against troubleful
rendering, but not if it mostly takes away freedom.. This is a fine balance,
but more keywords would give ... a mess.

Hugo

Post a reply to this message

In article <3c49cfa0$1@news.povray.org>, "Hugo" <hua### [at] post3teledk> 
wrote:

> My humble opinion is that more words just add complexity but not simplicity
> for the users. It's best to have just a few words with much freedom. A
> strict way of expressing a camera is okay if it protects against troubleful
> rendering, but not if it mostly takes away freedom.. This is a fine balance,
> but more keywords would give ... a mess.

But using the wrong keyword can be very confusing. Orthographic cameras 
have no angle, the angle keyword does something completely different. A 
"view_area" keyword might be better.
The behavior might be intuitive and useful, but the syntax used to make 
it currently is not.

On the other hand, you don't want to make different keywords that mean 
the same thing, like "no_shadow" and "shadowless".

-- 
 -- 
Christopher James Huff <chr### [at] maccom>

Post a reply to this message

Christopher James Huff wrote:

> The behavior might be intuitive and useful, but the syntax used to make 
> it currently is not.


Really ?
If my memory serves well, in first betas of P3.0 (1996), orthographic
has to be set with up and right.  Later, they introduced the
"automatic" adjustement.  Pretty simple : put orthographic *after*
distance or angle, and it will try to match.  I always found that
very intuitive.

Basically, all that matters to me (and many others, I suppose) is
having the ability to set the "automatic approximate orthographic"
easily.

BTW, why was that change (being more strict about perspective type
declaration) needed ?

And, given the number of potential broken scenes, isn't it more
of a potential support problem than anything else ?

Fabien.

Post a reply to this message

I like the explicit way to specify the area with
up and right vectors. Then there is no confusion
if a precise operation is needed.


_____________
Kari Kivisalo

Post a reply to this message

In article <3C4### [at] skynetbe> , Fabien Mosen 
<fab### [at] skynetbe>  wrote:

> And, given the number of potential broken scenes, isn't it more
> of a potential support problem than anything else ?

Yes, the bugs reported as job000208 and job000196.

job000196:

When "angle" keyword within camera statement appears after "panoramic"
keyword it is ignored. Report:
http://news.povray.org/povray.beta-test/19868/129184/

Solution: It appears the code was never designed to use "angle" for the
"panoramic" camera. With 3.5 the camera type (see job 208) is now enforced
and "angle" is always ignored. If this is not the desired behavior, change
the parsing code of "angle" to make direction adjustments for the
"panoramic" camera type as well.


job000208:

with orthographic camera objects disappear when "angle" keyword is used

Reported: http://news.povray.org/povray.beta-test/19674/

Solution: 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. Now, with version 3.5 specified the camera type has
to be the first thing in a camera statement. The default (which obviously
does not need to be specified) is still perspective, of course.


And there have been other problems with the unpredictable nature of camera.
Of course, there need to be further changes, but as nobody seems to know all
the possible combinations of keywords and their order, it is a rather
difficult task without breaking anything.  I still hope to come up with a
complete solution for beta 11, which will basically allow one order to fit
all needs, which should be possible.

    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