strimbob

i love the new max, but I have a problem and it is this

I'm trying to use jit.node with jit.camera and erase_color so the background does not get redraw, i have look at the camera.direct.feedback example but the workaround is not ideal for what i am doing.

here an example of what i mean, any help would be great

Hello
i love the new max, but I have a problem and it is this
I'm trying to use jit.node with jit.camera and erase_color so the background does not get redraw, i have look at the camera.direct.feedback example but the workaround is not ideal for what i am doing.

erase_color-help

Here's a way to get the feedback you're looking for with nodes and cameras:

When capturing with cameras and nodes, the alpha component doesn't do the smear-o-vision like it does when rendering to the window. I'll log this as a feature request. What you can do is use slabs to produce the background trails. You'll also have more control this way. Here I've used jit.gl.slab @co.accum.jxs which simulates jit.gl.render's erase_color smearing.

When capturing with cameras and nodes, the alpha component doesn't do the smear-o-vision like it does when rendering to the window.  I'll log this as a feature request.  What you can do is use slabs to produce the background trails.  You'll also have more control this way.  Here I've used jit.gl.slab @co.accum.jxs which simulates jit.gl.render's erase_color smearing.


Yes, I really hope that Cycling will provide an actual replacement for jit.gl.render alpha effects when doing render to texture capturing!

This example, similar to those that have been given at various times on the forum over the years, clearly illustrates the limitations of co.accum.jxs -- it is not possible to have a black background because the accumulation color eventually clips at white, even though the erase_color is explicitly set to 0 0 0 .

This example, similar to those that have been given at various times on the forum over the years, clearly illustrates the limitations of co.accum.jxs --  it is not possible to have a black background because the accumulation color eventually clips at white, even though the erase_color is explicitly set to 0 0 0 .


"This example, similar to those that have been given at various times on the forum over the years, clearly illustrates the limitations of co.accum.jxs -- it is not possible to have a black background because the accumulation color eventually clips at white, even though the erase_color is explicitly set to 0 0 0 ."

I'm sorry, but I really don't follow. The accum shader does exactly the same that as render's erase_color. Do you have a simple patch that shows the limitation you're talking about?

I'm sorry, but I really don't follow.  The accum shader does exactly the same that as render's erase_color.  Do you have a simple patch that shows the limitation you're talking about?


Opening the patch you posted on my computer, the background clips to white even though it is explicitly set to black. Looking more closely, this is probably due to the use of co.average.jxs?

Perhaps I've not understood something about how to use co.accum.jxs.

I've attached a patcher that hopefully illustrates what I'm talking about.

It has two examples, one using the built-in erase_color and one using co.accum.jxs. On my computer, the second window shows the ball clipping to white, while the first window shows the expected behavior.

The capture method relies on jit.gl.sketch, as I've not yet spent time looking at the new Max6 methods. Incidentally, in Max6 the first window (alpha1) displays strange motion artifacts. The same patcher in Max5 animates smoothly.

I'm on a new MacBook Pro 17", AMD Radeon HD 6750M 1024 MB.

Opening the patch you posted on my computer, the background clips to white even though it is explicitly set to black.  Looking more closely, this is probably due to the use of co.average.jxs?

Perhaps I've not understood something about how to use co.accum.jxs.  

I've attached a patcher that hopefully illustrates what I'm talking about.
It has two examples, one using the built-in erase_color and one using co.accum.jxs.  On my computer, the second window shows the ball clipping to white, while the first window shows the expected behavior.

The capture method relies on jit.gl.sketch, as I've not yet spent time looking at the new Max6 methods.  Incidentally, in Max6 the first window (alpha1) displays strange motion artifacts.  The same patcher in Max5 animates smoothly.

I'm on a new MacBook Pro 17", AMD Radeon HD 6750M 1024 MB.


Hi Wesley. Curious if you have any response?

Hi Wesley.  Curious if you have any response?


thanks for the response-) it is Jesse patch that illustrates the problem perfectly, it the freezing of the background witch i like with erase_color, but i am having fun with co.accum.jxs too now

thanks for the patch. I see what's happening. I'll look into this and get back later. I've been preoccupied with dev work, so your recent posts just slipped me by. The motion artifacts you've seen in the Beta have been fixed. If you see them for some reason in the release, please let us know.

