"Psnarf" <nomail@nomail> wrote:
> The code for demo.pov:
>
> #include "colors.inc"    // The include files contain
> #include "stones.inc"    // pre-defined scene elements
>
> camera {
>     location <0, 2, -3>
>     look_at  <0, 1,  2>
> }
>
> sphere {
>     <0, 1, 2>, 2
>     texture {
>         pigment { color Yellow }
>     }
> }
>
> light_source { <2, 4, -3> color White}
>
> -=-=-=-=-=-=-=-=-
> Why does the radius of the sphere change if the render window is not 1:1.333?
> A ratio of 1:1.777 (16/9) produces the attached image.

I don't think it's the "render window", but rather the camera configuration
which is the controlling factor.  In the same way that you can scale the sphere,
you can scale the camera.  Depending on the aspect ratio of the image, you're
going to need to compensate for that in some way - the easiest being the camera.

If you look at the diagram of the camera, you get a "viewport" with "uv
coordinates" of the image going from -0.5 to 0.5 both vertically and
horizontally, or one unit in each orthogonal direction.  If those are not
equally subdivided into the same number of pixels per unit, then when you try to
draw a circle, you get an ellipse.   When you try to draw a square, you get a
rectangle.  So when the image aspect tries to "pull" in one direction, you
"squash" it the same relative amount in the other so that it all balances out.

Believe, me, we've covered this very topic from a variety of angles, and if
you're intensely interested, I can point you to a number of threads, and you can
try to do some experiments of your own to demonstrate to yourself how it all
works.

http://news.povray.org/povray.binaries.images/thread/%3Cweb.5bb3646e813dde7ac437ac910%40news.povray.org%3E/

http://news.povray.org/povray.binaries.images/thread/%3Cweb.587ce3fc782d1af2c437ac910%40news.povray.org%3E/?ttop=418740
&toff=50&mtop=415328


While not "POV-Ray", I personally find it instructive to learn how people code
pixel shaders from scratch, which gives me a lot of easily-accessible insight
into how things like cameras, light, shadows, transform matrices, pattern
functions, mathematical object primitives, and CSG operations work "under the
hood".

https://www.youtube.com/watch?v=dKA5ZVALOhs
https://www.youtube.com/watch?v=PBxuVlp7nuM

https://iquilezles.org/www/articles/frustum/frustum.htm

Post a reply to this message

I did not know the default aspect ratio was 4/3, or 1.333. I still don't see the
connection between the rendered object in 3d space and the +W +H switches to the
povray command. A ball should look the same no matter the size of the rendered
image. If the aspect ratio of the povray scene is different than the dimensions
of the rendered scene, should not the borders be extended, leaving a 4/3 box in
the center of the final image? I'm looking for a keep-aspect-ratio switch.

Post a reply to this message

hi,

"Psnarf" <nomail@nomail> wrote:
> ... I still don't see the
> connection between the rendered object in 3d space and the +W +H switches to the
povray command.

the width + height were used to ensure the ratio matches that specified in the
camera; any size will do as long as you have the aspect ratio be the same for
both camera _and_ image.  ;-)


regards, jr.

Post a reply to this message

Hunted down section 1.4.2.4 in the manual.
camera
{ right x*ImageWidth/ImageHeight
  (other camera settings...)
}

Post a reply to this message

From Section 2.3.1.1.6:
Most computer video modes and graphics printers use perfectly square pixels.
Note: 640/480 = 4/3 so the ratio is proper for this square pixel mode.
Non-square pixels: IBM VGA mode 320x200

It may be some time before the default aspect ratio changes to 1080p, 1.777.

Post a reply to this message

> Hunted down section 1.4.2.4 in the manual.
> camera
> { right x*ImageWidth/ImageHeight
>    (other camera settings...)
> }
> 
> 
It's image_width/image_height, no capital and with an underscore.

camera
{ right x*image_width/image_height
   (other camera settings...)
}

It can also be set using the up vector as follow :
camera
{ up y*image_height/image_width
   right x
   (other camera settings...)
}

Yes. That structure will ensure that the camera will always respect the 
aspect ratio of the generated image.

image_width and image_height are internal, reserved variables that 
contain the actual dimensions of the rendered image.

Post a reply to this message

On 6/1/2021 6:34 PM, Psnarf wrote:
>  From Section 2.3.1.1.6:
> Most computer video modes and graphics printers use perfectly square pixels.
> Note: 640/480 = 4/3 so the ratio is proper for this square pixel mode.
> Non-square pixels: IBM VGA mode 320x200
> 
> It may be some time before the default aspect ratio changes to 1080p, 1.777.
> 
> 

