|
|
|
The rendering time in Terragen
written in collaboration with Oshyan Greene Software and hardware considerations Terragen is a photorealistic rendering software. In creating images with this application, you will quickly discover that if you want to display a landscape with the maximum level of details on the sea, on the land, and in the sky, you will be confronted to very long processing times, hours, and even days in some extreme conditions. The processing or CPU time depends on many parameters, both software and hardware. In collaboration with Oshyan Greene, a skilled Terragen user who manages the Ashundar website, we are going to describe all parameters affecting the speed of processing. In order to compare Terragen settings, we must use an identical processor. In order to compare processor speeds we must use an identical Terragen scene. Mixing the two can easily cause errors in thinking or measurement. We must thus describe separately the software and the hardware aspects. Software considerations Describe first sofware factors. If we consider a given platform (constant processor speed, memory, video, cache, etc) what elements of a Terragen render affect CPU time the most ? We must distinct two classes of objects : - Scene elements like the terrain size, the cloudscape size, water details, etc. - Render settings like the level of detail, extra blended detail, render resolution, etc. Sorted by decreasing importance, from the most penalizing to the less important, we can list 7 factors that affect the rendering time. As all factors that we will describe, they support a direct comparison in benchmarks : 1.
Render resolution 4.
Atmospheric and cloud accuracy settings Let's review each item in separating the list into scene elements and render settings. 1. Render resolution The render resolution affects all scene elements equally because Terragen makes not difference between elements. Indeed, scene elements affect the default settings render in slowing down more of less quickly the overal processing speed depending on the require accuracy. Generally speaking, concerned elements are the water, the land and the sky (atmosphere and clouds). For example, if you increase the cloud or the atmospheric accuracy, this object becomes water, sky, or land, depending on its level of details, altitude, color, texture (bumpiness), density and transparency.
Water is the key of our concern. If by any chance you set up some waves and shore (foam), the water will require always a longer processing that any other surface because it has to rerender any element that it reflects or includes, with added effects like distortion and refraction. In average, the water accuracy makes it takes 4 to 10 times longer to render than an equivalent area of land. The water also takes longer with higher distortion (large roughness and/or wave size), effects like "Water Works" or SOPack "Height Ripples", and if you set up a lot of transparency with a high visibility (and refraction) of underwater surfaces. Terrains take longer the larger they are of course, but thanks to the "front-to-back" rendering method, the difference has been reduced in most scenes since v 0.9x, excepted in orthographic renderings. Estimating the render time The render time is directly proportional to the number of pixels being rendered. For a constant level of detail, if you double the resolution, changing from 800x600 to 1600x1200 pixels, you quadruple the render time. Why ? Because the surface of your image is became 4 times larger. If each pixel takes the same amount of time to render, they are now 4 times more numerous (1.92 Mpixels vs 0.48 Mpixels). This generally proves itself in normal real-world tests as well. This increasing of the render time is very significant and noticeable when you create very detailed images in high resolution. In these conditions you quickly pray to have a fast computer and much memory ! Personally, one month after have created my first images, I upgraded my system with a processor twice as fast and I installed twice as more memory. A way to get a rough estimation of the render time is to calculate the time required to preview the image with all details at a medium resolution (e.g. 640 x 480 pixels). Displaying the image at a medium resolution with all level of details, to get the processing time of the high resolution image you multiply the render time by the square of the enlargement ratio (41x from 640x480 to 4096x3072 pixels). Or you can render the image at the nominal resolution (4096x3072 pixels) but with a medium level of details. To get the processing time for the highest level of detail, multiply this time by about 150 (in minutes). For example, a preview that lasts 1 minute at the medium level of detail in 1024x768 resolution means that the rendering will last about 150 minutes or about 2h30m in the same resolution but with highest accuracy. However, this last calculation is not accurate As we told, to get an accurate estimation you need to preview the image with the maximum level of detail, but depending on the use of not of the "cloud cast shadows" and other smoothing feature, the render time can be much longer, even in preview in 200x150 pixels (the render time can last say 45 minutes disabling these options, and can be 4 times longer if such options are enabled). A calculator taking only into account the number of pixels to plot (thus applying the first estimation) is available on Kranky's RZB website. For short, since the render resolution affects *everything*, it is the main penalizing factor. If you double the render resolution, you quadruple the render time, so no matter what your render time for your "base scene", this will always increase it to a great degree. The same is true about the level of detail and extra blended detail; a lower detail landscape will take *much* less time to render than high detail landscape.
2. Extra blended detail As its name tells, extra blended detail (EBD) concerns an additional level of detail that enhances the resolution. It is accessible in the Render Settings window. EBD increases the render time by about 3x and affects all non-sky elements equally. It affects land and water, but if a significant portion of your render time for a scene was spent on sky before turning on EBD, and there is no water in the scene, turning it on will probably only increase the overall render time by 2x or so. EBD does operate on water, and since water already takes much longer to render than land or sky, using EBD and water together, especially with high detail cloudscape, can be a real killer, even on the fastest systems. Note that the "Extra" and "Blended" detail features, what we usually call the "cool options", are only accessible in the registered version of Terragen. A must if you are looking for the best image quality. 3. Number of surface map Each layer of the surface being superimposed to the all landscape, it affects the entire terrain. Each of them adds fairly significantly to render time - the more you have, the longer the render. One simple benchmark did by Oshyan Greene resulted in a render time 1:05 for 1 surface vs. 7:05 for 12 surfaces ! Recent benchmarks have shown this can be highly variable; the case mentioned is probably a bit extreme. Greene guesses that, for the land only, you might experiment an increase of about 20% for each additional surface map layer. 4. Atmospheric and cloud accuracy settings These factors affect not only the sky appearance, but reflections on water as well. Using near default settings for the sky (small cloudscape less than 1000 m, 2D clouds, normal atmospheric and sky accuracy, etc.) the render time is pretty quickly. But as soon as you increase either the level of detail, the accuracy, turn on the 3D clouds, "Clouds cast shadows" or increase the cloudscape size beyond about 20,000 m, the render time starts to go up a bit, but it is not huge. Really large skies, 150,000 m and up, take a noticeably longer time to render, and so this may be one thing contributing to lengthy render times. According to test made by Greene, it is more to do with how much cloud is visible, not just the cloudscape size. With no clouds, the landscape will render very fast. Also being close to the sky layer can increase render time. Increasing atmospheric and/or cloud accuracy can have a very dramatic effect on render time, depending on the scene. For example, if there is water in the scene, because it reflects the sky, the increase will be very large, since not only the sky now has more to render, but also the water which is reflecting it. And since water already takes longer than any other element, it is really something to try your patience! Atmospheric accuracy affects many elements, and is generally the most important setting in terms of sky accuracy controls. Primarily, it affects strength and clarity of rays (the more accuracy, the more defined are the edges between light and shadow), as well as the sharpness of cloud shadows cast on the ground. It also affects the likelihood of banding in the sky.
Atmospheric and cloud accuracy generally give fine results at default settings. If clouds are the key elements of your composition, turning their detail up to the maximum is a good idea as they focus all the intention. However, the accuracy doesn't generally affect ray clarity or strength, but only the "internal" detail of the cloud structures, so it's a detail that not everybody change. In some cases, with extremely large skies for example, you will get "banding" or other artifacts in the clouds, and in these cases turning up cloud detail will usually help. If bands do not disappear in the final image, you will need to blur this part of the sky, if it is possible, for example in using the "smart" blur tool in Photoshop. The landscape size affects also the haze density and water wave size. Haze density can affect rendering time, but it is not so significant a factor as to justify being particularly concerned with it. Defaults settings are fine for general scenes, without rays or cloud details. But if you are trying to get really nice, defined rays, or if your cloud cast shadows on the ground and appear "muddy" or ill-defined, you should increase this setting to improve the result. This is one of the more demanding accuracy settings in terms of render time, however, particularly with water in the scene, which reflects the sky as discussed above. See Oshyan Greene's article about the atmospheric accuracy for more details. 5. Terrain size Measured in points, the larger terrain (4097x4097 for example instead of 513x513 points) will take longer to render, but this duration is highly dependent on the point of view of the camera. Today Terragen uses "front-to-back" rendering which does not draw parts of the scene that are behind other parts. So if you have a large mountain directly in front of your camera, and lots of mountains behind it, the large mountain will cover up the others, and render time will not be that much greater for a larger terrain because most of the scene is in the foreground, where there is not much more data than on the smaller terrain. Of course if the shadows of the foreground is light enough to display some level of details, its renders will last longer. Working with a large foreground is an extreme case, but this rendering method does mean that larger terrains have a lot smaller impact in "average" scenes than you might normally think. However, on orthographic renders, or ones with very high camera perspectives where most of the terrain can be seen (as planetscape or a landscape seen from orbit), the rendering will takes a longer time. With a normal "ground level" perspective this is much less noticeable and significant. 6. Ultra antialiasing After the Quality accuracy, the second parameter displayed in the Render Settings window is the Anti-Aliasing group. Associated to the fast sub-pixel smoothing it offers an anti-aliasing method that helps in smoothing stair-edge polygons. Ultra Anti-aliasing increases render time by 15-25%, but the visual improvement is almost always worth it. In practice, the speed hit when using it is hardly noticeable and I generally leave it on, even for previews. 7. Fast sub-pixel smoothing By default the anti-aliasing method is enabled in the Rendering settings window. Its objective is to smooth the stair-edge aspect of polygons. The fast sub-pixel smoothing gives great anti-aliasing result. Not only it corrects "stair-edges" but corrects shading errands too in lower detail levels. The resulting image looks fluent and much professional that the raw rendered output. However, its activation is paid by a slight slow down of all renderings. Hardware considerations
After have described software factors that affect the render time, hardware bottlenecks can emphase all the problem when you render heavily detailed landscapes. There are two main factors to consider : the CPU speed and the amount of memory. CPU considerations Given identical Terragen settings, what CPU/system renders fastest ? It is not so useful to predict that a 4 GHz processor is faster than a 1 GHz; the faster processor of a given family will of course render faster... The speed of the processor should not affect whether the program will freeze, or cause reboots. If a slow system is stable, properly cooled, and has the system resources (memory, mostly) to render a given scene, it will render it without any doubt, just much slower than faster processors. What is more important for speed is the type of processor, the brand and family. AMD Athlon's for example are faster than Intel P4's but not always compatible will all your peripherals. To check. The only thing to keep in mind is that Terragen often seems "frozen" although it's really just working hard. So, don't disturb it ! This would of course be enhanced on a processor running slowly, say under 500 MHz with less than 256 MB RAM (v0.9x), 512 MB RAM (TG2) and 1 GB (TG3); Terragen will be like frozen but it will not really be. The render may take up to several days, but it would finish, all other things being equal. Now, if you work with other applications while Terragen is rendering a high resolution scenery, the time shared by the CPU between applications can extend a rendering lasting 1 hour when it works alone to several days if you simultaneously work with Office programs, and other graphic editors. Note that the temperature of your CPU and other electronic components of your computer is a critical factor that affects the good functioning of your computer, hence the use of a fan on both the CPU and on the cabinet to extract the excess of heat. These are not simple accessories; they are mandatory and must remain operational if you want that your system works in good conditions. We usually say that every 10°C rise in junction temperature will cut the mean time between failure (MTBF) of a semiconductor in half. So, as we all expect a very long life for our computer, better to use oversized and powerful fans, and why not adding an extra fan on the cabinet if you noticed that your system is rather hot after have used it heavily. Memory considerations After the CPU speed, the second major bottleneck is the amount of memory required to render high resolution images. Large terrains will cause problems, but except for the largest terrains (8193x8193 points), you only need about 32 MB of memory for terrains. The render buffer set at 64 MB by default will cause more problems on low memory machines, and so it should be decreased. Settings of 5-10 MB should not cause problems in most circumstances, and so should be used in favor of larger settings in memory-limited circumstances (e.g. using v0.9x on a 500 MHz CPU equipped with 256 MB RAM or 1 GB RAM with TG3, and trying to render at high resolution in 1024x768 pixels a 513x513 points terrain with a very extended landscape and cloudscape). Good to know, the available memory has no effect on the ability to render high sky and atmospheric detail. If your system lack of memory, (e.g. you only have 256 MB RAM or less to run v0.9x or 1 GB for TG3 generally speaking, especially on newer operating systems like, the rendering will just get very slow, as the computer will rely more and more on swap file space on the hard drive. You may get a "Your computer has run out of memory, Windows is increasing the size of your swap file" message if you have it set to manage your virtual memory automatically (this is the default). This can be adjusted by changing the swap file settings of the OS, of course. Usually its size is equivalent to the 2 times your memory, so 500 MB of swap file for 256 MB RAM. But generally, an extreme slow down is preferable to a crash... But in some circumstances, if the memory is really too low (say 256 MB RAM for TG3 instead of 1 GB, the rendering will start but the application will close without warning after some minutes of work. At last, when creating static renderings, the fact to use a low-end or a high-end video board does not much affect the render time. Fast graphic boards are mainly required when you have to handle tens of frames per seconds, like for example running a flight simulator that has to show fluid movements without erratic behaviours and slow down in refreshing scenes. The minimum rate for the last version of Fligh Simulator to prevent these jerky moves is about 20 frames per seconds, the highest the best. Only high grade video boards support these speeds. Hence their use in high-end home computers and graphical stations. For Terragen this problem only appears if you create 3D animations that show the same constraints as the scenes displayed in a flight simulator. So if you have to buy a new computer or have the possibility to upgrade your old model, even if you don't use dynamic simulations yet or don't play with vectorial games, Google Earth or simulators, I warmly suggest you to buy a fast video board. In fact, my own tests confirmed that on two similar computers running at the same CPU speed and using the same amount of RAM, the one using a faster video board seemed faster to the end-user than the one using an ordinary video board. The fact to refresh the screen faster has thus a direct impact on the overall computer speed felt by the user, even if the processing time is identical on the two systems.
By way of conclusion A benchmark is always a very difficult task to plan if you want to be complete and impartial. The analyst must well known the product under test, make a difference between software and hardware influences, and create a test protocol well representative of the average use of the application. If you only work with small terrains using standard settings it is possible that you be never confronted to memory problems and severe slow down. On the contrary, if you mainly work on a small PC to create very detailed landscapes you will soon or later be face to resource problems. A good benchmark must take into account as many as parameters as possible, a scene including land, water and sky, and for each element several details, surface maps, and parameters like transparency of water, color, sky size, etc. The objective of a benchmark is to be compatible with the largest scenes as possible. It must thus be as independent as possible on the particulars of a scene. All that being said, you understand easily that in multiplying some or all the above factors together, over 40 interdependant parameters on about 100 currently available under Terragen, we can get dramatic increasing or decreasing of render time. If most renderings can be achieved in a reasonable time (some hours), the most complex images require at lot of patience. So, before launching your final rendering, try to reduce the most resource hungrier settings like the accuracy, the number of surfaces, the size of the terrain or the one of the cloudscape, etc. If the image keeps all its details, you won and you have saved some CPU time. Hope this helps. Good luck ! For more information about Terragen benchmarks Portefolio Terragen (renderings) Terragen homepage, Matt P.Fairclough at Planetside Ashundar Terragen Community, Oshyan Greene Yahoo! Terragen group (forum) KK3D website I thank the members of the Yahoo! Terragen group and specially Oshyan Greene for his advice. Back to the Portefolio Terragen Back to Art - Back to Reports & Reviews
|
||||||||||||||||||||||||||||||||||||||||||
