/3GB switch
Only 2 GB of RAM is allowed per
application in 32-bit Windows. If you have enough physical memory,
you can use 3 GB with the /3GB switch. I urge caution, though,
as my computer was rendered unstartable when I made the change.
http://www.microsoft.com/whdc/system/platform/server/PAE/PAEmem.mspx
http://3dnature.com/faq/index.php?qid=85&catid=41
Animations longer than 99,999
Frames
Default is for 5 frame digits.
Don't forget to increase for longer animations.
Network rendering options
This topic has been brought up
many times on the WCS user list. Despite our best efforts, there
still seems
to be confusion.
Users have 2 basic options when
rendering across a network. It doesn't matter whether you use
SC or not. The options remain the same.
1) Run WCS from a rendering 'server'.
Map the 'server' WCS folder as the same drive on the server and
all clients as described in the SC tutorial. This method is easy to set up and
removes the need to keep track of Paths and copy files across
the network. Users that follow this method will have the fewest
problems. Disad: Possible network slowdown.
2) Run WCS locally on each client.
The easiest (and my recommended) way to use this method is to
copy the entire server WCS folder to the same drive on each client.
That removes the need to keep track of Paths and leads to the
fewest problems. Disad: Lots of copying across the network.
Other methods are variations
on these two themes, or worse yet, a cross between them. Choose
that path at your own peril. I cannot stress this enough. Keep
it simple. Or ignore the wisdom of experienced users and perish.
If you stick to one of these
basic configurations, you will have the fewest problems. If you
choose to mix, match, and confuse the setup, you're asking for
trouble. And the more you complicate matters, the harder it will
be for anyone to help you troubleshoot it.
Network rendering with SuperConductor
Before SuperConductor, this section
was longer. Now, you just follow the tutorial and render! A few quirks have been
reported. My farm machines run Windows 2000 Server, XP, Vista,
Server 2008, and Windows 7.
- Follow the tutorial to the
letter. Render farms can be flaky if you don't do everything
just right. Some users find prayer and/or sacrifice helpful.
- Network and server traffic can be factor. Dedicate a server
and don't use it during rendering. WCS is set up to automatically
retry file access failures five times within a few seconds to
avoid this problem. Unfortunately, if the server is unresponsive
for too long, an error will occur and the affected node will
stop rendering.
- Problems apparently linked to Win98 and WinXP were reported,
but I haven't had any.
Some other things to keep in
mind when using SC.
- If you have lots of client machines, this can mean lots of
network traffic. At some point this will slow the network down.
Projected planimetric images
VNS only. Camera Editor >
General page > Projected. Choose a Coordinate System from
the dropdown list.
Reducing render time with
effect_block_init (VNS 3)
The Advanced Config Option effect_block_init
may reduce render time if you have complex vectors covering a
large area with multiple DEMs. It performs vector processing
once per DEM using only the vectors that impact that DEM. I know
of no disadvantage to using this option and recommend it for
all projects.
Render Speed
If you haven't already, check
the Interactive
Reference Manual for
tips and speed. The manual is ALWAYS a good place
to start.
Here are some obvious and not-so-obvious
places you can cut render time.
General
-Change camera elevation, pitch, etc., to reduce the amount of
visible terrain.
-Use terrain data with high enough resolution but not higher
than you need to create the look you want.
-Use textures where they add detail but don't use them gratuitously,
they will add to rendering times. Use 2D textures instead of
3D if you can. Some texture elements take longer to render than
others so do rendering tests and choose texture elements that
give you the look you need but render the fastest.
-Do render tests while enabling and disabling various components
and see which ones add significantly to rendering time. Then
see if you can streamline the render intensive ones to them to
make them more efficient.
DEMs
-Tile terrain
-Use the largest grid size you can get away with.
-Disable DEMs you can't see.
-Use vectors to limit shadows to the near camera area only.
-Render in segments for high resolution projects. Disk swapping
slows things down.
Terrain Parameters Editor
-Use Fractal Depth Maps for animation and stills that use shadows;
use the Variable Fractal setting for other stills.
-Set Maximum Fractal Depth as low as you can, but high enough
to break up terrain polygons sufficiently.
-Increase Maximum Pixels per Polygon (I generally use 2 but you
can use decimal amounts).
Draped Images
-Limit high-resolution orthos to areas where detail is seen;
use low-resolution images for distant terrain.
-If many orthos are used, mosaic them.
Camera Editor
-Use only the number of AA passes you need.
Shadows
-For all shadows (Shadow Effect
Editor, 3D Object Editor, Cloud Editor): select the Use File
checkbox.
Ecotypes
-Don't use a higher Ecotype density than you really need.
-Use Image Object Distance Dissolve.
Image Object Library
-Select Keep in Memory Long and Load Fast options
on the Image page.
3D Objects
-Set the render quality as low as you can get away with but high
enough to produce satisfactory results.
Render Options
-Disable Render Diagnostic Data on the Enabled 2 page.
You won't need it if you're rendering final output. This will
free up valuable memory and may head off memory-related errors.
Reducing VNS 3 Polygon Merge
Times
-If you have many thousands of polygons and vectors over a large
area, you may encounter long "merging polygon" times.
Try adding the effect_block_init advanced config option in the main Prefs
window with a value of yes. This will enable more complex
(but newer and less-tested) code that may process your geometry
faster. If that doesn't help, you can render using VNS 2-type
rasters by deselecting the Vector Polygon Rendering Enabled
(Common) checkbox on the General tab of the Ecosystem Editor.
This is a global setting so all Ecosystems will use the older
one-Ecosystem-per-polygon method. This method is not as precise
as vector polygon rendering but it's faster to evaluate.
Segments
Highly recommended for large
images. In fact, you may not be able to render them otherwise
(see Errors).
-Number of segments should divide
evenly into height.
-Use plenty of Bottom Overscan to prevent chopping off foliage
between segments. For VNS users, try Tiled Rendering with several
Tiles in X and a Tiles in Y value of 1. In this case you'll use
Side Overscan. It usually takes less Side Overscan to accomplish
the same results as regular segment Bottom Overscan. After all,
foliage tends to be vertical, so vertical Tiles make sense.
-Reflections do not work well with segments. I repeat (for those
who disregard this warning), water reflections do not work well
with segments. Water can only reflect what's in rendered view.
Each segment is rendered on its own so it can't reflect anything
in other segments. That means segment seams within the final
image will have mismatched reflections. To work around this limitation,
render another job with n+1 or n-1 vertical segments. This will
give you coverage along the original seams. Combine the two images.
-If you need to render in segments, memory is at a premium. Disable
Render Diagnostic Data on the Render Options Editor Enabled
2 page.
Tips for Reducing Memory Consumption
Even if you have plenty of RAM
(more than 2 GB per cpu or core) and make it available for Effects,
you'll eventually hit the silly Windows 32-bit limit (2 GB or
3GB for large-address aware apps) or 64-bit limit (4 GB for large-address
aware apps). Those of us old-time animators from the early days
of desktops learned the art of trimming projects to render them
within strict memory limitations. For those youngsters accustomed
to the brute-force method of computing: learn to be lean!
-Search these hints for memory
-Chris Hanson's memory-saving hints at 3DNature.com |
