"Thorsten Froehlich" wrote:
> (There seems to be something wrong with my previous post

Which was not a post but a mail... :)

<snipped description of how the camera works>

Basically, your description of how the camera works tells me that it works
just like I thought it did.

> Currently (...) 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.

Yes.

> I guess you never noticed that you can even specify multiple
> cameras in a scene without any error or warning message.

Actually I'm fully aware of that.

Anyway, you say that the immediate keyword processing make the results
nearly unpredictable, but you also say that there's in fact only very few
useful parameter combinations.

Is it then correctly understood that the majority of the unpredictable
results are caused by users using parameter combinations that are not
useful?

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

Seems like it was correctly understood then, and the solution is to generate
much more errors, or?

> What is even more difficult is that combinations depend
> on different parameters that don't depend on each other.

That's a bit abstract for me...

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

Ok.

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

But you know what to do, I expect?

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

I'm still not sure I understand the problem. Orthographic has always worked
for me both when specified in the beginning and in the end...

Is the projection plane placed L units in front of the location point, where
L is the length of the direction vector? If so, couldn't the projection
plane just go through the location point instead?

> 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'll see what I can do.

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

Post a reply to this message