This version of GL Tools contains several enhancements over version 0.3. There are both Leopard and Tiger Versions available.
- GL Logic Op Patch
- Faster GL Spline
- A Field of View patch (not the built-in one)
- Depth Buffer Alpha Threshold
- GL Points can now be attenuated by distance
GL Logic Op allows you to control which logic operation is used when drawing pixels to the frame buffer.
Depth Buffer Alpha Threshold allows you to disable writes to the depth buffer for transparent pixels. This helps when you have depth checking enabled and images with transparency.
GL Point attenuation doesn't work on Intel GMA950 Video cards (found in MacBooks and MacMinis). This is a driver bug; please file a bug report with Apple, not us :)
There was one report of invalid patch names for the Tiger build, but we've been unable to reproduce this after testing on several machines. If you experience this, please let us know; we're interested in solving this.
Thanks to all the beta testers for their testing, feedback, suggestions, and patience while 0.4 was in development. :)
Between the last beta and this production release, the only change was some interface text (consistent category names across tiger and leopard now), as well as a small fix to the Field of View patch to multiply against the previous matrix instead of simply overwriting it. This will hopefully ease some FOV + Matrix patch combination issues.
Attenuated GL Points.
Depth Buffer Alpha Threshold (on the left, normal on the right)
(composition for this can be found at http://kineme.net/Applications/Compositions/GLToolsSplineComposition)
Hello.
I have a reproducible VRam leak with the GLPoint patch.
I took a look at the source, but am unfamiliar with unofficial (skank?) SDK. Im running point inside of an iterator, and leak memory VERY fast. Inside of the iterator I am changing the point size, but nothing else. I have no input image, however, it definitely is a reproducible leak according GL monitor.
I also have not be able to reproduce with 100% certainty, but have had window server lockups when using the the spline patch inside of an iterator as well.
Just a heads up. 10.5.3, X1600.
can you post a composition that demonstrates this? GLPoint doesn't perform any allocations or GL allocations in the execute method, so it can't really leak.
[UPDATE: The GLPoint and GLSpline issue are due to ATI Errata, not due to a bug in GLTools code. Don't use these patches on those cards I guess... more GL Driver bugs :( ]
I've noticed some weird behaviour with the FOV patch inside other transformation patches (specifically, 3D Transformation and Trackball). This comes from the multiplication with the existing matrix (noted in the last paragraph of the notes above).
The only way around this that I've been able to discover is to put the Field of View patch outside of these patches. In other words, put the transformation patches inside the FOV for expected results.
If there are any mathematicians who know matrix math and know how to solve this, I'd love to hear the right way to solve this.
I have the .plugin file in both patches and plugins folder on my system library. What am i doing wrong?
Can you tell us the full path you're placing it in, and which version of OS X you're running?
If you're on Leopard (OS X 10.5), it should be one of the following:
/Library/Graphics/Quartz Composer Patches/
or~/Library/Graphics/Quartz Composer Patches/
If you're on Tiger (OS X 10.4), it should be in
/Library/Graphics/Patches/
If you place it in the Plug-Ins folder by accident on Leopard, you'll get some warnings in the console (Console.app), which lets you know that at least QC is seeing the file and trying to do something with it.
I am running leopard. and it is in the system/library/gfx/qcpatches
and in system/lib/gfx/qcpulgins and i get this error when i try to open a spline example.
These are only a few errors that i get. All the errors are based around not finding the plugin. Thanks
don't put them in /System/[anything] -- those are special patches (backdrop, others), and we don't test plugins there, nor do we recommend putting them there.
What happens if, when in /Lib.../qcplugins, you open a composition that uses some of these patches (there are a bunch scattered around the site). If they don't generate any warnings, and appear to work correctly, then it's loaded and working, and you're perhaps searching the patch creator in the wrong place (The category is "Kineme GL", not "Plug-In") or something.
[the other errors could be helpful too -- they sometimes indicate why it's getting confused, etc]
its working now thanks. but when i open a file example. the replicated spline file from one of the compositions posted here, none of my qc windows pop up. all i get is a blank inspector and no other windows. I have physically open the file through qc. or i get an error like this:
thanks for the quick help.
that's not happening anywhere in our code (we haven't made any image converters, and gltools doesn't do anything with images, except pass them on to opengl...). Maybe you should try the latest beta, and see if it goes away?
I've just been working with the Kineme GL Line Structure patch, and have noticed a couple of odd things:
The line seems to have quite a high minimum width. Even with low settings, it seems to remain quite chunky.
The alpha channel for the start and end colours seems to be ignored, even with the blending mode set to 'Over' (this is not the case for example, with the GL Point Structure patch).
Not sure if these are intended behaviours or not.
It would also be great to see some kind of antialiasing implemented for this patch, too (as it is with the builtin Line patch).
alx
Quartz Composer Blog: http://machinesdontcare.wordpress.com
Music Site: http://www.toneburst.net
blending is a known problem in current GLTools stuff - I think I know how to fix it, but I'm still experimenting to see what's happening exactly (it's glBlendFunc stuff).
The line width is probably wide because of different blend settings from the stock GLLine patch -- there are several known issues with "proper" AA line drawing in OpenGL...
These aren't intended; we're working on it :)
(For what it's worth, the structure patches as-is are likely to be abandoned in the near future, in favor of genuine spreads, once we solidify the setup/control for them... then it gets crazy :)
Thanks for the reply cwright.
Looking forward to a future release then.
I wonder, will the spreads functionality make it possible to create several discrete lines, each with several points? I'm currently achieving the same with JavaScript and an Iterator patch, but it's horrendously slow.
I'm really looking forward to all these 'Spreadable' patches. It'll make so many of the projects I've been working on so much easier. We still need a set of patches for generating the spreads structures though...
Wonder how toby is getting on with his structure tools.
alx
Quartz Composer Blog: http://machinesdontcare.wordpress.com
Music Site: http://www.toneburst.net
I Think it is the new killer kineme patch ! You know we are already there for crazy beta testing !...:)
I've just been working on this JavaScript code to generate a random spread of a given number of values, and output it as a struct. I'm not very good at JS though, so any comments or things I could do to improve it would be much appreciated.
Ultimately, this kind of thing should be done in a custom QC plugin, which I'm sure would work much faster, but for my porpoises, this should work for the moment.
If I ever get around to learning Obj-C/Cocoa, a set of spreads plugins are first on my list, if someone else doesn't beat me to it ;)
a|x
Incidentally, I've noticed that if you stick code containing '<' and '>' characters inside code tags, it gets confused, so I've been using the preformatted tag.
a|x
Do y'all want spreads to be structures? I was under the impression that were were going to abandon QC objects all together, and pass around C Arrays for spreads (creating a new port that handles this kind of data). The reason for this would be to avoid the not-in-order stuff that sometimes happens with structures, and to handle lots of data really really quickly (no method overhead per item, which is usually cheap for small sets, but gets expensive for larger one)...
thoughts?
(Mind you, these JS patches are still handy as an intermediate solution)
Anything fast would be priority for me. Faster = more elements = more stuff + better fx. Something that gets around the 'random order' stuff would be great too.
Would it be possible to have a spread to structure patch to keep compatibility though? Not sure if that would be necessary, if there's equivalents to the 'index/key member' patches, but perhaps there would still be cases where javascript would be handy.
Those were my thoughts too -- message overhead on a per-element basis will make structure 3-6x slower best-case.
It would be possible to "structureize" and "destructureize" a non-structure spread, but then you're going to get a nasty speed hit (the composition is only as fast as its slowest part, and if you shove a million element structure through some per-element processing, it's going to suck no matter how fast everything else is :)
The performance hit wouldn't matter much for doing some processing on the spread where the rendering isn't dependent on it.
E.g. I sometimes process a ton of stuff when the composition loads, and hide it with a loading screen. Other times (like with the slitscan stuff I had so much trouble with) I have 2 parts to the composition, one doing the back-end data processing, the other doing the rendering. The back end might only churn out 1fps, but the front end continues running on old data at 60fps. (Great in some cases, but a real pain in the arse to get around in others, like the slit scanner!)
If having a new data type is a faster way of doing it, that's cool. The advantage of using Structures now of course, is that you can use Iterators (though ultimately we're trying to do away with them).
This is definitely an interim solution.
My intention is to test the 'pseudospreads' compositions with an Iterator, and all the per-instance variables being calculated outside the Iterator by JS, and see if this speeds the whole thing up to the frame-rate I was getting by using 128 individual macros instead of an Iterator in my previous tests.
a|x
To remedy this problem, I installed a syntax-highlighting filter for drupal. You can now use [blockcode] or, say, [javascript] to delineate code blocks, and it'll highlight syntax and automatically handle angle-brackets. More details are available in the "Input Format" section on every compose/reply page.
Cool. That's much better smokris.
a|x