Subject says it all. I've used glCopyTexImage2D with rect textures, and it worked. The man page says it only supports GL_TEXTURE_2D, but it says the same for glCopyTexImage2D, which does work with GL_TEXTURE_RECTANGLE.

Thanks,

EDIT: My subject line was ungrammatical. Should be:

"Will glCopyTexSubImage2D work with RECT textures."

Yes. The man pages predate the extension, which says:

Accepted by the <target> parameter of GetTexImage,
GetTexLevelParameteriv, GetTexLevelParameterfv, TexImage2D,
CopyTexImage2D, TexSubImage2D and CopySubTexImage2D:

TEXTURE_RECTANGLE_ARB

Yes: http://oss.sgi.com/projects/ogl-sample/r...tangle.txt

The man pages are for OpenGL 1.1 or so, and know nothing of any extensions or later revisions to the spec. You should always refer to the OpenGL extension registry for information about how extensions work: http://oss.sgi.com/projects/ogl-sample/registry/

[edit]doh, beaten by Alex[/edit]

Thank you two. Now that I've got "impostor" trees working, I'm looking into making better water ( reflections, perturbations, etc ) and I need to be able to read the back buffer into a texture.

This brings up another question, actually. I know that reading the backbuffer via glCopyTexSubImage2D will require a flush; is it better to manually call glFlush before calling glCopyTexSubImage, or should I just let GL decide if it has to?

You don't want to call glFlush in that situation.

Any reason to read the back buffer into a texture rather than rendering to a texture in the first place?

In the case of rendering reflections, I'll use FBOs and just render directly. However, for per-pixel water opacity and for distortion, I'll be rendering on top of what's already rendered ( e.g., the world ) so I might as well just render the world, then pull out the color and depth buffers for use by the water shader.

TomorrowPlusX Wrote:This brings up another question, actually. I know that reading the backbuffer via glCopyTexSubImage2D will require a flush; is it better to manually call glFlush before calling glCopyTexSubImage, or should I just let GL decide if it has to?

You don't need to call flush. On a single context, the copyTex* command is serialized inbetween your drawing and texturing, so it will automatically have complete content drawn and ready to copy at the time it is executed.

If you are using multiple contexts (i.e. pbuffers) then you need to ensure that context A's drawing is complete before copying or using it in context B, so you need to finish, or use a fence. FBO's avoid this problem since you can render to texture with one context.

Good information, thank you! Looks like I can re-examine my FBO code and remove a glFlush command I figured belonged, but may in fact not.

I recently used both glCopyTexSubImage, glCopyTexImage, and FBOs to add soft shadows in the demo I showed off earlier, and I was able to use rectangular textures in all, and haven't needed to use a single call to glFlush until the very end. BTW, be careful of FBOs when you need to have a depth buffer: on ATI cards you will be limited to a 16 bit depth buffer. Depending on your needs, that may be fine, but I had visual errors compared the 24 bit depth buffer. (that's why I used glCopyTexSubImage (and glCopyTexImage for the depth buffer because otherwise my program would freeze the entire computer) instead of just FBOs)

What demo? I'd like to see some soft shadows!

Regarding FBO's imprecise depth buffer. It shouldn't be an issue here, since I'll only be using it to display a reflection, which I'll probably blur in the fragment program anyhow.

I have the download here. I also posted about it in this thread. It should run on your video card, just... not very well. I use a fragment shader to blur the alpha on the low-lit render based on the result of the stencil operations and the depth buffer. (making it so it doesn't bleed over on the edge of an object)

That's impressive -- though I get only 4 fps on my 5200! It's a clever technique.

Though the fragment shaders do give it quite a hit, another large performance issue is the fact that I always use z-fail shadows, which require a lot extra geometry/fill rate. When I implement this in games, I'll likely use frustum culling to use z-pass for most cases, and z-fail only when it's going to intersect with the near view plain. (that model of the girl is rather large, though: about 2300 polygons) Just out of curiosity, what fps do you get with just hard shadows?

akb825 Wrote:Though the fragment shaders do give it quite a hit, another large performance issue is the fact that I always use z-fail shadows, which require a lot extra geometry/fill rate. When I implement this in games, I'll likely use frustum culling to use z-pass for most cases, and z-fail only when it's going to intersect with the near view plain. (that model of the girl is rather large, though: about 2300 polygons) Just out of curiosity, what fps do you get with just hard shadows?

First, when using just hard shadows I was seeing about ~45 fps.

Regarding z-fail and various optimizations. I totally feel your pain. I'm also using z-fail, and have taken a couple approaches for optimization.

First, I cache the extrusion ( for the non-moving primary light ) in an FBO for non-moving entities. This is obvious, and helps regarding vertex throughput, but not fillrate.

So, second, to minimize what's drawn... what I do is I have an AABB which encloses the shadow extrusion ( since the extrusion is infinite, I clip against the ground plane, or the terrain ( if a terrain is loaded, using ray-intersections )). I let the scenegraph determine the visibility of this bounding box, and turn on or off the shadow drawing for that object accordingly. Since I have fog, if the bounding-box is completely behind the far fog distance I turn off that shadow as well, since using additive lighting, you'd not see the distant shadow anyway.

With this I can be in the center of a grove of trees and boulders -- all casting shadows -- and still get a half-decent framerate. Well, sort of. My 5200 is a crock. But on a 9800 it's pretty good.

I considered doing trickery to toggle between z-fail and z-pass but the extra math to determine which to use seemed to outweigh the benefits, anyway. Well, that's not actually profiled, just a guess

Nonetheless, I bow before your shader mojo. I'm buying the Orange Book soon ( this or next week ) and will start learning. I've put off shaders until I felt like I had a decent grasp of the fixed-function pipeline.

Thanks for the suggestions. I suppose caching the extrusion would be a little easier if I did it in software instead of using a vertex shader. I suppose that for static objects I could do the extrusion once in software, just so I can cache the extrusion.

I would imagine that if you simply have a box for your frustum culling, which you extrude for the shadow, it won't outweigh the benefits of using z-pass. It wouldn't be that much more math, AFAIK. It would also be the equivalent of drawing your model 2 less times. With enough models, it can really add up. (in my case, the simple scene I have would likely be 1/3 faster)

As for the view on shaders, I learned them somewhat early, since I felt that I could use them to aid me where the fixed function pipeline could not. IIRC, I first decided to learn them when I wanted to make shadows the first time, and felt that doing the calculations on hardware with a vertex shader would be much more efficient. Learning them before GLSL was implemented in hardware probably contributed to why I still use asm shaders today. Call me crazy (OSC already has ), but I just feel I have more control over asm compared to GLSL. Besides, at least you're guaranteed asm shaders will work in hardware as long as it fits the restraints of number of instructions etc. For example, for my conditional blur for soft shadows, it would have been too easy to use an if statement rather than multiplying the kernel by 0. If I did that, then BOOM: no hardware shaders on anything but the X1600. (on the Mac) I haven't gotten lost in any of my shaders, though I will admit I haven't written nearly enough to say I never will. When I make my first large game engine (with something like 8 rendering passes with all the effects enabled (though all the later passes will just be with textures)) I will likely make my final decision to stick with asm or move on to GLSL.