Greetings !

Half question half feature change request !

   Of all the features in Pov-Ray there is one that has properties
that make little sense when compared to the operations of other
features. This would be of course the image_map & and height_field
location.
   Why is it when everything else is centered at origin these have
been implemented to start at origin and go to x1 y1 ? There is no
other feature, outside of the media feature and radiosity, that I
can think of, that causes more confusion for new users and old,
than this aggravating quirk.
   Would it have been difficult to have had the image automatically
centered ? I think this behavior should be changed in Pov-Ray release
4.0 if at possible. It sure would ease the suffering of millions.


   Another problem for many users has been the fact that image maps
act on a solid object the same as a pigment and or texture. That is
if applied to one side of an object it appears reversed on the opposite
side of the object. Perhaps it is time to implement a new option to the
image map feature to allow something like a hollow statement. This would

allow application of an image map to a single surface and not the entire

object. Handy for that beer bottle label, ship decal, and so on.

Comments and discussion encouraged.


Ken Tyler

Post a reply to this message

I agree with you one the centering of image_maps, since that what everyone
tends to do anyway before applying any tranformations. (ie. translate <-.5,
-.5, 0>).  Same deal with height_fields.

The other thing you bring up is a little more complicated.  I don't think it
would be easy to have an image apply to only one part of an object.  That
would be handled better with parametric mapping, but that would mean having
to create a UV space for all primitives.  For a sphere that should be simple
enough, since that's pretty much covered by spherical mapping anyway.  A box
would have to be split up a bit.  Cylinder even harder.  Sor...hmm.

Maybe it could happen someday.

-Mike



Ken wrote:

> Greetings !
>
> Half question half feature change request !
>
>    Of all the features in Pov-Ray there is one that has properties
> that make little sense when compared to the operations of other
> features. This would be of course the image_map & and height_field
> location.
>    Why is it when everything else is centered at origin these have
> been implemented to start at origin and go to x1 y1 ? There is no
> other feature, outside of the media feature and radiosity, that I
> can think of, that causes more confusion for new users and old,
> than this aggravating quirk.
>    Would it have been difficult to have had the image automatically
> centered ? I think this behavior should be changed in Pov-Ray release
> 4.0 if at possible. It sure would ease the suffering of millions.
>
>    Another problem for many users has been the fact that image maps
> act on a solid object the same as a pigment and or texture. That is
> if applied to one side of an object it appears reversed on the opposite
> side of the object. Perhaps it is time to implement a new option to the
> image map feature to allow something like a hollow statement. This would
>
> allow application of an image map to a single surface and not the entire
>
> object. Handy for that beer bottle label, ship decal, and so on.
>
> Comments and discussion encouraged.
>
> Ken Tyler

Post a reply to this message

Ken wrote:

>    Why is it when everything else is centered at origin these have
> been implemented to start at origin and go to x1 y1 ? There is no
> other feature, outside of the media feature and radiosity, that I
> can think of, that causes more confusion for new users and old,
> than this aggravating quirk.
>    Would it have been difficult to have had the image automatically
> centered ? I think this behavior should be changed in Pov-Ray release
> 4.0 if at possible. It sure would ease the suffering of millions.

I respectfully disagree.  The documentation is incredibly clear.
A simple "translate <-0.5, -0.5, -0.5>" centers things -- this is 
so trivial there is no reason to change the source code. 

-- 
http://www.flash.net/~djconnel/

Post a reply to this message

Dan Connelly wrote:

> I respectfully disagree.  The documentation is incredibly clear.
> A simple "translate <-0.5, -0.5, -0.5>" centers things -- this is
> so trivial there is no reason to change the source code.
>
> --
> http://www.flash.net/~djconnel/

I respectfully disagree with your respectful disagreement.
Your simple example is 28 characters long. That's a lot
of simple typing. Nor does it redily explain the ambiguity.

Ken

Post a reply to this message

IRDWYDOMD :).

There is no ambiguity -- the docs are incredibly clear.

If you mean consistency, it isn'c clear to me it requires height fields
be centered.  Boxes aren't.  And it is conventional to assign coordinates to raster
images with the origin at a corner.  Either centered or uncentered
would be justified.

And if you want to count characters, just do "translate -0.5" .
You can even assign this to a macro to make your own "keyword".
There's no reason to clutter up the official keyword list.

Dan

Ken wrote:
> 
> Dan Connelly wrote:
> 
> > I respectfully disagree.  The documentation is incredibly clear.
> > A simple "translate <-0.5, -0.5, -0.5>" centers things -- this is
> > so trivial there is no reason to change the source code.
> >
> > --
> > http://www.flash.net/~djconnel/
> 
> I respectfully disagree with your respectful disagreement.
> Your simple example is 28 characters long. That's a lot
> of simple typing. Nor does it redily explain the ambiguity.
> 
> Ken

-- 
http://www.flash.net/~djconnel/

Post a reply to this message

I think that a simple translate is best, anyhow, who's poor figners cannot
take the miniscule extra effort to type a translate command, hell the amount
you just wrote they must be worn down to the stumps, i hope your medical
insurance covers this.

and while were on the subject, what is the point of fixing something that
isnt broken, if it works, LIVE WITH IT.

Rick

Dan Connelly wrote in message <364### [at] flashnet>...
>IRDWYDOMD :).
>
>There is no ambiguity -- the docs are incredibly clear.
>
>If you mean consistency, it isn'c clear to me it requires height fields
>be centered.  Boxes aren't.  And it is conventional to assign coordinates
to raster
>images with the origin at a corner.  Either centered or uncentered
>would be justified.
>
>And if you want to count characters, just do "translate -0.5" .
>You can even assign this to a macro to make your own "keyword".
>There's no reason to clutter up the official keyword list.
>
>Dan
>
>Ken wrote:
>>
>> Dan Connelly wrote:
>>
>> > I respectfully disagree.  The documentation is incredibly clear.
>> > A simple "translate <-0.5, -0.5, -0.5>" centers things -- this is
>> > so trivial there is no reason to change the source code.
>> >
>> > --
>> > http://www.flash.net/~djconnel/
>>
>> I respectfully disagree with your respectful disagreement.
>> Your simple example is 28 characters long. That's a lot
>> of simple typing. Nor does it redily explain the ambiguity.
>>
>> Ken
>
>--
>http://www.flash.net/~djconnel/

Post a reply to this message

Yeah, I also agree that centering image_maps would be logical, but it has never
annoyed me, so I haven't complained. Getting height_hields to look right is a
pain anyway, so the translate -.5 thingy kinda doesn't matter. Still, you have a
point.

The other problem is much more important. I don't think it's very difficult (to
somebody much wiser than me ;)). You shouldn't need any parametric mapping in
many cases (like applying an image to only one side of a polygon or cylinder).
This is how I imagine it: if the outside surface is hit by the sample ray,
calculate the map color; if the inside is hit, don't calculate. This should be a
sufficient solution in most cases (like the bottle label example).

Margus

Post a reply to this message

Mike wrote:
> 
> The other thing you bring up is a little more complicated.  I don't think it
> would be easy to have an image apply to only one part of an object.  That
> would be handled better with parametric mapping, but that would mean having
> to create a UV space for all primitives.  For a sphere that should be simple
> enough, since that's pretty much covered by spherical mapping anyway.  A box
> would have to be split up a bit.  Cylinder even harder.  Sor...hmm.
> 
> Maybe it could happen someday.
> 
> -Mike
> 

Maybe it will happen today.  ;-)  Go to
http://nathan.kopp.com/patched.htm

to get my unofficial version of POV-Ray that includes limited (but mostly bug
free) surface mapping (or parametric mapping or uv mapping or whatever you want
to call it).  It currently works for bicubic_patch, mesh, mesh2 (a new syntax
for the mesh object), lathe, sor, sphere, and box.

You could also get the SuperPatch from Twyst's patchstation, since it includes
most of my surface-mapping code (I think it is currently lacking the code for
lathe & sor).  If you don't need the lathe/sor stuff, you should probably get
the superpatch since it has all sorts of other really cool features.  :-)

