Sign in to follow this  
BrennendeKomet

glReadPixels reboots my comp :)

Recommended Posts

I need to calculate how many pixels in my scene are of white color. For this purpose i use a call to glReadPixels function, with the following parameters:
float colors[3*600*600];
glReadPixels(0,0,600,600,GL_RGB,GL_FLOAT,colors);
But all i get - is memory overlfow or or somthing like that - the computer reboots... When i use
float colors[3*600*600];
glReadPixels(0,0,1,1,GL_RGB,GL_FLOAT,colors);
that is when i read a single pixel - everything goes ok... So, i wonder, where is the whoel memory going? is the scene too big? (0,0,600,600 - in windows coordinates) or do i have to pass some other parameters to glReadPixels()? Thanks in Advance :) edit: formatting...

Share this post


Link to post
Share on other sites
Your call to glReadPixels looks fine to me. I'm not sure what your problem is, but it's generally not a good idea to allocate 4 meg arrays on the stack. You could be running out of stack space, but if that was the case I would expect the second version to fail in the same manner as the first.

Enigma

Share this post


Link to post
Share on other sites
I'll join Enigma in the assumption that it's a problem with too much stack. Depending on the overall situation and system architecture, it might just work to set the new stack ponters to the desired sizes, but an access beyond a sane limit will cause damage. Try a dynamic allocation.

Share this post


Link to post
Share on other sites
Whatsoever if you want to compute how many white pixels are there, you should not use glReadPixels, especially if you expect to compute it over many frames. I'd rather recommend color keying and occlusion queries.

Share this post


Link to post
Share on other sites
I have before had an array about that size and I got a compile time error about not having enough room on the stack. Then I decreased the size by a bit and it worked fine. So I'd imagine that if its a problem with the stack, then the compiler would tell you. Also, I think there's an option somewhere in MSVC for setting the stack size.

Share this post


Link to post
Share on other sites
Being able to compile and being able to execute are different problems. Though you're right that most of the time such memory limitations can be more or less "stopped" by the compiler.

Share this post


Link to post
Share on other sites
Thanks for Your replies!

Well, as Enigma noticed - it there was problem in allocation - then neither the second call would work... so i don't think that its running out of stack...
Also, i don't need to calculate white colors this every frame - but rather each time the user releases mouse button... but that's not so important... however, vincoof could you please provide me with slightly more details about "color keying and occlusion queries"? Even a link would be of great help! (it's difficult to google with such clues...)

JazzD, i think your experience will be very usefult for me :) can you please remember what have you found out when you had this problem? and how you decided to overcome it?

again gross thanks to everyone!

Share this post


Link to post
Share on other sites
color keying can be computed in a fragment program (very easy, but needs good hardware : GeForce FX and up, or Radeon 9500 and up) or in texture combiners with DOT3 and alpha testing (harder, but supported on a very wide range of hardware : basically all GeForces and all Radeons to date).

occlusion query is a way of counting the number of fragments that hit the framebuffer. Look for references about the ARB_occlusion_query extension or the former NV_occlusion_query.
The 3D Lens Flare tutorial gives hints on how to use occlusion queries, but it is merely limited to querying a single pixel. You might need to extend this query for multiple fragments.

Share this post


Link to post
Share on other sites
if I remember correctly, setting

glPixelStorei(GL_PACK_ALIGNMENT, 1);
glPixelStorei(GL_UNPACK_ALIGNMENT, 1);

might help, so there are no overhead bytes needed to store the data. Does it work if you change the line:

float colors[3*600*600];

to
float colors[4*600*600];

to give yourself extra memory?

Share this post


Link to post
Share on other sites
Quote:
Original post by lonesock
glPixelStorei(GL_PACK_ALIGNMENT, 1);
glPixelStorei(GL_UNPACK_ALIGNMENT, 1);

hmm no :)
This setting is useful only for reading unsigned bytes. But since GLfloat is 4-byte aligned, there is no need to call glPixelStore because OpenGL's default is 4 already.

Share this post


Link to post
Share on other sites
Huh... i found what was the problem, so if anyone is interested - here we go:
At first, my question did not reflect my problem:
I posted:

float colors[3*600*600];

while in my program it was:

float colors[3*600];

so this is where i got "happens when the allocated memory for the array doesn't fit with the resolution" (c) JazzD
Now when i corrected this stupid mistake, i received a "stack overflow" error in the debugger (note: this time it was at run-time, but not during the compilation).
Finally, making use of the dynamic allocation (just once - at the start of the program), i received the correct result :)

Thanks everybody for help!

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this