|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Somewhere along the ways I've missed an important detail...How does one
set the aspect ratio in a PoV image?
--
ICQ#66022322 http://tailkinker.contrabandent.com
Worker bees can leave
Even Drones can fly away
The Queen is their slave
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Somewhere along the ways I've missed an important detail...How does one
> set the aspect ratio in a PoV image?
To change the width or height of the image, use the +W and +H command line
switches.
To change the actual aspect ratio of the image being rendered, change your
camera declaration:
camera {
location ...
up y
right x*aspect_ratio
... (include look_at or whatever else you want at this point)
}
Generally you want to use both of these at once so that you get a 1:1 pixel
aspect ratio. This can be quickly and conveniently done via
up y
right image_width/image_height
though many (including myself) consider this bad style when used for
anything but quick test scenes, since it makes the image difficult to render
with a non-1:1 pixel aspect ratio, which is useful and necessary in some
cases.
- Slime
[ http://www.slimeland.com/ ]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Slime <fak### [at] emailaddress> wrote:
> right image_width/image_height
You mean "right x*image_width/image_height"?
> though many (including myself) consider this bad style when used for
> anything but quick test scenes, since it makes the image difficult to render
> with a non-1:1 pixel aspect ratio, which is useful and necessary in some
> cases.
Using the automatic aspect ratio (to always get 1:1 pixels) like above
sounds tempting at first, but as you said, it's actually not necessarily
a good idea with most scenes.
What one does not immediately realize (before making actual tests) is
that adjusting the aspect ratio of the camera with the 'right' or the 'up'
keywords always adjusts it vertically (regardless of which one of them is
used, which comes as a surprise to most). That is, if you change the
aspect ratio of the camera, part of the scene will go out of the image
or additional scenery will appear in the upper and lower sides of the
image. The horizontal range of view will keep constant (it can't be
adjusted with 'right' nor 'up').
More often than not, if a scene is designed to be viewed at different
aspect ratios, it's usually designed so that the viewing range can be
freely modified horizontally. This is very typical in eg. outdoor scenes.
That is, if you render a wider image, more scenery appears at the sides
of the image. It's quite rare that scenery is designed so that interesting
new parts can come to view if the image is enlarged vertically.
In these types of scenes having an automatic aspect ratio correction
in the camera would not be helpful at all: Changing the aspect ratio will
not change the horizontal viewing area.
However, this is actually not the main problem: The main problem is
that it's not at all unusual that only visible parts of the scene are
modelled, while the parts of the scene outside the viewing area are
modelled with less accuracy or not at all. For example, someone could
model a brick wall just up to the altitude that it covers the intended
image.
This means that if the scene had automatic aspect ratio correction and
someone happens to render an image with a different aspect ratio, some
parts of the scenery may become visible (at the top and bottom of the
image) which were never intended to be shown.
Moreover, if this someone renders a scene with the aspect ratio set
to the other direction, parts of the original scene will end up out of
the image, perhaps even clipping something important in the original
image.
I assume this is seldom what the original author had in mind.
This phenomenon is also bad in that if someone rendered an image like
this with a different aspect ratio, chances are big that he would not
notice there is something wrong with the image. If due to the clipping
or extra unwanted scenery coming to view the overall quality of the
image suffers, this person could just think the author sucks.
On the other hand, if the scene had no automatic correction, what
the user would get is a squeezed image which has a higher probability
of alerting him that something has gone wrong. (Even though the modern
convert-4:3-tv-image-to-16:9-tv-by-squeezing generation might actually
not see anything wrong, but that's a different story.)
Also, as you said, if someone *wants* to render the image with
non-square pixels (one example being the Windows startup image),
the automatic aspect ratio correction would only cause trouble.
Now, what if someone really wants an automatic aspect ratio correction
which does it *horizontally* instead of vertically (which might be quite
feasible with some scenes)?
This is a much less trivial thing to do. In order to do this one would
have to change both 'right' and 'angle' values of the camera in such way
that the vertical visual range would not change but only the horizontal.
The correct formula to do this is something I have yet to see.
(Hmm... Would this subject make a good entry in the povQ&T site?)
--
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote in message
news:416edac8@news.povray.org...
:snip:
>
> Now, what if someone really wants an automatic aspect ratio correction
> which does it *horizontally* instead of vertically (which might be quite
> feasible with some scenes)?
> This is a much less trivial thing to do. In order to do this one would
> have to change both 'right' and 'angle' values of the camera in such way
> that the vertical visual range would not change but only the horizontal.
> The correct formula to do this is something I have yet to see.
>
> (Hmm... Would this subject make a good entry in the povQ&T site?)
>
probably, it seems to spark a debate every so often.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> You mean "right x*image_width/image_height"?
Right =)
> What one does not immediately realize (before making actual tests) is
> that adjusting the aspect ratio of the camera with the 'right' or the 'up'
> keywords always adjusts it vertically (regardless of which one of them is
> used, which comes as a surprise to most).
I just tested this and I'm not getting that result. I think that's only true
if the 'angle' keyword is specified, since it always adjusts the horizontal
angle of the camera, But 'angle' is an optional keyword (one of the
modifiers, so it doesn't even really have a default).
I'm using this scene:
sphere {z*3,1 pigment {rgb 1} finish {ambient 1}}
camera {location 0 right x up y}
When I change "right x" to "right x*10", the sphere stays the same height
and gets skinny. When I instead change "up y" to "up y*.1", the sphere stays
the same width and gets tall. If I add "angle 67" to the camera, *then* I
get the behavior you're describing.
- Slime
[ http://www.slimeland.com/ ]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Slime <fak### [at] emailaddress> wrote:
> I think that's only true
> if the 'angle' keyword is specified
Good to know.
Seems like if you change the visual range of the camera with 'direction'
instead of 'angle', then 'right' will adjust the horizontal viewing range
of the image.
So, if you want to implement this behaviour, it can be done eg. as:
camera
{ direction z*4
location <5, 2.5, -10>
look_at 0
right x*image_width/image_height
}
This is, in fact, a good tip. I'll take it into account if I write
something for the Q&T site.
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
You know far more than I. Maybe I'm confused, but
this camera statement does give a wider field of view
if you change the width to more pixels. If you render
at 800x400 you see more on the sides than if
you render at 600x400. I find it to be convenient
for changing the aspect ratio. Such as rendering
for slide film (1.5:1) 3000x2000 or computer
screen (1.33:1) 800x600.
camera {location <0,-0.5, -5.5>
right x*image_width/image_height
look_at <0,0,1> }
Harold
"Warp" <war### [at] tagpovrayorg> wrote in message
news:416edac8@news.povray.org...
> Slime <fak### [at] emailaddress> wrote:
> > right image_width/image_height
>
> You mean "right x*image_width/image_height"?
>
> > though many (including myself) consider this bad style when used for
> > anything but quick test scenes, since it makes the image difficult to
render
> > with a non-1:1 pixel aspect ratio, which is useful and necessary in some
> > cases.
>
> Using the automatic aspect ratio (to always get 1:1 pixels) like above
> sounds tempting at first, but as you said, it's actually not necessarily
> a good idea with most scenes.
>
> What one does not immediately realize (before making actual tests) is
> that adjusting the aspect ratio of the camera with the 'right' or the 'up'
> keywords always adjusts it vertically (regardless of which one of them is
> used, which comes as a surprise to most). That is, if you change the
> aspect ratio of the camera, part of the scene will go out of the image
> or additional scenery will appear in the upper and lower sides of the
> image. The horizontal range of view will keep constant (it can't be
> adjusted with 'right' nor 'up').
>
> More often than not, if a scene is designed to be viewed at different
> aspect ratios, it's usually designed so that the viewing range can be
> freely modified horizontally. This is very typical in eg. outdoor scenes.
> That is, if you render a wider image, more scenery appears at the sides
> of the image. It's quite rare that scenery is designed so that interesting
> new parts can come to view if the image is enlarged vertically.
> In these types of scenes having an automatic aspect ratio correction
> in the camera would not be helpful at all: Changing the aspect ratio will
> not change the horizontal viewing area.
>
> However, this is actually not the main problem: The main problem is
> that it's not at all unusual that only visible parts of the scene are
> modelled, while the parts of the scene outside the viewing area are
> modelled with less accuracy or not at all. For example, someone could
> model a brick wall just up to the altitude that it covers the intended
> image.
> This means that if the scene had automatic aspect ratio correction and
> someone happens to render an image with a different aspect ratio, some
> parts of the scenery may become visible (at the top and bottom of the
> image) which were never intended to be shown.
> Moreover, if this someone renders a scene with the aspect ratio set
> to the other direction, parts of the original scene will end up out of
> the image, perhaps even clipping something important in the original
> image.
> I assume this is seldom what the original author had in mind.
>
> This phenomenon is also bad in that if someone rendered an image like
> this with a different aspect ratio, chances are big that he would not
> notice there is something wrong with the image. If due to the clipping
> or extra unwanted scenery coming to view the overall quality of the
> image suffers, this person could just think the author sucks.
> On the other hand, if the scene had no automatic correction, what
> the user would get is a squeezed image which has a higher probability
> of alerting him that something has gone wrong. (Even though the modern
> convert-4:3-tv-image-to-16:9-tv-by-squeezing generation might actually
> not see anything wrong, but that's a different story.)
>
> Also, as you said, if someone *wants* to render the image with
> non-square pixels (one example being the Windows startup image),
> the automatic aspect ratio correction would only cause trouble.
>
> Now, what if someone really wants an automatic aspect ratio correction
> which does it *horizontally* instead of vertically (which might be quite
> feasible with some scenes)?
> This is a much less trivial thing to do. In order to do this one would
> have to change both 'right' and 'angle' values of the camera in such way
> that the vertical visual range would not change but only the horizontal.
> The correct formula to do this is something I have yet to see.
>
> (Hmm... Would this subject make a good entry in the povQ&T site?)
>
> --
> #macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb
M()}}
> N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
> N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}// -
Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 14 Oct 2004 13:46:00 +0000, Tail Kinker
<tai### [at] contrabandentcom> wrote:
>Somewhere along the ways I've missed an important detail...How does one
>set the aspect ratio in a PoV image?
I used to run into this problem all time back when I had my
Amiga. The NTSC resolutions had a pixel aspect ratio of
10:11. The pixels were a little bit taller than they
were wide. So if I rendered a sphere, I would get an
ellipsoid, slightly taller than it was wide.
Here is that I did (please excuse any wrapping):
up <0, 1, 0>
right <(output_image_width / output_image_height) *
(output_pixel_width_ratio / output_pixel height_ratio), 0, 0>
That was my general formula. Those are not pov
variables: you'de have to plug in values beased on what
device/format you were rendering for.
so for a "normal" PC render:
right <(640/480) * (1/1), 0, 0>
which reduces to:
right <(640/480), 0, 0>
Now for an amiga 640x400 NTSC render with those
10:11 pixels:
right <(640/400) * (10/11), 0, 0>
Adjusting the RIGHT parameter expands/contracts
the camera field of view left and right, so sometimes
things will get cropped off the right and left edges (contract)
or sometimes extra thigns will appear on the right and
left edges (expand).
Since we are dealing with ratios, it is not necesary
to use the exact output file pixel dimensions. I could use
4/3 in place of 640/480 with identical results.
Off the top of my head, the wide screen TV format
is a ratio of 16/9? If it is, then your right statement
for that format would look like:
right <(16/9), 0, 0>
Hope that helps. Hope it wasn't too much detail. :D
If there is any confusion let me know nd I'll whip up an
example and post it on the binaries newsgroup.
--
to all the companies who wait until a large user base becomes
dependant on their freeware, then shafting said happy campers with
mandatory payment for continued usage. I spit on your grave.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Harold <bai### [at] 3dculturecom> wrote:
> You know far more than I. Maybe I'm confused, but
> this camera statement does give a wider field of view
> if you change the width to more pixels.
Read the thread further.
--
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|