Hi all

What does this camera "right" statement imply?

Does it have to do with aspect ratio? I am guessing that "image_width" and
"image_height" are PovRay built-in variables, taken from the command line
or an .INI file, and that this has to do aspect ratio?

Why does Moray use

right     <    1.35836,         0.0,         0.0>

and not the line above?

Thanks!
-- 
Stefan Viljoen
Software Support Technician
Polar Design Solutions

Post a reply to this message

In article <40b70c5a@news.povray.org> , Stefan Viljoen <rylan@<deletehis> 
wrote:

> What does this camera "right" statement imply?
>
> Does it have to do with aspect ratio? I am guessing that "image_width" and
> "image_height" are PovRay built-in variables, taken from the command line
> or an .INI file, and that this has to do aspect ratio?
>
> Why does Moray use
>
> right     <    1.35836,         0.0,         0.0>
>
> and not the line above?

Don't be confused by the x*image_width/image_height.  It simply is a short
form of writing a vector with the x-component having the value
image_width/image_height.  That plague with x*image_width/image_height
started with 3.5 as some users put it in every scene, which is not the
intended use.  It only makes sense if you plan to render a scene at a fixed
aspect ratio regardless of the image aspect ratio (that is, if different
resolutions of an image when rendered are not expected to be proportional).

Most of the time the camera "right" is specifying the width of the the view
only.  However, it is a vector also able to specify a part of the camera
direction together with the other camera vectors.  Please refer to the
reference part of the manual, which has a lengthy camera section describing
the camera parameters in detail.

What Moray outputs is simply an aspect ratio in a vector.

    Thorsten

____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

news:40b719ac$1@news.povray.org...
> Don't be confused by the x*image_width/image_height.  It simply is a short
> form of writing a vector with the x-component having the value
> image_width/image_height.  That plague with x*image_width/image_height
> started with 3.5 as some users put it in every scene, which is not the
> intended use.  It only makes sense if you plan to render a scene at a
fixed
> aspect ratio regardless of the image aspect ratio (that is, if different
> resolutions of an image when rendered are not expected to be
proportional).

Uh? I'm not sure I understand why this is a "plague"... The stretch/squeeze
issue is such a common headache for newcomers that it made its way into FAQ
9.1.2.4, which is the primary source of the image_width/image_height trick.
Hey, for a couple of years in the pre-internet days (no peer support then) I
rotated all my vertical scenes to render then at 800*600, so I'm talking
about "real" headaches... As far as I'm concerned, automatic aspect ratio
should have been the default setting (instead of 4/3) because it's extremely
practical and something less to worry about. The FAQ says that the current
behaviour is necessary because of the possibility of non-square pixels, but
only gives the old Windows startup screen as an example. Are there other
common circumstances (video output?) where having square pixels by default
would be problem?

G.

-- 

**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters

Post a reply to this message

Gilles Tran wrote:
> 
> As far as I'm concerned, automatic aspect ratio
> should have been the default setting (instead of 4/3) because it's extremely
> practical and something less to worry about.

I agree the 'trick' is not as bad as Thorsten tries to make it in 
practical scene design (i often play with the aspect ratio of the render 
when creating a scene and don't want to be required to modify both 
render parameters and camera settings every time i change it).  But 
automatic aspect ratio is not as easy as it might seem because there are 
at least two ways to implement it (automatic right vector length or 
automatic up vector length).

And note changing the default is a problem in terms of backwards 
compatibility (otherwise the current '1.33' would already have been 
changed).

> Are there other
> common circumstances (video output?) where having square pixels by default
> would be problem?

The most common probably is printing on a printer with anisotropic 
resolution.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 01 May. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

Gilles Tran <tra### [at] inapginrafr> wrote:
> Uh? I'm not sure I understand why this is a "plague"... The stretch/squeeze
> issue is such a common headache for newcomers that it made its way into FAQ
> 9.1.2.4, which is the primary source of the image_width/image_height trick.

  The problem I see with this "trick" is that it's unpredictable.

  Even though a perfect model of the scene models everything which could
be viewed from the camera location (looking at any direction), it's quite
common that to save work people just model the visible part of the
scene (visible with the current camera location and look_at).
  What happens if he (or worse, someone else) decides to render the image
with a different aspect ratio? The image doesn't get squeezed, but at the
cost of either extra scene (which may not be modelled at all) coming into
view or part of the original scene going out of view (which may leave
important details out of the image).
  Both of these phenomena may be as bad as a squeezed image because they
can potentially destroy the look of the image by introducing modelling
artifacts (lack of proper modelling of the scene) or by leaving out important
details of the image.

  Another problem is that the automatic control of aspect ratio can only
