 |
How To: Cut Render Times and Costs
Cost Savings Techniques
It may seem counterintuitive 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 support@respower.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
available every day 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.
- Make sure you have a high-speed Internet connection. ResPower uses a 10 mbps
fiber optic connection, and will likely be upgrading by the end of 2007, so
the odds are your end will be the bottleneck, especially if you're on dial-up.
- 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.
|
|