vade

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()?

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

jit-gl-render-erase-vs-glcleargl_color_buffer_bit

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?

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 


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?


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?

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?


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.

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.

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.


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.

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.


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.

Its less obvious with this image, but still happens: 

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.

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

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.


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.

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.


Shall I file an official feature request on the list?

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:

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:

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

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


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.

jit.gl.render erase vs glClear(GL_COLOR_BUFFER_BIT)