clipka <nomail@nomail> wrote:
> Me, I cast my vote for the default-to-square-pixels approach.

  Why? You can *already* do that with the current POV-Ray. There's no need
to add anything new to get the behavior.

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

  There is a big difference between rendering at higher resolution and
outright clipping big parts of the image out, or adding big parts which
weren't intended to be seen.

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

  You would have to intentionally tamper with the scene file in order to
destroy the image composition. With an automatic square-pixel assumption
the tampering would be inadverted.

> 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

  All of those can be already done with the current version of POV-Ray.

> If complemented with command-line / ini options to explicitly specify a pixel
> aspect ratio, I guess we'd have all aspect ratio issues solved.

  In fact, that can also be done currently, albeit indirectly. You can use
the 'Declare' command-line option to pass values to the scene file. You
can create a camera definition which sets its aspect ratio according to
such an identifier.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   All of those can be already done with the current version of POV-Ray.

In fact, I fail to see a need for changing the camera at all.  Of 
course, I'm one of the people who simply "got it" when reading (gasp!) 
the docs.

-- 
Chambers

Post a reply to this message

>>   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
>
>  All of those can be already done with the current version of POV-Ray.

I think the point of the request is to make easier to choose from the above 
options without needing to resort to some carefully figured out statements.

Post a reply to this message

>> camera{
>> hfov 90
>> }
>
> What's wrong with the "angle" keyword?

It isn't obvious from the keyword exactly what it sets, and there isn't a 
vertical equivalent.

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> I think the point of the request is to make easier to choose from the above 
> options without needing to resort to some carefully figured out statements.

  That might have been a minor, secondary point. The main point was that
the current default camera behavior should be changed. *That* is what I
disagreed with.

-- 
                                                          - Warp

Post a reply to this message

scott wrote:
>> What's wrong with the "angle" keyword?
> 
> It isn't obvious from the keyword exactly what it sets, and there isn't 
> a vertical equivalent.

 From 3.3.1.1.3:
"The angle keyword followed by a float expression specifies the 
(horizontal) viewing angle in degrees of the camera used."

Am I wrong to assume that someone can look up the documentation?

Aside from that, if you want to change the aspect ratio of the image, I 
find POV's up and right vector usage quite easy to use.

But again, I'm one of those weirdos who actually knows how to read (the 
docs).

-- 
Chambers

Post a reply to this message

>  That might have been a minor, secondary point. The main point was that
> the current default camera behavior should be changed. *That* is what I
> disagreed with.

The current default behaviour means that if you want to render someone elses 
scene for your desktop wallpaper or to print out, you have to search through 
their code for the right camera block and make some changes, I can't even 
remember the number of times I have had to search through and put in some 
"image_width/image_height" statement.  Is this really the best thing for the 
default behaviour?  IMO the default behaviour should mean the least work for 
what is most common, ie if you actually *want* non-square pixels you should 
have to go and fiddle with the code.

Post a reply to this message

>>> What's wrong with the "angle" keyword?
>>
>> It isn't obvious from the keyword exactly what it sets, and there isn't a 
>> vertical equivalent.
>
> From 3.3.1.1.3:
> "The angle keyword followed by a float expression specifies the 
> (horizontal) viewing angle in degrees of the camera used."
>
> Am I wrong to assume that someone can look up the documentation?

Of course not, but using eg "hfov" instead of "angle" means you don't even 
need to open the documentation to realise what it is setting.  It also then 
means the corresponding vfov could be used, again, without having to lookup 
in the documentation.  Once a language syntax gets more complex it's 
actually really handy to work like this, where most things are "obvious" 
without having to look up in the documentation each time.

> But again, I'm one of those weirdos who actually knows how to read (the 
> docs).

...and I'm one of those weirdos who doesn't like needless inefficiencies, no 
matter how small :-)

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> The current default behaviour means that if you want to render someone elses 
> scene for your desktop wallpaper or to print out, you have to search through 
> their code for the right camera block and make some changes, I can't even 
> remember the number of times I have had to search through and put in some 
> "image_width/image_height" statement.

  If the author didn't put such a statement in their camera block, then
maybe the author didn't even intend for the image to be rendered in other
aspect ratios?

  And if you really want to censor part of the image so that it will fit
your screen, then how about rendering it with the intended aspect ratio
and the width of your screen, and then clip it with image editing software?
At least that way you have more control over what you are censoring.

-- 
                                                          - Warp

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> > Am I wrong to assume that someone can look up the documentation?

> Of course not, but using eg "hfov" instead of "angle" means you don't even 
> need to open the documentation to realise what it is setting.

  And exactly how would you even know about the "hfov" keyword without
reading the documentation?

-- 
                                                          - Warp

Post a reply to this message