Advanced Blitting

I thought of some features that would be cool to have in OpenGL 2.0, mainly for the accelertion graphics cards could provide to these functions.

  1. Instead of using quads, triangle fans, or strips to specify a bitmap-use a glBegin(GL_BLIT)–or something to this effect. Instead of passing vertices that determine the corners, just pass a single vertex (which can be a point in 3-d) which would be the center of the bitmap. Also, no glTexCoord calls would have to be made, just bind to a texture before glBegin(GL_BLIT) and the code will automatically bind the corners to blit!

  2. The current projection and modelview matrices would transform the blit the same as other fragments, with following exceptions: (which I will try my best to explain)

  3. Translations and scalings would work like the same as for other fragments.

  4. Rotations that are not strictly in the xz plane (rotating around the z-axis), would skew and scale the blit, but it would not form a rotated plane like quads, and other polys, would. This would allow for many “sprites” to appear 3-D without the harsh artifact intersecting polys can leave when blending is enabled (in some instances).

The reason this would be great is that many optimizations should be apparent for sprite engines. However, the main reason I’d love to see this is for particle engines! A bitmap of a particle could be loaded into texture memory. When a particle needs to be drawn, just give it a position. Since a particle will never be able to intersect other fragments, they will always render correctly with blending enabled. The blitter object will always be parallel to the view. Rotating on the y-axis for exmple would make the blitter object look squished, or flipped–which in some cases is what I would want, and yet the object would still have no depth!

Please post replies and let me know what your thoughts are!

Some more thoughts on blit stuff.:>

A glBlitVertex() could be called with the following enums to determine how OpenGL treated the passed vertices:

GL_BLIT_TOP_LEFT: vertex specifies top left of blit
GL_BLIT_BOTTOM_LEFT: vertex specifies bottom left of blit
GL_BLIT_CENTER: vertex specifies center of bitmap

Another thought about having GL_BLIT is that a vertex array could be used for positions, and a single call to glDrawArrays would draw all the blits on the screen at one time. To draw a bunch of different sprites, with one call, may require a somewhat different approach…(maybe interleaved arrays) This would work great for particle engines that just draw the same bitmap many times at different positions though!

You might want to take a look at the NV_point_sprite extension (use Google), courtesy of our very own Matt Craighead.

Unfortunately it’s proprietory and (iirc) is only available on high-end GeForce hardware. I would very much like to see it in standard GL, but not at the cost of delaying the ARB ratification of 2.0.

Ideally, I’d like an extension of vertex programs to cover 1-N input/output transforms rather than just 1-1; this should theoretically be able to replace point sprites, traditional evaluators, pn_triangles etc. In practice, this is still fairly bleeding edge and probably won’t get standardized until it’s settled down a bit.

You brought up a good point MikeC about not delaying the ARB ratification of 2.0. I only thought of this idea because it seems it would be so simple to implement, yet very cool to be graphics card accelerated. I’m thinking millions of particles and/or sprites baby!

I took a glance at the NV_point_sprite extension, and it had mostly the same thing I had in mind, I guess great minds think alike One thing though, a global switch would not be needed because each fragment would use glBegin(GL_BLIT) (or whatever) instead of glBegin(GL_POINTS)…oh well, it was just a thought anyway.