"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

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

-- 

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

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