GarageFarm's plugin couldn't handle the tyFlow cache, the submission failed silently and I lost 2 hours troubleshooting. On iRender, I uploaded the caches directly to the server's SSD, pointed 3ds Max at them, and rendered all 300 frames in 65 minutes for $18.40.
Last Updated: May 2026
Heavy simulation caches are the hardest thing to move to cloud and the reason IaaS farms exist for VFX. My last tyFlow particle destruction scene generated 18 GB of cache files for 300 frames. My Phoenix FD fluid simulation: 32 GB of VDB caches. GarageFarm’s plugin couldn’t handle the tyFlow cache, the submission failed silently and I lost 2 hours troubleshooting. On iRender, I uploaded the caches directly to the server’s SSD, pointed 3ds Max at them, and rendered all 300 frames in 65 minutes for $18.40. The server’s 256 GB RAM loaded the Phoenix VDB caches that crashed my local 64 GB machine. For heavy sims, IaaS isn’t just better. It’s often the only option that works.
| Sim Type | Typical Cache | RAM Needed | Upload Time | iRender | GarageFarm |
|---|---|---|---|---|---|
| tyFlow Particles (simple) | 2-5 GB | 32 GB | 5-8 min | Works | Usually works |
| tyFlow Destruction (heavy) | 10-25 GB | 64-128 GB | 15-30 min | Works | Cache path fails |
| Phoenix FD Liquid | 15-40 GB | 64-128 GB | 20-45 min | Works (256 GB RAM) | Plugin misses VDB |
| Phoenix FD Fire/Smoke | 5-15 GB | 32-64 GB | 8-18 min | Works | Supported |
| tyFlow + Phoenix Combined | 20-50 GB | 128+ GB | 30-60 min | Works (verify paths) | Too complex |
Why Do Heavy Sim Caches Fail on SaaS Render Farms?
Two reasons. First: SaaS farm plugins collect scene files, textures, and proxies, but simulation caches are stored in separate folders with absolute paths. GarageFarm’s plugin for 3ds Max looks for textures and bitmaps, but tyFlow caches stored in D:\Cache\tyFlow\ get missed because they’re not standard texture references. The plugin doesn’t know to look there.
Second: RAM. SaaS farms distribute frames across multiple machines, and each machine may only have 32-64 GB RAM. A single frame of my Phoenix liquid sim requires loading the full VDB cache for that frame plus adjacent frames for motion blur often 4-8 GB per frame in memory. My local 64 GB machine couldn’t handle it. iRender’s 256 GB servers load it without breaking a sweat. RebusFarm actually handles Phoenix FD better than GarageFarm. Their support team manually configured cache paths on my third project with them, and it rendered clean.
How Long Does It Take to Upload 30+ GB of Simulation Caches to iRender?
On a decent connection (50+ Mbps upload), 30 GB takes about 35-45 minutes through iRender’s transfer tool. That’s the real hidden cost of heavy sim work on cloud, upload time is billed. A 30 GB upload plus 65 minutes of rendering equals roughly 110 minutes of server time, or about $15 in billing beyond the render cost itself.
My workaround for repeat projects: I leave my sim cache folder on the iRender server between sessions. The server template preserves my files, so the next time I boot up, my 32 GB Phoenix cache is already there. I only re-upload when the simulation changes. This cut my effective upload overhead by about 70% over a 3-week production. The one caveat: iRender charges storage for data on inactive servers, but at less than $0.50/day for 30 GB, it’s negligible compared to the upload time saved. GarageFarm doesn’t offer persistent storage, so every submission re-uploads the full cache.
This is where I render heavy sim scenes with 256 GB RAM → Try iRender for tyFlow & Phoenix FD
FAQ
Can I render tyFlow simulations on GarageFarm?
Simple tyFlow particle effects usually work. Heavy tyFlow destruction with large cache files (10+ GB) often fails because GarageFarm’s scene collection plugin misses the cache folder. TyFlow stores caches in custom paths that aren’t standard 3ds Max texture references. Fire/smoke particles without external caches generally render fine. For heavy tyFlow work, use iRender or Xesktop where you upload caches directly and verify paths on the server. If you must use SaaS, RebusFarm’s support team can manually configure cache paths for you.
How much RAM do Phoenix FD liquid simulations need on cloud?
Typically 64-128 GB per frame, depending on VDB resolution and motion blur. My mid-complexity liquid simulation used 72 GB per frame, impossible on my local 64 GB machine, comfortable on iRender’s 256 GB server. A simple fire/smoke sim might only need 16-32 GB. The RAM spike comes from loading adjacent frames for motion blur: the renderer loads the current frame’s VDB plus 1-2 neighboring frames simultaneously. If your Phoenix sim consistently crashes locally, check your RAM usage, cloud rendering with 256 GB may be the fastest fix.
How do I reduce upload time for large simulation caches to cloud farms?
Three strategies. First: leave caches on the cloud server between sessions. iRender’s template system preserves files, saving re-upload time (cut my overhead 70%). Second: compress VDB caches using half-float precision instead of full-float, typically reduces file size 40-50% with minimal quality loss for fire/smoke. Third: only cache the frame range you’re rendering, not the full simulation timeline. A 300-frame render doesn’t need frames 301-1000 on the server. These three combined took my typical upload from 45 minutes to about 12.
You may want to read other articles of mine here.
Image source: RedefineFX | Jesse Pitela
COMMENTS