Acessing to the textures data of the OpenGL driver

OpenGL OpenGL: Advanced Coding
1

Evil smile. You’ll like this one

Here is my problem:
I’m trying to find the intersection between a ray and the world. Everything works fine, excepting for the transparent surfaces (like sprites). A texel can be totally transparent or totally opaque.
If my ray hits a transparent texel, it returns an intersection with the surface. I don’t want that; i want it to return the intersection if the texel is opaque only.

It’s easy to find what is the texel hit in the triangle, and thus the position in the texture space.

And now…? to test this texel i need an access to the texture. I don’t want to access to the video textures… -too slow-. I’d like to avoid to copy the textures in memory myself -the driver already does it, waste of memory-. So, is there a way to access to the textures kept in system memory by the driver ??

Y.

2

No, you can’t access the textures.

3

Aaaaarggghh nooo ! Will i have to duplicate my textures in memory then ? cry

Y.

4

You should make you data structure so that surfaces have info about their texture.

5

So… at a given time, i will have:

  • the texture in video memory;
  • the same texture in the system memory, kept by the driver;
  • the same texture in my own data.

Three times more memory than i’d need. I should switch to D3D :]

Y.

6

Nah. You have the videomem/sysmem copies anyway, and I’m pretty sure you’d have to have them under D3D as well. For your purposes you only need to store one alpha bit per texel; you don’t care about the RGB color info. So assuming 32-bit textures you’ve got a grand total of 65 bits per texel instead of 64. Big deal.

(I did something similar back in my 'Miggy days, using the blitter mask plane for hit detection, and it worked fine.)

7

Although you can’t directly access the textures, you can get a copy of a driver’s texture with glGetTexImage.

Since the drivers copy of a texture is in system-memory, querying it should be pretty fast (basically the cost of a memcpy).

Mike F

8

No no no no no… any pending texture deletes or glTexSubImage calls might invalidate the driver’s copy of the texture data, so your call to glGetTexImage would almost certainly force a pipeline flush. Bad.

I know I sound like a stuck record on this, but it keeps coming up over and over again. The glGet functions should never be used in a main animation loop. If there are exceptions to this rule, I’ve yet to see one.

9

Hum, making copies of the texture doesn’t seem to be a good idea… not only glGetxxx is slow, but i’ll also need to do for a bunch of textures each frame. I don’t want my engine to spend its time in copying the textures

However, i think the 1 additionnal bit per texel could be a good solution. It’s not a lot of additionnal memory and should be quite fast to access. Thanks for the idea

Y.

10

Maybe I’m missing the point here, but isn’t the best way (memorywise) to just store the data wether it’s transparent or not, i.e. not storing the texture itself. This will store the “texture” as 8 pixels per byte.

11

Hem no, i’m talking of some “sprite” textures. You see, with a transparent background. A texel can be totally transparent or totally opaque, but not all the texels are either transparent or opaque.

Y.

12

Originally posted by MikeC:
[b]No no no no no… any pending texture deletes or glTexSubImage calls might invalidate the driver’s copy of the texture data, so your call to glGetTexImage would almost certainly force a pipeline flush. Bad.

I know I sound like a stuck record on this, but it keeps coming up over and over again. The glGet functions should never be used in a main animation loop. If there are exceptions to this rule, I’ve yet to see one.[/b]

glGet doesn’t have to be slow on infreqently modified data (eg. textures) A driver could very easily detect that there are no pending modifications for a piece of data and not bother with the pipeline flush. Whether or not drivers actually do this is another matter, I can only suggest that the poster try it and see whether the results are acceptable or not.

Mike F

13

Ysaneya: If the texel is completely transparent, does it matter what color it has? If the texel is completely opaque, the ray (from your first post) will “hit the texture”, but does it still matter what color that texel has? If your image is AxB in size, then create an array of bits that is of size AxB, and place either zero (for transparent) or one (for opaque) in each bit in the array. When your ray hit the texture, look at the bit representing the transparency/opacity for that texel.

14

Mike F:
Unless it’s specified somewhere, i’ll certainly not rely on that. The performances can be acceptable on my machine and very bad on another, so…

Bob:
Uh, yes, i didn’t understand. It’s also the suggestion of Mike C (adding 1 alpha bit per texel). I don’t need the color, just to know if a texel is transparent or not, so it’s a good suggestion i believe.

Y.