Jump to content
  • Advertisement
Sign in to follow this  
Shai

OpenGL coords consistency and the ModelView matrix

This topic is 4323 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I got a problem and I'm not sure what the answer is, hence the post :) Let's say I've positioned a cube at (5.0, 5.0, 5.0) with reference to the global XYZ axes. I place a camera at (10.0, 10.0, 10.0) with reference to the global XYZ axes and it points towards the cube. I render the scene as seen by the camera and store the positions of the scene as seen by the camera in a texture. Will the coords of the cube as stored in the texture still be (5.0, 5.0, 5.0) or will they be different because of the position of the camera? Why am I asking this? I want to render a scene as seen from a camera and store the positions in a texture. Then I want to switch to a different camera located at a different position and use the texture from the first camera. However I'm worried that the coords stored in the texture of the first camera won't "point" to the same object when they're read by the second camera. Basically what I'm afraid of is that both cameras use different axes in which case the point at (x, y, z) as seen by the first camera won't be the same as the point (x, y, z) as seen from the second camera. If that's the case, then I'll need to store world coords in the texture instead of view coords. But OpenGL doesn't have a ModelToWorld matrix, it only has a ModelView matrix. Could anyone tell me how to calculate the ModelToWorld matrix?

Share this post


Link to post
Share on other sites
Advertisement
Guest Anonymous Poster
Don't understand your question...

A texture is just a flat 2d image, it only contains flat 2d coordinates.

Whatever is rendered from one camera, is all rendered relative to that camera.
The resulting image exists in screen space, and is projected to only 2d screen coords.


What do you mean by having the second camera 'use' the texture rendered from the first camera view?

Share this post


Link to post
Share on other sites
kind of unclear what you mean when you say "texture". By rendering to a texture you take a 3D world and transform it into a 2D world that's mucked with so that it's drawn in perspective. So, no, you do not maintain the 3D world information, all "coordinates" such as they are become 2D coordinates relative to the texture space.

So, yeah, I think you are using the word texture when you mean something else. Could you describe conceptually what it is you are trying to do. Specifically, this sentence doesn't make any sense:

"I want to switch to a different camera located at a different position and use the texture from the first camera"

what do you mean by "use it"?

[EDIT: damn you AP and your speedy typing!!]

-me

Share this post


Link to post
Share on other sites
ah sorry, I'll try to clarify


Here's the excerpt from the paper I'm trying to implement:

"Obtain 3D positions of the geometry: The geometry is rendered to a positions texture from the light's view. 3D world coordinates are output for each pixel instead of color."


When I say "render to a texture", I mean taking the position of the geometery and storing it in the RGB channels of the texture. What I'm worried about is that both cameras use different coordinate systems.

- I render the scene as seen from camera A
- I store the coords of the geometry as seen by camera A. I suppose these coords are the (ModelView matrix * model coords)
- I switch to camera B
- I read the positions texture created by camera A

Suppose that camera A stored the coords (10, 10, 0) somewhere in its positions texture. Now I switch to camera B and camera B reads (10, 10, 0). Will the point at (10, 10, 0) as seen by camera B be the same as the point at (10, 10, 0) as seen by the camera A.

What it comes down to is that I need to know whether the coords in the positions matrix are stored relative to the position of the camera or whether they're world coords.

Share this post


Link to post
Share on other sites
Quote:
Original post by Shai
...
What it comes down to is that I need to know whether the coords in the positions matrix are stored relative to the position of the camera or whether they're world coords.
They are stored in whatever coordinate space you transform them to before storing. According to what you say you're doing now...
Quote:
Original post by Shai
- I store the coords of the geometry as seen by camera A. I suppose these coords are the (ModelView matrix * model coords)
...they are stored in the view-space of Camera A. You could do it this way but then when rendering from Camera B you will need to transform the positions back into world-space (multiply by the inverse of Camera A's view matrix) and then into Camera B's view-space.

It makes more sense to just store the positions in world-space because then you will only need to multiply them by Camera B's view matrix. To transform the original point in model-space to world-space you multiply by only the model matrix. Since OpenGL combines the model and view matrices, you will need to manually pass them separately into your shader. So your shader for Camera A would have something like this...
vec4 worldPos = modelMatrix * modelPos;
//worldPos is what you write to the texture
//now you can multiply worldPos by Camera A's viewMatrix
//to get the point in view-space if you need it for something
//else in the rest of this shader
Then in the shader for Camera B you just get the point from the texture and multiply it by Camera B's view matrix to get the point in Camera B's view-space.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!