|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
It took me 13 years of povving to understand the camera. That is, to come up
with the code for a box which exactly fills the screen, regardless of camera
angle/ distance and image aspect ratio.
I believe that the documentation provided with povray tells no lies, but it
doesn't tell enough of the truth. If you already fully understand how the
camera works, what is written there makes sense. But there are notable
omissions from the documentation:
i) no mention of how +W and +H affect the camera.
ii) no mention of the hierarchy of all these redundant little variables.
Q: If one were to redesign the camera object from scratch, could you make it
more intuitive? Could the camera either require either more heavily lifting or
less?
What if it automatically gave you circular-cross-section spheres regardless of
the pixel ratio? How many people *want* elliptical-looking spheres when they
change the pixel ratio?
Post a reply to this message
|
|
| |
| |
|
|
From: Warp
Subject: Re: New camera, or new camera docs illustrations.
Date: 25 May 2009 10:53:56
Message: <4a1ab104@news.povray.org>
|
|
|
| |
| |
|
|
gregjohn <pte### [at] yahoocom> wrote:
> i) no mention of how +W and +H affect the camera.
Perhaps because those parameters don't affect the camera in any way?
(Ok, there's an exception: If you use image_width or image_height for
defining anything in the camera block, then they do affect it. But that's
not all that relevant.)
> What if it automatically gave you circular-cross-section spheres regardless of
> the pixel ratio? How many people *want* elliptical-looking spheres when they
> change the pixel ratio?
What happens when you *want* to render the image for a resolution with
non-square pixels?
(Yes, there are such situations, and they are pretty common. Search for
"anamorphic" if you don't believe me.)
And if the aspect ratio of the pixels were always assumed to be 1:1 when
changing the resolution of the rendered image, which dimension or the camera
should change when the aspect ratio of the image changes?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
From: scott
Subject: Re: New camera, or new camera docs illustrations.
Date: 27 May 2009 04:55:24
Message: <4a1cfffc@news.povray.org>
|
|
|
| |
| |
|
|
>> What if it automatically gave you circular-cross-section spheres
>> regardless of
>> the pixel ratio? How many people *want* elliptical-looking spheres when
>> they
>> change the pixel ratio?
>
> What happens when you *want* to render the image for a resolution with
> non-square pixels?
You specify in some way that you want this, rather than it being the default
behaviour.
> (Yes, there are such situations, and they are pretty common. Search for
> "anamorphic" if you don't believe me.)
Whilst they may be pretty common, I can't believe they are as common
compared to people who change the aspect ratio for rendering as a desktop
wallpaper or printing out on certain sized paper.
> And if the aspect ratio of the pixels were always assumed to be 1:1 when
> changing the resolution of the rendered image, which dimension or the
> camera
> should change when the aspect ratio of the image changes?
The scene file author should get to decide. How about the following syntax:
camera{
hfov 90
}
This would fix the horizontal field of view to 90 degrees, POV would
automatically calculate the vertical FOV to ensure square pixels based on
the image aspect ratio. This would work if you made some landscape scene
and didn't want any more to be visible left/right, or any part to be cropped
left/right, by rendering at different aspect ratios you just get to see more
or less sky.
Of course the scene author could also use just the "vfov" keyword if they
wanted the vertical FOV to remain fixed and the horizontal to be calculate
automatically.
Then, of course you could specify both "hfov" *and* "vfov" if you really
wanted both directions to be fixed, this would allow for non-square pixels.
POV *could* even warn you that this was about to happen (maybe just once for
each scene file, IDK), and give you three options: 1) render non-square, 2)
adjust the horizontal image resolution to give square pixels, 3) adjust the
vertical image resolution to give square pixels.
Post a reply to this message
|
|
| |
| |
|
|
From: Warp
Subject: Re: New camera, or new camera docs illustrations.
Date: 27 May 2009 05:05:22
Message: <4a1d0252@news.povray.org>
|
|
|
| |
| |
|
|
scott <sco### [at] scottcom> wrote:
> > What happens when you *want* to render the image for a resolution with
> > non-square pixels?
> You specify in some way that you want this, rather than it being the default
> behaviour.
I'd want it the other way: If you want to use a different camera aspect
ratio you have to specify it. By default the camera aspect ratio should be
preserved.
> > (Yes, there are such situations, and they are pretty common. Search for
> > "anamorphic" if you don't believe me.)
> Whilst they may be pretty common, I can't believe they are as common
> compared to people who change the aspect ratio for rendering as a desktop
> wallpaper or printing out on certain sized paper.
Have you taken into account that someone rendering someone else's scene
using an aspect ratio different than what the original author intended
might end up with an image which either clips out parts of the original
image or, worse, shows undermodeled parts which were not meant to be seen?
Shouldn't the choice of how changing the aspect ratio of the camera
affects the composition of the image be left to the author of the image
rather than the person who renders the image (given that sometimes these
are two different people)?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Have you taken into account that someone rendering someone else's scene
> using an aspect ratio different than what the original author intended
> might end up with an image which either clips out parts of the original
> image or, worse, shows undermodeled parts which were not meant to be seen?
>
> Shouldn't the choice of how changing the aspect ratio of the camera
> affects the composition of the image be left to the author of the image
> rather than the person who renders the image (given that sometimes these
> are two different people)?
If you read the rest of my post you'll see that I 100% agree with you, and
this is what my proposed syntax allows, albeit with more flexibility than
the existing one.
Post a reply to this message
|
|
| |
| |
|
|
From: Warp
Subject: Re: New camera, or new camera docs illustrations.
Date: 27 May 2009 06:27:18
Message: <4a1d1585@news.povray.org>
|
|
|
| |
| |
|
|
scott <sco### [at] scottcom> wrote:
> If you read the rest of my post you'll see that I 100% agree with you, and
> this is what my proposed syntax allows, albeit with more flexibility than
> the existing one.
It is currently possible to make a camera which always assumes square
pixels. Doing so in a way that changing aspect ratio affects the composition
of the image vertically (ie. the image is clipped or extended on the upper
and lower sides) is easy. The horizontal equivalent requires a bit more
work, but is also perfectly possible.
(Personally I don't really recommend doing so, for the stated reasons.
I'd say the principal reason is that rendering for an anamorphic resolution
with non-square pixels cannot be done without modifying the scene file.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott wrote:
> camera{
> hfov 90
> }
What's wrong with the "angle" keyword?
--
Chambers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"scott" <sco### [at] scottcom> wrote:
> Then, of course you could specify both "hfov" *and* "vfov" if you really
> wanted both directions to be fixed, this would allow for non-square pixels.
Not the ideal solution, as getting from the desired image & pixel aspect ratios
(which I expect to be *the* known values in such cases) to the angles requires
some messing around with trigonometrics.
Post a reply to this message
|
|
| |
| |
|
|
From: Warp
Subject: Re: New camera, or new camera docs illustrations.
Date: 27 May 2009 13:37:08
Message: <4a1d7a44@news.povray.org>
|
|
|
| |
| |
|
|
Chambers <Ben### [at] gmailcom_no_underscores> wrote:
> scott wrote:
> > camera{
> > hfov 90
> > }
> What's wrong with the "angle" keyword?
It sets the horizontal field of view (regardless of what the camera
aspect ratio is). Making it set the vertical field of view instead requires
something more complicated.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> > You specify in some way that you want this, rather than it being the default
> > behaviour.
>
> I'd want it the other way: If you want to use a different camera aspect
> ratio you have to specify it. By default the camera aspect ratio should be
> preserved.
Me, I cast my vote for the default-to-square-pixels approach.
> Have you taken into account that someone rendering someone else's scene
> using an aspect ratio different than what the original author intended
> might end up with an image which either clips out parts of the original
> image or, worse, shows undermodeled parts which were not meant to be seen?
This argument is a bit short-sighted: The same could be said about rendering an
image at a much higher resolution than originally intended by the author -
which may get you "undermodeled" parts *everywhere*.
Furthermore, an author cannot pass on his scene's source code and at the same
hide those undermodeled parts from curious eyes - just a few changes to the
camera block will reveal them anyway.
Even so, as some previous poster mentioned, a possible solution to this issue
would be to allow the scene author to specify (in the camera settings) how to
deal with non-matching aspect ratios, by choosing between (e.g.)
a) adjust horizontal field of view to fit
b) adjust vertical field of view to fit
c) enlarge field of view to fit
d) reduce field of view to fit
e) distort to fit
f) enforce aspect ratio
(Option f) could pick a resolution with about the same total number of pixels as
specified on the command-line / ini file, but the ratio chosen by the scene
author.)
If complemented with command-line / ini options to explicitly specify a pixel
aspect ratio, I guess we'd have all aspect ratio issues solved.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |