I have limited experience with Stoke, so please bear with me if I’m approaching this wrong. Using 2.0.7.55072, max 2013.
I am trying to essentially “Up-res” a realflow sim. It has been saved out as 4 PRTs, which are being loaded with a PRT loader.
I am using the same PRT loader as both the distribution and velocity sources, setting it to emit only at 0, use seed count as rate and new particles only to get a stoke duplicate of the original particle motion. My plan was to then slightly jitter and partition to increase particle count, prior to meshing in frost.
Although all the particles are created correctly on the first frame, they don’t follow the motion of the loaded PRTs. I think the error is coming from the grid spacing. The smallest I am able to set the grid spacing to in the velocity field source is the size of pretty much the entire sim. It won’t let me go lower than 0.1m, metres being the scene scale. The PRT has been scaled to help Realflow, since it behaves oddly at smaller scales.
Is there a way to change that minimum spacing size? If I scale the PRT back up to 100% I get a result which is closer to what I’m looking for, although the motion still isn’t picked up accurately enough to use.
RealFlow simulations (as well as Naiad etc.) usually come in Meters.
But the rule of thumb in 3ds Max is that you should never use a scale that causes you to go below a size of 1.0 Generic Unit for the finest detail. In other words, you should have your 3ds Max System Units set to Centimeters or even Millimeters, and should be scaling the PRT Loader UP 100 or 1000 times (10000% or 100000%) so that the meters become CM or MM. This is due to the lack of Double Precision values in Max.
Since Stoke is running inside of Max and also works at Single Precision, using tiny voxels is not allowed and the minimum size in the UI is capped at 0.1. Of course, with the UI being a script, you could try to edit the Stoke UI and reduce the lower limit to 0.001 or something. But the Max spinner precision, albeit customizable, won’t let you go too low either. So the above PRT scaling approach is recommendable.
In the future, once RealFlow starts saving in PRT 1.1 format, you will be able to set your system units to CM or MM in Max, create a PRT Loader, pick the PRT file from RealFlow and it would scale automatically (and flip the axes, too) thanks to the embedded Metadata. But right now, you need to do the scaling yourself.
The whole of the rest of the scene is scaled correctly (it’s liquid in a glass) so the realflow was being scaled down to fit it. I have a setup that matches the set in the shoot, correct depth of field, etc etc.
I will scale up the PRT to run stoke, and scale down the resulting PRT to render.
So, continuing this I have run into something else.
Stoke only seems to be reading a couple of frames of the motion from the PRT, and then it runs to a stop. Do I have to do something specific in Magma to make it read the velocity and update the positions? I can read the velocity channel in the PRT, but it doesn’t appear in the channel list in the distribution source rollout in Stoke.
The velocity channel shouldn’t appear as a distribution source but you pick it as a velocity field source. Sometimes particles will “escape” the velocity field in which case you need to create velocities to get them back into the velocity field… It’s easy to see by viewing the velocities of the PRT Loader and then seeing if the Stoke particles are escaping or not and if that’s the issue. You also might need to play with Grid Spacing value on the velocity field input. Larger values effectively blurs out the velocities while smaller values stick closer to your velocities. You have to adjust it on a case per case scenario.
If your PRT Loader has frames with 0 particles, or no frames at all, be sure to set the Limit To Custom Range to a valid range that actually contains particles, otherwise the channels might not be read.
Have you considered posting screenshots or videos of what you are seeing? Sometimes worth more than a 1000 words
Even better, if you can share scene and PRT files, we could try to look at the actual data…
Using a higher than 1 Sub-Steps value might also help with the precision of the advection, but I cannot guarantee it applies to your case without actually seeing what is going on.
Tobbeo, the grid spacing is making a difference. I had kept it as small as possible to try and get as much detail into the motion as I could, but increasing it a little seems to get them moving again. I guess they were falling between the grid cells?
Bobo - I sent you a PM with a link to the scene / PRTs, too.
The main issue was wrong scale of the Velocities in the source PRT file (they had 3 times larger magnitude than necessary).
Also, as Sam mentioned, using a slightly larger grid size helped too.
But for what he is after, using the Repopulation feature of Krakatoa v2.3 would be much better, as it creates precise replication of all channels for any number of particles without the need to simulate (it is completely history-independent).
First of all, thanks for the opportunity to be testing stoke 2.0… great tools you’re providing to vfx artists!
Here is my new quick test using real flow sim (blue dots) and stoke 2 using krakatoaprtloader with bin sequence used to give source distribution and velocity (orange velocities - it would be cool to have display as small dot’s also). At the end, we have some “shifting” on their position, but I don’t have the ability to “use node’s transform” like we do in prt loader. Or do we?
I’m assuming if I want to move on z axis, I would have to save this new sim in prt format and load it with prtloader from krakatoa, right?
