|
 |
[XP and Fup2 povray.unofficial.patches, since this seems to be a problem
of megapov only]
On Wed, 30 Aug 2000 11:35:46 -0700, ryan constantine wrote:
>"Peter J. Holzer" wrote:
>>
>> On Tue, 25 Jul 2000 15:30:39 -0700, ryan constantine wrote:
>> >what i really want is to use cylinder type 4,
>> >however the results are not what i expect. what i expect to see is all
>> >four corners with straight rods conecting them instead of the curved
>> >ones from type 2. all i get, however are four horizontal rods. i don't
>> >see any of the sphere-corners. changing the right and up vectors has no
>> >effect.
>>
>> Strange. It works (almost) fine for me (megapov 0.5a on linux).
^^^^^^^^^^^^^^^^^^^^^
Oops. I obviously used povray 3.1g when I tried that (I tried both with
several camera statements, but it seems I missed some combinations).
>could you post your camera code?
camera {
cylinder 4
angle 360
location <0, 10, 0>
right <20, 0, 0>
up <0, 6, 0>
direction <0, 0, 2.5>
look_at <100, 10, 100>
rotate <0, clock, 0>
}
With megapov the picture looks very strange. If the camera points
directly to one of the vertical rods, the rod fills the whole width of
the picture and I can see a mirror image of the other rods in it. If it
points between vertical rods, I see only the horizontal rods.
Looks like the camera is much too narrow.
Looking at the source, I see that this block has been added in megapov:
/* 1999 July 10 Bugfix - as per suggestion of Gerald K. Dobiasovsky
added this if(Precompute_Camera_Constants) block */
/* Get aspect ratio, normalize camera vectors */
if (Precompute_Camera_Constants)
{
VLength(lx, FCR);
VLength(ly, FCU);
/* The inverse of the usual aspect ratio */
Camera_Aspect_Ratio = ly / lx;
VNormalize(FCR, FCR);
VNormalize(FCU, FCU);
VNormalize(FCD, FCD); /* If not normalized in "angle"-statement in parse.c */
}
/* ---- */
/* 2000 May 8 Bugfix - added Camera_Aspect_Ratio */
x0 /= Camera_Aspect_Ratio;
This is wrong for two reasons:
1) It tries to scale the cylinder in inverse proportion to its radius
(i.e, if you specified { up <0, 5, 0> right <20, 0, 0> } it gets transformed
into { up <0, 1, 0> right <4, 0, 0> }, which is totally unexpected.
2) The if (Precompute_Camera_Constants) block is obviously intended to
be entered only once (since it normalizes FCR and FCU,
Camera_Aspect_Ratio will always be 1 after the first pixel).
Fixes:
1) Change
Camera_Aspect_Ratio = ly / lx;
to
Camera_Aspect_Ratio = lx;
and
x0 /= Camera_Aspect_Ratio;
to
x0 *= Camera_Aspect_Ratio;
2) Add
Precompute_Camera_Constants = 0;
at the end of the if-block.
This will restore the length of the right vector, but will normalize
the up vector (so the length of the up vector will be ignored, only its
direction counts).
If you just want the same behaviour as in povray 3.1g, remove the whole
normalization stuff. I don't see any problems with that.
hp
--
_ | Peter J. Holzer | Nicht an Tueren mangelt es,
|_|_) | Sysadmin WSR | sondern an der Einrichtung (aka Content).
| | | hjp### [at] wsr acat | -- Ale### [at] univieacat
__/ | http://www.hjp.at/ | zum Thema Portale in at.linux
Post a reply to this message
|
|
|
|
"Peter J. Holzer" <hjp### [at] SiKituwsracat> wrote...
> 1) Change
> Camera_Aspect_Ratio = ly / lx;
> to
> Camera_Aspect_Ratio = lx;
> and
> x0 /= Camera_Aspect_Ratio;
> to
> x0 *= Camera_Aspect_Ratio;
>
> 2) Add
> Precompute_Camera_Constants = 0;
> at the end of the if-block.
Peter,
After carefully reviewing your changes, I agree with your observations. A
similar change was applied to the other cylinder cameras. This means that
they will work according to the documentation (which is, I guess, the best
description of how the cameras should work.). :-) Also, to be consistent
with the other cameras, the "Precompute_Camera_Constants = 0" line should to
go right before the "break" at the end of the camera's block, not at the end
of the "if" block. It amazes me that it has been missing for so long!
-Nathan
Post a reply to this message
|
|
|
|
i thought my original post about a month ago had the description of what
"everyone" thinks should be the result of a cylindrical camera. i'll
state it again here. actually, i think there should be tow cylindrical
cameras.
#1. take for example your line of sight right now. close one eye.
imagine a line that runs from as low as you can see, through the center
of your vision, up to as high as you can see. this line should be
definable in 3d space. next, imagine a vector coming straight out your
eye in the direction of main interest. this vector should go in the
direction vector of the camera. now think about your field of view left
to right. this should go in the angle of the camera. rays are shot
outward, perpedicular to the line at all times. of course, the line
should be definable to any length, the direction any vector, and the
angle from nearly zero, all the way to 360 degrees.
#2 my dream cylindrical camera would actually be a cylinder (in the
previous example, a line is a cylinder with infinitely small radius)
that would wrap outside the subject to be rendered and would shoot rays
inward or outward as set by the user. rays would stop at the opposite
side of the cylinder in order to exclude subjects outside the radius if
shot inward. in this camera, the center axis would be defined in the
same way as the line in example one. the radius would be definable as
well. rays for this camera would be shot perpedicular to its interior
surface if shot inward, and the exterior surface if shot outward.
any thoughts?
Nathan Kopp wrote:
>
> "Peter J. Holzer" <hjp### [at] SiKituwsracat> wrote...
> > If you just want the same behaviour as in povray 3.1g, remove the whole
> > normalization stuff. I don't see any problems with that.
>
> You see, this is where the problem comes in. What behavior is deisred? It
> seems that many people have different opinions as the the answer to that
> question.
>
> Hopefully we can all come to an agreement. Maybe someone should take a shot
> at describing the final behavior of the cylinder camera (how they think it
> should work) from the user's perspective (i.e. NOT using any code or math
> formulas in the description). If everyone agrees with that, then maybe we
> can finally make this thing work "correctly."
>
> -Nathan
Post a reply to this message
|
|