be done by adding/removing extra image vertically. (Making image_width
and image_height change the 'up' vector does not help: The elongation of
the image is still done vertically.)
  One could think "my scene is ok regardless of how much the viewing plane
is elongated horizontally... but why is 'right x*image_width/image_height'
doing it the wrong way? What should I do?".
  The only way to control the aspect ratio horizontally would be to make
the 'angle' change as well. Are you willing to guess the correct formula?
  Scenes are quite often designed so that they look good even if a
"widescreen shot" is done of them. It's not unusual that modelling
extra scene vertically is skipped.

  Even though this trick may sound pretty handy at first, personally I'm
not completely happy with it.
  IMHO this trick should not be freely preached without a good warning
about its (often surprising) side-effects.

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

In article <40b72edf$1@news.povray.org> , "Gilles Tran" <tra### [at] inapginrafr>
wrote:
> Uh? I'm not sure I understand why this is a "plague"... The stretch/squeeze
> issue is such a common headache for newcomers that it made its way into FAQ
> 9.1.2.4, which is the primary source of the image_width/image_height trick.
> Hey, for a couple of years in the pre-internet days (no peer support then) I
> rotated all my vertical scenes to render then at 800*600, so I'm talking
> about "real" headaches... As far as I'm concerned, automatic aspect ratio
> should have been the default setting (instead of 4/3) because it's extremely
> practical and something less to worry about. The FAQ says that the current
> behavior is necessary because of the possibility of non-square pixels

The drawbacks have been discussed in this thread:
<http://news.povray.org/*/thread/%3Cslrnc079it.ntq.cera%40queen.mcs.drexel.e
du%3E/>

The summary is that for new users image_width/image_height does more harm
than good as it is not really easy to predict how it behaves.  In particular
Warp gave a good summary of all the problems related to this.

> Are there other
> common circumstances (video output?) where having square pixels by default
> would be problem?

Apart from DV and fullscreen DVD video and most video output systems
available, which are non-square, DVD widescreen is heavily stretched - the
compressed video is always 720 pixels in width and 480 (NTSC) or 576 (PAL)
in height. And there are also non-square pixels with 1280*1024 on a CRT
monitor.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Christoph Hormann <chr### [at] gmxde> wrote:
> But 
> automatic aspect ratio is not as easy as it might seem because there are 
> at least two ways to implement it (automatic right vector length or 
> automatic up vector length).

  Have you actually tried them? They do exactly the same thing: The viewing
area is always modified vertically, never horizontally. (If you wanted
automatic horizontal viewing area change, you would have to deal with
both 'right' and 'angle', with a less trivial formula.)
  I see this even more problematic.

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

In article <40b72edf$1@news.povray.org> , "Gilles Tran" <tra### [at] inapginrafr>
wrote:

> 9.1.2.4, which is the primary source of the image_width/image_height trick.

Note that it does by no means suggest the use of the keywords, but rather
expressed the formula for computing the correct square-pixel aspect ratio.
Maybe it should be more elaborate and explain why image_width/image_height
are not the optimal or recommended solution.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Warp wrote:
> 
>>But 
>>automatic aspect ratio is not as easy as it might seem because there are 
>>at least two ways to implement it (automatic right vector length or 
>>automatic up vector length).
> 
> 
>   Have you actually tried them? They do exactly the same thing: The viewing
> area is always modified vertically, never horizontally. (If you wanted
> automatic horizontal viewing area change, you would have to deal with
> both 'right' and 'angle', with a less trivial formula.)

It works perfectly with an orthographic camera.  With perspective it is 
indeed quite complicated but this does not mean it would not be possible 
implement an automatic aspect ratio in both ways i described.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 01 May. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

news:c97cgl$64o$1@chho.imagico.de...

> And note changing the default is a problem in terms of backwards
> compatibility (otherwise the current '1.33' would already have been
> changed).

Yes, it's certainly stuck that way in the current POV-Ray line, no big deal
anyway. Changing 1.33 into image_height/image_width is certainly the first
thing I do when reusing old scenes though...

> The most common probably is printing on a printer with anisotropic
> resolution.
But is that a common problem? I can imagine that some printers are able to
do anisotropic printing, but I guess that these machines would be able to
print standard, square-based images too. What would be the point of not
being able to do so, or am I missing something obvious there?
Googling about pixel ratio returns links to (professional?) video
production, with people complaining that entry-level software like Bryce or
Poser cannot do non-square pixels for video, unlike professional apps like
AfterEffects.

G.


-- 

**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters

Post a reply to this message