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

"Thorsten Froehlich" <tho### [at] trfde> wrote in
news:3c49ed90@news.povray.org: 


> 
> job000208:
> 
> with orthographic camera objects disappear when "angle" keyword is
> used 

This is not a good description of the bug reported (by me). The camera worked exactly
as expected in 
this scene, but due to some problem related to vista buffer, objects started to
disappear in certain 
cases. (This was confirmed by "advanced users", the bug disappears when the vista
buffer is turned 
off.) It seems that you never checked the actual scene, and didn't even read the bug
report carefully. 

My bug report does not justify the changes you've in my opinion.

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

Again, this is simply wrong.

Gergely

Post a reply to this message

In article <Xns### [at] 204213191226> , Gergely
Vandor <ger### [at] vandordatanethu>  wrote:

>> job000208:
>>
>> with orthographic camera objects disappear when "angle" keyword is
>> used
>
> This is not a good description of the bug reported (by me). The camera worked
> exactly as expected in this scene, but due to some problem related to vista
> buffer, objects started to disappear in certain cases. (This was confirmed by
> "advanced users", the bug disappears when the vista buffer is turned off.)

It may not look like your bug report, that doesn't mean it doesn't describe
the actual problem and its cause.  The actual cause of a problem does not
have to match your interpretation of the cause, but the source code and what
it does that causes the problem.

> It  seems that you never checked the actual scene, and didn't even read the
> bug report carefully.

If you think this, fine.

> My bug report does not justify the changes you've in my opinion.

I am not going to get into a discussion about this.

>> 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
>
> Again, this is simply wrong.

No, it isn't.  The changes seen when using the "angle" keyword are caused by
the direction vector length which is changed by "angle" as you can read in
the manual.  The vista buffer code apparently does not expect these changes
and thus causes the objects to "disappear", which simply means there are no
intersection tests because the vista buffer has "optimized" them away based
on the camera.

    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

"Thorsten Froehlich" <tho### [at] trfde> wrote in
news:3c4a0572@news.povray.org: 

[snip]
>> It  seems that you never checked the actual scene, and didn't even
>> read the bug report carefully.
> 
> If you think this, fine.
> 

[snip]

>> Again, this is simply wrong.
> 
> No, it isn't.  The changes seen when using the "angle" keyword are
> caused by the direction vector length which is changed by "angle" as
> you can read in the manual.  The vista buffer code apparently does not
> expect these changes and thus causes the objects to "disappear", which
> simply means there are no intersection tests because the vista buffer
> has "optimized" them away based on the camera.
> 

Oh, I am sorry then, I was wrong. I hope you weren't offended, and thank you for the
explanation.

Gergely

Post a reply to this message

Thorsten Froehlich wrote:

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


Thanks for the reply.  This leaves me with the following thought :
why should the user use a given order ?  Can't POV-Ray parse all
the options and rearrange them internally to the right order for the 
camera ray transforms ?*  I mean, there is no ambiguity between this :

  camera {
     look_at ..
     right ..
     ultra_wide_angle
     angle ..
     up ..
     location ..
   }

and this :

  camera {
     angle ..
     up ..
     right ..
     location ..
     look_at ..
     ultra_wide_angle
   }

This would avoid 'stupid' mistakes that happened when you forgot to
set a >180° angle *after* a lens that accepts it. This would avoid
breaking thousands of existing scenes.  This would avoid the
memorisation of the order.

About angle/direction : only allow a single of these at the time.
If both are present, it's an error.

About orthographic : either split it into 2 perspective modes
("orthograpic" and "orthographic_auto"), or add an optional
keyword to activate the automatic behaviour.

Just my 2 Eurocents.

Fabien.

(* : I don't know the internals of the parser, and thus don't know
  if it's easy or not).

Post a reply to this message

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

> Thanks for the reply.  This leaves me with the following thought :
> why should the user use a given order ?  Can't POV-Ray parse all
> the options and rearrange them internally to the right order for the
> camera ray transforms ?*

This is the ultimate goal.  However, knowing the camera type in advance is
required for this in order to then issue correct warnings/errors if some
options are exclude/undo others.  As said, the current change is not
complete, it is a kind of a test to see how much trouble forcing the camera
type as the first thing really causes.

So far all I have seen are the perspective/orthographic problems that
existed in a different form before as well.  Once all useful combinations of
parameters have been determined, and you already pointed at some (also there
are interactions between angle and up/right!!!), they will be implemented.

The sooner a fixed order that covers all current features (that make sense,
not some of the odd effects that are possible but probably undesired), the
more likely it is that such an order will be implemented in beta 11...

So input on the suggested order(s) is desired, all they need to be is
deterministic.

As for the orthographic with angle issue, that is already covered and no new
keyword is needed, as angle automatically suggests what should happen when
it appears in an orthographic camera.

    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

On 2002-01-19 20:58, Christopher James Huff <chr### [at] maccom> wrote:
> 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 view area is already given by the up and right vectors. Angle is a
different thing - it's the angle under which the view area appears from
a distance |direction| away. So I think "angle" is ok, even though an
orthographic camera doesn't really have an angle.

	hp

-- 
   _  | Peter J. Holzer    | Hört doch dieses törichtes Volk ohne
|_|_) | Sysadmin WSR       | Verstand, die Augen haben und nicht sehen,
| |   | hjp### [at] hjpat         | die Ohren haben und nicht hören!
__/   | http://www.hjp.at/ |    -- Jeremia 5:21

