PDA

View Full Version : Dynamic cubemap through PBuffers - garbage output on all but one face above 16x16!



ChiefWiggum
11-24-2005, 03:54 AM
This is a long running quest to get dynamic reflections working through pbuffers. I've had various bugs crop up over the last 2 years, first on 9800's then on my current 6800. This one I simply havent been able to solve, and havent found anyone doing the same thing on the forums, google.

I'm drawing to a pbuffer cubemap, and drawing that by binding it to a texture. There are no errors in creating the pbuffer, and its infact the same pbuffer class I use successfully for all other RTT including post processing.

When I draw to the cubemap, only the X+ face actually works. This will be 100% clear, no corruption at any resolution. The other faces generally show glClearColor on them, but sometimes will show garbage:
http://users.on.net/~pixelated/cube_garbage1.jpg, http://users.on.net/~pixelated/cube_garbage2.jpg
(They are multicoloured because I clear each face to a different colour for testing! If I redraw a 2nd time, only the clearcolour is shown on faces except X+ which works)

It should look like: http://users.on.net/~pixelated/cube_ok.jpg

(the stuff in the Y-,Z- faces isnt garbage! And yes I know they dont line up properly :) )

To switch faces I call wglSetPbufferAttribARB(m_hPBuffer, face) where face is one of the WGL_ cube face defines. No errors here either.

I've tried drawing all faces at once (make pbuffer current, draw each face, make FB current & use as texture), I've tried updating one face at a time (make pbuffer current, draw current face, make FB current & use as texture).

I also allow my program to save TGA's of cubemaps so they can be used as static reflections. This has the same output as described, I get the image back with glReadPixels once it has been drawn.

I've tried calling glFlush after each face is drawn, or once after all faces are drawn. Tried glFinish too.

I thought its hopeless but just 10 minutes ago I realised if I resize the cubemap to 2x2, 4x4, 8x8 or 16x16 it WORKS! No corruption at all. If I go above 16x16 its very strange - the first draw into the newly recreated pbuffer has most faces drawing (some with garbage), the 2nd draw ONLY the X+ face draws.

I've also tried changing the update interval - once very frame, every 2, every 5, 10 frames...

Surely someone else has implemented this successfully, I'd love to hear they found a similar problem and solution :)

I'm using a 6800GT, 81.94 drivers, windows xp SP2

Thanks for any help!

Edit: Depth and stencil buffers are cleared before each face is drawn (with the colour clear, and the colour clear clearly works!). I first thought it could be depth or stencil problems but at 16x16 it works fine!

Edit 2: I havent even found a demo on the net using pbuffer cubemap RTT! Maybe this is why..? :)

Zengar
11-24-2005, 05:31 AM
Hm, I would recomend you to use the GL_FRAMEBUFFER_OBJECT extension for it as it skips the whole pbuffer fun.

Could you prob. post the code or the link to a demo?

Zulfiqar Malik
11-24-2005, 06:35 AM
This is not exactly realated to your problem, but i would definitely agree with Zengar!
I tried using pbuffer cube maps for shadow map rendering but even after a couple of days of trying i couldn't get it to work. Then a few days later ATI announced suport for FBO (nVidia had it already) and boy, was i glad. With FBO i was able to get the cube map RTT up and running within a couple of hours!
I am sure this doesn't help your problem, but just a little suggestion :) .

ChiefWiggum
11-24-2005, 01:11 PM
I cant really post a demo because its a massive 3d editor! I'd have to post tons of textures & other stuff. I might try post some code but the relevant code is in about 4 different classes.