Hi,
thanks for the patch. I see what's happening.  I'll look into this and get back later.  I've been preoccupied with dev work, so your recent posts just slipped me by.  The motion artifacts you've seen in the Beta have been fixed.  If you see them for some reason in the release, please let us know.


ok, so I figured it out. I didn't quite have the entire drawing/erasing process down correctly in the shader. Fortunately in Max6, jit.gl.texture has an @erase_color attribute, which is needed. To get this all to work, the texture needs to have an alpha of 0 when capturing starts. When you draw, the alpha component is then used to mix the new image with the previous one. If alpha is 1, it fully takes the new image. If 0, it fully takes the previous. This masking effect prevents saturation to white.

ok, so I figured it out.  I didn't quite have the entire drawing/erasing process down correctly in the shader.  Fortunately in Max6, jit.gl.texture has an @erase_color attribute, which is needed.  To get this all to work, the texture needs to have an alpha of 0 when capturing starts.  When you draw, the alpha component is then used to mix the new image with the previous one.  If alpha is 1, it fully takes the new image.  If 0, it fully takes the previous.  This masking effect prevents saturation to white.

One more thing, I've added this to Max6 as co.accum.erase.jxs. I didn't want to change co.accum.jxs because it will break existing patches. Besides the name still works. Use accum.erase with a jit.gl.texture @erase_color 0 0 0 0 for capturing to get jit.gl.render style erasure.

One more thing, I've added this to Max6 as co.accum.erase.jxs.  I didn't want to change co.accum.jxs because it will break existing patches.  Besides the name still works.  Use accum.erase with a jit.gl.texture @erase_color 0 0 0 0 for capturing to get jit.gl.render style erasure.


Thanks Wes, this is great. Very cool to see this working!

So in my reading of this, setting jit.gl.texture's @erase_color to 0 0 0 0 allows the alpha of the incoming captured raster to be passed through? In that case I gather this means that I no longer have to set glclearcolor in jit.gl.sketch?

One possible bug to report: I added a @color control to the patch so I could test the effects of manipulating the gridshape's alpha. This behaves as expected in the case of the @capture technique running through co.accum.erase.jxs. Interestingly, it does not work in the first case, using a straight ahead jit.gl.render path.

Thanks Wes, this is great.  Very cool to see this working!

So in my reading of this, setting jit.gl.texture's @erase_color to 0 0 0 0 allows the alpha of the incoming captured raster to be passed through?  In that case I gather this means that I no longer have to set glclearcolor in jit.gl.sketch?

One possible bug to report:  I added a @color control to the patch so I could test the effects of manipulating the gridshape's alpha.  This behaves as expected in the case of the @capture technique running through co.accum.erase.jxs.  Interestingly, it does not work in the first case, using a straight ahead jit.gl.render path.


It doesn't work in the patch you just posted because jit.gl.gridshape @blend_enable is 0. The reason it works in the accum.erase shader I posted is that the shader explicitly makes use of the gridshape's alpha while in your patch, the gl commands that take place ignore it.

Setting jit.gl.textures's @erase_color will cause the texture to be cleared to that color value when it starts capturing. In the specific case of the patch I posted, a value of 0 is used by the accum.erase shader to pass the previous frame. If your patch as setup differently, something else would happen.

It doesn't work in the patch you just posted because jit.gl.gridshape @blend_enable is 0.  The reason it works in the accum.erase shader I posted is that the shader explicitly makes use of the gridshape's alpha while in your patch, the gl commands that take place ignore it.

Setting jit.gl.textures's @erase_color will cause the texture to be cleared to that color value when it starts capturing.  In the specific case of the patch I posted, a value of 0 is used by the accum.erase shader to pass the previous frame.  If your patch as setup differently, something else would happen.


thank you!! i can get on converting my patches over now, i am happy about jit.gl.camera!!

I've read the above several times, yet I'm not grasping how to apply it to a simple processing of two textures via an accum.erase.jxs slab into a videoplane. I have exactly the same construct working with accum.jxs, just not accum.erase.jxs. Please see attached patcher.

I've struggled for a while trying to make this work with jit.gl.node in capture mode. Finally managed. Perhaps it will help someone else.

erase_color help