Difference between rendering to window or matrix
Hello,
I am making a patch which composes two different matrixes on top of each other, keeping the alpha intact. I am currently doing this with 2 jit.gl.videoplanes because I need to be able to rotate, scale and move them dynamically. I need to render this to a matrix so I can then export the resulting matrix. There is already a fullscreen window showing other things and I don't want to create an extra window just for this.
But the problem is that the result looks different in a matrix (or jit.pwindow) or a window. The window renders the desired effect (the right layer order and alpha) but rendering to a matrix creates a different composition somehow. What is the difference to rendering to matrix or window? I am using Max 5.1.3 and OS X.
I created a sample patch which does the same thing twice, only once rendering to a window and once to a pwindow. Load to images and use the bang button. It is best to load a PNG with alpha transparency on the first read.
I think you should try to capture to a texture, then bang that texture to output to a matrix. An example of this can be found in the examples folder of the Max directory.
If you're only using the matrix to record your video, I'd recommend using a screen capturing tool instead. IshowU is a good one for Mac. It's quite fast, and saves you the hassle of rendering twice.
Hoi Bas,
I am not capturing the screen, I am composing two images with run-time generating rotations etc and saving the resulting image to disk.
The thing I don't understand why the same path renders differently to a window than to a matrix. Apparently there is a very big difference between the hardware and software renderer as you can see in the example. I would expect them to work the same. Strange.
>>Hoi Bas,
>>
>>I am not capturing the screen, I am composing two images with run-time >>generating rotations etc and saving the resulting image to disk.
Could you explain the difference in output between the two? Either you get it from a screen capture, or from a render to a matrix, which you then save. Same difference?
Oh and yes, there definitely are some differences between hardware and software rendering. Theoretically, there shouldn't be, software could even process a lot more complicated things, but at a much slower speed, so generally, a lot of things are left out in software rendering, making it look far worse.
A few things about the software renderer.
1. it is slow. I can also recommend rendering using hardware, rendering to texture and reading back to a jit.matrix. Rendering to texture typically voids using multi-sampling, so you may wish to render at double resolution and then perform an averaging downsample in software for FSAA.
2. The windows software renderer is less feature complete than Apple's. With the apple software renderer under earlier versions of OS X, you can also get better results if you set the @quality 1 attribute of the jit.gl.render object.
3. Some of what you describe sounds like it is perhaps related to not using depth buffering. You need to be sure that @depth_enable 1 is set on your jit.gl.render object (which it should be by default)
Here a screenshot of the differences, both methods are completely the same, but one renders to a pwindow and the other to a window. Both renderers have @depth_enable 1 (in the inspector)
The window output is correct: an image with another image in top with alpha blending. In the pwindow, you only seem to see the bottom of the 2 images (the one that is rendered first) and the second seems to be ignored.
Any ideas why? It seems to me this is all quite straightforward and there shouldn't be such a great distance.
Or is there a better way to do this overlaying thing to save to a disk? The bottom image should be rotated and moved and scaled according to runtime variables. I was planning on doing this by rotating the jit.gl.videoplane.
Hey, I just found out that if I set the depth_clear to 1 in the inspector of the pwindow renderer it starts working.
But I can only set this attribute by freezing it in the inspector. Adding @depth_clear 1 to the object doesn't seem to stick.