procedural drip shape

[super gnu]

an idea i had.    in the shape operator, or as a seperate one, a procedural drip. 

at rest its a sphere.  when it moves, a "tail" stretches out along the direction of travel.   this could change length depending on velocity, with some range/max stretch controls. 

only technical issue i see is ram usage with all those non-instanced shapes.     could maybe be mitigated by having a discrete number of "steps" in the shape change, maybe with a spinner to change number so controlling ram usage. 


i got this idea as i was struggling trying to do droplets with particle tails, meshed with frost.    at slow speeds this works great, but at some points i have spray flicked off an object.   at high speeds, the tail  of paticles gets too spread out to mesh, and only increasing the substeps to insane levels allows the trailing birthed particles to keep up with main one.  this slows things to an absolute crawl. 

im sure there are workarounds using bindings etc, but a simple "drip" shape would remove a crapload of messing around. 

im guessing there may be a way to do this manually, by having a set of custom drip shapes and using the velocity of the particle to direct particles to different shape operators, and aligning  along motion vector, but thats way above my head at this stage, and again, a procedural shape operator would fix it much more simply. 


another novel feature would be to align the drip to direction of travel *and* the surface its on, so you could have a "flatten base" option for drips so they sit properly on a surface instead of intersecting. 

is the above doable?  

not in time for my deadline i expect

[Zemmu]

an idea i had.    in the shape operator, or as a seperate one, a procedural drip. 

at rest its a sphere.  when it moves, a "tail" stretches out along the direction of travel.   this could change length depending on velocity, with some range/max stretch controls. 

only technical issue i see is ram usage with all those non-instanced shapes.     could maybe be mitigated by having a discrete number of "steps" in the shape change, maybe with a spinner to change number so controlling ram usage. 


i got this idea as i was struggling trying to do droplets with particle tails, meshed with frost.    at slow speeds this works great, but at some points i have spray flicked off an object.   at high speeds, the tail  of paticles gets too spread out to mesh, and only increasing the substeps to insane levels allows the trailing birthed particles to keep up with main one.  this slows things to an absolute crawl. 

im sure there are workarounds using bindings etc, but a simple "drip" shape would remove a crapload of messing around. 

im guessing there may be a way to do this manually, by having a set of custom drip shapes and using the velocity of the particle to direct particles to different shape operators, and aligning  along motion vector, but thats way above my head at this stage, and again, a procedural shape operator would fix it much more simply. 


another novel feature would be to align the drip to direction of travel *and* the surface its on, so you could have a "flatten base" option for drips so they sit properly on a surface instead of intersecting. 

is the above doable?  

not in time for my deadline i expect

Isn't this doable with spawn? I believe that there are more than one example files of droplets in the public gdrive folder, and they work pretty well...

[super gnu]

an idea i had.    in the shape operator, or as a seperate one, a procedural drip. 

at rest its a sphere.  when it moves, a "tail" stretches out along the direction of travel.   this could change length depending on velocity, with some range/max stretch controls. 

only technical issue i see is ram usage with all those non-instanced shapes.     could maybe be mitigated by having a discrete number of "steps" in the shape change, maybe with a spinner to change number so controlling ram usage. 


i got this idea as i was struggling trying to do droplets with particle tails, meshed with frost.    at slow speeds this works great, but at some points i have spray flicked off an object.   at high speeds, the tail  of paticles gets too spread out to mesh, and only increasing the substeps to insane levels allows the trailing birthed particles to keep up with main one.  this slows things to an absolute crawl. 

im sure there are workarounds using bindings etc, but a simple "drip" shape would remove a crapload of messing around. 

im guessing there may be a way to do this manually, by having a set of custom drip shapes and using the velocity of the particle to direct particles to different shape operators, and aligning  along motion vector, but thats way above my head at this stage, and again, a procedural shape operator would fix it much more simply. 


another novel feature would be to align the drip to direction of travel *and* the surface its on, so you could have a "flatten base" option for drips so they sit properly on a surface instead of intersecting. 

is the above doable?  

not in time for my deadline i expect

Isn't this doable with spawn? I believe that there are more than one example files of droplets in the public gdrive folder, and they work pretty well...

yeah as mentioned in my message , ive done it with spawn, and then skinned them with frost, and youre right, it does work well, when drips are moving slowly.   however when source particles are moving very fast, tyflow is only able to place spawned particles every substep.     my setup currently works fine with no suibsteps (set to frame)    however when i add spawned particles and move them fast, the spawned particles are added at the position on each frame...  which is way to far apart to mesh.     increasing substeps brings spawned particles closer to source particle,   but even at 32 substeps they are still too spread out, and obviously my sim runs 32 times slower.

---

in any case, ive got an acceptable result by swapping the shape for a single elongated drip shape aligned to travel direction at the moment they fly off.

[tyFlow]

A procedural drip shape like that might be neat for previs, but I don't think something that simple would hold up in production. A more complex setup involving a mesher like Frost and more physically-accurate particle trails would be necessary. So the amount of work required to implement something that wouldn't hold up in hires work seems like a potentially wasted effort. A good suggestion nonetheless.