Hi
As we know Pflow is single threaded, and obviously the FumeFX follow is single threaded too . Since we can sample FumeFX as particles and saving all channels (“Including the velocity per voxel”) in a much optimized tree structure “PRT files” than the FXD files, theoretically we could simply skip the Pflow if:
We could have a node in the KCM which queries certain information from the second prt loader which could be the FumeFX voxels sampled by krakatoa for example geting information from the closest particle in the reference PRT loader which would be the FFX voxel. In this case we could get velocity data and update those in the KCM !.
It does, but there are some elements currently missing from Krakatoa to make this work, and it could be politically problematic, too.
*First, we would need either a particle acceleration structure (particle kd-tree) or a simpler voxel grid structure to stuff the PRT data into and then sample data from. We have discussed that before in a different context, so it is a possibility.
*Second, we would need a History-Dependent PRT object that can track particle data from the beginning to the current frame in order to perform the integration / advecting. We actually had an inhouse prototype that was about 3 times faster than PFlow on an 8 core system for doing the same basic simulation. I wish it were 8 times faster, but I suspect the MagmaFlow used was not complex enough to saturate all cores.
*The above mentioned prototype could not add or delete particles though - it started with a single PRT file and then drove the particles around. To do what you are asking for, we would need emission capabilities and conditional deletion capabilities. In other words, we would be recreating some of what PFlow/TP already do, and this has never been our goal or intention.
In a voxel grid the position can be uniquely determined for a particle by an integer ID. For example pos (x,y,z) in a grid with dimensions l, w, h can encoded as
ID = x + l * (y + w * z)
.
You don’t have to sample position to position. For the high density particles, you convert their position to a set (8?) of ID’s that you need to look up, along with weights. So instead of finding the nearest sparse particles by position, you are doing it explicitly by ID, and that’s simpler.
It wouldn’t be much different than doing texture lookups, just that we’re encoding the texture to a long 1D array of IDs.