Gravitate And Boundary (Composition by gtoledo3)

sweet been working on the same lines for a few days.

this runs really smooth george. i like it as its all noodles. been doing a cl boid flock with matthais, as of late. made flock in unity that is pretty awesome yesterday. i'm thinking i could do something similar in.

matthais and i have got a cl version working much better now. added some new rules and and parameters etc... still have to use the feedback though as a cl particle system needs the feedback patch.

this system is great because i can run full screen and like you said its backwards compatible, so leopard users can play. i took a peep inside the iterator. still trying to follow all the logic on how your getting the gravitation.

anyways nice one. thought i would ask you cause your the only guy who comes up when you type "flocking quartz composer"

if you want to try out a cleaner version of the boids in cl hit me up on skype "ter.maximus" and i will send to you.

i was thinking about about using a gl look at patch to follow the center of a flock as they wander around 3d space like you would do with a camera in unity, but maathais put in boundaries so its not necessary. maybe cool idea for this patch though. kind of let the flock wander where it wants and follow it instead it following you. although i like the mouse bit. just something i was thinking of lately..

I've been interested in flocking since before I started QC! So, it's definitely been ongoing ;)

The all noodle aspect is the fun part for me. Now, I realize I'm using smooth in the iterator and that this isn't backwards compatible, but it could be retrofitted pretty easily. I like using the node patches to prove a point; because I believe in visual programming as a coding language. It sometimes rankles me when I do something like this and someone goes "oh you didn't even code it". I understand what they mean, but I don't agree with the premise.

An OpenCL implementation is potentially VERY great, because of possibility of speed, if it actually does result in more speed (OpenCL definitely doesn't always mean amazing speed gains), and integration with the geometry pipeline.

I'm nearing the end of my night, so I probably won't be hitting you up on skype tonight ;) Admittedly, I'm not big on the video chat as well.

I would have commented it, and will when I do a second round with some more function, and have some more stuff how I would like it. There is something going on when I test for if a given particle is by x/y that isn't doing quite what I expect when I expect. Probably a case of being up too late.

It makes sense what you're talking about with a look at, or 3d transform. The only thing about that is that sometimes you really have to see the overview of a flocking scene to have some kind of context of what is happening.

If I understand one of your comments correctly, you are incorrect about needing to use the feedback patch to do an OpenCL particle system. You can derive the last frame with a queue, and shift off of the initial seed with a multiplexer once you have obtained that frame. I believe this to work more stably than the feedback patch in most instances. When something taxing is happening, the feedback patch tends to "crater" and make things not render smoothly, whereas other methods tend to keep graphics rendering smoothly, at least on my particular laptop. I haven't tested that premise extensively on a wide variety of hardware.

your right opencl doesn't mean anything runs faster, although there is the potential. im with you most of the time i make it point to do things in qc visually rather than in js or something. like conditional logic and stuff gets hairy and is hard to follow visually with noodles as i think its easier understand someones logic in code, but i generally like a combination of multiplexor's, logic, and conditionals.

doesn't make it any easier to read someone else logic cause you need to follow the wires visually but i defiantly enjoy being able to program visually. who cares if someone says you didn't code that they obviously don't know who GT is. i mean i understand it kind of as well where someone that doesn't know how to code can visually program but with your mouse or with your keyboard coding is code, you just can't say o wrote that. i guess you have to say i wired this code up instead of wrote it up.

interesting i will have to try your technique with particle system. your saying set your initial position then send the current position back through a multiplex and queue it to get old position ?

hmm that should work i guess in theory, i mean thats how i calculate accelerations or to tell direction for multi-touch. i don't know enough about the inner workings of the feedback patch to say if its any faster.

i make it point sometimes to replicate private qc patches by using just qc as well. don't really know why ?

Thanks for sharing this. Sorry if this has been covered -- what are the issues, if any, for OpenCL regarding 32 and 64-bit modes in QC? I pretty much run only in 32-bit mode...

Don't be afraid to experiment with OpenCL in 32 bit, especially simply running compositions.

The main (only?) bug that I've found to exist when running QC 32 bit that doesn't happen 64 bit, in the context of working with OpenCL is that if you select all of the text in the OpenCL kernel program editor and hit delete, QC will either beachball or crash, and end up with gunky graphics garbage in the programming inspector if it does survive the delete.

So, effectively, only highlight the "code" part of the kernel and delete that, leaving the commented out parts. If there is no text in the kernel editor, it wigs out, but if you leave the commented out notes, it seems to work fine.

On the feedback/queue note, if it can't be handled by "old school" QC feedback loops, and one needs clarification of which frame is which, one can loop back the 0 index to obtain the past frame or 1 index to get the current.

However, one usually doesn't need to even do that. For example, I just looked at the OpenCL N-Body example. I setup a multiplexer to sample the initial position / velocity with two multiplexers. I have the output of the kernel going back to to input 1 on both multiplexers. Patch time shifts the index from 0 to 1 on startup. It works exactly like the N-Body normally does. I hooked up a queue setup to see if forcing (or just "making sure" of) past/current value made a difference in for the n-body and it didn't really (sort of surprisingly). A simply loopback works as well as the feedback patch. I relate to where you are coming from though, because it wasn't obvious to me that this could be done with OpenCL kernels at first. Something makes me feel like the feedback patch is a bad hack. Like, how I can publish outs with a consumer in a QCPatch/qtz, but I can't then drag that QCPatch/qtz onto another, because output ports and consumers really aren't supposed to coexist. Half-baked to say the least. I already indicated it, but it also seems to cause evaluation problems if you use a composition loader to load something that utilizes a feedback patch in a sufficiently complex composition. Stuff starts halting when it shouldn't (eg, frame rate dips for trivial stuff... graph evaluation going awry).

Anyway....

To me, conditional logic and feedback loops in an iterator make a lot of sense... there is that iterator variables patch that easily allows one to do things per index, or over ranges of indices. So, if I hook a conditional to apply to only a given index or range, then only that group is "doing stuff". Super cool/easy abstraction, at least I think. I hate it when people get so "oh the iterator sucks blah blah". It could be better performance wise, but it frigging rocks from a use standpoint.

Iterator, sprite, etc., should be integrated so that they take advantage of OpenCL, and/or GPU acceleration when one simply wants to use patches instead of an OpenCL program. Performance difference between the two routes is something that ideally should be eliminated. That kind of use of OpenCL makes a hell of a lot more sense than what happened. That way, the technology could shown people more immediate performance gains instead of being a non-fully implemented OpenCL prototyping environment.