|
|
Particles and Visualizer I'm seeing some issues with a particle system based composition that I'm attempting to play across multiple machines via Quartz Visualizer. My main aim is to have a particle system generating particles and the particles flowing from right to left across multiple machines. The attached file is a prototype of boid objects being fed to an emitter then being rendered out with a simple image texture. The emitter is working as expected and works great on a single display, however when I run it across two displays, the emitted particles don't "line up" across the displays. For instance, if I track a single particle across the first display, it doesn't enter the second display as it is leaving the first. My current setup is one macbook running the comp in host mode, with a second iMac running in client mode (I've tried running with 'run processing composition on clients' checkbox checked and unchecked with no visible difference). Both have the same screen res and are arranged horizontally within visualizer to be directly next to each other. The background image is lining up as expected to span both displays, however the particles being displayed on the monitors don't seem to be being generated from the same system. Am I expecting too much from Visualizer to be able to render the particle system across the two machines (i.e. due to the amount of information the emitter/renderer is generating and displaying it simply can't "keep up") or is my particle system not setup correctly? Or is there a better way to approach the overall problem (a single particle system spanning multiple machines/displays)? Still a relative kineme/QC newbie so any advice is gratefully received and appreciated.
|
It may or may not be relevant, but I did find that I got this error repeating
I don't have 2 displays or experience with Visualiser.
I'd run a check to see if you can pass a simple sprite across the displays, from one comp to the other as it were.
I'm guessing QVisualizer doesn't do all the work of distributing a single compostion across displays for you but that's totally a guess.
Totally irrelevant but I mostly don't get the stones image displaying, except for once when I selected the patch and looked at it's settings, weird.
Thanks for the quick reply. Are you seeing this error from within QC? I'm able to run the comp without any errors - I'm running it on Snow Leopard, if running it on a different OS version could be causing problems.
I did try a more simple comp with a single image based sprite moving across the screen via an interpolation patch and the synch between the two displays was near pixel perfect - obviously a lot less data being sent between the two displays (the x value of one sprite vs the x,y,z of hundreds of particles) though.
Don't know whether it's this amount of data that is "confusing" qv or whether the data that is being sent over the network doesn't mesh with how qv synch's between displays. Thanks for the suggestion though.
Re the stones not displaying correctly, I'm not sure - they have always displayed just fine for me. Something to do with them originating as a local file from my machinge perhaps?
have you tried opening up the comps on two different computers then using something like osc, 1024 network, or bonjour etc.. to send a message that triggers lets say the comp on the right to start animating once the comp on the left has hits the edge of its screen. it seems the visualizer would be the proper way to do this sort of thing, i just have yet to really give it go yet.
running in QC 32 bit
Yes within QC GF Log - and it stops, thus far anyway, if I swap to a VBO patch
I can't really test Visualiser with one display only (I had a try). When you say a lot less data being sent, do you mean you are having to send data b/w two different comps or Visuliser is doing automatically by splitting one comp across two displays? reason for asking is moving a sprite with an interpolate is deterministic and will result in same calculation one matter how many instances of the comp are running.
So if QVisualiser just 'offsets' all the (X,Y) values on the sprite for each instance it will be pixel perfect. Particle systems are a bit less deterministic, like an n –body system is actually not calculable for time=t with many bodies (pos over 4 or 5 I think), even if you have a cray-computer (or whatever surpassed them). You can only get the positions of the bodies by iterating the positional data and calculating the (gravitational) influence of each body on each other body.
I haven't looked closely at your Particle system and aren't familiar with using them, but I note there is at least two randomised position related values which may result in the two different systems being run in each instance of your comp (one for each display) differently — even if all other things were identical like parallel execution frames. I might be way of the mark here because I don't know QVisualiser and how it does what it does (sounds like a really cool tool though). Like I said I don't know particle systems either but I know chaos theory allows for small deviations to amplify quickly in chaotic calculations (which a particle system may be approximating).
This would be a good point for an expert with PTools and QVisulaiser (cue: cwright or smokris) to comment and say what's right and what's wrong about my hypothetical.
No the image gets embedded in the patch/composition fine. Works now, I guess I just need a machine reboot or a good nights rest.From my understanding (which may well be wrong) of visualizer is just renders the composition twice and in essence crops each version to the appropriate size and position. I think that usefuldesign.au is right in that the random elements will be computed on each computer and wont match up.
the random stuff can line up, but only if a lot of things work out correctly (Which is unlikely with ParticleTools)
Basically, a deterministic random source is needed (QC has a few of these internally, for the Random patch, Particle System, and a few other things). However, this can still suffer from tiny clock drifts. Additionally, per-frame random sources (i.e. deterministic sequences) can get messed up if one of the machines drops a frame, but the others don't. You can solve this by pre-computing large "random" tables in advance (i.e. at startup), and step through them according to time. ParticleTools will still struggle with this because any dropped frames will cause the table step to drift, and since it's an iterative simulation, a single missed value can mean a totally different result.
here is a determinant particle emitter that may help you get non stochastic results. you need the simplex noise generator plugin.
http://kineme.net/composition/dust/DeterminantParticleEmitter