Trying to figure out the best approached to creating particle systems that are unique and isolated to packed primitives.

Basically, I've got a rigid body shatter effect and for each packed prim I want to have an energy effect that travels along with the prim geo. I'm after a particle effect that basically ‘clings’ to the surface with maybe the occasional wisp or particle that escapes a tightly controlled field around the surface. I don't want a comet trail/firework sort of effect as it travels through space. Think of something like an ether fire engulfing an object: all flame and form around the source without any smoke emission.

For instance, the look could be similar to stationary geo with a VDB-driven velocity field manipulated by curl noise.

It feels like my base needs to be a per-piece particle system that starts as a scatter-on-surface system and…then everything I've tried just doesn't get me where I need to be.

So, I guess my questions are:

1. Is a for-each loop pretty much a given here?

2. Any way I can avoid making the first step in the for-each loop an unpack? Because, you know, that's painful…

3. How do I keep the particle system contained to the volume of the packed primitive/fragment geo?

This isn't meant to sound as broad as it might; I've got (I think) a fairly good understanding of forces/velocity/etc in POPs/DOPs but I just can't seem to find the right combo here.

The particles need to inherit the overall velocity/acceleration/transformations of the fragments as they transform, but they need to do it in a contained, volumetric fashion. My prototype tests have been getting me imagery that at one extreme looks like the particles are getting ‘stamped’ in space and like the comet tail at the other.

I've tried a few ways to create a VDB per-fragment, and it, uh, wasn't a pretty for performance or visuals. (willing to take the perf hit for the right look, btw)

4. I literally had not considered pyro for this until typing the ether flame description in the post. Does this sound like something suited for a pyro solver? Haven't done much pyro besides some advection hijacking.

I'd be grateful for any advice.

Thanks!

–
mC

0. first let me suggest the technique as all the answers are dependent on that
- take initial state of your packed RBD points (non time dependent)
- separate them a bit so that they dont penetrate (Exploded View or something similar), this will be your “rest” state you can do your particle sims, you can transfer any attribs from animated pieces tho these to help with emission timing etc.
- unpack and do your particle sim, you can do it as a single sim for all the pieces at once as they are separated, just remember the @name attrib of the source piece per particle
- use Transfer Pieces to transfer your particle sim from the “rest” state to the rbd sim points

so now the answers may be mre clear:
1. for loop is not necessary
2. to access geometry you have to unpack, but this can happen on a frozen frame so shouldn't be a problem
3. now that everything is in the rest position (with gaps among pieces) you can pretty much treat all pieces as a inverted static collider so that all particles belonging to that piece are kept within
4. particles or pyro, the technique is similar

Hey, Tomas…thanks for the response.

I've got this mostly set up through to the sim, but I'm at a loss as to how to get the @name attribute through to the pyroSolver.

I'm passing @name from the unpack node to the create_fuel/Pyro Source node (losing one point attr in the process somehow), then @name is carried through to the add_noise/Attribute Noise node, and then called out in the Volume Rasterize node Attributes field.

The @name attr looks like it's getting nerfed in the rasterize node. The only name attrs getting through are for the prim attrs fuel and temp.

How can I get @name through to the pyroSolver?

And do you just typically make a large enough bounding box for all the fragments collectively in the rest position? Wondering if there was a way to isolate bounding boxes to the fragments for the sim. And, yeah, I know the explode node distance is overkill but just wanted to be able to see everything going on this first time out.


–
mC

Can't have a look at it right now, but with the pyro the idea is to
either
- use clustered sim, where each fragment will have its own cluster, therefore its own set of volume primitives
Or
- use TOPs to cache them as wedges per piece

Then for any of the methods, instead of name you'll have to use different lookup attrib (for transform pieces) to assign to your volume clusters as well as to the pieces as name is already taken for volumes as a volume name

Gah…feel like I'm close but I can't get the shatter motion through to the pyro solver correctly. I have some ugly wiring in the source points network that looks like its working, but there's something that just isn't getting through.

If I reference the averagepoints/cluster centers then the volumes burn. If I reference those same points after they've been transformed, I get empty volumes.



–
mC

Woo! I got it! I think! Maybe…

I'm not sure why the bounding areas are not compressed around the pryo clusters as they move through space. Almost certain I missed a flag somewhere, just not sure which one I missed.

And, second, if I wanted to drive the activation of the per-instance/per-piece pyro sim via @active/@TimeInc/whatever, how would I tell each separate cluster to activate at different times? Multisolver/wrangles in the pyroSim? Does the pyroSim understand the concept of clusters in the same way the rigidBodySolver understands points/pieces?

–
mC