The biggest are our renders, the more RAM are used by the process.
Size of the render seems to be the most important for the quantity of RAM.
But I guess that details and AA can modify the needed RAM.
Is there a mathematical rule from a specific sized render to evaluate for modified Details and AA the needed RAM in more or less.
Weird question i guess, another brainstorming while waiting for a render.
David
Rendering is a process that involves many systems, many of which need to use RAM with varying amount depending on many factors. It won't be possible to quantify all of them here. But I'll start with some of the most important ones I can remember off the top of my head.
All of the following will use RAM, so these requirements add together. The list is not exhaustive by any means, so actual RAM use will be even higher.
1) Final image, including render elements.
RAM is proportional to the image size (width times height). It's also proportional to the number of render elements (approximately). Most render elements use 12 bytes per pixel. So a 1000x1000 image will use 12 Mb per render element. RGB and Alpha elements are always rendered. So a 1000x1000 image will always use at least 24 Mb. A 5000x3000 image will use at least 360 Mb. A 5000x3000 image with 10 render elements (including RGB and Alpha) will use about 1.8 Gb. Some combination of render elements that don't need 12 bytes per pixel may be packed together so the total may be slightly lower.
Final image RAM use is *not* affected by anti-aliasing (AA) settings.
2) Buckets while render is in-progress
RAM use for subpixels in a bucket is proportional to the number of pixels in the bucket, plus some necessary padding/overlap pixels. That is then multiplied by the square of the Anti-aliasing number. It is also multiplied by the number of render elements. Additional buffers are used for Depth of Field, GISD, anti-aliasing bloom, and a depth buffer for occlusion calculations. Each of those additional buffers is proportional to the number of pixels in the bucket plus padding pixels, and proportional to the square of the AA number. GISD buffers may re-use render elements already in memory or may require additional buffers. So it's hard to define exactly how much they will use. There will be other requirements I've forgotten to mention.
With threaded rendering there are usually more than one bucket rendering simultaneously. So you can expect RAM use to increase with increasing number of threads.
As long as "allow auto reduction" is enabled in the Bucket Controls (and it is by default) then the number of subpixels in each bucket should cap out at 1 million subpixels (not including padding/overlap between buckets), so even with very large images or very high anti-aliasing the RAM use per bucket should not climb excessively. However, very high AA values will still use more RAM than low AA because of the padding/overlap area of each bucket, whose number of subpixels is proportional to the square of the AA number and also varies with other factors such as anti-aliasing bloom, DoF method and pixel filter.
RAM used by buckets during rendering is freed when the buckets finish.
3) Anti-aliasing bloom, if enabled, requires additional buffers that are proportional to the size of the image (in addition to anti-aliasing bloom buffers per bucket). These buffers are freed up when the render finishes.
4) GISD, if enabled, requires additional buffers that are proportional to the size of the image. Which buffers are allocated depends on what render elements are already available (because they were enabled in the GUI), so GISD may or may not increase RAM usage. Any allocated buffers will be freed up when the render finishes.
5) 2d motion blur, if enabled, requires additional buffers to be allocated temporarily when the render has almost finished, to perform a post process. Additional motion vectors need to be generated during the render, if the user hasn't already enabled motion vectors as a render element, but they can be freed when the render finishes if the user didn't enable the motion vectors element.
6) Subdiv cache. The RAM used for the subdiv cache should never exceed the "size of subdiv cache" parameter in the render settings. Depending on number of threads, scene complexity, lighting complexity, image size, render detail and other settings in the "subdiv cache settings", the actual RAM use of the subdiv cache may reach the prescribed limit or it may stay below. If you enable "preallocate subdiv cache" then it will always use the prescribed amount of RAM. This RAM is freed when the render finishes.
Please note that we don't recommend changing the "size of subdiv cache" parameter without seeking advice from us first, if you have a particularly challenging scene. In general you should stick with the default which is set when you start a new project (assuming you use our factory default project). On the 64-bit version it varies with the number of cores detected on your system (we also recommend that you use the 64-bit version). With 8 detected cores (e.g. a Core i7 processor) the default is 1200 Mb. With 16 detected cores the default is 1600 Mb.
7) Many other rendering systems. There are other ray-tracing data structures that use amounts of RAM that depend on the complexity of the models in the scene, caches of various sorts, and many, many smaller components that all use RAM that may depends on various parameters. There are probably some big RAM hogs that I've forgotten to mention.
8 ) The scene in memory. Objects, populations, shaders (especially ones that load images), heightfields and heightfield operators, etc. all use RAM before rendering even starts. However, populations that are already populated and objects/images/heightfields that are already loaded into Terragen should not use a lot more memory when rendering starts - the renderer just uses the data already loaded.
9) The 3D Preview has some memory requirements of its own, before rendering even starts. Closing all 3D Previews before you start a render can often free up a good chunk of RAM. This can vary with scene complexity and shading modes, and to some extent the number of cores detected in the system.
10) Other components of the system and general application overhead.
I haven't covered everything, and I may have forgotten some important factors. Generally, there isn't really a simple formula for estimating the RAM use of a render, not even roughly. However, a big factor is image size (width times height) multiplied by the number of render elements. Perhaps equally important are the complexity of your models and the number of instances in your populations. But each of these factors are, for the most part, independent uses of memory, not compounding factors. Anti-aliasing shouldn't usually be such a great burden on RAM, but there may cases where it does. Of course AA does greatly affect render times in many cases.
Matt
Thanks a lot Matt . Many questions got their answers here.
I'm very grateful for the time you spent to explain all this points
Thanks again David
Quote from: Matt on January 06, 2014, 04:04:33 PM
Please note that we don't recommend changing the "size of subdiv cache" parameter without seeking advice from us first, if you have a particularly challenging scene. In general you should stick with the default which is set when you start a new project (assuming you use our factory default project). On the 64-bit version it varies with the number of cores detected on your system (we also recommend that you use the 64-bit version). With 8 detected cores (e.g. a Core i7 processor) the default is 1200 Mb. With 16 detected cores the default is 1600 Mb.
One more question about this specific point. I have the 64-bit version and i7 Core processor with 8 detected cores. I have one computer with 1200 Mb and one other with 1600 Mb.
Do you mean that with a 8 detected cores, there is a max-limit of 1200Mb (same with 16 a max-limit of 1600MB) ? Or is it a only a default and on a computer with 1600 Mb how can it be changed ?
David
Indeed thanks, Matt. Very informative. I need to be careful when rendering out the museum wall in high resolution, so this makes me think. You say alpha is always rendered; can I not turn that off, if I don't need it? I never use an alpha layer.
I'll also check out he AA bloom, how it affects the image, and whether I really need it.
And 2D/3D blur is ticked by default in the render node. Should I disable that, or is it the other blur settings in the camera that are off.... is that enough not to have it taken into account, I mean?
The default scene should scale the subdiv cache to be proportional to the number of cores by an internal ratio. You can change the number, there is no maximum, but we *do not recommend doing this*. In fact we may remove this setting in the future as it's seldom actually needed and often misused. If however you get warnings that the size of the subdiv cache is too small, then you would need to manually increase it (this would likely be because you were loading a project from someone else who changed it manually, or using a non-standard default project).
- Oshyan
Not having it may not be wise. If I work on a file on my32-bit 2gig machine, and open it to render on a 64-bit 16gig machine, the subdiv cache is the same as set in the first machine, so I have to manually increase it. It's probably saved with all other settings.
If we remove the setting, we'd probably just make the cache *always* auto-adjust, rather than respecting the TGD settings that were manually set. So problems like the one you're describing wouldn't happen anymore. And indeed this is yet one more reason to remove this feature IMO...
- Oshyan
Quote from: Dune on January 07, 2014, 03:40:31 AM
You say alpha is always rendered; can I not turn that off, if I don't need it? I never use an alpha layer.
It can't be turned off.
Quote
And 2D/3D blur is ticked by default in the render node. Should I disable that, or is it the other blur settings in the camera that are off.... is that enough not to have it taken into account, I mean?
3D motion blur (the default) does not use any extra RAM. It may affect render times, but only by a very small amount if there is no motion. The impact on render times depends on how much motion there is. It's probably still best to turn it off for your project.
2D motion blur does use extra RAM and processing time, even when there is no motion, but if there is no motion it processes fairly quickly.
Matt
Thanks, guys!