Why do I get this message when I use a perspective camera with a matrix 
transformation ,e.g.:

camera {
         perspective
         right x * 4.0
         up y * 3.0
         matrix <0.9358968469314277, 1.862645149230957E-9, 
-0.3522741496562958, 0.05264317989349365, 0.988771082367748, 
0.1398586481809616, 0.348318487405777, -0.14943809807300568, 
0.9253877382725477, -68.93845592397729, 101.72871539795597, 
-174.07854648367464>
         angle 38.58009
}

?

The matrix just contains a rotation and a translation, so the vectors 
are perpendicular and the warning message is obviously wrong.

Is there any workaround other than turning off vista buffers?

Thanks
-sascha

Post a reply to this message

Sascha Ledinsky <sas### [at] userssourceforgenet> wrote:
> The matrix just contains a rotation and a translation, so the vectors 
> are perpendicular and the warning message is obviously wrong.

  But the values in the matrix may not be accurate enough.

  How about just using the rotations and translations directly?

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

>   But the values in the matrix may not be accurate enough.

That's double precision (64bit)... How accurate does POV need them?

>   How about just using the rotations and translations directly?

My program represents the camera orientation as quaternion - it coverts 
it to matrix representaion before exporting it. If there already is a 
matrix representation, POV should be able to use it :-/

Do you know how to convert orientations represented as quaternions or 
axis-angle pairs into fixed-angle representations (for use in POV's 
rotate <x,y,z> command)?

Thanks
-sascha

Post a reply to this message

In article <422db829$1@news.povray.org>,
 Sascha Ledinsky <sas### [at] userssourceforgenet> wrote:

> >   But the values in the matrix may not be accurate enough.
> 
> That's double precision (64bit)... How accurate does POV need them?

No, that's decimal ASCII text. Those are *not* the exact values your 
program computed. And the problem may still be in your computations, 
simply using double precision is no guarantee that your numbers are 
correct. Rounding error can easily accumulate and result in a 
non-orthogonal final matrix.


> Do you know how to convert orientations represented as quaternions or 
> axis-angle pairs into fixed-angle representations (for use in POV's 
> rotate <x,y,z> command)?

<http://www.mathworks.com/access/helpdesk/help/toolbox/aeroblks/quaternio
nstoeulerangles.html>

You could also compute the camera basis vectors and tweak them to be 
perpendicular inside POV. For example, find the inaccurate right and 
direction vectors, use them to compute the correct up vector, then use 
the direction and corrected up vectors to compute a working right vector.

-- 
Christopher James Huff <cja### [at] gmailcom>
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

Christopher James Huff wrote:
> In article <422db829$1@news.povray.org>,
>  Sascha Ledinsky <sas### [at] userssourceforgenet> wrote:
> 
> 
>>>  But the values in the matrix may not be accurate enough.
>>
>>That's double precision (64bit)... How accurate does POV need them?
> 
> 
> No, that's decimal ASCII text. Those are *not* the exact values your 
> program computed.

Yes, sure, I know that representing (binary) floats as decimal is always 
problematic, but I think that's about as accurate as possible...
I don't think that POV likes hexadecimal IEEE754 representations?

> Rounding error can easily accumulate and result in a 
> non-orthogonal final matrix.

I've used the vecmath package from Java3D - All I do is creating a 4x4 
matrix from a unit-quaternion... From looking at the images it renders 
(with -UV) everything looks right.
Could it be that the test for perpendicular vectors in POV-Ray is a bit 
too pedantic?

>>Do you know how to convert orientations represented as quaternions or 
>>axis-angle pairs into fixed-angle representations (for use in POV's 
>>rotate <x,y,z> command)?
> 
> 
> <http://www.mathworks.com/access/helpdesk/help/toolbox/aeroblks/quaternio
> nstoeulerangles.html>

Thanks a lot for that link, I'll try that...

-sascha

Post a reply to this message

