jit.gl.render erase vs glClear(GL_COLOR_BUFFER_BIT)
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 :
For discussion. Thank you.
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?
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.
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.
----------begin_max5_patcher---------- 1115.3ocyYssjahCD8Y6uBUT6iNDzMtjml86XqTtvfFGkBKQ.4LS1T4eORBi GRF.yEarKOCTVRf59nS28Qx+b8JmcxWYkNfOA9OvpU+b8pU1lLMr5z2W4bH9 0jr3R6vbNvJKi2yb1T0mh8px1dtrjq3RAvyE7OP805QHOpxXJ0OxYUSiiC3y m5hmZeT4tu9ATP83eVJTh3C1Q67uE73r5dxiUIegK1usfknpdYXTjq2F.F5a tEQMWggtdmmBwwCbgd9sFOpwTTx+e6T.Q5m47XqLV6fglF+050lKaFH3HXun cl2gMePCGzNwimyjwp1AEzb.ED0BJXKnf7dz.kOBfd8vR5AU7lEpfBL2Hv6L pn8O8K4Bt+FfytXw9VgAHYVvPHwbi58NXHOtP+tTrhsLQ7tL6a0qMHBNFHBc 8HNIxiBs4AfFBTm.HWXgu5+MesUTbVjIXUFmJrraxDcLHEYBHUWIkKXwoiKO r+jfCHMzBGAAtHOL1OpNsyiWt3uxUteS4dP9cNC7TbZbtB.6Dizid6gXUA+U KQpMDiNIDqh3fv1TzPDteBzMOTqKBDqHtjsMQlIKLE1q+a.bp7BVISnhMZBZ 32jPa5WJk3RB7gX5FfMETSWuY34j.WBppxWD77j.qR6+3wG6i80URK7zRZ4S cCCn99DcFKjKDRBwgZV26Sd8EdZJSzj3Mc13UDpzkDSskC6Bu5tVIdt.lNAW Mf468vAXiJ7ENVo4Sql.J7ALHbH.Ebx.0zXYPRziGPYJS9bd49i7twftpHhf yMZi3aKHFZizL0HuSkE6Lmsku.10I1X6ue46QyEjZRXnA2YAD6NpTRw3yLG0 mHasFoH8GsuB0avO3jxRj2v70apDx8Ytemmxj4YwBsNR89jDom1vjdiIOcJS xoOOoJhEkOKKNr0nJRWxGT8.GjoLfOHXN5OgnYH.Eq0g4gvQgA5ft.zclD0Y 31tdB0pTDzCEKbtAZv.5aaqgbmwHkb+9L1nkLFLPWs+3rQe1.25XvBcTDq3h biVgDxrqRgwtgXpGBsAD38XF67M8xUgDnWV888oQQiOC8rkNCIjyZmgdgOlm FogO8BWjJeAjjw0abMQa.5NAOU9CQRO6QqWJ1DO+VXfsvGAY3XTWeJ0hig2p SIv95bx3h+9mBvZbl1+S.sTdrHoF.pOKRvaVUJqTwE1s92XPli3Gz1dlpMvT doIohE97Zcocn1Cc.liot4BYNHzPrGxhYOlC87xKWdKG9LH6Y4VuzJFzRztv x0xAO9C.cnOTfyxYM3gPcVtDOlCZ5hlCtKpC75aOCvbtTdmC7zboVW4oZClJ R5cbRPPWHkRCzJE05iw0ZhN27ay50yahF.2ajtCDhaX7n18IzM1mtxKQMscX Xqtz4luAtDBe8cIyuvzch0g7u9tCJ5tEDMjEmvEKg4fDNBWLyIXHouWzRsWT 1XzhYNQWAlyeWLg3RqOhOeeWBs5nGZDK7VyWLV.740+Z8uQ.Gt8I -----------end_max5_patcher-----------
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.
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:
@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.
Hope that helps.