Would be great to have an option to specify a different blend radius according to the velocity of the particles. Could make interesting results in realflow stuff.
Are you trying to get a particular effect? For example, are you trying to connect fluid into strings without creating artifacts near a bigger pool?
I’m currently testing meshing with Realflow’s grid fluids which is working very nicely, but what I’m suggesting could give better control and realism to any type of an effect. Say a regular realflow splash effect made out of SPH particles- you could have better blending control of the shape at the core of the splash compared to the splashing particles that already broke apart.
Using a KCM, you can already do this effect.
Are you sure? As far as I can tell Frost can change it’s particle radius according to a radius channel (which I’d also be happy to know how to do in KCM using realflow bin files) but anything that has to do with blending parameters - anything that’s under the Zhu or the Anisotropic rollouts - can’t be driven by custom channels. Even if the velocity data is loaded in the KCM how can you tell the blend parameters to use it?
Currently the blend parameters are global, so they can’t be set for individual particles. We will probably change the Zhu/Bridson blending at some point, because it can give strange results when combining particles with different radii. Anisotropic meshing is also a bit of a work in progress. I’ll make a note of your suggestion.
Unfortunately I don’t know RealFlow as well as I’d like to. Does RealFlow let you control individual particle radii, or is there a particular .BIN file channel that you’d like to use as the radius?
No, Realflow meshing also treat the radius of each particle as a global size. In Houdini however, you can basically hook up any channel to any parameter you want so for example the resolution of the mesh can be higher only in the areas where the particle’s neighbors data is higher. Same goes for blending strength and distance etc. The major downside with Houdini is that it’s much slower. I guess the most useful channels to drive within any of the parameters would be neighbors data, age and velocity. Would be really great to have such functionality in Frost even if it behaves slower.
Another thing worth mentioning is that Realflow can export particles as PD files. The PD format was introduced in RF5 to support Renderkit’s mesh generation in max. Renderkit has two mesh generation types, the first is the one you can create inside Realflow and the other one is mesh generation in max that’s created only in the render. You can’t see it in the viewport (thus no caching is possible) and apart from being quite buggy it also only works with MentalRay which is a major disadvantage.
I don’t know if the PD files are any better, but as you see in my attachment it lets you choose which channels to export. Perhaps it can read and deal with those channels faster.
Isaac.
The data exposed in RealFlow’s BIN particle files is:
[]Position[/]
[]Velocity[/]
[]Force[/]
[]Vorticity[/]
[]Normal[/]
[]NeighborCount[/]
[]TextureCoord[/]
[]RealflowInfoBits[/]
[]Age[/]
[]IsolationTime[/]
[]Viscosity[/]
[]Density[/]
[]Pressure[/]
[]Mass[/]
[]Temperature[/]
[]ID[/]
Using a Krakatoa Channel Modifier (KCM) on a PRT Loader loading your BIN files you can access any of these channels to make your own Radius channel for Frost. If you aren’t familiar with KCMs, here is an introductory tutorial: thinkboxsoftware.com/krak-in … magmaflow/
Simply make the output node in your KCM write to a channel named “Radius” and tell Frost to “Use Radius Channel” and you should be good to go.
Here: http://www.realflowforum.com/view_topic.php?pid=31724 is an example of a KCM using the RealFlow Vorticity channel to color particles. You should be able to adapt it to set their Radius value instead.
Variable meshing resolution is on our wish list for a future release.
I’ll need to take a look at “neighbors”. I’m curious if that is simply the neighborCount as in .bin files, or if it actually lists the neighbors according to RealFlow.
If we do expose blending radius (etc.) per-particle, Krakatoa will be the way to control it, as Darcy described above. I still need to take a look at Houdini – their Blending Distance may be equivalent to our Radius for Metaballs.
Valuable post that list would be nice in the Krakatoa .bin documentation. For custom channels is it the same as it is listed? ie Upper/Lower case ect. I know most are already exposed but I am just curious.
The definitive source for documentation on RealFlow file formats is C:\Program Files\Next Limit\RealFlow 5\doc\file_formats.
When accessing these channels in Krakatoa, use the exact spelling from the list. In general we name exposed particle channels LikeThis, but that is merely convention. Your custom channels can be almost anything. At some point it may enforce valid PRT file channel naming which is described here: http://www.thinkboxsoftware.com/krak-particle-channels/
Should have guessed, thanks for that. I rummaged through all there online docs, the help file, and the script reference, but never thought to look in the app root folder for additional docs.
Darcy, Thanks! Yes I already noticed bobo’s thread re using KCM’s to feed Frost’s radius channel shortly after starting this thread. Works very well! Just wish other parameters could be controlled like this. Yes I know PixelPro as well for a long time. Not too many FX Artists in Israel. 
Paul, I’m glad to hear you’ll check houdini out. I’m not a houdini person myself, but I’ll try to get a working houdini scene file for you guys to check out that shows all the advantages I mentioned.
Keep up the amazing work!
Isaac.