 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
[Thorsten Froehlich talks about cleaning up the way the camera works, and I
think this deserves a new thread.]
Thorsten,
Cleaning up the way the camera works sounds very interesting, and like a
good idea!
However, there's a few things I don't understand.
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?
You also say that the order dependency will not and cannot be removed. I
don't understand either.
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, and it isn't possible to explain the
effects of them all. Making the order of the parameters independent will
make it easier to understand.
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.
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.
I'm not entirely sure that's the right way to go, but I'd like to hear
comments about it.
I have thought out many more details about how the camera could work, but
I'll take one step at a time...
> 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...?
> 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 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"
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
(There seems to be something wrong with my previous post, so I post again)
In article <3c3102f7@news.povray.org> , "Rune" <run### [at] mobilixnet dk>
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich <tho### [at] trfde> wrote:
: I guess you never
: noticed that you can even specify multiple cameras in a scene without any
: error or warning message.
I have noticed this and I have always liked this property. It can be
an extremely useful property sometimes.
For example: An include file may set a camera given some parameters (say,
an include by Colefax). However, this include doesn't support everything a
camera could support (eg. normal perturbation of the camera rays). Fortunately
this doesn't matter, as I can call the include file, which sets the camera,
and I can afterwards add the extra stuff to the camera, and everything works
just great. I mean, like:
#declare some include file parameters
#include "fancy_include.inc" // this sets the camera according to the params
camera
{ normal { bumps .5 scale .1 }
}
This is incredibly versatile and useful. Disallowing this property would
certainly deprive povray of a great feature.
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" wrote:
> For example: An include file may set a camera
> given some parameters (say, an include by Colefax).
> However, this include doesn't support everything a
> camera could support (eg. normal perturbation of the
> camera rays).
Or focal blur.
> Fortunately this doesn't matter, as I can call the
> include file, which sets the camera, and I can
> afterwards add the extra stuff to the camera, and
> everything works just great.
Exactly. :)
I recently discussed this exact thing with someone (I don't remember who)
while creating the screen.inc include file.
> This is incredibly versatile and useful. Disallowing
> this property would certainly deprive povray of a great
> feature.
I don't think it will be disallowed. Only things where it's important that
it's specified a specific place in the order of parameters.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c31e212@news.povray.org> , "Rune" <run### [at] mobilixnetdk>
wrote:
>> This is incredibly versatile and useful. Disallowing
>> this property would certainly deprive povray of a great
>> feature.
>
> I don't think it will be disallowed. Only things where it's important that
> it's specified a specific place in the order of parameters.
Yes and no. It may very well have to be disallowed if the reported "bugs"
are supposed to get fixed. The order dependency problems could not be fixed
reliably without it* unless a way is found so that there is one order that
will always work as desired.
Thorsten
* Or the not appropriate method of storing the position of each and every
keyword found in the camera statements. If it turns out that this will be
the only way to satisfy all parties, the current "bugs" - which are nothing
more than very complex and correct but undesired interactions - will have to
remain and the code won't be changed...
____________________________________________________
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:
:>> Disallowing
:>> this property would certainly deprive povray of a great
:>> feature.
: It may very well have to be disallowed
I don't think I need to comment this...
--
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 1 Jan 2002 01:27:58 +0100, "Rune"
<run### [at] mobilixnetdk> wrote:
>You also say that the order dependency will not and cannot be removed. I
>don't understand either.
I'll dissect the source for you, namely Parse_Camera in parse.cpp, and
extract some tissue for further inspection.
* if the 'orthographic' keyword is parsed
- the camera type is changed to orthographic
- the up and right vectors are adjusted to get the same image area
as with the perspective camera
* if the 'angle' keyword is parsed
- the direction vector length is adjusted accordingly
* the 'direction', 'up' and 'right' vectors directly change the
respective camera parameters
* if the 'look_at' keyword is parsed
- the up vector is calculated
- the right vector is calculated
- the direction vector is calculated
You can see that there are different means to address the various
parameters of a perspective/orthographic camera. So you can see the
order they are specified in really counts.
Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG e-mail : pet### [at] tagpovrayorg
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Peter Popov" wrote:
> I'll dissect the source for you, namely Parse_Camera
> in parse.cpp, and extract some tissue for further inspection.
Actually I was aware of all that, not because I've seen the source code, but
as a result of many years of using POV-Ray.
> You can see that there are different means to address
> the various parameters of a perspective/orthographic
> camera. So you can see the order they are specified in
> really counts.
The point is that it doesn't really make sense to specify the up, right and
direction vectors (the core of the camera) *after* you specify either of the
"adjusting parameters" like angle or look_at. So as Thorsten also pointed
out, there are some orders that are not useful.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ok, here are my suggestions so far.
For the orthographic camera make the projection plane go through the
location point rather than through the (location+direction) point. This
should keep those objects from disappearing.
And here's a big change - make the angle keyword adjust the up and right
vectors instead of the direction vector. For the perspective camera it will
make no difference. For the orthographic camera it will mean that the
viewing area will be adjusted no matter if the angle is specified before or
after the orthographic keyword. This means that the orthographic keyword can
be specified at the very start, and yet the angle trick will still work.
Backwards compatibility won't be a big problem as it is doubtful that users
have specified an angle keyword after the orthographic keyword when it's
ignored anyway. If they have, they can just remove it, and the scene will
render like before.
I'm not fully aware of how it will affect the other camera types, but I
think it should be no problem to adapt them to work well with this new
behavior.
If this change is implemented there will AFAIK be nothing that adjusts the
length of the direction vector. This alone is a great step towards a more
predictable and intuitive camera.
Now here's one more change that will be possible if the before mentioned
change to the angle parameter is implemented - h_angle and v_angle should be
allowed for all camera types! h_angle will only adjust the right vector
while v_angle will adjust the up vector. This is particularly useful for
camera types like cylinder camera type 1 and 3, where the vertical and
horizontal angle respectively can currently only be set indirectly by
messing with the up and right vectors respectively. h_angle and v_angle were
never needed any more for the spherical camera in the first place than for
those camera types.
So, what do you say?
BTW, the documentation for the various camera types really should be
improved. I think I can do that to some extent, but I'd like to wait till
the camera mechanism is fixed.
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
|
|
| |
| |
|
|
|
|
| |
|
|