Sascha Ledinsky <sas### [at] userssourceforgenet> wrote:
> My program represents the camera orientation as quaternion - it coverts 
> it to matrix representaion before exporting it. If there already is a 
> matrix representation, POV should be able to use it :-/

  You could just apply the transformations to the location and
look_at vectors of the camera and write just those.

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

In article <422e2195@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   You could just apply the transformations to the location and
> look_at vectors of the camera and write just those.

Not if you need the camera to roll. If you don't, though, that'd be the 
easiest way to do it. And with a little more work, you could figure the 
appropriate amount to roll the camera.

-- 
Christopher James Huff <cja### [at] gmailcom>
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

Christopher James Huff <cja### [at] gmailcom> wrote:
> Not if you need the camera to roll. If you don't, though, that'd be the 
> easiest way to do it. And with a little more work, you could figure the 
> appropriate amount to roll the camera.

  If you multiply the location, look_at and sky vectors with the
transformation matrix (with the sky vector translation should not
be performed) it should give the same result as if a direct matrix
transformation was added to the camera block.

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

Sascha Ledinsky <sas### [at] userssourceforgenet> wrote:
> Why do I get this message when I use a perspective camera with a matrix
> transformation ,e.g.:
>
> camera {
>          perspective
>          right x * 4.0
>          up y * 3.0
>          matrix <0.9358968469314277, 1.862645149230957E-9,
> -0.3522741496562958, 0.05264317989349365, 0.988771082367748,
> 0.1398586481809616, 0.348318487405777, -0.14943809807300568,
> 0.9253877382725477, -68.93845592397729, 101.72871539795597,
> -174.07854648367464>
>          angle 38.58009
> }
>
> ?
>
> The matrix just contains a rotation and a translation, so the vectors
> are perpendicular and the warning message is obviously wrong.

Are you sure about this Sascha ?

I.e. have you verified that this really is a rotation matrix ?

IIRC rotation matrices should be orthogonal (A^T*A = I or A^T = A^-1).
Thus their row (or column) vectors should form an orthonormal set of
vectors.

The row vectors in your matrix do not seem to satisfy that demand.
(See the output from the test script below.)

For me it seems that your matrix has been generated by using single
precision math.


Tor Olav


// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7
// Test for orthogonal matrix. (I.e. M^T*M = I or M^T = M^-1)

#version 3.6;

#declare Decimals = 17;

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7
// The matrix elements

#declare M11 = 0.93589684693142770;
#declare M12 = 1.862645149230957E-9;
#declare M13 = -0.3522741496562958;
#declare M21 = 0.05264317989349365;
#declare M22 = 0.988771082367748;
#declare M23 = 0.1398586481809616;
#declare M31 = 0.34831848740577700;
#declare M32 = -0.14943809807300568;
#declare M33 = 0.9253877382725477;
#declare M41 = -68.93845592397729;
#declare M42 = 101.72871539795597;
#declare M43 = -174.07854648367464;

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7
// Test camera transformation.  (Check output for warnings)

camera {
  perspective
  right 4*x
  up 3*y
  matrix <
    M11, M12, M13,
    M21, M22, M23,
    M31, M32, M33,
    M41, M42, M43
  >
}

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7
// Define row vectors and check if matrix is orthogonal.
// (Vector lengths should be 1 and dot products should be 0.)

#declare vR1 = <M11, M12, M13>;
#declare vR2 = <M21, M22, M23>;
#declare vR3 = <M31, M32, M33>;

#debug "nn"
#debug concat("nvR1: <", vstr(3, vR1, ", ", 0, Decimals), ">")
#debug concat("nvR2: <", vstr(3, vR2, ", ", 0, Decimals), ">")
#debug concat("nvR3: <", vstr(3, vR3, ", ", 0, Decimals), ">")
#debug "n"
#debug concat("nvlength(vR1): ", str(vlength(vR1), 0, Decimals))
#debug concat("nvlength(vR2): ", str(vlength(vR2), 0, Decimals))
#debug concat("nvlength(vR3): ", str(vlength(vR3), 0, Decimals))
#debug "n"
#debug concat("nvdot(vR1, vR2): ", str(vdot(vR1, vR2), 0, Decimals))
#debug concat("nvdot(vR2, vR3): ", str(vdot(vR2, vR3), 0, Decimals))
#debug concat("nvdot(vR3, vR1): ", str(vdot(vR3, vR1), 0, Decimals))

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7
// Make new set of normalized and perpendicular row vectors
// and check if matrix is orthogonal now.

