glReadPixels reading z value

Started by
13 comments, last by svnstrk 12 years, 6 months ago
i need the exact world coordinate at the mouse i clicked.[/quote]
Then you already had the code to do that, using glUnproject() gives you a pixels window x, window y, and z-depth value from read pixels, all you needed to do was put z in your unproject function instead of 1.0

NBA2K, Madden, Maneater, Killing Floor, Sims http://www.pawlowskipinball.com/pinballeternal

Advertisement
Anyone here not suggesting to implement ray picking using a simple ray vs aabb query? glReadPixel forces rendering to become sync rather than async, and can absurdly impact performance in some cards (i.e. GeForce 480)

Anyone here not suggesting to implement ray picking using a simple ray vs aabb query? glReadPixel forces rendering to become sync rather than async, and can absurdly impact performance in some cards (i.e. GeForce 480)


im not sure what mean by async and sync but i dont have any (noticeable) performance issue right now. i just notice 2 ways doing this: raypicking or glReadPixel.
Hi!
Normally, a GPU renders independently of the CPU's state. It's called asynchronous rendering. When you use functions like glReadPixel, the CPU has to stop (waste time) and wait until the GPU sends the requested data. And the GPU has to wait until the CPU tells him there's no more data to ask. This breaks the async and rendering becomes synchronous.

If your application isn't stressing the CPU nor GPU, you won't see major performance drops. But once you start hitting bottlenecks and your game does some heavy load on either of them, the performance drops quickly when rendering in sync. That's all.

Another, probably bigger problem with glReadPixel, is that you don't see any noticeable performance issue, but it may vary a lot in different systems. It may turn out that your game runs slower even in more powerful PCs. I'm just warning you. glReadPixel is very handy compared against raypicking/raycasting, but has it's drawbacks.

Hi!
Normally, a GPU renders independently of the CPU's state. It's called asynchronous rendering. When you use functions like glReadPixel, the CPU has to stop (waste time) and wait until the GPU sends the requested data. And the GPU has to wait until the CPU tells him there's no more data to ask. This breaks the async and rendering becomes synchronous.

If your application isn't stressing the CPU nor GPU, you won't see major performance drops. But once you start hitting bottlenecks and your game does some heavy load on either of them, the performance drops quickly when rendering in sync. That's all.

Another, probably bigger problem with glReadPixel, is that you don't see any noticeable performance issue, but it may vary a lot in different systems. It may turn out that your game runs slower even in more powerful PCs. I'm just warning you. glReadPixel is very handy compared against raypicking/raycasting, but has it's drawbacks.


thats an interesting point Matias, I'll try to take a look at it. Does it helps not to do glReadPixels(..) between the 2 rendering. eg:

render to FBO
render to front buffer
glReadPixels(..)

Actually I did glReadPixels in a different function. I dont put glReadPixel at render() function, instead I put it in mouseFunc(..). Does this help the performance knowing that CPU has the pixels AFTER the scene is rendered? And besire raytrace and glReadPixel, is there any other function can be used to implement this function?

thanks in advance

This topic is closed to new replies.

Advertisement