Hi, can you help me make a simple magma flow to change the particles position slightly?
I want to increase the particles of a realflow simulation without increasing the particles inside RF because it starts becoming very slow and too many particles will make the pressure too high causing particles to explode— (also if i dont import external particles, i have the problem that the realflow object fill emitter is aligning the particles in such a way that i cannot get rid of moire effect even with over 1million particles)
i pretty much want to do a low_particle sim in RF (particlese coming from max) and make a high particle sim out of it in magma flow–
is this possible with floating integert connect to position output? what are the steps to achieve this effect? (could i also partition these particles with random seeds to save time changing integer manually?
i think it would be really helpful for getting high density volumes with low particle sims
would appreciate your help because i am not sure how to continue
The first method would be juttering the positions of the original simulation - this will produce a “spongy” looking cloud.
You can see the results at the bottom of this page: software.primefocusworld.com/sof … uences.php
BUT DON’T USE THE APPROACH described on the page, just look at the images. (the method is quite obsolete).
The current method (since v1.1.2) is described here: software.primefocusworld.com/sof … rtices.php
It works with any kind of particles that can be deformed incl. PRT Loaders, PRT Volumes and Geometry Vertices.
Basically, you add a Noise Modifier on the stack and set the Scale to a very low value (producing very high frequency), then you partition.
The same could be done with a KCM, but there is no real reason to do so since adding a simple Noise Modifier is a lot easier.
Once the KCMs introduce support for advanced data access (including mesh and particle sampling), it might become an option.
You can also use Proxy systems in PFlow Box #3 if you have access to it, but it is quite slow.
We have developed our own internal workflow where we take a low-res system, convert to PRT Mesher, convert that to a Level Set and load the resulting velocity field using our Flood tools, then drive a high-res cloud using the Flood PFlow Operators in a similar fashion to how you drive particles with FumeFX. Obviously, PRT Mesher and Flood are not public so you cannot use this approach.
We are also looking at developing methods to generate huge amounts of particles based on low-res systems on the fly, but this is v2.0 matter and we don’t know if it will happen…
Another thing you could do is simulate a low res system in RealFlow, mesh it in RealFlow, import the mesh in Max and try to fill the volume with particles using PRT Volume. Add a Noise Modifier to the PRT Volume and tweak the positions to remove the grid appearance (in v1.5.2 PRT Volume will have a built-in option to distribute particles randomly without an obvious grid).
Thank you Bobo for the help,
i will try the noise method tonight–
1)the change seed function will work on the noise modifiere as well when creating partitions correcT?
2)also, i have filled an object with 1million particles, but even with 2 million particles i still see “roughness” inbetween, how can i totally fill an object leaving no gaps?
3)would it be possible for future versions to “fill” in the gaps of low particle systems at render time? sort of like voxel rendering smoothing everything out, but just like a composite between the rendered image and the blurred image to add smoothness— (or an algorithm to add pixel in front behind left right )
i will try the mesh method as well, good idea didnt even think of it, and i wasnt even familiar with prt loader, just tried it, for future versions would be nice to determine particle amount instead of spacing, also, i have just tried to put spacing at 0.08 or even 0.1 and max almost froze up, and gave me bad allocation error after couple minutes— (another great addition would be to assign grid propertiers from the start, (with seed function) so one could pick standard grid, and different patterns, fractal patterns!, straight(stackbond) or running bond, and even fill object on edges and vertices with particles , that would really make it flexible, but even now i am really starting slowly to comprehend how powerful and open the krakatoa system is and what possibilities it allows never before possible! /phizikl in love
mesh to particle via prt volume meethod is great, only that i cannot partition it :
Krakatoa Error: errormessage *realflow_bin_particle_ostream: did not write the expected number of particles to file: path\filename.bin" Wrote:2392218 instead of -1 particles
now i try to render the sequence, but it gets stuck on first frame, the realflow bin. sequence importer is animating the mesh over time though, im assuming the PRT Volume will only fill mesh on one frame and not an animated mesh?
now i have a problem, 1)partition doesnt work (maybe because of this static volume state which is not allowing me to render sequence?) and 2)rendering sequence with prt volume doesnt work , can you help?
weird because if i select single frames in viewport render them out individually it loads each frame fine and renders correctly—
This is a known (reported) bug when saving BIN files. It is being fixed soon.
What exactly are you partitioning? You are not supposed to partition anything.
*You take the BIN files in RealFlow and make BIN Mesh files.
*You load the BIN Meshes with the RealFlow Mesher in Max.
*You create a PRT Volume out of the RealFlow Mesher.
*You save the particles to PRT files WITHOUT PARTITIONING - the PRT Volume does not support partitioning because it does not do random distribution and has no Random Seed. And even if you were partitioning, you would be writing to PRT and not BIN.
*Now you can load your PRTs in a PRT Loader, add a Noise modifier on top, set up a high frequency noise as described in the Tutorial (the Noise DOES have Random Seed) and partition that to many more PRT files if you really need more than what the PRT Volume generated.
At this point, if you want your particles back into RealFlow for some strange reason, you could create a single PRT Loader with all PRT sequences and write to BIN (without any culling or modifying which seems to cause the error above). But in general you should never use BIN where you can use PRT.
