 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I know it's Waaaaaay too late for inclusion in 3.5, but this might be
food for thought for 4.0 (or 3.6)
Instead of having the camera right:up vector ratio default to 4:3 and
providing image_height and image_width built-in variables so that we can
adjust the value of the vectors to match the image aspect ratio, why not
have it default to image_width:image_heigth?
[Not part of the TAG, nor the POV-Team, but I happen to have a few very
good ideas of what's going to be in 3.5]
--
Francois Labreque | Unfortunately, there's no such thing as a snooze
flabreque | button on a cat who wants breakfast.
@ | - Unattributed quote from rec.humor.funny
videotron.ca
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Francois Labreque <fla### [at] videotron ca> wrote:
: Instead of having the camera right:up vector ratio default to 4:3 and
: providing image_height and image_width built-in variables so that we can
: adjust the value of the vectors to match the image aspect ratio, why not
: have it default to image_width:image_heigth?
I have explained this in
http://www.students.tut.fi/~warp/povVFAQ/languageVFAQ.html#aspectratio
The biggest problem of having POV-Ray set automatically the aspect ratio
of the camera to match the aspect ratio of the final image is that:
1) There isn't an unambiguous way of doing it. There are basically two
ways of doing it (and counting all the in-between mixes of the two we get
an infinite amount of variations): Stretching the camera vertically or
horizontally. Which one is the correct? Or a mix of both?
2) Rendering the image with another aspect ratio than the camera will
either hide details (part of the scene will be left out) or show extra
details (part of the scene from outside the camera view will kick in),
which can be sometimes unwanted. With the current behaviour you always
get the intended image, no matter what is the aspect ratio of the image.
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Francois Labreque" <fla### [at] videotronca> wrote in message
news:3B7DCB3E.D9D4B910@videotron.ca...
> I know it's Waaaaaay too late for inclusion in 3.5, but this might be
> food for thought for 4.0 (or 3.6)
>
> Instead of having the camera right:up vector ratio default to 4:3 and
> providing image_height and image_width built-in variables so that we can
> adjust the value of the vectors to match the image aspect ratio, why not
> have it default to image_width:image_heigth?
>
> [Not part of the TAG, nor the POV-Team, but I happen to have a few very
> good ideas of what's going to be in 3.5]
Well, sometimes (when making heightfields) I change the image dimensions to
increase the detail in a certain direction, or because I don't need that
high resolution. Having these changes affect the camera would mean that I
would _have_ to use the same aspect ratio for my images (ie, I couldn't go
from 100x500 to 100x1000 without changing the whole scene).
...Chambers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ben Chambers wrote:
>
> "Francois Labreque" <fla### [at] videotronca> wrote in message
> news:3B7DCB3E.D9D4B910@videotron.ca...
> > I know it's Waaaaaay too late for inclusion in 3.5, but this might be
> > food for thought for 4.0 (or 3.6)
> >
> > Instead of having the camera right:up vector ratio default to 4:3 and
> > providing image_height and image_width built-in variables so that we can
> > adjust the value of the vectors to match the image aspect ratio, why not
> > have it default to image_width:image_heigth?
> >
> > [Not part of the TAG, nor the POV-Team, but I happen to have a few very
> > good ideas of what's going to be in 3.5]
>
> Well, sometimes (when making heightfields) I change the image dimensions to
> increase the detail in a certain direction, or because I don't need that
> high resolution. Having these changes affect the camera would mean that I
> would _have_ to use the same aspect ratio for my images (ie, I couldn't go
> from 100x500 to 100x1000 without changing the whole scene).
There's nothing preventing you from setting the up and right vectors to
a specific value. I was just talking about changing the default
behaviour.
--
Francois Labreque | Unfortunately, there's no such thing as a snooze
flabreque | button on a cat who wants breakfast.
@ | - Unattributed quote from rec.humor.funny
videotron.ca
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Francois Labreque <fla### [at] videotronca> wrote:
: I was just talking about changing the default behaviour.
To what?
Modify the x-vector of the camera to match the aspect ratio? Or would it
be better to modify the up-vector? Or perhaps modify both half-way? Or perhaps
they should be modified weighting by the aspect ratio (ie. if the image is
wider than taller, then the x-vector is modified proportionally more than
the up-vector)?
I suppose you read my other article where I explained why it's not so
trivial as you may think.
(It's trivial to implement, but what it's not trivial is deciding which is
the correct behaviour. It also introduces some problems, as I described.)
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 17 Aug 2001 21:56:14 -0400, Francois Labreque wrote:
> I know it's Waaaaaay too late for inclusion in 3.5, but this might be
> food for thought for 4.0 (or 3.6)
>
> Instead of having the camera right:up vector ratio default to 4:3 and
> providing image_height and image_width built-in variables so that we can
> adjust the value of the vectors to match the image aspect ratio, why not
> have it default to image_width:image_heigth?
What stands against writing "right <image_width/image_height, 0, 0>"
in your camera definition?
Johannes
--
E-Mail: bre### [at] 5slorg www: http://spock.5sl.org/~bretscher
pgp fingerprint = 441A 3B97 811D EC61 DC0A 474B 17C4 EB7F 9BD1 BEAC
God, Root, what is difference?
Illiad
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
>
> Francois Labreque <fla### [at] videotronca> wrote:
> : I was just talking about changing the default behaviour.
>
> To what?
> Modify the x-vector of the camera to match the aspect ratio? Or would it
> be better to modify the up-vector? Or perhaps modify both half-way? Or perhaps
> they should be modified weighting by the aspect ratio (ie. if the image is
> wider than taller, then the x-vector is modified proportionally more than
> the up-vector)?
There were some arbitrary decisions made a long time ago to have the
right-vector default to be 4/3 units in length while all the other ones
have unit lengths. To me it would seem logical to have it follow the
image dimensions. There's no need to start modifying the up, direction,
or sky vector.
> I suppose you read my other article where I explained why it's not so
> trivial as you may think.
I never said it was trivial - I only said it would be more intuitive to
the people using it. And, yes, i did read your other post. I think
your argument about "always getting the intended image" doesn't hold
up. It assumes you want a 4:3 image to begin with. I'm pretty sure
that any one who makes a 300x300 render would have built his or her
scene to render properly with a 1:1 aspect ratio.
> (It's trivial to implement, but what it's not trivial is deciding which is
> the correct behaviour. It also introduces some problems, as I described.)
And having the default aspect ratio be 4:3 instead of relative to the
image dimensions does not introduce problems? We see so many newbies
ask "why is my image squashed?" that there's a faq question dealing with
it.
The default aspect ratio is set to 4:3 because it was assumed by the
coders that (a) all monitors have a 4:3 aspect ratio, (b) all images
will be displayed on such monitors and (c) everyone will want
full-screen images. My suggestion makes only one assumption: pixels
are square.
I was just suggesting that, IMHO, it would be more intuitive (for the
newbies at least) to have the default behaviour or the camera settings
follow the image dimensions and allow someone working with an image size
where the pixels are not square or wanting to produce a specific effect
be able to do so rather than having everyone who wants to trace an image
that does not have 4:3 dimensions remember to change the length of the
right (or up) vector. That is all.
Let's face it, having the aspect ratio be automatically computed rather
than fixed would not matter as most images are made at 4:3 resolutions,
but it would simplify the work for those who work with other image
sizes.
How often do you render non 4:3 images using square pixels?
How often do you render 4:3 images using non square pixels?
Maybe a good compromise would be to have it settable on the command-line
(sorry Bill!) or in the .ini file. Therefore someone who deals mainly
with non 4:3 media such as CD artwork, windows icons or 18"x24" posters,
for example) could "set it and forget it".
--
Francois Labreque | Unfortunately, there's no such thing as a snooze
flabreque | button on a cat who wants breakfast.
@ | - Unattributed quote from rec.humor.funny
videotron.ca
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Francois Labreque <fla### [at] videotronca> wrote:
: Maybe a good compromise would be to have it settable on the command-line
: (sorry Bill!) or in the .ini file.
If it's settable in the command line, then it's automatically settable
in the .ini file.
And I agree that there could be such an option for those who prefer it.
(I'll ask if the team thinks it's a good idea and if it's not too late
for 3.5...)
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
