hi wetterberg.

the cornerpin object handles gl textures exactly the same way as matrices. simply send a texture to the object or set it's @texture attribute to a named texture.

the object functions similarly to gl.videoplane.

jit.gl.cornerpin is the cat's pajamas (or it would be if cats had sharp corners)

I notice that it can be positioned, but not scaled or rotated - and changing jit.gl.render's camera doesn't affect it - so I guess it's very much a 2D thing (unlike jit.gl.videoplane)

well wasn't i just in need of software keystone correction :)

yeah, I know it's very similar to videoplane, what I am asking is:

Is there a way for me to transform my gl scene in this way without having to render the whole damned thing into a texture?

I am trying to project my gl objects - mainly meshes - for the same type of distortion - without having to capture teh whole thing to texture.

My hope was that since this was jit.GL I would be able to distort gl like this. I dunno if I'm wording things right here, I'm sorry.

@pseudostereo - yes 2D only, so not entirely like gl.videoplane :)

@wetterberg - nope, you need to render your scene to a texture. fortunately, this process is greatly simplified with the gl.node object. simply drop a gl.node in your patch with it's name attribute set to your current render context name, rename your render context to something new (only for your gl.render and your jit.window objects), set @capture 1 on your gl.node, and you're done.

Hey guys,

Where can I find this [jit.gl.cornerpin] object?

Thank you!

@robert Shame. I'll see if I can come up with something by squeezing my matrix before it reaches the jit.gl.mesh and then leaving everything else as-is.

Either way I'll try it out with jit.gl.node. The problem there is that jit.gl.cornerpin will always be used in live situations like this. But who knows, I may get lucky! :)

@ygreq: it's a new object in 6.0.4

one thing i forgot to mention, in case it isn't obvious, the gl.cornerpin should drawto the gl.render context, not the gl.node context.

"in case it isn't obvious." you havin' a laugh? Okay, I'm officially lost here.

I have *six* objects to deal with, and the naming isn't at all obvious to me right now:

jit.gl.render jit.window jit.gl.node jit.gl.cornerpin jit.gl.mesh jit.gl.texture

now (let me try to talk my way through this)

jit.gl.texture should share a context name with jit.gl.mesh. jit.gl.mesh normally renders to jit.gl.render. Now what we want to do is intercept this, run it through jit.gl.node, send it to jit.gl.cornerpin, which then sends it to jit.gl.render, forwarding it to jit.window. yes? No? Am I close?

I'm sorry, but I hope you can see how the layperson is completely confused by this? :)

The naming there is totally beyond me; the jit.gl.cornerpin helpfile has no naming at all, and the jit.gl.node in its helpfile has one name and a different context...?

I just did the math though, and I can't trial and error this, there's way too many combinations, as far as I can tell.

Please help me out here. Cheers, a.

How about this?

DiGiTaLFX :)

beautiful - sums up all the different parts rather nicely! Thanks, I got it working thanks to you and Robert. This is ace - and oh my, I can feel it's been some years since I've rendered to textures, this is blazingly fast!

Two questions: 1) If I were to do some shader work (attempt) to mess with this, it would be in-between jit.gl.node and jit.gl.cornerpin, correct?

2) More importantly, there seems to be something amiss here: without me changing anything but the aforementioned parameters my navigation (space navigator, very close to examples done here, it's done with jit.anim) is now *upside-down*, as if my image has been flipped somehow.

Does anyone know what could have caused this?

Fab! Glad it makes sense now :)

1) Correct!

2) Ah yes! Seems that when sending a texture to the cornerpin it's inverted. Easiest fix for now is to put the following slab between the Node and the Cornerpin to invert the image:

[jit.gl.slab output @rect 0. 1. 1. 0.]

I think this is something the Cycling folks need to fix?

DiGiTaLFX

hey, I actually found a bug? That's cool :)

cheers mate - any suggestions for slab effects?

Try the following to add a bit of a glow to your scene:

And the sobel shader can be quite cool:

ah yeah, I remember now: v001.scanlines -> gauss == loveliness. And if you do individual control of the two width axes of gauss then you can do this rotating, swirly nonsense that looks really... what's the word? J.J.Abrams'ey? :) Good stuff.

thanks for inspiring me!

hey guys, thanks for pointing out the bug and coming up with a temp workaround. my apologies for letting this slip in there. we'll get it fixed up for the next update.

When i use the mouse to set the corner pins: How would i save and restore the locations of the pins?

hi karl kliem. the mouse is simply setting the object's corner attributes (upper_left, upper_right, etc), so you save and recall the same as you would any jitter attribute. freezing the attributes in the inspector is probably the easiest way to save a current state.

hi robert,

thanks for the suggestion. however, i need to provide an easy user interface for a non-technician to set up the projection mapping of several canvases right before the concerts. it would be great if jit.gl.cornerpin could output the cornerpin locations out of the dump outlet, so i could automate saving the values.

+1 for dump output (or attrui saving which would do the trick as well)

Hi Karl

How about this?

DiGiTaLFX

thanks! i checked the reference and the wheel menu, but these messages are not mentioned. how did you find out?

@digitalfx: cheers man!

does this get* business apply to all jit parameters/objects?

here's a way of storing and recalling with pattrstorage and preset

yes, all jitter attributes can be recalled this way. take a look at the documentation on attributes if you need more info: https://cycling74.com/docs/max6/dynamic/c74_docs.html#jitterwhatareattributes

