FBO without window = teh borked

Posts: 834
Joined: 2002.09
Post: #1
I posted something along these lines to the GL dev-list, but didn't get a reply, so I'm trying it here as well...

Did the latest graphics update tighten the requirements on FBO creation in any way? My software creates an FBO and an RTT target pretty early in its setup, before the window associated with the current context is shown (it's created, but hasn't been sent the makeKeyAndOrderFront message).

The result suddenly is that the RTT target seems to be disassociated from the FBO - rendering to it doesn't take, it cant be cleared, and it is filled with random bits of texture memory. Recreating the FBO once the window is created makes it work again, as does showing the window before the FBO is created. The FBO is reporting itself as complete, and no GL errors are reported.

[Image: fbo.png]

The one on the left is the expected rendering, the one on the right is the broken one.

I'm also a bit curious as to if this is something in 10.5, the graphics update, or GPU bound. If you have the time, please give it a spin: Galder

Start it up, switch to windowed and then restart the game. Please tell me your results and post your system and game.

Major thanks for any insight! Smile
Quote this message in a reply
Posts: 3,591
Joined: 2003.06
Post: #2
Seems to work normally for me:

MacBook 10.5.2 2GHz Intel Core 2 Duo w/GMA X3100

Galder 1.1.2

Here's what little insight I have: I was having major FBO problems a couple weeks ago, unrelated to what you're dealing with (I was rendering to depth texture), and later discovered that it was a small error with my code in a distant section of the program that was causing the malfunction. It *looked* like it was tied to the size of my viewport somehow and I got garbage in part of my rendering outside of the size of the viewport. I spent about two days trying to track down why... Turns out that the reason was because I had glScissor turned on. Of course, all along I was thinking in the back of my mind that it might have been a driver bug (even though I had some solid test evidence to point *heavily* to the contrary). So the moral of the story is: As much as you might think it's not your fault, keep looking! Wink

Impossible to say without seeing code. I dunno... Do you have *any* gl calls in a windowDidLoad method or similar? Maybe you set a state at that time which makes the FBO rendering work correctly. glColorMask not set right for some reason related to not having a window? Are you setting state in a drawRect method of an NSView which needs to be called at least once before the FBO rendering will work? No clue, just shooting stuff out there... Wacko

[adding] BTW, that "solid test evidence" I was talking about was thanks to OSC, who was kind enough to put together a small GLUT app demoing render to texture, and then also render to depth texture. That was eventually key to tracking down my bug. When I gave up and replaced ALL of my rendering code with the GLUT demo rendering code, it still showed the bug, which meant it wasn't near the section I was looking at.

So moral of the story number two: Make a super simplified test application to test that the basic rendering concept works as advertised on your hardware of interest.
Quote this message in a reply
Posts: 5,143
Joined: 2002.04
Post: #3
Works fine here (Core Duo iMac, Radeon X1600 mobility, 10.5.2 + LGU1).
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  Copying from OpenGL window to other window Ingemar 7 6,442 Nov 4, 2006 03:50 AM
Last Post: OneSadCookie