Just remember... these are unofficial versions of POV so don't expect any help
from the POV Team.

-Nathan Kopp

Post a reply to this message

Dan Connelly wrote:

> this is so trivial there is no reason to change the source code.
>
> --
> http://www.flash.net/~djconnel/

  I don't believe it's any less trivial than wanting 4 demensional
vectors added to the source code. I have recently seen requests
for that too. Seems strange in light of the fact you can describe
any point in space with the current 3 demensional coordinate
system currently in use.

Ken Tyler

Post a reply to this message

Ken wrote:
> 
> Dan Connelly wrote:
> 
> > this is so trivial there is no reason to change the source code.
> >
> > --
> > http://www.flash.net/~djconnel/
> 
>   I don't believe it's any less trivial than wanting 4 demensional
> vectors added to the source code. I have recently seen requests
> for that too. Seems strange in light of the fact you can describe
> any point in space with the current 3 demensional coordinate
> system currently in use.

You can't apply built in vector ops to homebrew 4d vectors as it is. 
This means that you have to do it explicitly with (slow) macros.  With
4d position vectors, you can easily program things that use homogenous
coordinates (i.e. rational splines, making homebrew NURBS reasonably
easy).  The image map thing is just a matter of an extra line of pov
code, 4d (and more) vectors make whole new capabilities feasible.

Jerry Anning
cle### [at] dholcom

Post a reply to this message

Jerry Anning wrote:

> You can't apply built in vector ops to homebrew 4d vectors as it is.
> This means that you have to do it explicitly with (slow) macros.  With
> 4d position vectors, you can easily program things that use homogenous
> coordinates (i.e. rational splines, making homebrew NURBS reasonably
> easy).  The image map thing is just a matter of an extra line of pov
> code, 4d (and more) vectors make whole new capabilities feasible.
>
> Jerry Anning
> cle### [at] dholcom

  I will concede the point but not my desires.

Ken Tyler

Post a reply to this message

Dan Connelly <djc### [at] flashnet> wrote:
: And if you want to count characters, just do "translate -0.5" .

                                               "translate-.5"

-- 
                                                           - Warp. -

Post a reply to this message

Ken <tyl### [at] pacbellnet> wrote:
:   I don't believe it's any less trivial than wanting 4 demensional
: vectors added to the source code. I have recently seen requests
: for that too.

  It should be nice if povray supported ANY sized vectors.
  For example, this should be very nice:

poly
{ 7, Poly1*clock+Poly2*(1-clock)
}

  Where Poly1 and Poly2 are vectors with 120 components.
  This would make a very nice morphing between two poly objects.

-- 
                                                           - Warp. -

Post a reply to this message

On Sun, 15 Nov 1998 19:53:21 +0200, Margus Ramst 
	<mar### [at] peakeduee> wrote:
>Yeah, I also agree that centering image_maps would be logical, but it has never
>annoyed me, so I haven't complained. Getting height_hields to look right is a
>pain anyway, so the translate -.5 thingy kinda doesn't matter. Still, you have a
>point.

Consider what this will do to the people and applications who expect 
the current behavior, as well.  Also, the only object I am aware of that
appears centered on the origin is the torus.  Most objects are created 
where you say they should be, and it's only the various modelers that 
force them to be created at the origin.

>The other problem is much more important. I don't think it's very difficult (to
>somebody much wiser than me ;)). You shouldn't need any parametric mapping in
>many cases (like applying an image to only one side of a polygon or cylinder).
>This is how I imagine it: if the outside surface is hit by the sample ray,
>calculate the map color; if the inside is hit, don't calculate. This should be a
>sufficient solution in most cases (like the bottle label example).

This doesn't keep it from showing up on the outside surface opposite 
the one you thought it would be on.  One could predicate it on the 
normal of the surface at the point of intersection, however.

Post a reply to this message

On Sun, 15 Nov 1998 15:30:24 -0500, Nathan Kopp <Nat### [at] Koppcom> wrote:
>You could also get the SuperPatch from Twyst's patchstation, since it includes
>most of my surface-mapping code (I think it is currently lacking the code for
>lathe & sor).  If you don't need the lathe/sor stuff, you should probably get
>the superpatch since it has all sorts of other really cool features.  :-)

