How does proximity work for particles? (I'm not very experienced with particle systems) Is it like 'boids', or 'flocking' behaviour?
Can you fill in some more details, like the input parameters, and how they would affect the system? We've had some particle stuff on the back-burner for a while.... maybe we should think about dusting it off in the near future? :)
It's quite ok :) I ask these kinds of questions even to native English speakers, because I'm not very good at translating word descriptions into program code without lots of questions :/
How were you thinking proximity would work?
When I mentioned "boids", I mean stuff like this: http://www.red3d.com/cwr/boids/ (I guess the word they use for proximity is kind of like "Separation" and "Cohesion")
I think this may be possible with existing patches (there's a SMS patch built in as a private patch, and Google made one too I think). Some Javascript (or, the upcoming Paython patch ;) to do the physics simulation and you're in business.
It's a private patch in Leopard called "TiltSensor". I've used it for a couple compositions so you could "inspect" a 3d object by tilting the laptop around. :)
I understood what you meant :). I was just saying that you could use the TiltPatch for the tilt input (which is what liquidmac does), and use Javascript to do the physics (collision, gravity, etc) simulation. The JS patch would take the tilt patch's input, do some work on the points, and then output to an iterator of points or sprites or whatever. Probably a lot of code (I don't know how complex liquidmac can get), but I think it can be done without any additional custom patches.
Doing complex math on a large array of points sounds like something that would be dreadfully slow in javascript (and thus necessitating a custom patch).
I put together a little test.. Generating 2,000 points (using very simple math) into a structure in javascript and then iterating through these points and drawing GL Points goes about 8fps on my MBP (and even if i disable the GL Points patch, it only runs at about 12fps).
IIRC the the optimized C code from VEE which I used a year ago for the firesim project easily handled 20,000 points at 60fps on a slightly less powerful machine.
For any nontrivial particle work, optimized/compiled code is still necessary I think (however your Python patch, with its integrated OpenGL bindings, may actually be usable for this, too, since you can avoid the whole QC Iterator patch behemoth).
Good example, thanks steve. I was hoping that the javascript engine did some kind of bytecode/on-the-fly compilation, but if it does it's horribly slow (as demonstrated). Even CSE'ing and pulling the object allocation out of the loop didn't appreciably boost performance on my machine. sigh.
I've not done any profiling with the python patch yet, but It has distinct parse/compile steps, so I'm hoping that it holds up slightly better. I'll try to whip up an example just to see what we have to work with.
(VEE's 3 years stale. PyOpenGL is 3 years stale too, but works with the existing python patch. Pyglet (another opengl implementation in python) is actively maintained, but doesn't work because it apparently does more strict state checking (which, as a side effect, also issues 1 additional branch per gl function call even in "correct" environments. probably not measurable, but man...). why aren't useful libraries maintained?!)
I spent some time today working on a "superiterator" patch that would be a light-weight (read: much faster) iterator patch (green iterator would be a part of this too). However, I discovered some problems with graph evaluation when executing subpatches multiple times, and decided to inspect the existing iterators to find out what they do to work around this.
Strangely, there isn't much going on in either the iterator variables or the iterator itself -- a simple for-loop (which is what I would have expected). This is much simpler than performance indicates, so I'm going to abandon the superiterator for now (it couldn't possibly be faster than the current one), and instead try to figure out what's happening behind the scenes to make this so slow... Very much not what I expected. I'm guessing now that it has something to do with QC graph re-evaluation/invalidation -- not sure how fixable this sort of thing is from a plugin.
On second thought, I think I'm just going to focus on spread ports....
What about the posibility to do the maths outside iterators then pass values thru a structure...a sort of "instance iterator variable
patch" that can distribute index, current position, etc...but outside his parent iterator...do you think it should give gain performance ?
i don't know for performance, but processing all the data outside the iterator, concat into a structure, then feed into the iterator is the only way i know .... and it is very tedious.
Seems we're all longing for the KNM supa-iterator...
Given the nightmares I encountered when working with a large/diverse GL rendering pipeline on the firesim project, GL sanity checks are immensely valuable, so I wouldn't want to lose that entirely. And maintained projects are indeed good.
Can Pyglet's sanity checks be #defined off somehow? If so, maybe we could make two different identical patches, one which does the sanity checking, and one which doesn't?
These aren't standard GL sanity checks (glError and friends), these are Additional sanity checks in the form of "Did you set up an OpenGL Context In Python?", which of course we cannot allow. Thus, it's useless and serves no purpose (since it's a guaranteed failure unless there's some magical way to pass in QC's opengl context)
#define means nothing in Python; I don't know of an equivalent and I don't feel like tweaking Pyglet just for this: the python patch will not include any of these libraries since that's the user's job anyway -- I want it to just work with what the user has installed (and then some more tweaks using pythonPath, once I figure out what that means and amos walks me through some more.)
Thanks for the link, I'll be sure to ask them when things are farther along. First I want to make sure I'm doing things correctly on my end before bugging them, just incase it is a problem on our side (very likely at this point :)
Ah, yes, that kind of sanitychecking isn't useful in this context.
I was assuming that pyglet was some sort of compiled C module that exported a bunch of functions to the python interpreter (like most other system-to-interpreter-bindings i've seen).. But, looking briefly at the pyglet source, it appears to all be python, and python code is doing the linking itself (?). In which case #define is indeed meaningless.
I've finished the GL Point Structure patch, and dropped it in to this composition as a replacement to the Iterator patch. It's about 50% faster (8fps -> 12-14fps), almost identical to smokris' measured "cached output" test (testing iterator performance over 2000 points). You can expect this new patch (and a corresponding GL Line Structure Patch) in a very-near-future GL Tools beta :)
which values will you need in the structure? I'm guessing Width, Height, Depth, Position (x,y,z), rotation (x,y,z), maybe color? I've been avoiding texturable primitives (quads, triangles) for simplicity, so this goes against that a little bit.
(p.s. please nobody ask for a GL Teapot structure. it will be rejected ;)
I was planning on having the GL Line Structure patch allow you to draw line segments (separate line pieces) as well as line strips (cone continuous line that connects a set of points). The current GL Spline is basically a glorified line strip (with a bunch of math made automatically).
It wouldn't be difficult to make, in retrospect... I'll think about it.
(this structure stuff is going to open a big can of worms.... I can feel it :)
Boids would be terrific ( i played a bit with it under Max/Msp, and it is a great phun !)
A Flocking algo, more generally, would be tremendous !!
please please.
I did start doing a JavaScript boids thing a while back. Didn't get far, and I have a suspicion that it would have been hideously slow, if I had got it to work. Maybe a plugin with a structure output for XYZ of each particle fed into an Iterator would work faster...
I'm looking at the "b" composition. Beautiful, and it goes nicely with music (acid jazz at the moment) too – the pieces look like they're dancing to it.
I have been messing around with the Kineme audio tools, to see what parameters look good being effected by the audio files...
This isn't with audio patches... but is another take on the idea... one with a "torus" flight pattern, "if you will".... I think it is really interesting how a shader like this can make the particles conform to a shape. I first tried this with the regular particle patch on an audio reactive qtz that I have a render of an vimeo.... "sensational moonlight"... I think that was vertex distortion?
If you use these setups (or any that I post), or do a derivative, please credit all involved :o) Otherwise, totally free for use! (sorry to be nitpicky). I'm actually most concerned about any compositions that I've used pieces of other people's stuff, and I have credited them within the composition... I don't want anyone to suffer for my wanton postings :o) !!!
How does proximity work for particles? (I'm not very experienced with particle systems) Is it like 'boids', or 'flocking' behaviour?
Can you fill in some more details, like the input parameters, and how they would affect the system? We've had some particle stuff on the back-burner for a while.... maybe we should think about dusting it off in the near future? :)
I'm not very experienced with particle systems too... I was trying to express in a bad way the concept of the behaviors of the particles...
Sorry I'm trying to express myself in a language that I don't know very well
and so sometimes I write some bullshit
Sorry
It's quite ok :) I ask these kinds of questions even to native English speakers, because I'm not very good at translating word descriptions into program code without lots of questions :/
How were you thinking proximity would work?
When I mentioned "boids", I mean stuff like this: http://www.red3d.com/cwr/boids/ (I guess the word they use for proximity is kind of like "Separation" and "Cohesion")
The link you post its very interesting. The concept in general is collision...
Maybe you know this amusing soft. something like this... in quartz is my dream... http://uri.cat/software/LiquidMac/
I think this may be possible with existing patches (there's a SMS patch built in as a private patch, and Google made one too I think). Some Javascript (or, the upcoming Paython patch ;) to do the physics simulation and you're in business.
i can't find the sms patch what key i have to use to find it or where i can find it? thank
It's a private patch in Leopard called "TiltSensor". I've used it for a couple compositions so you could "inspect" a 3d object by tilting the laptop around. :)
ok i know this tilt patch,
but i show you the liquid mac for the collision not for the tiltpatch sorry for the misunderstanding!
I understood what you meant :). I was just saying that you could use the TiltPatch for the tilt input (which is what liquidmac does), and use Javascript to do the physics (collision, gravity, etc) simulation. The JS patch would take the tilt patch's input, do some work on the points, and then output to an iterator of points or sprites or whatever. Probably a lot of code (I don't know how complex liquidmac can get), but I think it can be done without any additional custom patches.
Doing complex math on a large array of points sounds like something that would be dreadfully slow in javascript (and thus necessitating a custom patch).
I put together a little test.. Generating 2,000 points (using very simple math) into a structure in javascript and then iterating through these points and drawing GL Points goes about 8fps on my MBP (and even if i disable the GL Points patch, it only runs at about 12fps).
IIRC the the optimized C code from VEE which I used a year ago for the firesim project easily handled 20,000 points at 60fps on a slightly less powerful machine.
For any nontrivial particle work, optimized/compiled code is still necessary I think (however your Python patch, with its integrated OpenGL bindings, may actually be usable for this, too, since you can avoid the whole QC Iterator patch behemoth).
Good example, thanks steve. I was hoping that the javascript engine did some kind of bytecode/on-the-fly compilation, but if it does it's horribly slow (as demonstrated). Even CSE'ing and pulling the object allocation out of the loop didn't appreciably boost performance on my machine. sigh.
I've not done any profiling with the python patch yet, but It has distinct parse/compile steps, so I'm hoping that it holds up slightly better. I'll try to whip up an example just to see what we have to work with.
(VEE's 3 years stale. PyOpenGL is 3 years stale too, but works with the existing python patch. Pyglet (another opengl implementation in python) is actively maintained, but doesn't work because it apparently does more strict state checking (which, as a side effect, also issues 1 additional branch per gl function call even in "correct" environments. probably not measurable, but man...). why aren't useful libraries maintained?!)
Yeah, my javascript code was decidedly unoptimized... but there are tons of other nontrivial consumptions.
Some other tests:
Generate the structure once during the first frame, then cache it and just iterate/render points every frame: 20fps. Thus: QC Iteration is slow.
Generate the strcutrue every frame, but don't iterate or render: 15fps. Thus: Javascript patch is slow.
So... I'm hoping for good news with the Python patch :^)
I spent some time today working on a "superiterator" patch that would be a light-weight (read: much faster) iterator patch (green iterator would be a part of this too). However, I discovered some problems with graph evaluation when executing subpatches multiple times, and decided to inspect the existing iterators to find out what they do to work around this.
Strangely, there isn't much going on in either the iterator variables or the iterator itself -- a simple for-loop (which is what I would have expected). This is much simpler than performance indicates, so I'm going to abandon the superiterator for now (it couldn't possibly be faster than the current one), and instead try to figure out what's happening behind the scenes to make this so slow... Very much not what I expected. I'm guessing now that it has something to do with QC graph re-evaluation/invalidation -- not sure how fixable this sort of thing is from a plugin.
On second thought, I think I'm just going to focus on spread ports....
That's interesting. Not too surprising though, I guess. Looks like Spreads is the way to go then...
Maybe the SuperGLSLGrid could be the first 'spreadable' patch (hint hint) ;)
It's actually a pretty good candidate for that, I'd imagine; being relatively simple.
alx
Quartz Composer Blog: http://machinesdontcare.wordpress.com
Music Site: http://www.toneburst.net
What about the posibility to do the maths outside iterators then pass values thru a structure...a sort of "instance iterator variable patch" that can distribute index, current position, etc...but outside his parent iterator...do you think it should give gain performance ?
i don't know for performance, but processing all the data outside the iterator, concat into a structure, then feed into the iterator is the only way i know .... and it is very tedious. Seems we're all longing for the KNM supa-iterator...
Given the nightmares I encountered when working with a large/diverse GL rendering pipeline on the firesim project, GL sanity checks are immensely valuable, so I wouldn't want to lose that entirely. And maintained projects are indeed good.
Can Pyglet's sanity checks be
#defined off somehow? If so, maybe we could make two different identical patches, one which does the sanity checking, and one which doesn't?These aren't standard GL sanity checks (glError and friends), these are Additional sanity checks in the form of "Did you set up an OpenGL Context In Python?", which of course we cannot allow. Thus, it's useless and serves no purpose (since it's a guaranteed failure unless there's some magical way to pass in QC's opengl context)
#define means nothing in Python; I don't know of an equivalent and I don't feel like tweaking Pyglet just for this: the python patch will not include any of these libraries since that's the user's job anyway -- I want it to just work with what the user has installed (and then some more tweaks using pythonPath, once I figure out what that means and amos walks me through some more.)
I suggest that you talk to the pyglet maintainers about this use case. I've found them very accommodating.
http://groups.google.com/group/pyglet-users
They may decide that they don't want to modify pyglet, but it doesn't hurt to ask. They may also have ideas for workarounds.
Thanks for the link, I'll be sure to ask them when things are farther along. First I want to make sure I'm doing things correctly on my end before bugging them, just incase it is a problem on our side (very likely at this point :)
Ah, yes, that kind of sanitychecking isn't useful in this context.
I was assuming that pyglet was some sort of compiled C module that exported a bunch of functions to the python interpreter (like most other system-to-interpreter-bindings i've seen).. But, looking briefly at the pyglet source, it appears to all be python, and python code is doing the linking itself (?). In which case
#defineis indeed meaningless.Just to clue y'all in:
I've finished the GL Point Structure patch, and dropped it in to this composition as a replacement to the Iterator patch. It's about 50% faster (8fps -> 12-14fps), almost identical to smokris' measured "cached output" test (testing iterator performance over 2000 points). You can expect this new patch (and a corresponding GL Line Structure Patch) in a very-near-future GL Tools beta :)
I can't wait to test it ! :)
yanomano.
This sounds great. Would you mind adding a GL Cube structure ?
(i'm using a Image Pixel ==> Cube Iterator, with many cubes, so a good performance boost is always welcome...)
which values will you need in the structure? I'm guessing Width, Height, Depth, Position (x,y,z), rotation (x,y,z), maybe color? I've been avoiding texturable primitives (quads, triangles) for simplicity, so this goes against that a little bit.
(p.s. please nobody ask for a GL Teapot structure. it will be rejected ;)
difficult ?
I was planning on having the GL Line Structure patch allow you to draw line segments (separate line pieces) as well as line strips (cone continuous line that connects a set of points). The current GL Spline is basically a glorified line strip (with a bunch of math made automatically).
It wouldn't be difficult to make, in retrospect... I'll think about it.
(this structure stuff is going to open a big can of worms.... I can feel it :)
yes, the usual Position / Rotation / Dimensions (W/H/D). I assume Texture data (if needed - which is not my case) can be set manually ... ?
and no, no Teapot structure...... ;)))
Chris: could you expand on the worm part ?
Boids would be terrific ( i played a bit with it under Max/Msp, and it is a great phun !) A Flocking algo, more generally, would be tremendous !! please please.
oh yes! boids would be useful for natural modeling. and with inter-particle gravity and collisions, we could use QC to model the birth of the galaxy!
:D
I did start doing a JavaScript boids thing a while back. Didn't get far, and I have a suspicion that it would have been hideously slow, if I had got it to work. Maybe a plugin with a structure output for XYZ of each particle fed into an Iterator would work faster...
a|x
Ok, it's not "flocking", or IS it? (dramatic music plays)
"That depends on your definition of the word 'flocking'..." .
very interesting compo...
I'm looking at the "b" composition. Beautiful, and it goes nicely with music (acid jazz at the moment) too – the pieces look like they're dancing to it.
I have been messing around with the Kineme audio tools, to see what parameters look good being effected by the audio files...
This isn't with audio patches... but is another take on the idea... one with a "torus" flight pattern, "if you will".... I think it is really interesting how a shader like this can make the particles conform to a shape. I first tried this with the regular particle patch on an audio reactive qtz that I have a render of an vimeo.... "sensational moonlight"... I think that was vertex distortion?
Thanks for the compliments!
If you use these setups (or any that I post), or do a derivative, please credit all involved :o) Otherwise, totally free for use! (sorry to be nitpicky). I'm actually most concerned about any compositions that I've used pieces of other people's stuff, and I have credited them within the composition... I don't want anyone to suffer for my wanton postings :o) !!!