A set of patches for drawing GL primitives and modifying the GL environment.
Source code is available on GitHub.
Credits
Logo by @usefuldesign.au.
Known issues
- The
GL Field of View
patch doesn't work properly on Mac OS 10.9 (it produces stretched output).
Thanks christopher ! Can you tell smorkis to modify the site to enable Good Bordeaux wine upload...:)
Yano.
i'm working on wine-uploading as we speak.
having a little trouble implementing the NSCoding protocol for the GoodBordeauxWine NSObject... when i unserialize it, it comes out kinda flat and lifeless.
ah well.
Yes i love partyzz with just tea.Earl Grey. Better for discuss about new features.
Is it normal that mapping is strange with a crop patch ?
Yano.
For even more fun, hook up an LFO to the Crop X parameter, and watch as it clips really strangely too. It's perfect at 0,0, and it drifts from there. Eventually, it starts clipping in the middle of the point too :)
looks like it's not handling the crop bounds properly.. not sure why that is, but I'll see what I can whip up.
Your test case compositions are the best, by the way :)
[EDIT: Ok, discovered the cause: Crop doesn't actually crop, it just gives the output a bounding rectangle. Texturing points doesn't honour the bounding offset because of how it generates texture coordinates (it takes the bounding width and height, and scales them from 0 to 1), but it does honour the size to generate the scale. I'm not certain if this is our bug (using the method incorrectly), or QC's. Filling in the texture's matrix doesn't seem to have any effect either (thanks Pierre, for all the useless methods and parameters :)]
This appears to be normal behaviour in a GL Point Sprite context; The textures used for point sprites don't seem to support manipulation very well (it only supports width and height clipping, not offset clipping). Crop doesn't actually do anything to the image other than change its width/height and x/y offset bounds, and expects the texture setter (QCOpenGLPort_Image setOnCGLContext:... and friends) to handle this correctly. It does when the texture environment is normal, but GL Point Sprites need a special texture environment, set with
glTexEnvf(GL_POINT_SPRITE, GL_COORD_REPLACE, GL_TRUE);
. This destroys the offset stuff, which gives the weird clip region.I've poked at various ways around this, and the only way seems to be to make an image from the image (without using crop)... I don't know if I should handle this internally, or make a separate patch for it (so that you know it's cooking what you feed it)...
Or maybe I have no idea what I'm talking about. I couldn't get The official API to use point sprites at all, using the exact same code...
Hi, 1- i've done a GLSL macro patch (shader) that displaces vertices according to an image, and if this seems to be working with apple 3d primitives (like GLSL grid), it is not working with Kineme GL prims, like GL quad. What's so special about Kineme GL prims ? 2- I'm using the Kineme Poly Mode macro to render prims wireframe, and if it is working with Kineme prims (which i CAN'T deform), it is not working with Apple prims (which i CAN deform) : it still renders the hidden edges. Any clues ?
Interesting cases; Can you provide a sample composition or two?
I'm thinking it has to do with the amount of geometry (GL Quad has only 4 vertexes, GLSL Grid can have several more), and perhaps the drawing method as well. I'll try to reverse engineer the glsl grid to see what we're doing differently.
[a quick inspection shows that glsl grid doesn't do anything magical... I wonder what's going on?]
[oops, spoke too soon. Lots of magic (vertex arrays and everything)... this'll be interesting...]
sample comp sent via mail
btw, i should be able to render wireframe via apple's GLSL shader, however, there's no main function where i could declare the Polymode... i must be missing something here...
Wow, this looks Really Bad (and it's not even our fault :)
plugging the movie into the Displacement input crashed immediately; Here's the backtrace:
I copied the pieces out of the PolyMode patch to make sure it wasn't something we're doing. None of those functions above is our code.
It crashes without any kineme stuff. It crashes in subtly different places each time, with subtly different values too:
[Note: They're using LLVM for on-the-fly translation/optimization perhaps?]
It looks good on the 1 in 100 tries that it works... unfortunately, this is Pierre's problem I guess :(
These symptoms look like Thread-unsafe code issues... kinda like Structure Tool's CIImage problem in Tiger... sigh
Polygon mode is a gl Call, so I don't know if it's available in GLSL...
There must be something rotten inside QC's code. See that #8 0x967ee768 in -[QCPatch(Private) _execute:arguments:] () where i don't use ANY private patch in the graph....
Honestly, QC 3.0 seems kewl on the surface, but each and everyday i face new unsolvable problems, related to DEEP bugs within the app.
But apart from that movie problem, i still can't display the regular GLSL grid with hidden edges removal using Kineme's poly mode... ;(
That notation is Objective-C for "Categories", extensions to existing classes.
I'm sorry if I don't understand, but what exactly are you looking for with "hidden edge removal" ? Back/Front face clipping? I had wireframe stuff working just fine, but maybe that's not what you're looking for...
And yes, some of the deep internal bugs are annoying... some of it even goes into the underlying frameworks (especially Core Image... fun buggy stuff in there)
I'm trying to display Quads instead of triangles. As i remember, it worked in the Kineme MeshTools beta (aka Kineme GLgrid ? ) where you coded an option to display only quads ( I'm also curious why you didn't implement the grid primitive in your GL set, as it was already coded... ? I thought you discontinued the grid as a specific patch to include it in the new set containing all the primitives) Sorry if i wasn't explicit enough.
Ok, I know what you mean now :)
hiding the triangles in polygon mode will be a bit difficult (it was easy in the mesh patch because I controlled the wireframe drawing, a luxury not easily available in polygon mode - there's possibly a way using glRenderMode, I'll experiment with that).
Do you think Mesh was developed enough to be useful for others? I didn't feel like it got to a point where it was useful (especially since there wasn't a good solution to the projected texture problem you struggled with). If you want, I can bundle it in the next beta :)
It might be usefull for other users as well, and since you already developped the primitive, why not bundle it in the next beta. (and keep the quad display... hehe ;)
So bad it couldn't make it to my latest project... (because of this texture prob. you mentioned. For info, i managed something but had to pre-render a lot of stuff to get some effect. a picture of it here: http://picasaweb.google.com/yannguegan/RennesEnTransSoirEDeVendredi/phot...