Right, not the lathe and sor patches.  Also missing is the cool new 
reset children warp.  I promise I'll get these into the next version.

>Just remember... these are unofficial versions of POV so don't expect any help
>from the POV Team.

Absolutely true.  If there's a problem with the superpatch, bug me.  If you 
use it and you love it, bug me.  If you just think it's a good idea, bug me.
If there's a patch I missed (except motion blur, PVM, POVMan, and most of 
the stuff in TMPOV with the possible exception of the julia texture) bug me.  
I don't get near enough mail about the superpatch.

Post a reply to this message

On Sun, 15 Nov 1998 06:10:38 -0800, Ken <tyl### [at] pacbellnet> wrote:
>Dan Connelly wrote:
>
>> I respectfully disagree.  The documentation is incredibly clear.
>> A simple "translate <-0.5, -0.5, -0.5>" centers things -- this is
>> so trivial there is no reason to change the source code.
>>
>> --
>> http://www.flash.net/~djconnel/
>
>I respectfully disagree with your respectful disagreement.
>Your simple example is 28 characters long. That's a lot
>of simple typing. Nor does it redily explain the ambiguity.

I respectfully disagree with your characterization of the
situation as an ambiguity, since it's consistent among things
that use images.  The real question is why image maps are on 
the x-y plane and height fields on the x-z plane.  I also 
respectfully disagree with your contention that it's 28 
characters... "translate -.5" is only 13.

Post a reply to this message

On Sun, 15 Nov 1998 23:33:33 -0500, Jerry Anning <cle### [at] dholcom> wrote:
>Ken wrote:
>> 
>> Dan Connelly wrote:
>> 
>> > this is so trivial there is no reason to change the source code.
>> >
>> > --
>> > http://www.flash.net/~djconnel/
>> 
>>   I don't believe it's any less trivial than wanting 4 demensional
>> vectors added to the source code. I have recently seen requests
>> for that too. Seems strange in light of the fact you can describe
>> any point in space with the current 3 demensional coordinate
>> system currently in use.
>
>You can't apply built in vector ops to homebrew 4d vectors as it is. 

BTW, what is the cross product of two 4d vectors? :)

Post a reply to this message

On 16 Nov 1998 11:58:41 -0500, Ron Parker <par### [at] my-dejanewscom> wrote:
>Consider what this will do to the people and applications who expect 
>the current behavior, as well.  Also, the only object I am aware of that
>appears centered on the origin is the torus.  Most objects are created 
>where you say they should be, and it's only the various modelers that 
>force them to be created at the origin.

Whoops, lathe and sor too.  What about TTFs that are created from the 
lower left corner?

Post a reply to this message

Ron Parker wrote:

> I don't get near enough mail about the superpatch.

  I have been waiting for you to finish the updated documentation
before downloading your superpatch version. Once this occurs
expect email :)

Ken Tyler

Post a reply to this message

Ron Parker wrote:
> Whoops, lathe and sor too.  What about TTFs that are created from the
> lower left corner?

... and superelipsoids, of course, which raises the question of why
superellipsoids are symmetric in x and y while almost everything else
is symmetric in x and z.

It's clear the only consistency in POV is there is no consistency.
It's like UNIX and basically every other piece-meal project.... the
inconsistency just adds to its attractive character.

> what's the cross-product of two 4-d vectors?

Good question!  I expect it would take 3 vectors to yield a cross
product :

y_i = a_j b_k c_l e_ijkl

(a, b, c are 4-vectors, e is a matrix)

where e_ijkl = 0 for and two elements of {i,j,k,l} equal,
+1, or -1 in other cases.

But cross products of 3-d vectors don't yield vectors, but pseudovectors,
as the result depends on handedness.  Either this or my physics background
is too faded for such details.

Dan
-- 
http://www.flash.net/~djconnel/

Post a reply to this message

