Using Dynamic Images from a directory in a boid particle system

Things may well have moved on since I last looked, but this is almost a 'seasonal' request, it pops up every so often and the answer thus far has always tended to be something along the lines of ...

Quote:
if you want to use multiple images per scene, you'll need to use "Render: Structure" and iterate through the structure (which is going to be horrifically slow).

We're considering eventually adding support for per-particle images (so you can have two Particles each with their own image, fed into two emitters, and then into the same scene, for example).

Would that solve your problem, or are you needing a different means of selecting images?

However, I find I can't get this to work in QC 32 bit, and I must admit I'm left wondering, why not just use the directory importer like one would in a slideshow?

Any chance of Particle Tools / KIneme3D Particle being updated to be 64 bit 10.6.x compatible [apologies if it's a sore point].

Please find attached what I can get working in QC 4 32 bit. I've left a 3D Render patch , you can try that out. Doesn't work for me - It's based upon the gravitate-nbody-haha example posted by gtoledo and has a directory scanner to image importer in a quick and dirty fix. Unless you've de-installed iChat the directory location ought to work :-).

If you are literally meaning create a unique texture image for every unique particle, it strikes me as likely to be expensive on processing power. Interesting idea though.

Oh, it definitely works. You get the output of a particle scene, use the render:structure to convert to an x/y/z structure, then use the iterator to place an object at each x/y/z point (do a search for my name and related terms, I posted how to do this with the boid fish example).

To get a different image on each particle, you take an image structure with however many images, and iterate through it. Cake.

(In fact, unless one needs iterator variables for some reason, like texturing different images on particles, you can use the GL Tools Structure Render in conjunction with the Structure:Render to place an arbitrary object(s) at a given x/y/z coordinate... it didn't exist when I posted my "workaround" qtz for rendering K3D particles.)

I don't follow the comment about directory importer/slideshow, and how it relates to the particle system scenario (but I'm dense sometimes).

I think smokris was really hot on getting a 64 bit version of Particle Tools for when SL came out, but I know that certain aspects of VEE lock it into 32 bit, and that it would be a real headache/impossible to change it.

@ smokris : Have you ever gotten anywhere in looking at other particle libraries or thought more about a different engine?

Ok, I was motivated to submit an example (hmm, I didn't notice you actually posted a qtz remix of mine, lol).

Caveat: one MUST do a Get Info on the QC app icon, and check off "boot in 32 bit mode". This qtz will likely crash in 64 bit.

Additional caveat on this nicely working example, one has to ensure that one has more images than the actual number of particles or else you end up with particles without an image at some points, just try running , say 12 or 13 particles and only having five images to cycle through, you still get individuated images by means of cycling in sync to the particles created, but you will end up with some particles 'un-illustrated'.

Additional observation, it seems that running through the index of the image structure still results in GFLog error, probably one that can be ignored.

<WARNING> QCProvider_CoreGraphics: Unable to extract native pixel format from CGImage (bitmap info = 0x00000003 | bits per pixel = 32)

I was getting this after swapping the Desktop Pictures path back to the iChat icons folder path.

I now see it is happening with even the successful means of using a unique image from the image structure series per particle [as in your example].

Doesn't happen when simply presenting each particle with one new image after another though.

Do like the way that this works.

Just make sure to cap the interpolate end time at -1 whatever the image count is. Actually, I would recommend to set that end time to something rather than set it by structure count so that it doesn't waver back and forth as particles decay.

I knew you would comment about the log; that warning happens when the pixel format is null, and is intrinsic in the directory scanner setup that smokris posted. It happens quite a bit in QC4. Nothing too important, but it will actually hose up QC if you have it delivering that message a million times per second ;-) I'm sort of "weirded out" as to why the pixel format is null in QC4 so often; I haven't checked this out in Leopard, but I sure don't remember getting that message like this. It happens whether QC is in 32 or 64 bit mode... it's quite obnoxious.

I'm not sure what I think about the qtz actually... I think it is revealing a particle tools bug where the index # of a particle shifts for some reason (it wouldn't be obvious if they weren't textured individually).

I'm sure it's expensive. If a particle system isn't the best application to do this, do you have any other ideas on what might work as an alternative.