Thanks for this object! I've been wanting something just like this for years. Could be accomplished before but so much easier now. And .gl!!!!

You can attach a pattr object to any Jitter attribute as well, as long as the object has a scripting name. See the attached. This allows you to easily set up a pattrstorage object to save state.

i see, nice!

just starting to learn the pattr family here. about time after all those years...

Ha! I would have loved to have been able to work this on friday - When you start getting into animating with jit.anim.drive and moving objects, sometimes "moveto" gets a bit hairy, since you don't really know the absolute position - I do now, I guess :)

Ah, I never knew that! How come the following doesn't work then?

Is there any way of setting the uvs for the plane?

one year later... with the camera

Hello,

How can I have a black background with jit.gl.cornerpin? Mine is grey, not very useful for mapping!

Thank you in advance,

Jacques Hoepffner

Hello Hoepffner, you can use the @erase_color attribute in the main [jit.gl.render] to set the window background color, and use the same attribute in a [jit.gl.camera] object to assign the cornerpin's background a different color.

I wish jit.gl.cornerpin could output to other destinations than jit.gl.render. I have this multidisplay rendering setup where 1 output window spans all 4 displays. I can use cornerpin as long as my corners stay inside their respective display portion (ie. scaling down the texture). But if I scale up instead of down textures start overlapping with the adjacent display's portion.

I'd like to use something cornerpin-like to compensate for projector tilt without using the projectors keystone correction. I tilt heavily and keystone then shrinks the image a lot, making inefficient use of the available pixels and light output.

Below 's my rendering setup. The node contains the geometry to be rendered. 4 camera's render views from 4 positions. Texture goes through a couple of slabs, into 4 videoplanes positioned to match the 4 display outputs.

Any ideas on how I could implement cornerpin-like adjustments that allow me to stretch the textures outside their display portion?

you could always capture cornerpin to a texture with gl.node, and then send to another cornerpin. or am i missing something?

Ah that's fantastic! I miss-interpreted your phrase above: "the gl.cornerpin should drawto the gl.render context, not the gl.node context". Tanx.

I had trouble getting the mapping I need because cornerpin distorts the texture in ways that don't work in my situation. I need to move the corners only horizontally, which also introduces a vertical distortion in the texture. That messes up things for me.

I managed to get the correction I need by setting frustum on the camera and sending the texture into a jit.gl.nurbs plane that I deform. Here the texture only morphs horizontally when the corners move horizontally. Great.

Now the issue is again that the nurbs corners extend out of their display area. Any tips as how to I could clip the nurbs planes to a ceratin portion of my output window?

again, i would say capture the nurbs to a gl.node texture (make sure you set the gl.node @adapt 0 and dims to the individual display dims). this should handle clipping of geometry extending beyond the display area.

Great, that works. Tanx!

In case anyone needs something like that, here's a patch:

This clips the rendering to the left half of a 640x240 window. Substitute the cornerpin for your geometry.

just had a little play with corner pin and my projector. I am guessing from looking around the object that it wont do more than 4 pins?

Cheers Ned

no, just the 4 corners. however you can do something like perform your major warping with the cornerpin, capture that to a texture, and then perform fine-tune warping using gl.mesh or gl.nurbs.

this patch uses an awesome nurbs-phys.multiple patch posted by user matmat to do warping.

note that capturing a cornerpin to a gl.node context disables the mouse interaction. this should be fixed in a future update.

I don't know if I missed it somewhere in this thread, but I'm having trouble applying the cornerpin to a blended context, and I'm not sure what I'm missing.

Originally, I had two [jit.gl.videoplanes context @depth_enable 0 @blend_enable 1 @blend_mode 1 1]. They were overlaying properly. Now I'm trying to name them "wholecontext", then use [jit.gl.node context @capture 1 @name wholecontext] and pass that to [jit.gl.cornerpin context]. I'm just getting a white screen. I'm rendering [jit.gl.renderer context].

I don't think I'm pointing this properly, but not understanding why. I also suspect that I shouldn't use videoplane this way.

Thanks

I just tested using matrices with the above naming context and it works fine. The only difference I can see is that I'm playing HAP.

please post your patch

Here's what I'm trying to do.

Here's a better example of what I'm facing. There are two patches here. "hap cornerpin test 2b" shows how the planes blend with no problem. "hap cornerpin 2" shows how adding the HAP Alpha movie makes it go white.

You need to add the "blend" argument to the jit.gl.hap object. That's part of the set of objects you are rendering in the node context.

@Jesse - As in [jit.gl.hap @blend 1]? That doesn't seem to take. I also don't see that argument in the reference.

Oh, you mean name the hap object context "blend", as in [jit.gl.hap blend]. Is that right? That doesn't seem to help either, unfortunately. Maybe I'm misunderstanding you. The videoplane is also named in the blend context.

Works fine here.

Yep! Got it going on my end too. Thanks, Jesse!

nurbs-phys.multiple patch posted by user matmat and Ramirez is great but I can't solve how to save the position of the points. how can I get out the numbers to let me save them with presets/pattr? any idea? armonico

you simply need to write the matrix of control points to save, and then read in the matrix file to restore.

Beautiful! This helps me a lot! Really thank you.

Is there a way to save the cornerpin settings when rendered through a jit.world?

you can do something like the following, or just use an external jit.gl.cornerpin