One thing I really enjoy about Ember, Houdini, Naiad is that you can generate velocities on one frame and anything you pipe through those velocities will follow them. This doesn’t seem to be to case with Stoke? If I create a sphere, convert the normals to velocities (pointing inwards) using Krakatoa then load that Krakatoa as a velocity field in Stoke I expect if I emit particles inside the sphere that the particles would hit the edge of the sphere and then keep moving and basically bounce around inside the sphere. Instead what happens is that they come to a stand still. I tried bumping up the velocities but no effect. Does Stoke not like reading single frame PRTs as a velocity source? Do the particles have to be in motion consistently?
First, you don’t need save to PRT, since the PRT Surface can already be used directly (as shown in the last video on the Beta Videos page thinkboxsoftware.com/stoke-m … nt-history).
Second, a single-frame PRT Loader does not load Velocities by default. This is because a single frame cannot be moving over time, and thus motion blur would be wrong and unexpected. Similarly, if Playback Graph is checked but the Graph spinner is not keyframed, the same frame will be loaded and its velocities will be scaled to 0.0 as a side effect of the time scaling code, If you speed up the playback, the Velocities will be scaled up proportionally, and if you slow it down, the Velocities will be scaled down. So when you scale the playback to 0, the Velocities also scale to 0.
But since you are not the only one who wants to be able to do a single frame/constant Velocity tricks, we added a checkbox a few years ago which reads “Keep Velocity Channel”. It is enabled only when “Load Single Frame Only” is checked, and will produce exactly what you want.
Here is why this feature was originally added to Krakatoa v1.6:
thinkboxsoftware.com/krak-si … stant-mot/
The geometry surface was only brought up as an example, there are other scenarios where I’d like to use a velocity field from a single frame PRT. I thought since I created velocities that show up in the viewport using Magma that the PRT would contain velocity information that was readily available regardless of how its rendered (like in Houdini/Naiad). I’m glad that there’s a checkbox. I will check it out.
Thank you.
Since Krakatoa would not know where the particles came from, we had to program the PRT Loader itslef to KILL the velocities when passing them to the renderer if the checkbox “Load Single Frame Only” was checked. Otherwise, single frame PRTs containing velocity would always produce motion blur, but go nowhere, which would be undesired in 99% of the cases.
The checkbox to keep the velocities was then added to prevent the killing in the remaining 1% where it makes sense to do so 
Also keep in mind that if you are copying Normals into Velocity, you must scale by a factor that converts to Units Per Second.
If you use a value of 1.0, your particles will move only 1 unit over one second. So you have to multiply by an InputScript set to read the FrameRate to scale them correctly.
I think that once you’re now introducing Ember and Stoke that the 1% will grow significantly if my time spent talking to Houdini guys is any indication. As for my own thinking and application, I use single frame PRTs in Naiad all the time and find it extremely powerful. I am only using the PRTs for velocities, not to render, so the motionblur issue is a moot point for me. Going forward, it’s my humble suggestion that you keep this in mind. This is one of the great issues with FumeFX at the moment as to advect velocities into a fumegrid you are forced to use moving particles and I’ve tried, without success, to replicated the spline setup with FumeFX. The only way I can get it to work is with Ember and using Ember Force – which of course we’ve already talked about is pretty slow (please, please get back to developing Ember soon, it’s your killer app IMO).
Hmm, thanks, will keep that in mind. I obviously don’t know how Krakatoa was developed and I haven’t had the time to read all the documentation on it, but (sorry for sounding like a broken record here) I can convert normals to velocities in Naiad and no need for anything else. I just scale the velocities up and down to decide how strong I want the velocities to be after I’ve renamed the normal channel to velocity. It even works if I simple pipe in input normal channel to velocity output in Magma and export it. I’ll see what results I get as I dig deeper.