On 16 Nov 1998 12:05:54 -0500, par### [at] my-dejanewscom (Ron Parker)
wrote:

>On Sun, 15 Nov 1998 06:10:38 -0800, Ken <tyl### [at] pacbellnet> wrote:
>>Dan Connelly wrote:
>>
>>> I respectfully disagree.  The documentation is incredibly clear.
>>> A simple "translate <-0.5, -0.5, -0.5>" centers things -- this is
>>> so trivial there is no reason to change the source code.
>>>
>>> --
>>> http://www.flash.net/~djconnel/
>>
>>I respectfully disagree with your respectful disagreement.
>>Your simple example is 28 characters long. That's a lot
>>of simple typing. Nor does it redily explain the ambiguity.
>
>I respectfully disagree with your characterization of the
>situation as an ambiguity, since it's consistent among things
>that use images.  The real question is why image maps are on 
>the x-y plane and height fields on the x-z plane.  I also 
>respectfully disagree with your contention that it's 28 
>characters... "translate -.5" is only 13.

I have also wondered why image ,maps and height fields were located on
two different planes. It always bothered me to add the extra code
required to place an image map over a height  field. It could have
been *so* much simpler, if they were both on the same plane.

My other pet peeve about image maps is not having an option to
automatically maintain the original aspect ratio of the image. It
would be cool to set the x or y dimension to "1" and let POV
automatically scale the other dimension to keep the aspect ratio
intact. Something like "constrain_x" or "constrain_y" added to the
image map statement would be one possible syntax.

Later,

Post a reply to this message

Ron Parker <par### [at] my-dejanewscom> wrote in article
<36505b72.0@news.povray.org>...
> ...  The real question is why image maps are on 
> the x-y plane and height fields on the x-z plane...
> 

'cause David Buck wrote planar image maps that way.  Slide projector
casting an image on a wall (since most of us thought of Y as up and put the
camera somewhere on the -Z axis).  Height fields are obviously on the
ground and stick up, so they are in the X/Z plane.  I never cared for the
fact that height fields were squashed into a 1x1x1 box, but since I didn't
do that code, I can't complain.  I wrote the TTF stuff, so I did it like I
wanted...

In general the objects are oriented they way they are because different
people wrote them at different times and had different ideas of how they
should go.

Xander

Post a reply to this message

Dan Connelly wrote:
> 
> Ron Parker wrote:
> > Whoops, lathe and sor too.  What about TTFs that are created from the
> > lower left corner?
> 
> ... and superelipsoids, of course, which raises the question of why
> superellipsoids are symmetric in x and y while almost everything else
> is symmetric in x and z.
> 
> It's clear the only consistency in POV is there is no consistency.
> It's like UNIX and basically every other piece-meal project.... the
> inconsistency just adds to its attractive character.
> 
> > what's the cross-product of two 4-d vectors?
> 
> Good question!  I expect it would take 3 vectors to yield a cross
> product :
> 
> y_i = a_j b_k c_l e_ijkl
> 
> (a, b, c are 4-vectors, e is a matrix)
> 
> where e_ijkl = 0 for and two elements of {i,j,k,l} equal,
> +1, or -1 in other cases.
> 
> But cross products of 3-d vectors don't yield vectors, but pseudovectors,
> as the result depends on handedness.  Either this or my physics background
> is too faded for such details.

The cross product of two 3d vectors certainly does yield another vector.
If it didn't, half of my code wouldn't work!

Regards,
John

Post a reply to this message

John VanSickle wrote:

> The cross product of two 3d vectors certainly does yield another vector.
> If it didn't, half of my code wouldn't work!

I said "pseudovector".  A velocity vector, for example, is a real
thing.  If I have a right-hand or left-hand coordinate system
doesn't matter.  But if I take the cross product of two sides
of a cube side in a fashion which yields a normal pointing
outside the box in a LHS, when I switch to a RHS the same
cross product will yield a normal pointing inside the box.
Since it is non-physical for a quantity to depend on the
coordinate system used, the term "pseudovector" is used.

