(There seems to be something wrong with my previous post, so I post again)

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

> You say that full backward compatibility will be preserved - I presume
> that's only when using the #version directive? It won't be possible to clean
> up the camera mechanism and at the same time make it support all the same
> things, so there'll have to be an "old" camera mechanism for #version <3.5
> and a new one for #version >=3.5 which isn't 100% backwards compatible.
> Isn't that what you mean too?

No, it is very possible to clean up the code and have all the functionality
with the language version set to 3.5!  In fact I have done most of it now.

The only problem that I still have to solve is the up and right vectors
would be adjusted by the orthographic camera all the time.  Currently you
can override the adjusting mechanism by having those two after the
orthographic keyword.  Anyway, I know what to do and will make those changes
in the next few days.

> You also say that the order dependency will not and cannot be removed. I
> don't understand either.

I think this is not obvious unless you know a tiny bit how the parser and
parsing works.  So I will try to explain it in general:

The parser basically looks at each keyword it find in order.  It has two
options.  Either it makes adjustments to the camera variables immediately,
or it stores the keyword data and makes the adjustments after it find the
end of the camera block.

Currently in beta 9 and all earlier versions for the keywords that allow a
different order the parser makes the adjustments as soon as it sees the
keyword.  This allows the position of a keyword in the camera to have
different effects.  Opposite to this, for most objects order does not matter
because the keyword data is processed after the end of the object block.

While processing the keyword data immediate has a lot of benefits when using
the camera, it makes the results nearly unpredictable.  I guess you never
noticed that you can even specify multiple cameras in a scene without any
error or warning message.  What happens in that case is that they are
processed as if they are all part of one camera statement in the order in
which they appear in the scene.

Even more interesting is that you can effectively change camera types as
often as you like.  And again you can create very interesting effects this
way.  They all follow the same rules, but the rules are a bit complicated
because setting a camera type or using one keyword may override some values
set by a keyword that appeared earlier.

This can result in bugs.  I.e. you should never set the focal point before
you set the location.

> It won't be possible to make a camera mechanism that's easy to understand if
> it's order dependent. There's nearly infinitely many order combinations in
> which the parameters can be specified

No, in fact there are only a very few.  Once you group parameters by their
function and order and consider which group excludes a whole other group you
have very few useful parameter combinations.

The problem is, right now all combinations are allowed, and a lot of them
have the same effect, some have a different effect and others cause bugs
depending on the order.  What is even more difficult is that combinations
depend on different parameters that don't depend on each other.

> And I think that it *is* possible to make it order independent. Just store
> the camera parameters in dedicated values, and only when the entire scene
> code has been parsed create the camera from those values using a predefined
> order of calculations.

No, for certain cases you need to allow order dependency.

> In most cases the camera will still work the same way as before, as most
> people have followed the hints in the documentation about specifying the
> look_at in the end etc., which follows an implied "correct order" to specify
> the settings. Only in a few cases it will work differently.

Which is actually a problem when using the orthographic camera because
look_at will undo all of the orthographic keyword side effects!

>> 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.
>
> I'm not sure which two models you're referring to. Could you explain...?

For example how angle and orthographic work together.  Angle does, as
documented, change the direction vector length.  However, when using it with
orthographic in order to do the perspective size trick you outlined this
will cause the disappearing objects depending on angle simply because the
objects might be outside the projection plane of the orthographic camera!
Only one way it can work as it should, but right now it would have to guess
if the user will later specify "orthographic".  thus in one model of
thinking order matters while if no orthographic camera is specified angle
works exactly as it is supposed to...

>> 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.
>
> I'm not sure if you're talking about the current behavior or the wished
> future behavior.
>
>> If you could post a draft of such a short summary here
>> 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)
>
> But many users expect the camera to work in a strange way in some cases,
> because it does. Wouldn't it be better to find out which behaviors users
> would find logical?

I am looking for the current useful behavior plus suggestions how people
what it to be fixed so it works as they expect it to work.  The "expect"
part is the most important here as I could come up with an approximate
current model easily by looking at the code - nevertheless, as I don't
actually use different camera types often I might not be able to think of
all useful combinations...

>> I would be very happy to engineer the camera parsing code
>> to exactly match user expectations, without the nasty side
>> effect that currently exist.
>
> I'm not quite sure how big changes you're talking about. Which is it closer
> to: "fix a few of the worst unexpected behaviors" or "complete rewrite with
> new, logical, predictable behavior"

The parsing code is very easy to change and there is very little to it once
there is a clear _goal_ of a specific behavior.  There isn't even enough
code there to rewrite it, it can only be rearranged, which will be
sufficient to fix the parsing problems.

The recent camera related bug reports, which are all causes of the camera
problems noted in the docs make nearly any change to the parsing code
feasible.  Of course this explicitly excludes new camera types and such.

Of course, to avoid any misunderstandings, I am only talking about the
parsing of the camera block, nothing else!  In particular I won't be adding
*any* to cameras (no new keywords), only fix the current ones to work in a
predictable manner!

    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