Hello,
Does anyone know whether it is possible to use gTextureImage3DEXT() to create 3D 32 bit floating point texture and bind it to FBO using glFramebufferTexture3DEXT()?
I am using 7800GT and latest 81.98 drivers. If this is not possible at the moment does anyone have any insight as to when it will get implemented if ever? Thanks.
Igor
I didn’t get your question entirely. But if you are trying to create a 3D texture render target, then i don’t think that any current hardware supports 3D texture render targets. This is just my knowledge and i am not 100% certain, so do confirm it with someone else too.
I am also interesed in it, but I don’t think current FBO supports 3d-texture render target.
I was hoping that someone here knows more precisely whether this is supported or not.
I am experimenting with GPGPU concept, and I had an idea to use GPU for some forward and backward projections in volume rendering just the way it is currently being done on the CPU.
True, I need to render to a 3D 32-bit floating point texture. Goal is to avoid dealing with bunch of slices as a separate 2D textures which would probably limit rendering efficiency.
If you read the FBO spec it says that you can attach 3D textures to an FBO, however, you have bind a slice to a color attachment. So in order to render to a 3D texture, you’ll have to loop and render to each slice.
This brings up a question, there are only 16 color attachements, so how would someone suggest rendering to a 3D texture with more than 16 slices? One option would be to have numSlices/16 fbo’s and switch between the fbo’s as you need them. Another option is to use one fbo and swap the textures out every now and then. That’s just what I thought of quickly, and I’m not really sure what the advantages/disadvantages are of both methods. Any help would be great.
Thanks.
Originally posted by brtnrdr:
This brings up a question, there are only 16 color attachements, so how would someone suggest rendering to a 3D texture with more than 16 slices?
Current hardware can output to only up to 6 textures anyway (that’s depth + stencil + 4 color attachments).
So, even though 16 color-attachment-points are defined, you are not able to use more than 4 of them.
Jan.
Doesn’t that limit apply to the number of outputs of a fragment program (which is limited to 4 color buffers), however, is it true that on current hardware you can’t attach textures to color attachments 4-15? Those enums are just “attachment points”, so you should be able to make a call like glDrawbuffer(GL_COLOR_ATTACHMENT4). However, I realize you can’t have an array of all 16 color attachments and say glDrawbuffers(16,array).
Igor I have a notice about 3D FBO (128x128x128 for my texture)
I think the FBO 3D doesnt run on nvidia
I have a code and it s running on ATI X800 but on nvidia 7800,6800,6600 i have an error when i use FBO 3D
Drivers problem ?
Originally posted by brtnrdr:
Doesn’t that limit apply to the number of outputs of a fragment program (which is limited to 4 color buffers), however, is it true that on current hardware you can’t attach textures to color attachments 4-15? Those enums are just “attachment points”, so you should be able to make a call like glDrawbuffer(GL_COLOR_ATTACHMENT4). However, I realize you can’t have an array of all 16 color attachments and say glDrawbuffers(16,array).
No, i meant it’s not possible to render to more than 4 color buffers in one operation. Of course you can use the color-attachments 4-15, but you can never use more than 4 at the same time.
Of course it is possible to render to 3D textures with more than 16 slices. Just bind slice 16 to color-attachment 0, slice 17 to attachment 1, …
Jan.
Originally posted by Igor Levicki:
[b] .
I am experimenting with GPGPU concept, and I had an idea to use GPU for some forward and backward projections in volume rendering just the way it is currently being done on the CPU.
True, I need to render to a 3D 32-bit floating point texture. Goal is to avoid dealing with bunch of slices as a separate 2D textures which would probably limit rendering efficiency. [/b]
The current FBO spec doesnt allow for 3D render targets.
And lets say you have a 3D voume, you still have to either slice it or ray trace it… there are no primitives for volume rendering besides triangles…
(1) Why not just brick your volume in a large 2D texture?
(2) Why not use regular ray casting as in the Krüger paper from 2003?