The same thing happens with angular momentum, which is a 
pseudovector (it's defined as a cross-product).  It is
fundamentally different from linear momentum.

In Physics, this is important when considering conserved
quantities like parity.

Dan

-- 
http://www.flash.net/~djconnel/

Post a reply to this message

Dan Connelly <djc### [at] flashnet> writes:

> I said "pseudovector".  A velocity vector, for example, is a real
> thing.  If I have a right-hand or left-hand coordinate system
> doesn't matter.  But if I take the cross product of two sides
> of a cube side in a fashion which yields a normal pointing
> outside the box in a LHS, when I switch to a RHS the same
> cross product will yield a normal pointing inside the box.

  Yes, sure.  The whole point is:

POV-Ray uses a right-handed coordinate system whatever your camera

, period.  I know this is going to make the whole crowd hurling mad and
becoming epileptic and throwing rotten tomatoes at me, but that's the way
it is.  The coordinate system has *nothing* to do with the way you display
it.  The cross-product of <x1, y1, z1> by <x2, y2, z2> is <y1*z2-z1*y2,
z1*x2-x1*z2, x1*y2-y1*x2>, whatever your camera is.  The confusing thing is
that the POV-Doc says that you can change the coordinate system handedness
by giving different combinations of up, right and direction vectors, which
is not true.  I repeat, POV-Ray uses a right-handed coordinate system
whatever your camera.  You can only change the way the camera looks at the
scene, in which you can choose to look at it as it is (that is, choose a
right-handed *camera*) of to flip it left-right (or upside-down, or
front-back, depending on the camera component you change into minus
itself).  This is a rendering-only characteristic and has nothing to do
with the real handedness of the coordinate system, which stays the real
right-handed system used by every mathematician in the world (or at least,
every mathematician I have heard of).

> In Physics, this is important when considering conserved
> quantities like parity.

  I won't deny it.  In fact, I keep saying it: we are in a right-handed
coordinate system, so the Physics theorems and laws are safe.  Now, you
just have to take care when you look at your scene...

  Okay, throw the tomatoes.  I won't read here till next Tuesday, so please
don't waste your ammunition till then, or till you're *really* sure I'm
wrong, in which case we will probably have an interesting discussion next
week >:-)

Roland.
-- 
Les francophones m'appellent Roland Mas,
English speakers call me Rowlannd' Mass,
Nihongode hanasu hitoha [Lolando Masu] to iimasu.
Choisissez ! Take your pick ! Erande kudasai !

Post a reply to this message

I could have sworn the Pov-Ray docs explicitly state that
the left handed system is used by default contrary to what
the rest of the world uses. I'm may be getting old buy my
memory isn't that bad.

Ken Tyler

Roland Mas wrote:

> Dan Connelly <djc### [at] flashnet> writes:
>
> > I said "pseudovector".  A velocity vector, for example, is a real
> > thing.  If I have a right-hand or left-hand coordinate system
> > doesn't matter.  But if I take the cross product of two sides
> > of a cube side in a fashion which yields a normal pointing
> > outside the box in a LHS, when I switch to a RHS the same
> > cross product will yield a normal pointing inside the box.
>
>   Yes, sure.  The whole point is:
>
> POV-Ray uses a right-handed coordinate system whatever your camera
>
> , period.  I know this is going to make the whole crowd hurling mad and
> becoming epileptic and throwing rotten tomatoes at me, but that's the way
> it is.  The coordinate system has *nothing* to do with the way you display
> it.  The cross-product of <x1, y1, z1> by <x2, y2, z2> is <y1*z2-z1*y2,
> z1*x2-x1*z2, x1*y2-y1*x2>, whatever your camera is.  The confusing thing is
> that the POV-Doc says that you can change the coordinate system handedness
> by giving different combinations of up, right and direction vectors, which
> is not true.  I repeat, POV-Ray uses a right-handed coordinate system
> whatever your camera.  You can only change the way the camera looks at the
> scene, in which you can choose to look at it as it is (that is, choose a
> right-handed *camera*) of to flip it left-right (or upside-down, or
> front-back, depending on the camera component you change into minus
> itself).  This is a rendering-only characteristic and has nothing to do
> with the real handedness of the coordinate system, which stays the real
> right-handed system used by every mathematician in the world (or at least,
> every mathematician I have heard of).
>
> > In Physics, this is important when considering conserved
> > quantities like parity.
>
>   I won't deny it.  In fact, I keep saying it: we are in a right-handed
> coordinate system, so the Physics theorems and laws are safe.  Now, you
> just have to take care when you look at your scene...
>
>   Okay, throw the tomatoes.  I won't read here till next Tuesday, so please
> don't waste your ammunition till then, or till you're *really* sure I'm
> wrong, in which case we will probably have an interesting discussion next
> week >:-)
>
> Roland.
> --
> Les francophones m'appellent Roland Mas,
> English speakers call me Rowlannd' Mass,
> Nihongode hanasu hitoha [Lolando Masu] to iimasu.
> Choisissez ! Take your pick ! Erande kudasai !

