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

Thank you!

To be honest, I did not know how to quickly check if the matrix is 
correct, and since the resulting images looked right... :-/

I have found the problem: The quaternion used to compute the matrix uses 
single precision floats. The fix was to first create a double-precision 
quaternion from it, then re-normalize that and feed the double-precision 
quaternion into the matrix...

Thanks again!

But still, isn't the test POV performs too strict?
I understand that POV-Ray must use double precision math for most 
operations, but would, in this case, the single-precision matrix really 
break the vista buffer?
This will enforce all external applications that are used to create 
POV-scenes to use double-precision math throughout, and I don't know if 
it is available in all (script) languages...

Post a reply to this message

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

> That should work, but I suspect it will lead to the same result if the 
> matrix is somehow not accurate enough...

No. Since the camera vectors are calculated by POV in this case, they 
will be perpendicular.

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

Post a reply to this message

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

> But still, isn't the test POV performs too strict?

No. The test does not cause any problems that can't be fixed by using 
correct input. This is a very simple, minor problem which occurs very 
rarely and has a simple fix and several possible workarounds.

-- 
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 <422eb8bb$1@news.povray.org>,
>  Sascha Ledinsky <sas### [at] userssourceforgenet> wrote:
> 
> 
>>That should work, but I suspect it will lead to the same result if the 
>>matrix is somehow not accurate enough...
> 
> 
> No. Since the camera vectors are calculated by POV in this case, they 
> will be perpendicular.
> 

I've found the problem and it does work now with the matrix keyword as well.
I should have checked my code earlier. Again, sorry!

-sascha

Post a reply to this message

Sascha Ledinsky <sas### [at] userssourceforgenet> wrote:
> Thank you!
>
> To be honest, I did not know how to quickly check if the matrix is
> correct, and since the resulting images looked right... :-/
>
> I have found the problem: The quaternion used to compute the matrix uses
> single precision floats. The fix was to first create a double-precision
> quaternion from it, then re-normalize that and feed the double-precision
> quaternion into the matrix...

Ok, so it was the Java3D package that used single precision floats ?

Btw.: I hope that you spotted my error in this part of my code:

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


It should be:

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


Btw.: I also recommend that you google for the "Gram-Schmidt process".


> Thanks again!

I'm glad that I could be of any help to you.


> But still, isn't the test POV performs too strict?
> I understand that POV-Ray must use double precision math for most
> operations, but would, in this case, the single-precision matrix really
> break the vista buffer?
> This will enforce all external applications that are used to create
> POV-scenes to use double-precision math throughout, and I don't know if
> it is available in all (script) languages...

I don't have any strong opinions regarding this. (And I don't really know if
such a matrix could cause any problems with the vista buffer.)

You may have a point, but if I had this problem myself, I would just
"correct" the matrix "manually" with a few lines of POV-script.

--
Tor Olav
http://subcube.com

Post a reply to this message

> Ok, so it was the Java3D package that used single precision floats ?

Sort of... I don't know if it can be considered as a bug: The double 
precision 4x4 matrix class (Matrix4d) has a setRotationScale() method 
that takes a Quaternion as argument - either float (Quat4f) or double 
(Quat4d). The thing is, if you use a float quaternion on the double 
matrix, it seems that it does not re-normalize the quaternion after 
conversion to doubles.
Now I do

public void setOrientation(Quat4f orient_float) {
	Quat4d orient_double = new Quat4d(orient_float);
	orient_double.normalize();
	matrix.setRotation(orient_double);
}

which fixes the problem...

I'm not sure if Sun's official J3D package has the same problems - I'm 
using it in an open source project and so I'm forced to use an 
"inofficial" javax.vecmath package :-(

POV-Ray is happy with the new truly double-precision matrix, so I'm 
happy too :-)

Thanks again,
-Sascha

Post a reply to this message