jit.gl.render erase vs glClear(GL_COLOR_BUFFER_BIT)

Nov 21, 2011 at 10:42pm

jit.gl.render erase vs glClear(GL_COLOR_BUFFER_BIT)

Hi.

This is probably a trivial misunderstanding, but I have always wondered about this.

In a normal GL application setting the glClearColor to 0.0, 0.0, 0.0, 0.0, and then calling glClear(GL_COLOR_BUFFER_BIT) erases the contents of the back buffer (or whatever the current draw buffer is) to the color you defined in glClearColor. Erase being the main thing, once you call glClear the contents of the buffer are set to the clear color, and anything that was in the buffer is over-written.

Now, in jitter, setting the erase_color 0.0, 0.0, 0.0, 0.0 to a jit.gl.renderer, and calling erase seems to do that, until you draw something. Say I have a video plane with blend enable set, blend mode 6 7 (i.e., over), and am drawing something with an alpha channel. I [t b erase] as usual and manually draw the video plane. Now, if I delete the video plane (or simply not bang it when using @automatic 0), even though I am still calling erase, the video plane is still on screen. In other words, the buffer is not being cleared in the same way.

What mechanism is Jitter using to clear? Is there a way to get Jitter to behave like calling glClear()?

Curious about this. See :

http://forums.v002.info/topic.php?id=180&replies=5#post-926

For discussion. Thank you.

#60149
Nov 21, 2011 at 10:51pm

Ah, look at that:

glClear(GL_DEPTH_BUFFER_BIT)
	Context: 0x01276600
	Virtual Screen:  0/1
	kCGLCPCurrentRendererID:  16918034 (0x01022612)
	GL_RENDERER:  NVIDIA GeForce GT 330M OpenGL Engine
	GL_VENDOR:  NVIDIA Corporation
	GL_VERSION:  2.1 NVIDIA-7.14.5
	kCGLCPGPUFragmentProcessing:  GL_TRUE
	kCGLCPGPUVertexProcessing:  GL_TRUE
Function call stack:
	0: 0x97cccb19 in glClear in 
	1: 0x101c99e6 in jit_gl_render_erase in 
	2: 0x000b384f in object_method in 
	3: 0x032a97fb in object_method in 
	4: 0x0eaef088 in jit_object_method in 

So it appears the GL_COLOR_BUFFER_BIT is not getting cleared *only* when erase color is 0.0, 0.0, 0.0, 0.0. Setting erase color to say, 1.0, 0.0, 0.0, 1.0 gives me:

glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT)
	Context: 0x01276600
	Virtual Screen:  0/1
	kCGLCPCurrentRendererID:  16918034 (0x01022612)
	GL_RENDERER:  NVIDIA GeForce GT 330M OpenGL Engine
	GL_VENDOR:  NVIDIA Corporation
	GL_VERSION:  2.1 NVIDIA-7.14.5
	kCGLCPGPUFragmentProcessing:  GL_TRUE
	kCGLCPGPUVertexProcessing:  GL_TRUE
Function call stack:
	0: 0x97cccb19 in glClear in 
	1: 0x101c99e6 in jit_gl_render_erase in 

With the expected GL_COLOR_BUFFER_BIT being set. That explains that. Hrm. This makes some proper alpha compositing a touch difficult, no?

#216536
Nov 21, 2011 at 10:55pm

If you need a different behavior than what jit.gl.render does, can you not use textures and capture instead? If that’s not an option, would you mind explaining the situation a bit more?

#216537
Nov 21, 2011 at 10:57pm

Sure, the situation is noted in the link I posted for Syphon. Essentially drawing a texture from other apps via a syphon client straight to a video plane (blend_enable 1, blend_mode 6 7) gives different results due to the lack of clearing the color buffer bit when transparent black is set as the erase color. Essentially, anything transparent is darker.

edit,

to be clear: assuming blend mode 6 7 (over) on a fullscreen quad video plane drawing content that is transparent or semi-transparent:

