I am using Max 7.3.5. and the issue is that non-captured image looks much better for my taste than captured. When dept is not enabled, I can sort the issue using technique suggested here:

https://cycling74.com/forums/capture-problems-2

Now in this case I need the dept to stay enabled, because I am using triangle wireframe mesh and when I rotate 3D objects things looks too weird without depth enabled.

Is there any workaround to this problem? Or is this problem fixed in newer versions of Max?

Hi there,
I am using Max 7.3.5. and the issue is that non-captured image looks much better for my taste than captured. When dept is not enab

capture-and-depth-enable-problem

It seems like layers of lines are summed differently in both cases....

Captured.jpg

NON-Captured.jpg

I'm not sure I can help, but wow those are some very lovely looking meshes!

IIRC drawing fine lines requires both anti-aliasing and blending to work together nicely. Maybe these settings are different in your main window context and your capture context?

I tried what you suggested but unfortunately it doesn't help. Here is the patch that demonstrates the problem

In the patch you can toggle between capture and non-capture options. Also you can switch between two examples, one focusing on the whole shape while one focuses on individual lines. When you switch between capture/non-capture options the patch sets different alpha values on the object because captured version is roughly twice darker.

There are three problems (maybe all three derive from one technical issue):

- Layers of lines seems to be summed differently creating different white/grey areas on the object.

- Different brightness of captured and non-captured version

In the patch you can toggle between capture and non-capture options. Also you can switch between two examples, one focusing on the whole shape while one focuses on individual lines. When you switch between capture/non-capture options the patch sets different alpha values on the object because captured version is roughly twice darker.

There are three problems (maybe all three derive from one technical issue):

- Aliasing present in captured version.
- Layers of lines seems to be summed differently creating different white/grey areas on the object.
- Different brightness of captured and non-captured version

I remenber having some similar problems with capture.

It had to do with the way transparency (or aliasing) of objects is composited (summed) with the background of the captured node. there is no simple way around this behaviour and it is not really jitter related.

try bgcolor 0. 0. 0. 0. or 0.5 0.5 0.5 0. or 1.1.1.0. for the node background and you will see the difference. Yes even if they are all 3 totally transparent backgrounds (alpha 0.), the fact that the color component is different affects the compositing result.

Sometimes, with graphical overlays like yours, it's better to capture with 0.0.0.1. background (no transparency) and overlay it on your final scene as luminosity..

In your case, you could make a simple shader that just display a white image with the alpha being your captured lines.

I remenber having some similar problems with capture.
It had to do with the way transparency (or aliasing) of objects is composited (summed) with the background of the captured node. there is no simple way around this behaviour and it is not really jitter related.
try bgcolor 0. 0. 0. 0. or 0.5 0.5 0.5 0. or 1.1.1.0. for the node background and you will see the difference. Yes even if they are all 3 totally transparent backgrounds (alpha 0.), the fact that the color component is different affects the compositing result.

Sometimes, with graphical overlays like yours, it's better to capture with 0.0.0.1. background (no transparency) and overlay it on your final scene as luminosity..

In your case, you could make a simple shader that just display a white image with the alpha being your captured lines.


I tried setting different erase_color attributes on jit.gl.node (I guess you meant erase_color) but it changes the colour of the background despite alpha being set to 0. If I enable blend_enable also on videoplane then background stays black but the lines get coloured. Also enabling blend_enable on videoplane makes the visual result very different and not acceptable - very grey and mid tones based, not much dynamics in terms of bright and dark.

I am capturing with 0. 0. 0. 1. and it gives the best results but still problematic. Can you explain a bit more what you mean by "and overlay it on your final scene as luminosity.. In your case, you could make a simple shader that just display a white image with the alpha being your captured lines." because I am not a very techy person when it comes to visuals and I struggle to understand what you are suggesting.

Also these various erase_color options seem to not affect aliasing which is still emphasised in captured image.

I think it would be great if there would be some screencapture object in Max, which would function like jit.record but just taking screenshots. That would solve quite a few problems I have.

I am capturing with 0. 0. 0. 1. and it gives the best results but still problematic. Can you explain a bit more what you mean by "and overlay it on your final scene as luminosity..  In your case, you could make a simple shader that just display a white image with the alpha being your captured lines." because I am not a very techy person when it comes to visuals and I struggle to understand what you are suggesting.

I think it would be great if there would be some screencapture object in Max, which would function like jit.record but just taking screenshots. That would solve quite a few problems I have.  

I've just discovered jit.desktop which I never used before and it seems that object is the answer to my problems. So I would just like to ask how is it possible that jit.desktop can "capture" an openGL context as we see it into jit.matrix while openGL "capture objets" do not have that capability? Over the last few years that I am having problems with capturing I got an impression that "capturing" openGL context as we see it was simply impossible within Max and that the problem was not a Max problem but an openGL one.

Are there any plans to add GPU driven jit.desktop to Jitter in the future? Which I assume could function as jit.gl.node only avoiding aliasing/brightness/sizes problems that come with current capturing options.

the desktop grabber is an OS level process, separate and distinct from the opengl based drawing. there are no plans to implement this on the GPU at this time. some experimentation performed prior to max 8 revealed little performance gains from drawing directly to a gl-texture, as the bottleneck is the desktop grab process, not the output.

Capture and depth enable problem