Nathan Wolek

I am working on a customized projection mapping solution and having issues with what I perceive as under-scanning or over-scanning of the image when the video re-emerges from the OpenGL world. I tried the pull out the essential elements in the included patch. My question is: why don't the two jit.pwindow images match?

Admittedly, I don't use Jitter nearly as much as I do Max and MSP stuff, so it is entirely possible that I missing something or misunderstanding. I have been through included tutorials, as well as some helpful online stuff by Andrew Benson and Sam Tarakajian, but nothing is leading me to a solution on this.

Patch follows my signature. I am attaching the test image as well as a screenshot.

Patch follows my signature. I am attaching the test image as well as a screenshot.
-Nathan


jitter-overunder-scanning-of-gl-render

    "version" : "Version 6.1.6 (307fb20)",

    "osversion" : "Mac OS X Version 10.9.4 x86_64",

    "scheduler_in_audio_interrupt" : "on",

    "audio_drivername" : "Core Audio",

And for those to whom this matters:
{
	"version" : "Version 6.1.6 (307fb20)",
	"platform" : "mac",
	"arch" : "x86",
	"osversion" : "Mac OS X Version 10.9.4 x86_64",
	"samplerate" : 44100,
	"iovs" : 512,
	"sigvs" : 64,
	"scheduler_in_audio_interrupt" : "on",
	"audio_drivername" : "Core Audio",
	"audio_driver_subname" : "",
	"eventinterval" : 2,
	"overdrive" : "on",
	"mixerparallel" : "off",
	"mixercrossfade" : 0,
	"mixerlatency" : 30.0,
	"mixerramptime" : 10.0
}


Add @transform_reset 2 to the jit.gl.videoplane and it should match.

Thanks! Boy was that setting buried. It seems to work on the jit.gl.render too.

The distortion is gone, but I am losing the resolution of my test grid (see new attachment). Any ideas on why that is happening?

I don't know why that's happening, but it may have more to do with the small jit.pwindow than with the jit.gl.videoplane - try using a jit.window instead & making it big or full screen and see if the problem is still there.

Apparently you're supposed to set the jit.gl.videoplane's dest_dim to fit the window. See 

 thread. But I couldn't see any difference, no matter what I set it to.

One thing you're doing that isn't helping at all is the "dim 1400 1050" on the jit.gl.videoplane - dim refers to the resolution of the underlying geometry, not the pixel resolution, and it slows the frame rate to a crawl, at least on my macbook. You'll get exactly the same results with the default (dim 20 20) - and your frame rate will be much better.

I don't know why that's happening, but it may have more to do with the small jit.pwindow than with the jit.gl.videoplane - try using a jit.window instead & making it big or full screen and see if the problem is still there. 

Apparently you're supposed to set the jit.gl.videoplane's dest_dim to fit the window. See this thread. But I couldn't see any difference, no matter what I set it to.

One thing you're doing that isn't helping at all is the "dim 1400 1050" on the jit.gl.videoplane - dim refers to the resolution of the underlying geometry, not the pixel resolution, and it slows the frame rate to a crawl, at least on my macbook. You'll get exactly the same results with the default (dim 20 20) - and your frame rate will be much better.


Perhaps turning off the filter in jit.gl.texture helps.

attach the needed align PNG file and I'll take a look.

Thanks everyone for weighing in! Thankful to be making progress with this finally after several hours not understanding what was going on.

@diablodale - it's actually one of the two images attached to the original post, but attaching it here again. I customized it to the eventual output dimensions using Processing.

@pedro - so you are adding that object to drop the filter, right?

@pseudostereo - is there a good resource to explain the differences between size, dim, dim_rect, dest_dim, etc?

dest_dim is a common attribute for all gl objects, and indicates the width and height in pixels of the current drawing destination. it is read-only.

the size attribute of jit.window and jit.pwindow corresponds to the @dest_dim attribute.

srcrect and destrect should be ignored if the p/window is a gl drawing destination. they are only applicable to matrix input.

dim means different things for gl objects, depending on if the object is texture based or not.

for all texture based objects (gl.texture, gl.slab, gl.node, gl.camera) the dim is the pixel dimensions of its internal gl-texture. by default, gl.slab and gl.texture will adapt its dim to the dim of the matrix or texture input. by default gl.node and gl.camera will adapt to the dimensions of its drawing destination (dest_dim). disabling @adapt will allow you to explicitly set dimensions on these objects, otherwise the dim attribute is read-only.

for all other gl objects, dim represents the dimensions of the geometry matrix used to create its vertex-mesh.

for something like gl.videoplane, the @dim really only needs to be 2x2 (defining the four corners of the videoplane).

gl.videoplane is unique in that it is a geometry object, but also contains an internal texture object that allows for jit_matrix input to be used as a gl-texture for its geometry. therefore, there is a "sendtexture" message that allows you to control the properties of that internal texture. in your case, you want to prepend "sendtexture" to the messages "adapt 0" and "dim 280 210" in order to size the texture exactly to match the dimensions of your drawing destination, and get the expected results.

the size attribute of jit.window and jit.pwindow corresponds to the @dest_dim attribute.
srcrect and destrect should be ignored if the p/window is a gl drawing destination. they are only applicable to matrix input.

for all other gl objects, dim represents the dimensions of the geometry matrix used to create its vertex-mesh.
for something like gl.videoplane, the @dim really only needs to be 2x2 (defining the four corners of the videoplane).

gl.videoplane is unique in that it is a geometry object, but also contains an internal texture object that allows for jit_matrix input to be used as a gl-texture for its geometry. therefore, there is a "sendtexture" message that allows you to control the properties of that internal texture. in your case, you want to prepend "sendtexture" to the messages "adapt 0" and "dim 280 210" in order to size the texture exactly to match the dimensions of your drawing destination, and get the expected results.


@Rob - So would the same "sendtexture" apply to jit.gl.nurbs? I don't see a "sendtexture" message in that documentation. That's where I am eventually going with this, since we are eventually projecting onto a non-flat surface.

no, gl.nurbs is a standard geometry object and doesn't contain an internal texture to handle matrix input (i.e. you can't send a matrix into gl.nurbs and expect it to show up as the object's texture).

you texture gl.nurbs the same way you texture all other standard gl objects, by setting its texture attribute to a named texture, or by sending a jit_gl_texture output to its input. make sure you set its color attribute to all white (1 1 1 1), otherwise the texture will show up darker.

Thanks to all for the help! Patch is working much better now and I can better understand what is going on. Pasting below in case others want to check it out. It is essentially one channel of an eventual four projector setup.

Jitter over/under-scanning of GL render