I prefer 16:10. I hear 3:2 is very nice too. 16:9 is only good for 
movies IMO. Should not be used for work displays.


Mike

Post a reply to this message

Yeah, but the exact syntax of those commands is more like:

camera {
 location <0, 0, -3>
 look_at <0, 0, 0>
 right x*image_width/image_height
}

Dunno which version you're landing on, but the most up-to-date documentation
will be at:
https://wiki.povray.org/content/Main_Page

I don't know if this will help or not, but consider this:

There is no sphere.
Likewise, there is no camera, no light - none of it exists.
It's all just one big mathematical simulation whose whole goal is to do one
thing - figure out what color to make that pixel at the current <x, y> location.
(Not on the screen, mind you - in a FILE - a big wad of 0's and 1's that might
have visual meaning when properly processed and displayed on your monitor.

http://www.rene-magritte.com/this-is-not-an-apple/
https://conceptually.org/concepts/the-map-is-not-the-territory

As such, you have no space, and no reference by which to establish an objective
unit of measure.  And so at some point you have to boot-strap things and impose
one "arbitrarily".
And that is done by the standard method of taking the image dimensions and
making it one unit high and one unit wide in the z=1 plane for the default
camera.
(you don't even have to declare a camera if you use the default and know that
it's at the origin and looking at <0, 0, 1>)
But now you have to take the number of pixels into account, and - adjust - for
that.

Take a piece of regular letter/A4 paper and divide it into 10 units long and 10
units wide - you get rectangles.   It gets farther off if you use 8.5 x 14.
So if you were going to use sin and cos to calculate the positions of points
around the circle, and you just graphed it as is - it would _look_ like an
ellipse because your basis vectors are unequal.  So instead of applying a
correction to every bloody thing that you do, you could just view the paper
through a lens that scrunched the paper in one dimension, altering the visual
perception of the graph such that it now properly _looks_ like a circle.

And that's the all the "camera" is in POV-Ray, a mathematical "lens" that maps
the raw mathematical result onto a different "space".

And truly, unless you have some specific need for knowing HOW it all works
(believe me, I understand), then just don't worry about it and plug-and-chug.


https://www.youtube.com/watch?v=uAXtO5dMqEI

Post a reply to this message

Am 01.06.2021 um 19:37 schrieb Psnarf:

> Why does the radius of the sphere change if the render window is not 1:1.333?

For some background information:

POV-Ray's historic roots date back as far as 30 years. The earliest 
pieces of code were developed for the Commodore Amiga series of computers.

When the earlier versions of the current scene description language were 
designed, square pixels were still a novelty, while screen aspect ratio 
was pretty much standardized: Virtually all personal computers of that 
era used standard PAL or NTSC analog TV sets as a displays, which had a 
designed aspect ratio of 4:3, and even computers that came with their 
own display followed that convention. (It was customary to have a small 
border around the image, so that the edges of the image wouldn't be 
hidden in the somewhat rounded corners of the TV set, but that usually 
didn't affect the aspect ratio too much.)

When it came to pixel resolution though, those early systems had a wide 
variety of standards: 320x200 was quite common, especially in NTSC 
dominated regions (note the 8:5 = 16:10 aspect ratio!), but the pixels 
would have been slightly taller than wide; 320x240 (genuine 4:3) was 
occasionally seen in computers specifically targeted at PAL-dominated 
regions, but e.g. the Amiga 500 in PAL mode would have used 320x256 
(5:4), using slightly squashed pixels.

And then there were those computers that used different modes to get 
more colours out of the same amount of video buffer memory (and memory 
read timing) at the cost of horizontal resolution, or vice versa, giving 
image resolutions as odd as e.g. 160x200 (4:5) or 640x200 (16:5). Not 
anywhere close to square pixels there.


TL;DR: Back in those days, it was anything but a given that the "storage 
aspect ratio" (the aspect ratio in pixels) of an image would match the 
"display aspect ratio" (the aspect ratio in cm or inch as displayed on 
screen), because pixels were rarely square back then.


That still holds true in some professional applications, e.g. HDV or 
DVCPRO HD - though the details of those formats tend to rarely be 
exposed to end users anymore.

Also, POV-Ray allows to render formats where the display aspect ratio is 
fixed in some other ways while the storage aspect ratio could be adapted 
depending on requirements; e.g. 360 degrees panoramic images (the 
standard 2:1 ratio there is sub-optimal unless your main focus of 
interest is near the "equator").

Post a reply to this message

Am 02.06.2021 um 00:45 schrieb Mike Horvath:

> I prefer 16:10. I hear 3:2 is very nice too. 16:9 is only good for 
> movies IMO. Should not be used for work displays.

Hear, hear!

Post a reply to this message