Post a reply to this message

Ken <tyl### [at] pacbellnet> writes:

> I could have sworn the Pov-Ray docs explicitly state that
> the left handed system is used by default contrary to what
> the rest of the world uses. I'm may be getting old buy my
> memory isn't that bad.



                                          Section 4.1.1
                           Understanding POV-Ray's Coordinate System

First, we have to tell POV-Ray where our camera is and where it is
looking. To do this, we use 3D coordinates. The usual coordinate system for
POV-Ray has the positive y-axis pointing up, the positive x-axis pointing
to the right, and the positive z-axis pointing into the screen as follows:

[Here is a picture of a left-handedly *displayed* coordinate system]

Section 7.4.4.5.2
                                          Handedness

The right vector also describes the direction to the right of the
camera. It tells POV-Ray where the right side of your screen is. The sign
of the right vector can be used to determine the handedness of the
coordinate system in use. The default right statement is:

  right <1.33, 0, 0>

[So the handedness described here is only the one of the camera, as stated
above.]

  I confirm my position.  The handedness of a coordinate system is given by
the way it calculates cross-products, not by the way it looks because it
has no canonical way to look.  A coordinate system is abstract, and if you
want to make it look like something you have to choose a camera
orientation.  This does not change the handedness of the space.  And
POV-Ray uses a right-handed cross-product.  The default *camera* is
left-handed, that's all.

  Other suggestions?

Roland.
-- 
Les francophones m'appellent Roland Mas,
English speakers call me Rowlannd' Mass,
Nihongode hanasu hitoha [Lolando Masu] to iimasu.
Choisissez ! Take your pick ! Erande kudasai !

Post a reply to this message

Roland Mas <mas### [at] acratrcojp> wrote in article
<m3s### [at] rpc66acratrcojp>...

>   I confirm my position.  The handedness of a coordinate system is given
by
> the way it calculates cross-products, not by the way it looks because it
> has no canonical way to look...
> 
>   Other suggestions?

The basic coordinate system used by POV-Ray (and many other renderers,
contrary to an earlier assertion that POV-Ray was somehow unique) is
definitely left-handed.  Also, inverting one of the coordinate axes of the
camera does transform the world from right to left handed.  The only
coordinate system of interest is that of the observer, which is defined by
the camera.

The rational for a left-handed coordinate system in computer graphics is
pretty easy to understand.  Given a camera sitting at <0,0,0> and looking
along the positive Z axis, larger Z values correspond to larger depth
values.  So, when removing hidden surfaces, I simply keep the one with the
smallest Z value.  For non-raytracers, the camera is almost always
transformed into this canonical orientation before rendering.

Why would a left-handed cross product look like a right-handed one?  Easy -
right thumb along one positive axis, fingers along a second positive one. 
Fingers curl in the direction of the third (in the positive direction). 
Look into a mirror as you do this.  It still works, but now it's a left
hand doing the pointing and curling.  It's an excellent example of parity,
since someone in a mirror universe would describe their mathematics in
exactly the same terms as you.

The biggest problems with left vs. right have to do with importing models. 
If a different coordinate system was used, the model could be mirrored,
rotated, or both. 

Xander

Post a reply to this message