OpenGL needs a depth buffer for transparency support

Hi Chris,

In order to do any alpha blending, we need to have OpenGL init a depth buffer when it is initialized. Right now MWorks does not do that. As you said, the place to do the init is in NSOpenGLView. I’m attaching a patch to git HEAD to do it. It happens in two places, for the mirror window and for the stimulus display.

Let me know when this makes it to the nightly - we’re going to be running this on 10.6 and the nightly once it does.

thanks!!
Mark

Attachment: enable_depth_buffering.patch (1.25 KB)

Hi Mark,

Based on my own experimentation, I’m not convinced that your patch is necessary. For example, the attached experiment draws three overlapping rectangles, each with an alpha of 0.5. The output (also attached) is identical with or without your patch.

Can you try my experiment on your setup and see if you get the same result? If not, then maybe it’s a hardware difference. (I’m testing on a MacBook with an NVIDIA GeForce 9400M.) If you do get the same result, can you provide another example where having the depth buffer enabled does make a difference?

Thanks,
Chris

Attachments:

Hi Chris,

It looks like RectangleStimulus calls this from PointStimulus to draw:

glBegin(GL_QUADS);
glColor4f(_r, _g, _b, *alpha_multiplier);
glVertex3f(0.0,0.0,0.0);
glVertex3f(1.0,0.0,0.0);
glVertex3f(1.0,1.0,0.0);
glVertex3f(0.0,1.0,0.0);
glEnd();

Meaning that there is no depth buffering at all; the z-distance is always 0. My plugin explicitly positions the various surfaces and masks in Z. So my plugin needs the depth buffer enabled.

Are there any advantages to setting a depth coordinate for MWorks?

Mark

Meaning that there is no depth buffering at all; the z-distance is always 0.

True. However, as the example demonstrates, you can still draw one rectangle on top of another by queuing the bottom one before the top one. Since there’s no perspective (because MWorks setups up an orthographic projection), doesn’t this give the same result as giving the rectangles different z coordinates, without the need for a depth buffer? Or am I missing something?

My plugin explicitly positions the various surfaces and masks in Z. So my plugin needs the depth buffer enabled.

Same question: Can you get the desired effect by altering the drawing order, without explicit z values?

Are there any advantages to setting a depth coordinate for MWorks?

Unless you’re trying to use perspective, I’d say no. In fact, in the 0.4.4 implementation of OpenGLContextManager, the depth buffer is explicitly disabled. (NSOpenGLPFADepthSize is set to zero.) However, I’m in no way an OpenGL expert, so it’s possible there are in fact good reasons to worry about depth.

Chris

doesn’t this give the same result as giving the rectangles different z coordinates, without the need for a depth buffer? Or am I missing something?

I think that’s right, yes.

Are there any advantages to setting a depth coordinate for MWorks?

Unless you’re trying to use perspective, I’d say no. In fact, in the 0.4.4 implementation of OpenGLContextManager, the depth buffer is explicitly disabled. (NSOpenGLPFADepthSize is set to zero.) However, I’m in no way an OpenGL expert, so it’s possible there are in fact good reasons to worry about depth.

Ok. Unless someone else has an opinion, I’m happy to try to reimplement with Z=0. I’ll get back to you with the results.
Thanks!
M

Unless you’re trying to use perspective, I’d say no. In fact, in the 0.4.4 implementation of OpenGLContextManager, the depth buffer is explicitly disabled. (NSOpenGLPFADepthSize is set to zero.) However, I’m in no way an OpenGL expert, so it’s possible there are in fact good reasons to worry about depth.

Yes, it all works properly with Z=0.

From what I have read, if you want transparency to work correctly in Z, you need to manually draw your polygons back-to-front anyway. So I can’t see any depth buffer benefits either. I reverted the core change and everything works fine.

Thanks for the time, Chris!
M

Yes, it all works properly with Z=0.

From what I have read, if you want transparency to work correctly in Z, you need to manually draw your polygons back-to-front anyway. So I can’t see any depth buffer benefits either. I reverted the core change and everything works fine.

Great! Thanks for verifying that.

Chris