setProjectionMatrix problem in Irrlicht 1.2

[QuantumLeap]

I used to do orthographic projections with the official Irrlicht 1.1 with no problem at all. The basic, as in Saigumi's tutorial:

Code: Select all

irr::core::matrix4 OrthoMatrix;
OrthoMatrix.buildProjectionMatrixOrthoLH(320.0f,240.0f,300.0f,-300.0f);
camera = smgr->addCameraSceneNode(Center,irr::core::vector3df(-14.0f,14.0f,-14.0f),irr::core::vector3df(0,0,0));
camera->setProjectionMatrix(OrthoMatrix);

This never gave me problems, and if the camera is a FPS I could even rotate the matrix around with the mouse, which was a really cool feature for my project. The meshes would never be cut, only selectively rendered according to their relative position inside or outside the matrix.
Now, with the SVN version of Irrlicht, and the new 1.2, the behavior is quite different. Some polygons in the meshes are simply not rendered at all, the models appear "cut" and some are not even rendered at all. I know there were a few changes in the implementation of matrix4 recently and I wonder if that's what's causing the problem? And how to solve it?

[vitek]

Are you sure it is a problem with matrices. It could be a problem with the mesh loader or even the renderer. Have you tried loading your mesh in the MeshViewer example program?

Travis

[QuantumLeap]

Vitek,

I'm not sure it's a problem with the matrices, could be the renderer indeed,but it's not the mesh loader for sure.

I know it because in my application the camera can either be a perspective camera or an orthogonal camera. When I'm in perspective mode, the meshes are displayed perfectly.

Did anyone else exerience similar problems?

[msz006]

QuantumLeap,

I updated the engine today and also experienced same problem.

To fix it, change the order of arguments on below line:

Code: Select all

OrthoMatrix.buildProjectionMatrixOrthoLH(320.0f,240.0f,300.0f,-300.0f);

like this:

Code: Select all

OrthoMatrix.buildProjectionMatrixOrthoLH(320.0f,240.0f,-300.0f,300.0f);

It solved the problem, but I don't know the reason exactly.(I just guessed from the screen status)

Let me know if any of you know the reason.

[QuantumLeap]

msz, it worked!!! Wow, so simple!
It seems like the argument order for the definition of the matrices has changed. Many thanks!

[vitek]

Why would you attempt to set zNear or zFar to a negative number? zNear should always be less than zFar, and it is usually a positive number near zero.

Travis

[QuantumLeap]

Why would you attempt to set zNear or zFar to a negative number?

Because this way when you move the mouse (change the camera angle) the slice of the scene rendered comprises a dept between zNear and zFar with a neat effect! If I put a positive value for zNear the meshes are chopped. Try by yourself and see. This may be an unintended side effect, but produces exactly the result I need.