We closed this forum 18 June 2010. It has served us well since 2005 as the ALPHA forum did before it from 2002 to 2005. New discussions are ongoing at the new URL http://forum.processing.org. You'll need to sign up and get a new user account. We're sorry about that inconvenience, but we think it's better in the long run. The content on this forum will remain online.
IndexProgramming Questions & HelpSyntax Questions › matrix bug since v125
Pages: 1 2 
matrix bug since v125 (Read 1800 times)
matrix bug since v125
Jul 19th, 2007, 7:49pm
 
hello,
i was using the g.mXY variables to make backface culling (dot product with the polygon's normal vector), but since the upgrade it seems that method became much less accurate.

I tried to use loadmatrix() before accessing the values but this doesnt change anything. I also tried with g.camera.mXY, g.ModelView.mXY but still the same problem....

any idea what i am doing wrong?
Re: matrix bug since v125
Reply #1 - Jul 20th, 2007, 11:42am
 
if you have your camera vector and the polygon's normal in the same space why not just use them ?
if u using opengl, let him do it for itself..
Re: matrix bug since v125
Reply #2 - Jul 20th, 2007, 2:04pm
 
First I was using the direction vector in Damkjer's camera code, but it seems somehow desynchronized with the underlying matrix.

Sounds to me the best thing is to take those values at their source, which is the transformation matrix.

So i switched to this g.mXY thing, and it worked perfectly until the update...

And im not using opengl.
Re: matrix bug since v125
Reply #3 - Jul 20th, 2007, 4:10pm
 
i dont know that code, but it should be the same way..
compute the direction vector yourself.. make sure you're doing the dot product of the 2 vectors in the same space..
check what changes did he do to his code..
Re: matrix bug since v125
Reply #4 - Jul 20th, 2007, 4:24pm
 
ok forget about his code, that's barely the point ^^
he didnt change anything to it anyway, its since processing 125 that things dont work the same.

the question is: where is the matrix stored?
in processing 124 it was accessible through g.m01 g.m11 etc etc
now where can i get those values? thats all i need to know

i could make a printmatrix() and parse the text but that's far too inefficient.

if there's no way to get the values now, then can i dl version 124 somewhere?
Re: matrix bug since v125
Reply #5 - Jul 20th, 2007, 5:02pm
 
float time = millis() * 0.001;
rotate( time );
loadMatrix();
println( g.m01 );

i never used any g. stuff, thought that was his code.
for what i have just tried you need to loadMatrix() it gives you the values of the current matrix.

that does not work ?
Re: matrix bug since v125
Reply #6 - Jul 20th, 2007, 5:20pm
 
ok that's my code:

 // Draw triangles, using normals from the OBJ file
 public void DrawPolygonsN() {
   pushMatrix();
   translate(X,Y,Z);  
   //loadMatrix();
   //Vertex cdir = new Vertex(g.m20, g.m21, g.m22);
   int currentS = 0;
   if(shapes[currentS].material != null) shapes[currentS].material.Activate();  
   for (int i = 0; i < faceCount; i++) {
     if(i > shapes[currentS].faceCount) shapes[++currentS].material.Activate();
     //if (cdir.Dot(faces[i].Normal) >= 0)
     faces[i].Render(this);
   }
   popMatrix();  
 }  

the culling stuff is commented, since cdir is now (0,0,0) all the time.

camera code im using is (damkjer's):
public void feed() {
parent.perspective(fov, aspect, nearClip, farClip);
parent.camera(cameraX, cameraY, cameraZ,
              targetX, targetY, targetZ,
              upX,     upY,     upZ);
}

This code is fed before each draw.
Now (target - position) should give me the direction vector that i need. Except the result is very inaccurate.
That's why i'd rather use some inner matrix values, rather than try to figure out what goes wrong.

What's a bit annoying is that, the patch was supposed to improve this
"- loadMatrix() now handles getting good matrix values into g.m00, g.m01 etc across all renderers"
But its just the opposite that happens (i didnt even need loadmatrix() before the patch, now whether i use it or not i get a {0,0,0} vector in g).
Re: matrix bug since v125
Reply #7 - Jul 20th, 2007, 6:11pm
 
im not sure you are getting the correct vector from the inner matrix.. if you're not using opengl, you're using p3d, and i assume it works the same way. column based matrices..

fix your camera position and debug the matrix..

 println( g.m00 + ", " + g.m10 + ", " + g.m20 + ", " + g.m30 );
 println( g.m01 + ", " + g.m11 + ", " + g.m21 + ", " + g.m31 );
 println( g.m02 + ", " + g.m12 + ", " + g.m22 + ", " + g.m32 );
 println( g.m03 + ", " + g.m13 + ", " + g.m23 + ", " + g.m33 );


one other thing, for backface culling what vectors do you test with?

for basic backface culling just use a vector from your camera position to a point in the plane (a triangle vertex) and the face's normal. if the angle is greater than 90º it should be ignored..

short pseudo code:
Vector cdir( cam - shape.vertex0 );
if( cdir.dot(shape.normal) >= 0 )
   shape.render();
Re: matrix bug since v125
Reply #8 - Jul 20th, 2007, 6:13pm
 
also make sure you're normal and shape->cam vector is in the same coordinate space.

Question: p3d does not handle backface culling himself ?
Re: matrix bug since v125
Reply #9 - Jul 20th, 2007, 6:43pm
 
P3d doesnt do the culling itself, or i couldnt find the command to activate it.

And you're right, i should have been using m10 m11 m12. I just modified the code to debug and forgot to put it back.
I also printed the whole matrix but its all zeroes. I don't think this place is used anymore. Which is a shame because for me it is quite important to have access to those values.

Truth is backface is just the tip of the iceberg... if i cant make this basic computation accurately, i'm going to have a hard time doing more advanced things =S

I guess i will go back to version 124 and hope this will be fixed in the future.
Re: matrix bug since v125
Reply #10 - Jul 20th, 2007, 6:50pm
 
"for basic backface culling just use a vector from your camera position to a point in the plane (a triangle vertex) and the face's normal. if the angle is greater than 90º it should be ignored.."

This is what i do. I'm quite sure about the code because  i done this many times in the past and also because it used to work perfectly before the patch.. the problem is just to find where the matrix values are gone. Sad
Re: matrix bug since v125
Reply #11 - Jul 20th, 2007, 6:57pm
 
simsam wrote on Jul 20th, 2007, 5:20pm:
Now (target - position) should give me the direction vector that i need. Except the result is very inaccurate.
That's why i'd rather use some inner matrix values, rather than try to figure out what goes wrong.


If by target you mean the targetX/Y/Z in your camera funcion, then that's the wrong vector, and the reason the results are bad. Taht vector is the direction of the camera, not the vector from camera to poly.

What you want is vertexOfPoly - camPosition for the vector, and dot that with the polygon normal.
Re: matrix bug since v125
Reply #12 - Jul 20th, 2007, 7:08pm
 
exactly as john said.
Re: matrix bug since v125
Reply #13 - Jul 21st, 2007, 12:25am
 
nah backface doesnt depend on the relative position of the polygon just its orientation and the camera's orientation

you got your view vector and the polygon's vector and thats all you need

whether the polygon is behind you or in front of you isnt the problem, but which direction it is facing relatively to you

http://en.wikipedia.org/wiki/Back-face_culling

"to test if the polygon is visible or not. If this test is true, the normal vector of the polygon is pointed away from the camera"
Re: matrix bug since v125
Reply #14 - Jul 21st, 2007, 12:26am
 
to make it short:
PLEASE TELL ME WHERE I CAN GET THE MATRIX

ill manage for the rest :p
Pages: 1 2