Rendering on a budget

[jim c]

For those of us not working for ILM, Framestore, etc, with access to renderfarms, what would be some good tips when trying to create photo-realistic animated renders with very limited resources. Lets say for arguments sake you're limited to a single computer with 12GB RAM, and 8 3ghz cores, plenty of disk space, and a decent gfx card (Quadro 4K). The idea would be to have renders of less than 10-15 minutes per frame. I realize that sounds crazy, but if you have a render that takes an hour per frame, you're obviously highly unlikely to ever complete the animation in any realistic time frame.

For example, in an interview with Ridley Scott, he talks about tricks he used to make the sets of Alien look better despite his limited budget, things like using dark sets, lots of smoke, etc. These things helped obscure the set a bit and prevent noticing parts that wouldn't bear close inspection.

Are there equivalent tricks that you would do with Mantra? Even to the point of say, choosing to use a darker scene rather than a more brightly lit one? Texture tricks? Try to do as much as possible in post? If so which parts make more sense to do there? Is relighting in post worth the effort?

Some things I'm already sort of aware of (not that I necessarily know how to do them):

- caching geometry to disk, especially stuff that's either a complex SOP network, or that's simulated

- depth map shadows as much as possible.

- possible consolidate all textures to just a single texture map? Is that practical, possible?

- reflection is a must have, but it get's expensive. You can make this faster with a reflection map, correct? Are there certain ways to "cheat" on this that are more effective than others?

[pclaes]

Here are a few tricks I can recommend - mostly to do with volumes:

- thicker volumes are faster to render than transparant volumes. This is because you can lower the opacity limit on your mantra rop. Also the stochastic sampling helps speed up things (see sidefx masterclass on rendering volumes).

- surprisingly shadowmaps are not always faster than raytraced lights. PBR in h12 is quite fast so do a speed comparison.

- consider rendering your smoke at half res with a sharpening filter, then scaling them up in comp and blurring them a bit if they don't need to be well-defined.

- volume step size is key! Measure the division size of your volume. (bbox_sizex/divisions_in_x), your volume step size should not be lower than your division size or you are wasting samples without adding more definition.

- volume division size is also important. A good rule for final quality results is to aim for about 1 voxel per pixel -- but that is only true if you need very defined smoke ( swirling smoke or pyroclastic dust). So choose your render resolution and stick with the pixel rule -- no need to sim higher if you won't see it.

- a low amount of pixel samples will speed up your render, but will create some noise - consider/try degraining in comp. (If you have motion blur you can get away with quite low pixel samples as your volumes get blurred anyway.)

*) Clustering:

- clustering 5 sims is generally faster than 1 huge sim. Yes, there is some overlap, but it is faster to work with in your scene, lighter to iterate as you only see a subsection of the entire volume.

- Before rendering, volumemerge the 5 sims into 1 before you start rendering (if you can -- on current hardware I was not going over 800.000.000 voxels as things were getting really slow - this is based on feature film (2K resolution) production quality so this number will be way too high for you per volume - especially considering you will have a lot of other things in your scene besides volumes), this can make a big difference in render speed. I think this has to do with the way the opacity clipping works, between 1 object or between 5 objects in case you render 5 volumes.

- if you are dealing with a lot of different smoke scenes where you need smaller smoke puffs here or there. Render your smoke with RGB lights around it so you can relight them in comp. Render the same volume from a few different angles and render a longer framerange so you can use it as a re-useable element in comp and track it or dress your scene with it -- a lot of the times background atmospherics is scene dressing and layering a bumch of elements to create a new shaped volume can work quite well (This works in 2D as well as in 3D in case you have some more extreme camera moves).

[lukeiamyourfather]

There are lots of ways to cheat and reduce render times depending on what is being rendered. If you can share specifics about the scene it would help to narrow down the possibilities. Though when push comes to shove there are limitations to what can be done with a single machine in terms of quantity and quality. That doesn't mean you need 1,000 render nodes to get good stuff. Five or ten nodes can make a tremendous difference, hell, even one node makes a tremendous difference.

