POV-Ray : Newsgroups : povray.newusers : sphere proportions Server Time
26 Dec 2024 20:03:27 EST (-0500)
  sphere proportions (Message 15 to 24 of 24)  
<<< Previous 10 Messages Goto Initial 10 Messages
From: Psnarf
Subject: Re: sphere proportions
Date: 1 Jun 2021 18:35:00
Message: <web.60b6b5fedfb9240b8b87fe773aaaf4dc@news.povray.org>
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

From: Alain Martel
Subject: Re: sphere proportions
Date: 1 Jun 2021 18:45:08
Message: <60b6b874$1@news.povray.org>

> 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

From: Mike Horvath
Subject: Re: sphere proportions
Date: 1 Jun 2021 18:45:48
Message: <60b6b89c$1@news.povray.org>
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

From: Bald Eagle
Subject: Re: sphere proportions
Date: 1 Jun 2021 19:00:00
Message: <web.60b6bb31dfb9240b1f9dae3025979125@news.povray.org>
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

From: clipka
Subject: Re: sphere proportions
Date: 2 Jun 2021 09:47:51
Message: <60b78c07$1@news.povray.org>
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

From: clipka
Subject: Re: sphere proportions
Date: 2 Jun 2021 16:01:13
Message: <60b7e389@news.povray.org>
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

From: Thomas de Groot
Subject: Re: sphere proportions
Date: 3 Jun 2021 02:41:23
Message: <60b87993$1@news.povray.org>
Op 02/06/2021 om 22:01 schreef clipka:
> 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!

Indeed. Good suggestions.

-- 
Thomas


Post a reply to this message

From: Alain Martel
Subject: Re: sphere proportions
Date: 3 Jun 2021 09:38:36
Message: <60b8db5c$1@news.povray.org>

> On 6/1/2021 6:34 PM, Psnarf wrote:

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

Yes... but, most modern monitors have exactly a 16:9 aspect ratio.
The ubiquitous 1920x1080 is 16:9.


Post a reply to this message

From: clipka
Subject: Re: sphere proportions
Date: 3 Jun 2021 14:36:54
Message: <60b92146$1@news.povray.org>
Am 03.06.2021 um 15:38 schrieb Alain Martel:

> Yes... but, most modern monitors have exactly a 16:9 aspect ratio.
> The ubiquitous 1920x1080 is 16:9.

Most, but not all.

Two 1920x1200 displays here. (And a third one tucked away in a box.)

In general, displays targeted at end-users are pretty much all 16:9; 
those targeted at people who do actual work with them come at 16:10 
surprisingly(?) frequently.

In their office range of displays, Eizo for instance currently offers 
more displays @ 1920x1200 than @ 1920x1080 (10 vs. 8).

In their photo/video editing range of displays, they don't even offer 
1920x1080; in that ballpark, 1920x1200 is the only thing they offer. (At 
higher resolution, they're tending towards 16:9 though, too, or even 17:9.)


Post a reply to this message

From: clipka
Subject: Re: sphere proportions
Date: 3 Jun 2021 16:29:46
Message: <60b93bba$1@news.povray.org>
Am 02.06.2021 um 15:47 schrieb clipka:

> (ramblerambleramble)

Oh, and one thing I forgot to mention entirely:

If you're using POV-Ray v3.8 or higher, and start you scene with

#version 3.8;

(as you should), then your sphere should automagically be round 
regardless of image size, even without messing with `right` and/or `up`.

At least that's what I had written in `changes.txt` some glorious day, 
so it must be true. Totally forgot that I implemented that.


Post a reply to this message

<<< Previous 10 Messages Goto Initial 10 Messages

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.