Pixel Access in an OpenGL Context?

[geezusfreeek]

Is there any way to get direct access to the pixels in an OpenGL context? :confused:

I was looking for that when I saw OpenGL stuff in the CGDirectDisplay technote (mentioned in the topic entitled "CGDirectDisplay and OpenGL" or something like that). I thought I had found something, but apparently I just hadn't done enough research into OpenGL itself. :(

[OneSadCookie]

No.

You can use glReadPixels to read, and either glDrawPixels or a textured quad to write them. If you go the textured quad route, GL_EXT_texture_rectangle may be of use to you.

What do you want to do with the pixels?

[geezusfreeek]

I was just theorizing and was thinking that effects such as particle effects could run a bit faster if they were generated simply as many many pixels rather than many many polygons. I think drawing right on top of a rendered scene right could be a very fast way to do this.

Would there be another way to achieve similar results? Masks maybe? What kind of performance hit could there be from changing a mask every frame?

[inio]

The video card can fill and blend pixels faster than you can in software. trust me on that one.

Particle systems should be drawn as lots of textured polygons. How those polygons are passed to openGL depends on the effect you want however:

1. classic "particle":
Draw it in it's real 3d location as a quad*. Calculating the corners of the quads is pretty trivial if you have the position of the camera in object coordinates (which isn't so trivial sometimes). You can also translate the object coordinates into world coordinates before generating the quads if you don't feel like generating an inverse transformation matrix. If there's demand I'll post code for doing these operations.

* If you think you're polygon limited, you can use a single tri, though this doubles your pixel load.

2. lens flare:
Draw this after rendering the scene with the same projection matrix you use for your HUD. Calculating the screen position of something is pretty trivial (though you have to generate the matrices on your own, this is a good way to learn what OGL is really doing when you call glRotate).

[geezusfreeek]

Polygons can be calculated faster than setting pixels? Even if the polygons would probably only fill only one pixel at a time anyway? That seems a bit odd, but I'll take your word for it. I was just theorizing anyway. Just wondering if it was possible to render things outside of 3D space, not counting objects aligned to the camera. Thanks for the explanation anyway. Once I get some more OpenGL experience, those effects will not be so far off for me.

[inio]

if you're blending, then yes, polygons will be faster. If you aren't blending then direct writes to VRAM would probably be faster. However, using polygons lets you very easily make multi-pixel fuzzy particles, which can look really cool.

[geezusfreeek]

Depends on the type of effect you are attempting with the particles I think.

With software rendering of opaque particles, I would imagine that a much larger number of particles could be rendered, as well as some nifty effects that I haven't thought of yet.... Like I have already said waaay too many times, to the point of possible being annoying, I'm not fluent enough with OpenGL to know everything it is capable of. All I know how to do right now is basic rendering and simple rotations. Enough to maybe make a very simple 3D game. Oh yeah, but my code for rotation isn't even up and running yet. Nope, I haven't much to go on... yet.... No biggie. Those NeHe tutorials are easy to follow!

I love the majority of the modern particle systems using 3D hardware, but there is a mindset that that is all there is. I'm sure that there are many other limitations that could be gotten around using a 2D particle engine. I always look for substitutes and see if there is anything that I can't do with the norm that I can do with the alternate method.