Having the right tool(s) for the job is paramount. Faster turn-arounds means more iterations which translates to higher quality work in the same amount of time. Mantra tokens are free with a Houdini license and HQueue is free as well so the only cost to setup a small render farm is the machines themselves and basic infrastructure (gigabit switch, cabling, etc.). It seems stupid to me to not take advantage of that. If the budget can accommodate the license of Houdini and the workstation then adding a few nodes at $500 each shouldn't break the bank and could greatly increase the rendering throughput (double, triple, quadruple, or more).

I realize the question was about optimizing renders but I think its important to point out that setting up a small farm is less expensive and easier than most users realize (a large farm is another story). Something else to consider is rendering using cloud computing like HQueue on Amazon EC2. The costs can get quite high in the long term but for extra help to get a project out the door it can be perfect.

[jim c]

Peter, thanks!

Luke, I didn't make this very clear, but this is specifically aimed at those of us doing projects as hobbyists. There's no money involved, hence paying extra for things is difficult to manage, since it's not really likely to lead to anything. By definition this means *not* having the right tool for the job, hell there is no job!

That's why I'm asking, giving a really constrained, limited hardware situation, what are things you can do to cheat or get things "good enough"? I began to think of this as I watched the interviews of the VFX guys for Bladerunner, and they talked about all sorts of "shortcuts" that they used to make the fx work, given the constraints that they had at the time. So I thought surely a hobbyist is in this kind of situation, and perhaps there might be some unique things that we can do to work around these limits?

Peter mentioned 2K film resolution, which raises an issue of size, perhaps limited your render sizes to 1080HD as a max? That gives you the option for 1080 HD and also allows 720HD if you want.

[kwejk]

forget PBR. Use the Raytrace engine for scenes that realy need good fast raytrace. (lot's of glass, water)

otherwise go with the Micropolygon engine. Bake out point clouds / photons for lighting.

Also use DepthMaps. If rendered with a smart shadow shader they can look just as good as raytraced shadows.

Realy understand your render engine. Dicing, Samples, Shader Quality, Z-Importance, Irradiance, Point clouds, SSS Caches.

Learn how to diagnose renders to find out what needs tweaking.

Convolved HDRI mipmaps saves lot's of time making environment calls just a call to a mipmap level and not a ton of tracing for soft reflections.

Ass for textures. big is bad, especially for farm rendering. At work we use 3Delight, also a micropoly renderer.

We generate directory textures. Every mipmap level is one file in that directory. That way the computer on the farm only need to read the texture mipmap (ex. 1mb ) and not a 40meg texture. This speeds up network rendering a'lot. Don't want your renders failing och slowing down bacause of network overload.

I se so many people go with PBR because it is the easy way. And the renders end up noisey after hours brute force rendering.

Write your own shaders if possible. That can save you a lot of Time. If you made it yourself you understand it

Basicly learn how to use a REYES renderer like PRman, 3delight or Mantra.

Edited May 11, 2012 by kwejk

[jim c]

Thanks, those are some great tips! I've heard of mipmaps, but don't really understand how to use them or make them. Any tips for doing so within Houdini? If I'm already converting the png textures to .rat, is this taken care of for me?

[edward]

Awhile back, Mantra would automatically convert non-RAT textures to RAT textures internally to ensure correct filtering. In H12, non-RAT textures are now directly mipmapped and filtered without conversion. So basically, in H12 you can be assured of correct filtering (ie. quality) regardless of your texture format. The real question is whether it is more efficient/faster to use non-RAT textures (less memory off disk, slower sampling) VS RAT textures (more memory off disk, faster sampling). My uneducated guess is that this will differ depending on your specific hardware, mantra cache size (texture/geometry caches are unified in H12), and the amount of memory needed to render your image. If your textures can fit in the OS disk caches, then your disk accesses will be super fast once swapped into RAM.