I was thinking of using FBO's and nearly did it yesterday, but I realised I use stencil shadows - and FBO still doesnt support that on nvidia (and probably ati!). So I'm stranded with these bloody pbuffers :(

Relic
11-24-2005, 09:45 PM
Is depth test enabled?
Have you selected pbuffers with depth bits?

Matt Zamborsky
11-25-2005, 08:11 AM
NVIDIA supports FBO with stencil buffer in >81.xx drivers.

ChiefWiggum
11-27-2005, 03:00 AM
Relic: Yep tried 32, 24 and 16bit depth in my pbuffer, same thing happens! Depth test is enabled (same code as the non-pbuffer renderings!)

Matt: Stencil works with FBO??? :eek: :eek: I'm sooo going to dump pbuffers completely then :D Thanks for the heads up! I'll check it out!

M/\dm/\n
11-27-2005, 05:15 AM
Make sure you dont use gluLookAt, it has problems with positioning, gimbal lock or something...

ChiefWiggum
11-28-2005, 12:09 AM
Well, since stencil is supposedly supported now (havent found anything on the net about it but dont care, I've given up on shadows in reflections, I just want the damn things to work)... I spent a few hours implementing FBO render to cubemaps. On the FIRST run of the code it worked! So well done to the people who brought us FBO, whereas the people who brought us the hell that was pbuffers:

YOU SHOULD BE SHOT AND HANGED. BY THE BALLS.

(and if its the same people... you've redeemed yourself :) )

Relic
11-28-2005, 01:35 AM
Search harder. ;)
Even with FBO example:
http://oss.sgi.com/projects/ogl-sample/registry/EXT/packed_depth_stencil.txt

rgpc
11-28-2005, 03:00 PM
Originally posted by ChiefWiggum:
To switch faces I call wglSetPbufferAttribARB(m_hPBuffer, face) where face is one of the WGL_ cube face defines. No errors here either.
I am curious - what is (was) the type of "face"? Is it an array of ints (as the function requires)? Or were you just passing in a single int with the define in it?

ChiefWiggum
11-28-2005, 07:14 PM
[quote]Originally posted by rgpc:
[B]
int face[4] =
{
WGL_CUBE_MAP_FACE_ARB,
WGL_TEXTURE_CUBE_MAP_POSITIVE_X_ARB,
0,0
};

11-29-2005, 06:48 AM
i use dynamic render-to-cubemap (via pbuffer) in my own graphics engine for shadow mapping. i use a Radeon 9100 card, and i've never had any problems with render-to-cubemap, even up to 1024x1024 resolution.

i looked through all the text that was posted and i guess i can't give you any advice other than keep trying new things. it is possible...

as for using FBO: i would use that (if i had a card that supported it) once i got the pbuffer method to work. if i switched over to using FBO simply because i couldn't get the pbuffer method to work, i'd feel defeated. but that is just me.

i'll try to look through my own code and if i find anything that might be helpful, i'll try to post it in a few days. good luck.

ChiefWiggum
11-29-2005, 03:55 PM
brybry: Thanks for the help! I've always hated pbuffers, its not a defeat thing, FBO is better in every way (better api, no context switch so faster!). I only wanted it to work with pbuffer so its more backwards compatible, but I use PS2.0 anyway so how backwards compatible can I be? :)

As for ATI+cubemap pbuffers, yes I once had it working on ATI too, had some other problems (not graphics corruption, I think it was just general performance problems, cant remember now). So it seems ATI has clearly got a better implementation than Nvidia at the moment!

12-02-2005, 05:57 AM
well, i'm not sure if you are planning to even bother with pbuffers anymore, but this is all that i could think of:

make sure that the WGL_TEXTURE_TARGET_ARB field of the attribute list sent to wglCreatePbuffer is set to WGL_TEXTURE_CUBE_MAP_ARB for cubemaps and WGL_TEXTURE_2D_ARB for 2D maps


Flags(0) = WGL_TEXTURE_FORMAT_ARB: Flags(1) = IIf(Color_Bits = 32, WGL_TEXTURE_RGBA_ARB, WGL_TEXTURE_RGB_ARB)
Flags(2) = WGL_TEXTURE_TARGET_ARB: Flags(3) = IIf(Cube_Map = 0, WGL_TEXTURE_2D_ARB, WGL_TEXTURE_CUBE_MAP_ARB)
Flags(4) = WGL_MIPMAP_TEXTURE_ARB: Flags(5) = GL_FALSE

hBuffer = wglCreatePbuffer(hCurrentDC, pixelformat, Width, Height, Flags(0))i believe that and wglSetPbufferAttrib for changing the target cubemap face are the only 2D/cubemap specific parts of pbuffers on WGL.

i don't care for pbuffers either, but until i can afford a better card, i'm stuck with them. my biggest complaint with them is all the context switching. i have been loading Doom 3 maps in my own graphics engine and with 60+ lights visible at once... context switching is one of the main bottlenecks in the whole thing. :mad: