|
|
1024_WaveformGenerator Hi, for the purpose of my own study - learning how to output a sorted NSDictionary for a custom plug - , i developed this tiny plugin that will generate waveform values, for use with KnM GLTools line structure. The plug is probably of no interest to anyone, as this can be done with a JS patch, however an obj-c plugin seems to perform much better than a JS patch. At least i learned something. note that sample comps are included in the archive. More info can be found here: http://1024d.wordpress.com/
|
and the vid:
neat construction all around - visualises input beautifully.
Very nice!
I was looking at a JavaScript implementation of something very like this a few days ago. Can't remember whose it was (someone on Kineme, though, I think)...
a|x
Its really nice, thanks for the sharing!
i cant check the plugin right now, but i presume you figured out how to output the sorted dictionary. Mind sharing how you did that?:) it would let me fix the simplex noise structure output.
for sure FSK. BTW, i'm using your simplex almost as an everyday basis. It's a life saver. Please share when complete... ;)
To get a sorted NSDictionary, i used this awesome NSDict. subclass by Matt Gallagher:
http://cocoawithlove.com/2008/12/ordereddictionary-subclassing-cocoa.html
brilliant implementation. The author is just adding a NSArray containing the index order. Simple and efficient. I banged my head a full day to do this myself - without results - and got it working with this source in less than 2 seconds... Internet spirit i love u.
it's a basic rewamp of one GLTools example. Don't remember either, but it should be smokris.
Nice one Franz. This really makes me wish I could learn Obj-C somehow. The speed advantage over JS is obvious. Everytime I go into the Apple introduction to Obj-C docs I think, #$%#$ I'd better at least learn C and understand */& methods in a strong way first!
ed.
This patch made me think of a feature request for GL LineStructure Patch: corners al la Ai (Illustrator).
I'm with you on Obj-C. Gotta do that myself as soon as I get a chance.
I think the above is something that could usefully be integrated into the mythical Vector/Bezier Tools patch we've all been talking about for years. Someone has to make it....
a|x
10.6 only? Arrrrrrrrghh... ;-)
Actually, I'm not sure how that would be useful, thinking about it. It would have to work essentially by adding extra points around corners. It would also have to do calculations to work out where to place those points, which would have a detrimental effect on the speed of the whole thing. Having said that, at the moment, it's structure-related speed issues that are the main factor slowing down how fast the GL Structure tools are able to work, isn't it?
a|x
this one should be ok for 10.5 - although untested
All good in 10.5 Thankyou Franz
10.5 on G5 is good!
Two things: a) Corners only become noticeable jaggy for me when structure length is fairly low, like <50 elements b) how to smooth corners. I thought about that too and I don't know how a graphics card or GLSL does it's thing so this is guessing: In Ai corners are usually in the 2D plane so smoothing is just adding a circular arc (like you said, adding points) or chamfering with a triangle fill.
Triangle fill would be a great add on it's own. Without alpha you could just draw a line the same width to cover the gap (perp to bisecting line). Adding alpha would require a triangle (a few minor trig operations) to avoid overlaps.
In 3D the easy way (concept only) would be draw a sphere same diameter as line width then union (logical OR operation) the pixels of line and sphere. But the drawing code/procedures of graphics cards may very well preclude that little interlude to it's rapid fire line rendering.
Also a core-image patch would access the OSX drawing methods (whatever replaced the old quickdraw toolbox) and the speeds would kind of depend on the underlying OSX Core-Image/Animation frameworks wouldn't they?
Something is because 3D apps can render a 3D scene and light it in real time and let you spin it around in a moment so lots of calculations going on there in a split second. So it's not the hardware or the shader language it's how it's implemented in QC. The rest of the story is where my ignorance begins!Cool, this is nice. What does the patch time do in this context?
This is a sorta similar thing that I use all of the time.
This isn't really possible directly with GL (unless you go the tessellation route @toneburst mentioned) --- GL is only really good for drawing triangles.
We've started work on the mythical vector kit, but that's still a ways off.
Until then, you could perform the expansion of line vectors into triangle geometry in Javascript --- for example, using the basic process described here: http://dminator.blogspot.com/2007/11/line-cap-calculation.html
Also, it seems like the idea topic of drawing non contiguous, distinct pieces of line came up recently, but I can't find the topic.
I've found that the easiest way to achieve that is to feed the structure a nan value. That can be hooked up automatically (like in the example I'm attaching), or by some kind of mouse control to switch the index.
(franz, not trying to get the thread OT, it's just that your plugin led me to thinking it may be useful to people to post these examples).
good find !
Time pin is for phasing. See attached example.
Just FYI, this is generally in programs drawing lines with corners shapes and options like that do not actually draw 'lines' using the GL primitive, but quads with textures on them to emulate stippling and other patterns. This is muuuccchhhh slower that just lines, since its 4x the number of verts, as wells textures lookups. Shrug, just saying. QC is really not ever going to perform as fast as a game engine or tuned dedicated graphics engine because of the nature of it being modular.
This modularity means programmers like myself and Kineme have to be super careful about touching, resetting and keeping GL state before and after our plugins run. This is slow. Good engines never need to do that, they know what is set when, and why, and optimize state changes to be as minimal as possible.
BTW, the same goes for Apples plugins.
From your experience, are there any particular guidelines to follow, in order to keep stuff out of panic ? QC wise of course.
I personally find openGL quite difficult to grasp.
Cheers, vade. I appreciate you taking the time to explain. Growing respect for QC plugin developers.
GT using structure transform patch
noice!
so patch_time input is null for this plugin AFAICT
Honestly its still a learning process for myself. Basically, the rule of thumb with "middleware" like plugins (its middle ware because you are in between whoevers plugin ran before, and who-evers plugin is running after yours) is that whenever you touch state, regardless of how stupid it seems, you cache the previous value with a glGetXXX and then reset it once you have finished.
Do that properly and consistently and you wont have issues. The catch is being disciplined enough to actually catch every change you make and to reset it.
i checked this out the other day and decided not to use it. it just seems like to much overhead. for now ill leave it like it is (so you have to use a structure index or key patch to get to the actual array with values). seems like less overhead. the solution for the for my plugin is to make two plugins instead of one (an extra one for structure output). i really wish the API had a way to make array structure output ports dynamically.
i still havent checked out this plugin since im rarely in SL and none of you plugins work on leopard. im curious why it needs the sorted dictionary. do you make the output port dynamically? if not, you can just define the property for the output port as an array and it will keep everything sorted.