fumefx to frost slow

Become a member of the CGSociety

Connect, Share, and Learn with our Large Growing CG Art Community. It's Free!

Thread Tools Search this Thread Display Modes
Old 11 November 2012   #1
fumefx to frost slow


I have been having a strange issue using a fumefx to frost. The workflow that I am using is, do the fumefx sim,use the PRT Fume FX and save as kraktoa prt and then put that PRT in the frost. I am trying to do a toon like smoke effect. The problem is that when I put the prt in the frost its unsually slow, specially in anisotropic mode. it seems to be better in the other modes but its still slow, which is unusual as my prt only has a maximum of 500K particles at the peak. Its it slow both rendering and previewing in the viewport even at low resolutions. while rendering it gets stuck at about 50% of pre processing frame for a while before it renders. Has anyone experienced this before? In a straight pflow frost can easily handle 2mil particles.

Old 11 November 2012   #2
Obviously your Frost settings make a big difference this is the results I got for each of the different loader methods.

  • Max2013 x64 +SAP Nitrous ( wireframe only I don't have my frost license with me)
  • Frost 1.3.4
  • Krakatoa 2.1.5
  • Avg Particle count 100k at frame 100 for all sources
  • The scene consisted of general default grid (100x100x100 spacing of 1.0 + Simple Source, all params default)
  • Each Frost is set to Zhu/Bridson Size of 1.0, all other params default.

PRT Loader
Version: 3dsMax 15.000
Start: 0f \ End: 100f
Total Duration: 100f
>-----< Pass# 1 >-----<
Time taken: 21.663s
Average FPS: 4.61617
>-----< Done >-----<

Version: 3dsMax 15.000
Start: 0f \ End: 100f
Total Duration: 100f
>-----< Pass# 1 >-----<
Time taken: 33.215s
Average FPS: 3.01069
>-----< Done >-----<

Pflow - Krakatoa ops + PRT Loader
Version: 3dsMax 15.000
Start: 0f \ End: 100f
Total Duration: 100f
>-----< Pass# 1 >-----<
Time taken: 29.531s
Average FPS: 3.38627
>-----< Done >-----<

Pflow - FumeFX ops
Version: 3dsMax 15.000
Start: 0f \ End: 100f
Total Duration: 100f
>-----< Pass# 1 >-----<
Time taken: 26.304s
Average FPS: 3.8017
>-----< Done >-----<

With the exception of a straight PRT Loader, all others are fairly consistent of course the gaps will spread as counts and mesh density increase but they are all in the ballpark.
poof ~>Vimeo<~

Last edited by JohnnyRandom : 11 November 2012 at 04:48 PM. Reason: Small Correction
Old 11 November 2012   #3
Hey thanks for running those tests. Those times seem more of what I would expect I am getting the slowness even in blocky low res frost meshes. Do you think it could be due to the low spacing of my fume sim?
Old 11 November 2012   #4
Is your FumeFX Preview Window open and/or set to GPU? Or the FumeFX VP display on?

That will definitely slow things down with everything else going on.

I would also suspect that Realistic viewports with mesh and AO would bring speed down too.

What plugin/max versions are you using?
poof ~>Vimeo<~
Old 11 November 2012   #5
I am using max2012 and fume 2.1 and version of krakatoa. I am not using the nitrous viewport. The thing is I have saved the particles to disk and I am not using the PRT fumefx, I have gone to a new scene with only the PRT loader and frost.
Old 11 November 2012   #6
That should be pretty perky in a fresh scene. What about your hard disk IO? Is you cache drive fast? or worse slow and full?

I would rollback my plugins and retest in max2012 if it weren't such a PITA (new machine and only have the latest builds installed where I am at) I can try again later when I get home and see if I get any significant changes.
poof ~>Vimeo<~
Old 11 November 2012   #7
The drives are fine. I have tried this in another computer with the same result. I thought I might be missing a step while using the prtFume FX. I am going to try saving the particles by putting it through pflow and saving it that way.
Old 11 November 2012   #8
It is as simple as Saving to Sequence the PRT FumeFX in Krakatoa.

Are you saving a ton of channels that you may not need? Position, velocity, density, ID are all you really need, of course temp, fire, fuel, density gradient are useful but not necessary. I am pretty sure you could get away with just position/velocity.
poof ~>Vimeo<~
Old 11 November 2012   #9
I was saving using the default settings, which included position,velocity,color,normal, and id. I did some further testing and I think its just that my computer can't handle more that 20k particles for close to real time display of the frost mesh and in general i guess the anistotropic mode is slower than the other modes. I think when dealing with large particle counts the smallest change makes big difference to the speed of the frost things like radius size etc. so i guess the key is to find the balance between quality and acceptable speed.

I am using AMD Phenom x6 1055T machine with 8 gigs of RAM.

Thanks for your help!
Old 11 November 2012   #10
Anisotropic is a touchy meshing algorithm it can be quite fast but the wrong settings will make it dead slow, I wish it also had some type of frame to frame check (mesh calming ) that would keep the mesh from disappearing so rapidly when the stretch reaches its limit, it causes a bit of flicker. I love the thin sheeting you can get with it, that mesh just needs to be stabilized somehow. I digress

Also note the Frost is a ram monster, you can nearly instantly consume all of your available system ram! I have seen 24gb gobbled up on a mid resolution mesh, fast! If your run out of sys ram your performance falls of a wall like a brick.

Open up task manager and monitor your 3dsmax.exe process and watch how fast Frost uses it, it seems to be pretty well optimized too, you get good performance in max until you go over the max system memory.
poof ~>Vimeo<~
Old 11 November 2012   #11
A few things that were partially mentioned already:

*Anisotropic mode has to search for neighbor particles for each particle to average their data and perform the stretching accordingly. It is always slower than all other modes. If you can get the look you want using Zhu/Bridson with a higher Blend Radius, you should get faster results. You can even drop a Relax on top to smooth things out.

*You don't need a PRT Loader if you are meshing a PRT file. It only makes sense if you are using Magma modifiers or deformations. You can simply pick the PRT file in Frost itself - this will reduce the memory overhead since the particles have to be loaded just once.

*Apropos memory, what JR said about memory usage is not exactly "Frost memory usage", it is the 3dsMax TriMesh generated. The actual meshing process uses only the memory needed to load the particles and about 500MB for the meshing algorithm. Once the final TriMesh is generated, it is passed to Max and can choke the viewport graphics display or the renderer. If you would collapse the Frost to an EditableMesh, its memory usage would be about the same. So Frost itself isn't using much memory to generate the mesh, the resulting mesh is what eats it up... Just wanted to put things in perspective.

*You don't need an ID channel when saving PRT FumeFX or PRT Volume to file, since that channel does not exist for non-simulated particles. (PFlow and TP have an ID channel). No need for Density or Normals either.

*When not in Anisotropic mode, Frost should not be affected much by the spacing of the particles. Of course, if the particle count is low (one particle per FumeFX voxel) and the meshing Radius is lower than the voxel length, you would get separate droplets per voxel and thus more polygons which would produce a larger mesh surface, higher memory usage and relatively slower processing time per frame. But if the Radius is high enough for the droplets to merge into a large blob, all particles inside the blob will be nearly ignored and only the surface ones will matter. So I would suggest a very counter-intuitive experiment - try to enable the Subdivisions of the PRT FumeFX and set the Subdivisions count to 1 or 2 to subdivide the FumeFX voxels and produce 8 or 27 particles per voxel instead of just 1. This will obviously create millions of particles, but will reduce the distance between the particles. Try to mesh this higher count system and see if it affects the meshing times in either direction. The PRT reading time will be slower, but the meshing time might go down if your issue is the distance between the particles...

Finally, I would not expect real time meshing from your setup. Meshing 10 million particles from a LIDAR scan takes about 30 seconds on my machine. Assuming linear performance scale, I would assume that 1 million would need about 3 seconds, and 500K could need 1.5 seconds. This is still orders of magnitude faster than BlobMesh in Max, and usually a few times faster than pWrapper.
I haven't seen exact numbers in your posts (just "slow" and "a while", which are not defined - are we talking 10 seconds, 30 seconds, a minute, several minutes?), or an example scene we could test with. Providing these might help us help you...

Last edited by Bobo : 11 November 2012 at 06:39 PM.
Old 11 November 2012   #12
Hey Thanks both of you for all your tips and suggestions. In the end I switched to zhu/bridson mode. But I was able to get a much faster result in the anitrosopic mode adjusting the radius size. so I think the counter intutive method that bobo mentioned would work .

I will be adding some RAM soon I know I am expecting a bit too much performance from what I have.

Here are some stats

Default Settings Union of Spheres
STS: Statistics for frame 168.000 (Frost001)
STS: Particle count: 206757
STS: Face count: 157458
STS: Vertex count: 78747
STS: Update time [s]: 0.958

Default Settings Anisotropic
STS: Statistics for frame 168.000 (Frost001)
STS: Particle count: 206757
STS: Face count: 55312
STS: Vertex count: 27700
STS: Update time [s]: 102.660

The difference is quite big in the update time thats why I was wondering if I was missing something. I am used to Frost being fast, Blobmesh is a now just a distant unpleasent memory.
Old 11 November 2012   #13
Originally Posted by Bobo: *Apropos memory, what JR said about memory usage is not exactly "Frost memory usage", it is the 3dsMax TriMesh generated.

Thanks for clarifying that That is an important distinction. I will state it properly next time.
poof ~>Vimeo<~
Old 11 November 2012   #14
Thread automatically closed

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.
Thread Closed share thread

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Society of Digital Artists

Powered by vBulletin
Copyright 2000 - 2006,
Jelsoft Enterprises Ltd.
Minimize Ads
Forum Jump

All times are GMT. The time now is 05:06 AM.

Powered by vBulletin
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.