Cost Savings Techniques
It may seem counter-intuitive that we want you to spend less money here, but we do. Well, more precisely, we want you to spend less money per render and do a lot more rendering. If you’re doing more rendering, it means that you’re getting more work, and we like to think that the availability of our service is at least partially to credit for that.
So technically we want you to spend more money here, but as a smaller and more frequent percentage of your ever-growing income. With that in mind, we are building a list of techniques you can use to reduce your render times. If you have any new ones that you would like to share, please share them with us by emailing them to email@example.com. We’d love to add them here.
- Render early and often. Don’t wait for your final render to use the farm. We often recommend that people start with boxes to verify that basic layout and animation is good, and begin replacing those objects with higher resolution models, better lighting & materials, etc., and render daily until each sequence is “Good Enough.” It’s better to have daily viewable product than to be sweating at the last minute. This is more feasible today than just a few short years ago; with Unlimited, Flat-Rate rendering, using the ResPower farm daily is affordable for as much work as you care to throw at it.
- If budget is exceedingly important, use Blender: http://www.blender.org/
It’s free and open source, so using it will cost you nothing. And you can render with it at ResPower for next-to-nothing. See Unlimited Rendering for current pricing [requires login]. Its learning curve is a little steep, but that’s the case with any 3D software.
- If you already use another package and don’t want to learn Blender, ResPower rendering can still be had for next-to-nothing. See Unlimited Rendering for current pricing [requires login]. Subscriptions do not automatically renew, so you don’t need to worry about recurring charges.
- Don’t think that a render farm can cure every problem; keep your scene files, objects, and textures as optimized as you can. For example, if you have a 600 frame animation and each frame takes 10 minutes longer than the optimal time, you would waste 120 minutes of “human time” during a 50-node render. That may not sound bad compared to the 100-hour time buildup on a single computer, but if your job is due at 5:00 and it’s 4:00, you may regret not optimizing a little bit more.
- Render at a lower frame rate. For test renders, render the odd-numbered frames and play back at 15 fps. This will be high enough resolution to verify that things look right. If you do the “every-other-frame” approach, then you can finalize a render that looks good by rendering the even frames and merging the two still sequences with a simple “File Move” operation on your end.
- If you can use a reflection map rather than raytraced reflections, do it. In fact, if you can turn off raytracing alltogether, do it. Raytracing is one of the slowest algorithms available for rendering. You should only use it if the reflections absolutely must be accurate.
- If you are using radiosity, it is better to bake it into the scene file prior to uploading. For V-Ray, it is best to build an irradiance map. Better yet, if you can fake radiosity by adding lights, do it. Radiosity is another incredibly slow algorithm.
- In 3dsmax, prefer a few high-polygon objects to a lot of low-polygon objects. For example, I once made an animation with a flying armada of CPUs. In one iteration, each CPU was modeled as a box with a series of cylinders underneath, representing the pins. In another iteration, I used a Boolean OR command to merge all of the cylinders and the main box into a single high-polygon count mesh, and then collapsed the modifier stack. With the second version, the model was manageable on a home PC with 1GB of RAM, even with hundreds of flying CPUs. On the original version, having more than one CPU model was completely unwieldy. I haven’t tested this experience in other packages, but I would expect similar behavior. Most 3D applications seem to be designed to handle large meshes efficiently, but have more trouble navigating the data structures at a higher level.
- Minimize your memory usage. If your render requires more RAM than the render node physically has, the node will use a hard disk to supplement the RAM available. This sounds good, until you consider that hard drives are hundreds of times slower than RAM. This is why it’s called thrashing when a computer starts using the hard disk as virtual RAM.
- Minimize your texture-file usage. Accessing the disk to grab file texture maps is time consuming. It’s much better to use procedural textures when possible.
- Lower the resolution of your texture maps where possible. If you’ve got a 5 megapixel texture map for an object that’s going to take up maybe 1,000 pixels in the final render, your texture map is unnecessarily large. Loading it is wasting resources that could be better spent on other rendering tasks.