5 replies to this topic

[mg_mchenry]

My matrices are all muddy and I wonder if anyone has a favorite resource for a reference on this.

I have a coordinate system where +x is to the right, +y goes into the screen, and +z is up. But it doesn't always quite work out.

I tried baking my camera matrix into my perspective matrix. Is that a mistake? Should people avoid that?
My camera has x rotation, z rotation, and a location. To get my camera matrix, I start from an identity matrix, do the rotations, then translate by the camera location.

Then I have an ortho perspective matrix. I multiply the perspective matrix by the camera matrix and pass that into the shader. Should I keep it separate?

Well, it's all mixed up. Moving the camera +z has the opposite of expected result. y also seems to be flipped when moving the camera. Yet, objects appear on screen as expected. Translating objects on the screen acts as expected.

I think the camera translations need to be inversed?

The model view matrix works exactly as expected. As does the perspective matrix.

[EDIT]
OK, OK! Before anyone attacks, I see that the camera does not go into the perspective matrix. I took it out and tacked it onto the model view matrix. Makes sense.
http://www.opengl.org/archives/resources/faq/technical/viewing.htm

It's still not doing the right thing, but I'll work it out.

Edited by mg_mchenry, 31 August 2012 - 12:29 PM.

[marek-knows.com]

Have a look at video #8 on my website, it should clear some things up: http://www.marek-knows.com/downloads.php5?vmk=gameEng8

[mg_mchenry]

So one thing I'm wondering is why it isn't common to have three matrices in the shader - one for model-to-wold space, one for world-to-camera space (is that the same as eye space?), and the projection matrix.

In my case, I'm working in javascript. Every object has an mv matrix that still has to be multiplied with the camera matrix before being passed to the shader. There has to be a break even point where it is faster to do that in the shader than in the javascript and I'm just wondering why it isn't normal to do it that way, even for native code.

[BornToCode]

Yes eye space is camera space. You can always break the View Matrix out of the Model. That way when you past the matrices to your shader you can pass three matrices instead of two. If you have a camera class for example, that will be your view matrix. Each Object will have his own wolrd matrix. Then in the shader you can just do Projection*View*World

Edited by BornToCode, 06 September 2012 - 12:30 PM.

[Radikalizm]

So one thing I'm wondering is why it isn't common to have three matrices in the shader - one for model-to-wold space, one for world-to-camera space (is that the same as eye space?), and the projection matrix.

In my case, I'm working in javascript. Every object has an mv matrix that still has to be multiplied with the camera matrix before being passed to the shader. There has to be a break even point where it is faster to do that in the shader than in the javascript and I'm just wondering why it isn't normal to do it that way, even for native code.

When you create the WVP matrix on the CPU you'll only have to go through this process once for every mesh. However, when doing this in a shader it'll have to be done for every vertex. For simple meshes the GPU will probably still outperform the CPU as it can do matrix multiplications really fast, but for more complex meshes this could not be the case anymore. You could also take the cost for uploading 3 matrices vs 1 matrix to the GPU into account, but this won't be that much of an issue tbh.

I have to say though that it isn't really a standard to calculate the WVP matrix on the CPU, I've seen many cases where this transformation was always calculated on the GPU without any real drawbacks.

And yes camera-space, eye-space and view-space are all the synonyms

[mg_mchenry]

When you create the WVP matrix on the CPU you'll only have to go through this process once for every mesh. However, when doing this in a shader it'll have to be done for every vertex.

Aha, that would be it. Thanks. My meshes only have a few dozen vertices, so shader matrix multiplication still might be faster. Probably faster.

This is a webgl app, so I'd have to test how it works out on low-powered devices with integrated graphics.