Particle Cache File Research Maya and Softimage

I have spend some days to do lot of simulation/cache file/render tests.
Different cache file types, network and local caching, direct shader and application cache loading.
The test was intented to get some numbers for high-particle count simulations. (whispy smoke, fine detail, small particles without texture...).
I got a bunch of isolated numbers including simulation times, cache write times, compression times, network<>local copy and write times, render time, preprocessing....
I tried to time every step seperately in the pipeline.

As a result I only present a short table with some combined production relevant numbers.

Parameters used to project the test results to a production environment

Scene Sequence Size The scene has a length of 500 frames Simulation time per frame (no caching) 3s/frame (0.3 FPS simulation speed) Render time per frame 5 min/frame Network render caches only I only present the times for render caches that you store on a fileserver.

Test Enviroment

• Windows XP64
• 4 Cores, 3Ghz
• Gigabit Network, write: 31MB/s, read 34MB/s
• All applications testen in 64bit

One conclusions first

• Caching local+copy OR network:
  Caching directly on a network drive is slower than caching local and then copying the files to the network.
  You only get half the MB/s if you cache to the network.
  Maya:
        Caching to the network is 2x slower than caching local + copying the files.
        Local caching is recommended
  XSI:
        The files are compressed, if you write the files local the slowest part is the compression.
        So caching to the network is only 15% slower than caching local + copying the files.
        The speed increase it not that much, so I would not do it.
        Directly saving into the right network directory is less error-prone.
        And if you manually copy the cache files, then you loose these few minutes you got (between the sim is done and you start to copy).
  

XSI 5 mio particles

Cache Types

Name Total Cache Size Description Attributes included None 0 No cache files used, always re-simulated. IceFull 77 GB Default XSI cache file, exported with... 1. Simulation environment caching 2. ICE cache node 3. Plot->Geometry cache: (Cannot export ID,      required for UVW texture coords) 14: Age, Position, Density, Color, EmitLocation, Force, ID, LocalTime, Mass, Orientation, Velocity, Scale, Size, SimulatedTimeFraction IceSmall 26 GB XSI cache file with specified parameters, exported with... 1. ICE cache node 2. Plot->Geometry cache: (Cannot export ID,      required for UVW texture coords) 2: Position, Color (RGB+A) Bapt 26 GB IceSmall converted into .bapt format. 3: Position, Color (RGB), Density(A)

Simulate phase

Cache Type Times h:m Description IceFull 4:11 cache local + copy files to network IceFull 4:39 cache to network IceSmall 1:33 cache local + copy files to network IceSmall 1:46 cache to network Bapt 2:39 cache local + convert files local to network Bapt 3:20 cache to network + convert files on network

Render phase

Cache Type Cache loaded by Times h:m Times 10 machines h:m Memory usage (shader and scene particle data only, no vol shader or other scene data) Description None - skip existing - 43:28 5:56 1815 MB skip existing frames. None - send in chunks - 88:41 8:52 1815 MB send in chunks of 25 frames. IceFull ICE node* 47:33 4:45 1024 MB IceSmall ICE node* 44:19 4:26 750 MB IceFull Geo shader** 44:27 4:27 627 MB IceSmall Geo shader** 43:24 4:20 525 MB Bapt Geo shader** 43:21 4:19 524 MB

*: Non-simulated (!!) ICE tree with cache node. Frame input of cache node set to expression 'Fc'.
**: The Geometry shader used was the BA_PT_Loader shader.

Conclusions

• .uncached rendering:
  Uncached rendering the whole sequence in one go is faster if you render on one machine, but as soon as you use multiple machines, it is slower. Exspecially if you render in chunks. Same applies if the skip-frame render has to restart at some time.
• .icecache format:
  The Icecache format is pretty good and small. There is no big advantage in using a native shader format. But you should only cache what is required, see IceSmall description. For whispy smoke you probably need only position and density (Export only the alpha, your cache files are reduced a lot).
• BA_PT_Loader geo shader:
  Render Time: Loading .icecaches with the BA_PT_Loader geo shader improves the render time per frame only by 6s/frame.
  Cache file size: The .icecache file size is the same if you load the caches via XSI or the shader. Memory usage: You save some ammount of memory if you use the geo shader. MR Compability: You can render the .icecaches with MRay in any software, you are not restricted to XSI.

Maya 2.5 mio particles

Cache Types

Name Total Cache Size Description Attributes included Pdc 345 GB Default Maya cache 17: lifespanPP, finalLifespanPP, emitterId, age, birthTime, particleId, mass, lastWorldVelocity, worldVelocityInObjectSpace, worldVelocity, lastWorldPosition, worldPosition, acceleration, lastVelocity, velocity, lastPosition, position. Bapt 27 GB Maya cache converted into .bapt format. 4: Position, Age, ID, Velocity

Simulate phase

Cache Type Times h:m Description Pdc 10:16 cache to network Pdc 5:20 cache local + copy files to network Bapt 3:40 cache local + convert files local to network

Render phase

Cache Type Times h:m Times 10 machines h:m Memory usage (shader and scene particle data only, no vol shader or other scene data) Pdc 43:04 4:18 281 MB Bapt 42:41 4:16 280 MB

*: Non-simulated (!!) ICE tree with cache node. Frame input of cache node set to expression 'Fc'. **: The Geometry shader used was the BA_PT_Loader shader.

Conclusions

• Although in this test results show that reading the huge maya cache files is not a drawback at render phase, I doubt that it will be the same in a production enviroment.
  This test was done with one machine reading the cache file from the fileserver.
But if a lot of render machines are loading 1Gb cache files every frame, your network will slow down.
• Do not cache Maya directly onto the network. Generate them local and copy them.
• Default Maya cache files are huge with a lot of not required attributes. If you want to use them, you should write a custom mel exporter to export only required settings. But they are still huge and slow even with less attributes.
• Writing a c++ plugin for maya to directly export .bapt files would 2 times faster than the current "local cache+convert".

Follow ups

• .bapt exporter:
  XSI:
  I have a layout exporter for XSI, but the improvement to .icecache exporter is not significant and you cannot load .bapt files into an ICE tree for a visual feedback in your render scene.
  Maya:
  I do not have enough maya c++ object access experience to develop such a plugin.
  But if anyone has enough experience to access the particle data within Maya, let me know.
  
•