Hi SOuPers and Alex Smolenchuk

With copier node life is easy when we are talking about particle effects. Usually the main problem is that I have a cool setup but hard to render it. Expecially if we have to pass the effect accross different apps or different render engines. Copier is an easy way to generate geometry from particles (skip the instancer with baking it into geo sequence). So we can say with copier we can do particle FX render agnostic way. Since there is alembic format supported all the major 3D apps we can do render and application agnostic output from particle effects. So that is my conclusion using copier node.
Thanks for sharing that!

My idea is to further development (based on what I wrote before) a so called multi-vertex-color workflow. That means it would be nice, the have multiple rgba inputs (up to let's say 99) and outputs as well.
So for eg. I create an rgbPP (basically a vector) within the particle node and create an expression which makes color based on the speed of the particles. And I create another rgbPP and use that to ouput the age of the particles (for eg. white is the born color and black is the death). And I create another rgbPP to output the world coordinates of the particles. And so on. If I had multiple rgb input in copier and I could output those channels to a mesh as different colorSets I could use them to render separated render AOV-s (layers / passes) and in the composite package I could refine the particle effect like hell.
Quote 0 0
Like it - will do.
Quote 1 0
Can we output points from the copier node and instance the mesh objects as unique objects with transforms? This way one could attach the output to Bullet rigid sets. Currently I am running a poly seperate over the output mesh object and going from there, but it would be even better to procedurally change the copier.inPosition count so the rigid bodies would update automatically at the other end (kinda like MASH but cooler of course) :)

Using the poly seperate breaks the proceduralism which is not a problem as it still works but we like proceduralism.
Quote 0 0


As a workaround, I usually output the arrays i want to store as meshes thanks to the point node (eg $TX=$CR, $TY=$WEIGHT, $TZ=$ID, etc.).
This way, you can store your arrays in alembic, version them, mix them... and even deform them !
And also, meshes are cross-plateform.

Quote 0 0
Bullet's standard implementation in Maya is a disaster.
Ian did great job with MASH's dynamics.

We can modify MASH networks with SOuP nodes if one needs the extra flexibility. There was a thread about it recently.
Everything you need to do is insert an arrayToDynArrays node like this: mash_dynamics -> mash -> arrayToDynArrays -> mash_bulletSolverShape
From that point you are in SOuP land.
If for some reason you don't like MASH's replicator and want to use Maya's instancer or SOuP's copier - pipe mash_bulletSolverShape.outputPoints into more arrayToDynArrays nodes to break-up the monolitic data set and use it as you wish.

I am a bit hesitant to replicate existing functionality (MASH dynamics) that in my opinion works well.
Let me know if you think we need something better/different.
Quote 0 0
Fair comment. I think I could use the highjacking method via arrayToDynArrays and MASH which could make another demo video at some stage. Ill take a closer look at this workstream.

@Pizzaman that workflow of yours is a bit foreign to me which is why its intriguing, this kind of information would make good video resource material. I wonder how we could tap into everybodies knowledge base and get some of this stuff out there for our users.

Quote 0 0