I think Rob Ramirez posted this either in the forums or facebook group, but I can't seem to locate it. Anyways I don't think there's a need for a videoplane or node. You can render the mesh directly to the window and use [jit.world @output_texture 1] to send directly to a syphonserver. Using the "sendnode" message, you can change the resolution of the jit.world's output_texture.

hi LSJ, i think greg's solution is more or less what you're already doing.

you can achieve this with two capturing jit.gl.camera objects. set the first to @adapt 0 and the dims of your syphon output, and the second can adapt to your render context window:

oh nice, your example gives the ability to have different aspect ratios. pretty useful.

Thanks all! This is some really helpful input...

There are still 2 unsolved mysteries...

1) Does jit.world support a "pwindow" mode - where the preview is not a window but is embedded in your presentation layer? Or would I have to just do old-school qmetro->jit.render->jit.pwindow? 2) It seems that jit.gl.syphonserver (or client) is inverting the Y axis (or the viewport is inverted). In my previous method, I was able to invert the jit.gl.videoplane Y axis using a -1 for Y scale to get the two objects to match up - however, it doesn't seem that the jit.gl.camera object supports changing of the scale parameter. Is there any way to normalize the view of both objects so they match? Here is a simple patch which shows what I mean about inverted Y axis. (I am viewing the syphon output with the Simple Syphon Client - it might be the one doing the viewport inversion).

1) no. yes.

2) yeah this happens in certain situations. simply send the output through a jit.gl.texture or jit.gl.slab between the jit.gl.camera and the syphonserver

Thanks Rob!

Adding a jit.gl.slab between the jit.gl.camera and syphonserver did the trick. I didn't even have to adjust any of the scale parameters. Is there a reason that would help me understand why this magically fixed the viewport discrepancy?

Slightly OT - The flowchart at the beginning of this post makes me think that a flowchart/anatomy-style chart visually describing the hierarchies of various Jitter objects would be extremely useful to people learning " Jitter - The Big Picture " (me : )

Sort of a "Knee bone connects to the thigh bone, but only if you do this first" with a little bit of "and here's why" added in.

I think the word "pipeline" was used above...

Has anybody made up such a thing?

curious jd

I haven't seen anything online and I have tried to read everything I could find - I had to make something like that to help me understand the flow as the use of named contexts was really confusing me. I think the Max documentation does a really good job of providing lots of examples - and provides good docs on the properties of each object - but the "Big Picture" of what is going on is not very well represented.

One thing I have found to help, especially with the jitter pipeline - is to use patch chords instead of named contexts / symbols. They may clutter up your patch a bit, but it is much easier to follow a signal flow .

In the patch I posted above, I have laid out things in a relatively top to bottom, left to right flow. One of the confusing things I am still unsure of is the fact the jit.gl.node object seems to use it's output node as both an input and an output. I.e., you connect it to the "input" of an OpenGL 3D object. This seems to kinda break the whole top=in bottom=out paradigm of objects. Also what is not very well represented visually is the difference between plain jitter matrices and the pipeline once things have been converted to the OpenGl realm. So everything going into the jit.gl.mesh object are standard jitter matrices - however, everything after the jit.gl.mesh seems to be a new type of object - a 3D OpenGl object - I am not sure if this has a specific name. It would be helpful if these had a different graphical representation - kinda like how jitter matrix patch chords look different than just plain patch chords. The output of the jit.gl.camera (an OpenGl texture object) does use a differently colored patch chord - but the connection between OpenGl 3D objects don't.

Hey Rob, not sure if you are still monitoring this thread, but one thing I noticed I could do is connect the output of the jit.world object directly to a jit.pwindow - and turn on either output_texture or output_matrix for the jit.world. Here in lies the question... Is there a fundamental difference between the two in this context? They visually look and behave the same, but I am not sure that means they are doing the same thing.

they are fundamentally the same thing. when a jit.pwindow receives a texture, it coverts to a matrix internally.

in both cases you are doing a matrix readback from the GPU. this is fine for situations where it's necessary, however if all you want is a preview window, this readback is unnecessary and can impact framerate. much better to create a shared context preview window, as explained here: https://cycling74.com/wiki/index.php?title=OpenGL_Preview_Window

Well, I think I have finally arrived at getting the results I was originally looking for - but I am still not sure I have figured out the best way to replace the jit.world with a jit.pwindow using the jit.gl.camera @capture solution. I did notice that using the output_texture method resulted in a reduced framerate / quality solution - it just did not feel smooth.

In this latest attempt I have the jit.gl.camera being sent to jit.gl.videoplane that is part of the jit.gl.render->jit.pwindow context). This is what I ended up getting to work tonight... it is still using a jit.gl.videoplane to render to the jit.pwindow - and I am still confused if this is necessary - but I couldn't figure out any other way - though, a lot of my effort is trial-and-error and still not yet based on fundamental understandings... Here is my latest patch - two output destinations - 1 is a jit.pwindow - 2 is jit.gl.syphon. Independent resolution renderings / capture - framerate is awesome - and no down-sampling I can see...