* if the erase color is 0, 0, 0, 0, for transparent black, it looks ok, but you get trails (no color buffer bit clearing).
* if the erase color is 0, 0, 0, 1, for solid black, compositing is incorrect, but you have no trails.

#216538
Nov 21, 2011 at 11:03pm

If you can post a patch that shows the issue, I can look at it when there’s time. If you can simulate the issue without syphon, that would be very helpful.

#216539
Nov 21, 2011 at 11:05pm

Sure. Its not specific to Syphon at all, just happens we noticed it when looking into an issue reported to a user. Ill whip up an example patch.

#216540
Nov 21, 2011 at 11:33pm
– Pasted Max Patch, click to expand. –

Use this image for the test image: http://i.imgur.com/hmxCL.png

Its less obvious with this image, but still happens: http://i.imgur.com/7RvYy.png

erase 0, 0, 0, 0 looks “correct” for normal rendering on black. However, because the GL_COLOR_BUFFER_BIT is not getting cleared, the color accumulates and adds smears (and if you connect the position to animate it, its worse)

if you use 0, 0, 0, 1, the image looks slighly darker.

However, I think I just stumbled on a realization. My assumption is wrong. The default jitter blend mode of 6 / 7is not “over”, but “mix” in compositing nomenclature. It looks like setting blend mode 1 7 looks correct, with erase color 0, 0, 0, 1. Win.

A good solution. Now I know. And knowing is half the battle. Thanks.

Edit: I would say though, that subtle stuff is definitely weird (not clearing the color buffer bit to get the streaks). It would be nice to maybe have a message that is like “erase_color”, and “erase_depth” “erase_color_depth” as well as “erase” just so you can control whats what.

#216541
Nov 21, 2011 at 11:42pm

Non alpha=1 erase_colors jit.gl.render don’t clear the color buffer and instead draw a full-window quad of the given color and opacity to create the smear-o-vision effect. This isn’t going to change, but I do see an argument for a jit.gl.render @clear_mode or something similar attribute to get standard glClear(color+depth) triggered instead of gl.render’s funky erase.

#216542
Nov 21, 2011 at 11:44pm

Shall I file an official feature request on the list?

#216543
Nov 21, 2011 at 11:56pm

Filed.

#216544
Nov 22, 2011 at 4:22pm

just a follow-up on this, since I was the one who reported this in the syphon forum.
Blendmode 1 7 does not solve the problem as this doesn´t work well if you use alpha masks or transparency with multiple layers.
A quick illustration of this. Two solids, one red in the background, one white in front with transparency set to 50% and a circular alpha mask, which gives the following results:

[attachment=177051,2947]

Attachments:
  1. blendmode17.jpg
#216545
Nov 22, 2011 at 5:02pm

@hc gilje what are you expecting to see? Can you post the patch that generated this?

#216546
Nov 23, 2011 at 3:32am

hc – I mentioned this in a follow up on the Syphon forum (sorry for cross posting) : this is a confusion about Over vs Mix and thus pre and un-premultiplied alpha. If your blend mode is 1, 7, (“over”) you need to edit the color you send to the object so it is premultiplied by the alpha component. If you do this, it composites as you intuitively think it should..

My guess is you are sending 1, 1, 1, 0.5 and expecting a half as dim object.

You need to send 0.5, 0.5 0.5, 0.5 to the oval for it to composite as you want. If you want to adjust opacity down to 0.25, send 0.25, 0.25, 0.25, 0.25.

If you want to tint it red, at 100% opacity: 1.0, 0.0, 0.0, 1.0; and at 50% opacity red, : 0.5, 0.0, 0.0, 0.5;

I posted a screenshot of over working with Syphon in the above scenario, and now it looks “correct” (read, as expected in other apps) when erase_color is 0, 0, 0, 1.0 (no streaks, solid black), when content with alpha is rendered in blend enable, blend mode 1,7.

Hope that helps.

#216547

You must be logged in to reply to this topic.