common render mistakes of motion graphics artists and freelancers

In the last years, I am seeing more Artists having trouble to larger projects, here are the problems as I see it.

  • the Heat problem. Many artists ignore the heat problem of the hardware. They going to build a custom pc without spending any thought about cooling. GPU rendering runs at high frequency which means it needs a lot of power and produces a lot of heat. The placement of the graphics card is essential so it does not get into the heat stream from the CPU or power supply. Your CPU or GPU should run around 72 degrees. Higher temperatures can damage your card and produce more crashes or the system starts to throttle down.
  • using CPU and GPU for rendering. Using CPU and GPU together is critical and could trigger lots of problems. When the CPU is too busy with rendering it may be impossible for the CPU to feed the GPU fast enough and you could get an overall render slowdown. Also when All Units are running under full throttle you can get easier into heating issues.
  • tx files. Using mid maps Tx files speed up your rendering and saves memory during render time, use it!
  • unoptimized geometry. Spending an extra hour to optimize your geometry can save you hours of render time, crashes, disk space etc.. use instances and render procedural as much as possible.
  • render procedurals. Use render procedurals or file format your render understands natively without the need to translate the geo in a pre-rendering process. For Houdini users, use the sop edit node then you left the path wisdom. 95% of all Houdini TD do not understand the proceduralism of Solaris.
  • separate graphics display. Use a weaker graphics card for display and keep your beefy GPU free for rendering, it saves tons of extra memory on your GPU.
  • too much data in cache files. Use as less attributes as possible in your cache files. Create AOV on the fly in den shader it saves a ton of memory.
  • wrong hardware. Get proper hardware which works together. If you plan a multiple GPU system, get enough PCI lanes and a decent CPU which is able to handle the data transfer for the GPU. Consider buying proper workstations, sure you can get faster machines if you build your own machine. But have a machine that is 30% faster but crashes all the time or battling heat issues etc.? Anyway, the thumb rule for speed benefits with a multiple GPU system:
    • Card 1 100%
    • Card 2 100%
    • Card 3 80%
    • Card 4 60%
  • always using the latest driver and software. Motion graphics artists like to live on the edge and ride shitstorms on social media if something fails, instead of working smarter. The biggest mistake, install daily build and working with it. The is a reason why Blender and Houdini have production builds. Work with the same software version during the project and only update if you really must. Have multiple versions of Houdini or renderer installed, if you wanna try new features. Don’t update your graphics cards, kernels, motherboard or windows version during a project, only update if the new version gives a real benefit.
  • Faster renders do not get your job done faster. To get quick render times, your scene needs to be optimized and your workflow or personal pipelines must work smoothly. Plus your hardware needs to be set up professionally to minimize technical issues. But that’s where most freelancer fails, as soon the things go wrong like hardware issues or dirty render scene on quick iterations then the stress kicks in. If you plan your project with longer render times in the beginning, it increases your error tolerance. Also, it’s a relaxed type of working to set up a render scene and send it over the weekend for rendering. You are sure to get the expected result on Monday because your CPU rendering can handle more significant un-optimized scenes or doesn’t run into heating issues etc. In the end, when you count the extra long hours to fix your hardware and software issues, you could have rendered on a slower CPU as well without the stress. Sure it’s fun to use lasted beta and hardware but also expect bugs and issues and it’s fun to solve the problems. If you are in production, you should fall back to save and solid system, this way you minimize as much as possible technical issues.

but that’s just my opinion!

Published by Heribert Raab

getting stuff done

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s