Post a reply to this message

On 2002-01-19 22:04, Thorsten Froehlich <tho### [at] trfde> wrote:
> 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.

You probably know this and have only postponed adapting the docs until
you have a complete solution, so I'll just mention it here so that it
isn't forgotten:

The docs still claim that the camera type can appear anywhere in the
camera statement and that the order influences the result. 

	hp

-- 
   _  | Peter J. Holzer    | Hört doch dieses törichtes Volk ohne
|_|_) | Sysadmin WSR       | Verstand, die Augen haben und nicht sehen,
| |   | hjp### [at] hjpat         | die Ohren haben und nicht hören!
__/   | http://www.hjp.at/ |    -- Jeremia 5:21

Post a reply to this message

Thorsten Froehlich wrote:

> As said, the current change is not
> complete, it is a kind of a test to see how much trouble forcing the camera
> type as the first thing really causes.


Apparently : much !


> So input on the suggested order(s) is desired, all they need to be is
> deterministic.


What do you mean by "deterministic" ?

> As for the orthographic with angle issue, that is already covered and no new
> keyword is needed, as angle automatically suggests what should happen when
> it appears in an orthographic camera.


Sounds right.

Anyway, here's my suggestion for the order, if there must be an order :

camera {
       Projection_Type

       right <..>
       up <..>

       location <..>
       look_at <..>

       angle .. / direction ..
  }

Fabien.

Post a reply to this message

Fabien Mosen wrote:

> camera {


Ooops, forgot "sky" !  I'll put it just after "up".

Fabien.

Post a reply to this message

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

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

I didn't say the feature was bad, just the syntax for it. Orthographic 
cameras don't have an angle.


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

My understanding is that the changes are to make the camera more 
predictable, not to remove functionality (the old camera was chaos, the 
options often interacted in unexpected ways). The changes are still in 
progress, the new syntax isn't complete yet. This feature could 
reappear, just with a more obvious name.


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

Not if it is easier to understand.

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

Post a reply to this message

In article <slr### [at] tealhhjpat>,
 hjp### [at] hjpat (Peter J. Holzer) wrote:

> The view area is already given by the up and right vectors. Angle is a
> different thing - it's the angle under which the view area appears from
> a distance |direction| away. So I think "angle" is ok, even though an
> orthographic camera doesn't really have an angle.

The what? And the user is supposed to know this?
I'm only saying the keyword is wrong. It isn't the camera angle.

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

Post a reply to this message

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

> Anyway, here's my suggestion for the order, if there must be an order

Based on what you write I am not sure you understood that there is no need
to have an order for the keywords, only an order in which they take effect.

    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 news:slr### [at] tealhhjpat Peter J. Holzer wrote:

> so I'll just mention it here so that it
> isn't forgotten:
> 
> The docs still claim ..

It's not forgotten, I just wait and see what comes out of this before 
making changes.

Ingo

Post a reply to this message

in news:3c4b2153@news.povray.org Thorsten Froehlich wrote:

> only an order in which they take effect.

Do you mean something like:

Camera
    	Type
    	if perspective
    	    	(right, direction) or angle
    	    	sky
    	    	...
    	if orthographic
    	    	...
    	    	...
    	type independent identifiers


Ingo

Post a reply to this message

Christopher James Huff wrote:

> (the old camera was chaos, the 
> options often interacted in unexpected ways)


I always thought that it was because the order directly influenced
the order of transformations of the camera ray.  Isn't it ?

Fabien.

Post a reply to this message

Thorsten Froehlich wrote:

> Based on what you write I am not sure you understood that there is no need
> to have an order for the keywords, only an order in which they take effect.


Oh, OK.  Let me say :

1) projection mode
2) location and look_at
3) sky
4) right and up
5) angle or direction

Fabien.

Post a reply to this message