#declare vN1 = vnormalize(vR1);
#declare vN2 = vnormalize(vcross(vN1, vR2));
#declare vN3 = vcross(vN2, vN1);

#debug "nn"
#debug concat("nvN1: <", vstr(3, vN1, ", ", 0, Decimals), ">")
#debug concat("nvN2: <", vstr(3, vN2, ", ", 0, Decimals), ">")
#debug concat("nvN3: <", vstr(3, vN3, ", ", 0, Decimals), ">")
#debug "n"
#debug concat("nvlength(vN1): ", str(vlength(vN1), 0, Decimals))
#debug concat("nvlength(vN2): ", str(vlength(vN2), 0, Decimals))
#debug concat("nvlength(vN3): ", str(vlength(vN3), 0, Decimals))
#debug "n"
#debug concat("nvdot(vN1, vN2): ", str(vdot(vN1, vN2), 0, Decimals))
#debug concat("nvdot(vN2, vN3): ", str(vdot(vN2, vN3), 0, Decimals))
#debug concat("nvdot(vN3, vN1): ", str(vdot(vN3, vN1), 0, Decimals))

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7
// Test camera with new transformation. (Check output for warnings)

#debug "nnnn"

#declare M11 = vN1.x;
#declare M12 = vN1.y;
#declare M13 = vN1.z;
#declare M21 = vN2.x;
#declare M22 = vN2.y;
#declare M23 = vN2.z;
#declare M31 = vN3.x;
#declare M32 = vN3.y;
#declare M33 = vN3.z;

camera {
  perspective
  right 4*x
  up 3*y
  matrix <
    M11, M12, M13,
    M21, M22, M23,
    M31, M32, M33,
    M41, M42, M43
  >
}

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7


Here is the output from POV-Ray 3.6.1 (g++ 3.4.1 @ i686-pc-linux-gnu):

vR1: <0.93589684693142772, 0.00000000186264515, -0.35227414965629578>
vR2: <0.05264317989349365, 0.98877108236774802, 0.13985864818096161>
vR3: <0.34831848740577698, -0.14943809807300568, 0.92538773827254772>

vlength(vR1): 0.99999999230612724
vlength(vR2): 0.99999999959349639
vlength(vR3): 0.99999998998475348

vdot(vR1, vR2): 0.00000000155646701
vdot(vR2, vR3): 0.00000000093214445
vdot(vR3, vR1): -0.00000000478968380


vN1: <0.93589685413209900, 0.00000000186264516, -0.35227415236664827>
vN2: <0.34831849532785164, -0.14943810049134260, 0.92538774572288385>
vN3: <0.05264317845820071, 0.98877108276968706, 0.13985864878611778>

vlength(vN1): 1.00000000000000000
vlength(vN2): 1.00000000000000000
vlength(vN3): 1.00000000000000000

vdot(vN1, vN2): 0.00000000000000006
vdot(vN2, vN3): 0.00000000000000000
vdot(vN3, vN1): -0.00000000000000000

Post a reply to this message

Warp wrote:
> Christopher James Huff <cja### [at] gmailcom> wrote:
> 
>>Not if you need the camera to roll. If you don't, though, that'd be the 
>>easiest way to do it. And with a little more work, you could figure the 
>>appropriate amount to roll the camera.
> 
> 
>   If you multiply the location, look_at and sky vectors with the
> transformation matrix (with the sky vector translation should not
> be performed) it should give the same result as if a direct matrix
> transformation was added to the camera block.
> 
That should work, but I suspect it will lead to the same result if the 
matrix is somehow not accurate enough...

Post a reply to this message