Since there is subframe sampling (LOL, I say that like it is a major factor and has something to do with it, which it doesn’t but would provide more accurate results) would it be possible to use geometry objects as velocity sources? IIRC Fume uses velocity from objects as collision detection, well maybe not detection, maybe interpenetration avoidance is a better term. Or is this strictly in the realm of Ember? or just plain silly?
This is a complex question with an even more complex answer.
We have discussed several possible approaches.
We looked at making the particles collide with geometry, but this would look strange because you would get dense accumulation around the surface. We discussed the ability of the velocity field itself to be affected by geometry occlusions, but this is slightly tricky since Stoke does not really run a simulation like Ember does, it just uses a velocity field defined elsewhere. If your velocity source (FumeFX, PFlow etc.) already contains collisions, Stoke particles will mostly respect that, except when using Fluid Motion since the divergence-free calculation would not know about the occlusion object.
And then there is the approach of faking it by simply taking a PRT Surface, feeding the Normals into a Velocity channel using Magma, and introducing a repulsive field into the fluid…
I did that a few days ago and here is what happened:
youtube.com/watch?feature=pl … 9RULFidW_Q
Hey that works pretty well! I suppose it even gives you another level of control by the amount of particles birthed to the surface of the PRT Surface object. Your “faking” it approach seems pretty close to what I imagine Fume to be doing.
Looks like interesting approach. But why this not work in Beta3? What more in calculation core will be in next Stoke build? 
When we can expect beta4?
It does work in Beta 3, but you have to modify the filter functions to allow you to pick any object as velocity source. There is nothing about the simulation itslef that is necessary, just a UI script modification. I posted elsewhere how to hack the UI script to allow all PRT objects to be picked.
Beta 4 should be released either today or tomorrow - we have one bug left to fix.
Yes, I updated picking filter, but have no luck to influence velocity field like in your example. Mixing with FumeFX had no results, with Pflow - weird results
Anyway, will wait for Beta4.
Did you scale the Normals enough? In my video, I used a Velocity Scale value of 100 to produce strong enough influence…
Of course, I tried different velocity scales, but with no luck.
Interesting that with Beta4 everything looks opposite (screenshot attached). Will figure it out, maybe with my scene scales is something not right.
What about about using a XMesh object as a velocity field? or would that run into the same problems?
Depends on what you mean by that 
*XMesh an animated object.
*Create an XMesh Loader and check “Velocity To Map Channel” > 2.
*Create a PRT Volume from the XMesh Loader
*Add a Magma modifier and copy Mapping2 → Velocity
*Create a Stoke object and pick the PRT Volume as the Velocity Field.
*Create some particles, for example in the volume of a box.
*Simulate…
Regardless of teh mesh object source you need to emit velocity from the face normal. It should not matter where it comes from. That said I would like to see how it behaves from an animated vertex count mesh with overlapping velocites.
Nice! but I was hoping that I wouldnt have to do all those steps manually.
Here is a video:
youtube.com/watch?feature=pl … zac-Q9yHyc
You can script the steps if you want.
Using meshes to drive particles is not in the scope of Stoke 1.0, but it is obviously possible, along the lines of direct mesh collisions. I will log it as a Wish for future updates.
The fact you can do it via XMesh and Krakatoa PRT Volume + Magma is quite refreshing though. Thinkbox Channels At Work
Thanks for the video, it gave me some other ideas as well.