Particle tools, getting coordinates?

Currently you can do this by feeding the Particle Scene into a Particle Render: Structure patch and then iterating through the output structure. It's okay to feed a single Scene into multiple Renderers, as all the particle calculations take place in the Scene.

cheers! big help... i'm also wondering if there is any way to be sure of a particles index?

i have a bunch of normal particles that are just created by an emitter... then i have these "special" particles directly plugged into the scene that are bigger and trigger events when they leave the screen... ultimatly i'd like them to effect each other and share the same forces, is this even possible? at the moment it seems to me if i want to check just the x value there is no way to single out my special particles.

Thanks again,

Ian

Indexes are not guaranteed.

Currently Render: Structure only outputs XYZ/UV coordinates and RGBA color. In a future ParticleTools release, we could add support for outputting other particle parameters, such as object type, current age, age limit, velocity, size, mass, area --- then you could test for certain known values (i.e., give normal particles a mass of 1, and the 'trigger' particles a mass of 2).

We could perhaps take the particle patch's title and make that a structure property, too, so you could differentiate between two otherwise-identical particles.

Let me know what you think.

Is collision testing/info something that might be able to happen in that scenario?

If one could test if a particle collides with a surface, a different particle explosion could trigger at the origin of collision. So, classic effects like a meteor flinging into a surface, and then exploding, could start happening in a reasonable way. The other interesting side effect is that all kinds of "other stuff" could start happening based on that kind of info; an md2 could go into it's death sequence, for example.

Yes, collision info could be included. Would a single monotonically-increasing "Number of Times This Particle Has Collided With Anything" counter work, or should we manage separate counters for separate colliders?

I've been thinking about that one ( I read it shortly after you wrote it, and have had it rattling around my brain all day ). I mean, separate counters for separate colliders is definitely nice. One could practically "fake" different walls in a building getting dented in with some clever use of K3D planes and some warping (really simple example). If the count was just on the particle, a whole slew of extra things could be done.

That said, I'm skeptical; the really basic suggested "step 1" change would allow some cool tricks from the start. I don't know how interested most people would be in adding that, even though I'm loving the idea. It's heartening that to see more interest in Particle Tools.

(Another thought; is it good to graft on a bunch more stuff if Vee/Particle Tools is so locked into 32-bit land, and it might make sense to just do a different particle/physics engine all together? I'm all for Particle Tools expansion and would use it, but I'm thinking about it more from your side of things.

Setting up particle collision with OpenCL is totally lame compared to using Particle Tools + K3D. It's not even in the same ballpark, and feels like a stupid 2D-esque image trick to me, the more I use it. This is using highly mod-ded versions of the Snow composition as a starting point. I can get it "looking" 3D, but it's still keying boundaries off of color. Eh. I hate to keep calling it lame, but it is totally lame. QC4=Corporate Skanky= they didn't have a clue why anyone was doing the stuff we were doing anyway, or how well it works, so it's no wonder new features fall short.