View Full Version : Krakatoa blockiness
th3ta 03-12-2010, 06:57 PM just started messing around with fumefx, pf, and krakatoa. Can anyone explain why my particles cloud looks so blocky? Is it a spacing issue within the FumeFX Simulation parameters?
|
|
just started messing around with fumefx, pf, and krakatoa. Can anyone explain why my particles cloud looks so blocky? Is it a spacing issue within the FumeFX Simulation parameters?
Several things can be a factor in this case:
1. Density is too high. You can see this by the heavy shadow artifacts. Try changing the Global Density down by one or two orders of magnitude (e.g. from 5.0/-1 to 5.0/-2 or 5.0/-3) to see if that will smooth it out.
2. When rendering FumeFX as Voxels, each FumeFX voxel gets converted into exactly one particle which holds all data of the voxel like color etc. Then you render as Voxels in Krakatoa and if the voxel size is the same as the FumeFX grid's, you would get one particle per voxel. A voxel is a cube in space. To smooth things out, we provide an additional Filter Radius parameter which lets you interpolate values over the neighbor voxels - the default value of 1 does no smoothing at all, so it is a lot like "Nearest Neighbor Filter". A value of 2 or 3 will probably give you a much better look, but it will also make it slower.
To get really good looking rendering of FumeFX, it is advisable to use a lot more voxels in the simulation itself, thus providing higher resolution of the simulation and more particles that can go into smaller Krakatoa voxels. Of course, this will slow down the simulation, but right now it is the only way to get higher quality from direct FumeFX rendering. In the future, we might provide ways to increase the number of particles per FumeFX voxel like we do in the PRT Volume, but right now you cannot do much about it.
Another thing that is possible to do is saving the FumeFX as particles to disk first, then loading the PRT sequence in a PRT Loader, adding a Noise modifier with a very small scale to produce high-frequency noise and saving several partitions of that PRT Loader to new PRT files. (see the tutorial on our site (http://software.primefocusworld.com/software/support/krakatoa/partitioning_existing_file_sequences_and_vertices.php)). This will give you a denser particle cloud out of a less dense FumeFX grid that you can render with smaller voxel size in Krakatoa, or even as particles.
Yet another thing many people do is create PFlow particles and drive them through the FumeFX sim using the FumeFX PFlow operators. See the animations by Matthias Mueller for example...
Hope this helps.
th3ta
03-15-2010, 02:15 PM
Thanks so much for the suggestions Bobo. Hope to get this sorted out this week.
Nardatronic
04-01-2010, 08:28 PM
Are you exporting the velocity data in the fumefx sim as well as the smoke, it's in the first fumefx tab ("general", if memory serves).
Burritoh
04-10-2010, 12:43 AM
Thanks for the insight, Bobo.
So if we use FumeFX to drive PFlow, how much does the resolution affect Krakatoa's rendering then? I understand about rendering Fume sims directly, but if Pflow is tossed in there, I wonder if the original Fume sim's resolution makes any real difference?
Thanks for the insight, Bobo.
So if we use FumeFX to drive PFlow, how much does the resolution affect Krakatoa's rendering then? I understand about rendering Fume sims directly, but if Pflow is tossed in there, I wonder if the original Fume sim's resolution makes any real difference?
When driving PFlow particles with FumeFX, the voxel size of the sim plays a lesser role. The particles use the velocity data in the voxels, so the voxel size is not directly obvious. You can think of it as of dust particles in a tornado - the air is moving and the particles are being blown around, so even if the velocity stays the same throughout a large voxel and then changes significantly from one voxel to the next, the particle's motion will be relatively smooth.
So the FumeFX sim resolution should be fine enough to capture the detail you want (eddies, swirls, occlusions etc.) while being fast enough to simulate in a reasonable time and with reasonable disk space usage.
CGTalk Moderation
04-10-2010, 01:01 AM
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.
vBulletin v3.0.5, Copyright ©2000-2012, Jelsoft Enterprises Ltd.