 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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] mobilixnet dk>
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
A few comments on camera behavior:
I haven't used angle much with the orthographic camera, mainly because it
doesn't make sense to me. (iow, what can "angle" mean when all the rays in
question are parallel?) I did notice, however, that POV will change amount
of scene that is in view when the "angle" is changed. Perhaps there should
be a different keyword (such as "zoom") to work with the orthographic
camera.
As for multiple camera blocks, there are other ways to handle them besides
disallowing them. When I first tried to use two camera blocks, I expected
to render two images, one with the first camera, and then start a second
render with the other camera. Perhaps, alternatively, a second camera
block could simply replace the first camera, wiping out the previous
camera settings.
John Haiducek
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
John David Haiducek <jha### [at] enginumichedu> wrote:
: I did notice, however, that POV will change amount
: of scene that is in view when the "angle" is changed. Perhaps there should
: be a different keyword (such as "zoom") to work with the orthographic
: camera.
There is already: right and up.
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Rune" wrote:
> Ok, here are my suggestions so far.
Are these the kind of suggestions you're looking for, or are the changes too
drastic?
I'd like to know if I should carry on or if I'm on a wrong track.
Rune
--
3D images and anims, include files, tutorials and more:
Rune's World: http://rsj.mobilixnet.dk (updated Jan 2)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
