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

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

-- 

|_|_) | Sysadmin WSR       | Verstand, die Augen haben und nicht sehen,

__/   | http://www.hjp.at/ |    -- Jeremia 5:21

Post a reply to this message