Except's Wesleyan Museum Rendered using LightWave 9.5 in 8 minutes on a Dual E6600 using Final Gather interpolated radiosity with fairly standard settings (2.0/100 MPS, 200 primary rays, 40 secondary rays, 4 bounce, 300% strength, 50% multiplier) at 1280x700.

LightWave 3D uses two and a half different methods for radiosity calculation. The first one is Monte Carlo, the second Final Gather, and the 'half' is background radiosity. Backdrop radiosity is a special variant of the Monte Carlo method, hence the 'half'. Each of these three variants can be used with the tick box options, for various uses, speeds and levels of quality and physical accuracy, giving you a broad range of control options to suit your particular needs. It will pay off taking the time to understand the difference of these methods in order to get fast, clean and accurate results. Good radiosity settings will get you fast and smooth results. Bad settings are usually either slow or ugly, or both. Learning how this works is not that hard, and requires only little experimentation with a simple scene, such as the one I'm using for this explanation.

What's new in 9.6?
9.5 brought us animated radiosity, per object Gi settings, the GI multiplier, and vastly improved speed and quality. 9.6 on the surface seems to add only a few options, but it again raises the bar for speed and quality. Internally the engine has been tweaked even further, and the 'sweet spot' for your settings has gotten a lot larger. Improvements in the sampling algorithm ensure more consistent performance, and the 'use bumps' and 'use gradients' options expand user control. The 'use bumps' especially is a very powerful feature that solves many issues of the past. Also, the radiosity analysis flags have now been embedded into the interface for easy access, which is a great help to set up your GI perfectly and to understand what is going on under the hood. The RenderQ script was added to provide a single-click cache workflow as well as other great uses.

LightWave 10 improves on the radiosity algorithms and methods explained here, but does not depart from its user operation. The guide is therefore essentially the same for version 9.6 and 10, but in general LightWave version 10 will produce better results.

The term for radiosity calculation in LightWave is radiosity preprocessing. We can discuss it in terms of two stages, although in reality there is more going on, but this is all you need to know to deal with it effectively. Below these two stages are explained.

Stage I: Placing samples

When using the interpolated option, which will be in 99% of all cases, LightWave places samples in the scene depending on the geometry detected. This process is explained here.

Min / Max MPS Samples are placed close to geometry changes and more widely spread on large even surfaces. The major setting for sample placement is the Minimum and Maximum Pixel Spacing (MPS) setting. This defines the range that samples are allowed to be apart in terms of output resolution of the camera. While the samples are thus placed in relation to the camera resolution, the samples are attached to geometry. It's like shooting sample points through the camera after which the stick to whatever they were shot at. This process makes primary evaluation points. In stage II below the rays are shot, but the primary rays (those that were shot from the primary evaluation points) also generate evaluation points if they hit a spot where there is no other evaluation point close enough. These secondary evaluation points are also controlled by the MPS settings. The secondary rays shot from the secondary points do not generate evaluation points. They sample what they hit, pass down the value and then the sample is discarded. The below diagram shows two primary evaluation points (purple) and three secondary ones (gray). The secondary evaluation points inform the primary ones through the primary rays (RPE), and they in turn get their illumination values from the secondary rays (SBR). The blue circles are planar to the camera's field of view and represent the MPS ranges. The below image shows the relationship between min. PS and max. PS. The green dots are evaluation points (both primary and secondary). The one on the left has a large range (1.0-100 mps) and the one on the right a small range (30.0 - 60.0 MPS). You can see that when min and max come closer together the samples start representing more of a grid in relation to the camera. Setting them further apart allows samples to crowd around areas of higher importance and large even areas to have only a sparse distribution. But don't overdo it, 0.5-500 would be an unlikely setting for any kind of situation. min. PS is often happy anywhere between 1.0~4.0, and max MPS between 40.0~200.0. Use the display of samples to see what's going on (see end of this guide) but you can also defer it from the preview which shows unblended shading of samples, thus you can see where things crowd. (btw these images were scaled, so their pixel distances don't match the figures, but they are correct in relation to one another)

Angular Tolerance

Angular Tolerance is the second setting for sample placement and it forever confuses everyone. What it does is control the amount of samples minimally placed on curved surfaces. It works in a similar fashion as the smoothing angle in surface editor. Below two renders which show sample placement, one with the default of 45 degrees, and one with 20 degrees, the smallest allowable angle. You can see that the sample density on the flat plane has not changed, but the curved outside area of Hank the Donut has more samples in the 20 degree image than in the 45 degree image. The density of inner samples is due to the light bouncing around there, not due to the angular tolerance. Hank showing samples with an AT of 46 degrees Hank showing samples with an AT of 20 degrees

There are three 'modes' of radiosity in Lightwave. This section discusses their differences and application.

In short:
Monte Carlo is the slowest but most accurate way of radiosity calculation, FG is a method taking a few shortcuts resulting is faster calculation at times.. Backdrop Only is a special mode of MC radiosity that only casts light from the backdrop and self illuminating surfaces, which is handy for fast outdoor scenes.

All modes can be used in interpolated mode and not. This makes a very big difference, and changes the operation of the mode significantly. Because this is so important, interpolated mode will be discussed first, and applies to all three methods.

3: Backdrop Only Method (BDO)

This method is based on the Monte Carlo algorithm. What is does differently than plain MC is that it only fires radiosity rays from the background and self-illuminating geometry. It is essentially a non-bounced radiosity method. It's therefore really fast and very useful for outdoor scenes that need some quick environment illumination, like from an HDRI or a background gradient. It also does not use much memory. Great for those clay look renders in white rooms. This can also be interpolated. Typical use of Backdrop Only radiosity, an exterior scene with not too much bouncing off surfaces. Rendered in 16 seconds on a Q9450 at 640x480.

These options were added in Lightwave 9.5 and allows you to switch off the radiosity rays cast by reflection, refraction, specularity, transparency and other directional (non-diffuse) sources. They are both off by default. Keeping this off can cut your radiosity time in half (but will NOT affect the normal render pass), but it should be used with care, as it might disable the subtle effects you might just be looking for. However, the speed gain is significant and in most cases, if you do not need it, or can organize your scene so that you don't need it, it will benefit you greatly to turn it off.

Directional Rays are all rays cast from surfaces that have some directional property to it. Examples are antistrophic surfaces, bump maps and sub surface scattering. If you wish to focus light through a lens as some of the above examples do, you need this to be on.

This is a list of exactly what happens in relation to the two settings:

Use transparency will make LightWave trace through transparency affecting the rays. This has a render hit but is sometimes necessary. With it off, transparent polygons will be treated as if they are not there at all, speeding up the process. Turning it on will make MC see transparency polygons, and it will make FG trace through transparent polygons using the MC method with directional rays set to on, and using FG when set to off.

In order to better understand the 'use transparency' option, take a look at the following diagram, describing the effects of a transparent polygon (red) being hit by a directional light source for Monte Carlo, and Final Gather with directional rays off. If directional rays are on FG will behave much the same way MC would when tracing transparent polygons:

This might seem confusing at first, but it is important to remember the differences between the Monte Carlo and Final Gather algorithms. The first image shows what the ideal situation is, which is what Monte Carlo does. The light penetrates the transparent polygon and continues on its way in its original direction, bouncing around further along the trajectory.

The second image shows what happens when Final Gather rays hit transparent polygons. Since Final gather does not take directionality of rays into account, when a surface is hit, no matter what surface, the subsequent radiosity rays are cast in a diffuse manner, and without color cast. This proves to be a problem with transparent surfaces such as windows, where the directionality of the radiosity is lost, and a non-accurate solution will result. You can therefore enable 'Directional rays' so LightWave will use MC to trace through the glass, slowing it down but providing accurate shading even though the FG method does not allow it natively.

The below examples have 'Use transparency' set to on.

Why Caching?
Caching is used for radiosity processes for two main reasons:

• To speed up rendering by saving already calculated data and reusing it when the data can be applied
• To make sure animations don't flicker.

Without caching animations with interpolated radiosity will flicker due to the slight variations in shading for each newly calculated radiosity solution, and it's extremely hard to get rid of this. Before caching the only way to use GI and render animations without flicker was to use non-interpolated Monte Carlo which is very slow and usually this disqualified using radiosity for animations, making people resort to setting up elaborate lighting rigs to simulate radiosity without actually using it. These rigs still come in handy sometimes, but with the speed and caching options of radiosity in LightWave today, using radiosity is usually both faster and easier to setup as well as faster to render.

There are two entirely different modes of caching in LightWave. One is called the static cache, which is the default, and the other the animated cache. They work quite differently and have different applications. Expecting one to work like the other is the source of many wasted computation hours and frustrations, so understand the process and properties well for each. There are various work flows possible to suit your needs, and it is extremely flexible in its application.

How the information is stored
Caching stores some but not all of the information associated with these calculations which are called 'preprocessing' in LightWave (the red progress bar in the render status window). Depending on the cached mode, different information will be stored. The static cache (when the animation checkbox is off) stores the evaluation points including their shading. Because the shading is stored it cannot change and any changes in light or object movement will not be reflected in the solution. Sometimes this is not a problem, but if you have animation where other things move other than the camera, you will have to use animated caching. Animated caching does not store the shading information, only the location of the sample points. This means the calculation of the cache is much faster than that of the static cache, but the GI is recalculated each frame, thus slower, since it has to recalculate the shading for each frame all over. This does however allow you to use radiosity and animate nearly everything, lights, objects, and so on. There are some restrictions to using this, which are summed up further along.

The radiosity process as explained above details two stages: the placement of samples and the casting of rays to collect information for the shading of those samples. In the interpolated modes the samples are then interpolated to get a smooth result. For each preprocessed frame information of the radiosity process is then added to the cache file on disk. The radiosity process works in full 3D space, and that information is also stored that way. The samples are really lying on top of the geometry they are shading. This means that it is not associated with anything other than the geometry it is affecting, and not with a particular camera or surface. A cache can be created with one camera and rendered with another. As long as all the areas visible to the second camera have been preprocessed, it should work just fine. This also means that during the calculation of a cache LightWave can already make use of the cache to speed up rendering. Let's say your camera moves half a view angle after the calculation of the first frame to calculate the cache for the second frame, half of the space that camera sees has already been processed therefore can be loaded from disk. LightWave handles this automatically and you do not need to remember what has been stored or not. If you accidentally try to store an area which has already been done, LightWave still preprocesses it, but by reusing the data already on disk will be really fast thus not penalize you with a lengthy unnecessary render.

The process:
First a cache location and file has to be set. The file will be automatically created when it does not exist. Then there are two ways to go about making a cache:

1. Render the scene and have each frame's radiosity information stored to disk
2. Bake the radiosity of the scene and render the scene afterwards
   

Some of this is personal preference, but there are some differences to be aware of. The first method tends to render slightly faster as some processes in the second method are redundant. But even for big scenes those differences are small. However you do have a two-step process in between which the computer might be sitting idle because it requires user intervention to start the render phase once the scene has been baked. The second option has its main application for network rendering. Instead of rendering the frames immediately on one machine, one often wants to use a render farm. You 'bake' the scene, which means as much as generating just the radiosity cache and not render, and then have all the computers in the network use that stored cache to create flicker free radiosity animation over the network.

Preprocessing can be done in various ways, depending on your use. Normally preprocessing is set to Auto and this works for most situations. It should be noted that LWSN nodes always use the 'locked' method regardless to what the scene is set to. Here's a description of the various preprocessing modes:

The options
Below the different options available and a description of their use and function

Animated Cache Notes
The actual working of the animated cache has been described above. However, there are some things you want to consider when you work with it a lot, or in specific scenes. First, you won't save much render time with it like the static cache does. It's really only preventing flicker. That's usually fine as LW's radiosity is really fast. There are also several circumstances in which the animated GI does not work well. Here's the list so far:

• Deformed objects (creates millions of sample points, renders very slow, and eventually might run out of memory)
• Volumetric plug-ins (HD Instance)
• Intersecting objects can create light artifacts on the intersection
• Small very bright luminous objects can cause flickering due to the rays being too dispersed creating too large a variance per shading point
• Moving shadows do not generate extra sample points, thus can look a bit ragged. Increase sample density if possible.
• Do not use the GI resolution multiplier with animated GI. It causes increasingly longer render times and possible flicker.

Truly understanding how the cache system works might allow you to understand these items more, but also might make you aware of potential problems. If your animated cache (to a limited degree this is valid for the static cache as well, but there it isn't as noticeable) goes increasingly slower... eg a long animation takes four times as long per frame after baking than without a baked solution. This would seem like a bug, but it actually makes a lot of sense, and it works as it's supposed to, and you can control for this as well.

The below scene had this problem at some point.

Except's Wesleyan Museum using animated Radiosity. Click here to view the test movie.

Understanding the caching process you can see why this happens. When baking, it places sample points only. However, it does so for the entire animation. If you zoom into a wall or objects turn, swivel and reveal parts of the scene that was previously unseen, more sample points are generated. On some complex objects with a lot of irregular geometry, or very complex scenes, these sample points might start to accumulate a fair bit (see example image below). So, after the scene bake, every frame has considerably more sample points than rendering a direct frame. There are several ways you can solve this.

• You can increase the MPS settings (example: 1.0-50.0 to 3.0-200 perhaps). While for a single frame this might be ugly, once the bake is done, it likely has plenty of sample points accumulated.
  
  
• You can bake using a frame step larger than one (my preferred method). For slow movements you can increase this quite a bit, as not a whole lot is revealed in the meantime. I have had scenes where this was set at 20. this means new sample points will only be generated every 20th frame, resulting in much less cluttering. Setting this too high, however, leads to flickering, because sample points are missing where they are needed, and LW fills them in on the fly to prevent gaps. So be careful, run a test if possible.
  
  

Render showing sample points without baking Render showing sample points after baking 200 frames

Using RenderQ
The disk cache always needs to be created with a single computer. This part of the process cannot be distributed among a network of computers since each frame is highly dependent on another. However, since it's always recommended to bake the scene first prior to rendering it, a tool called RenderQ helps when using a single machine. It's like a tiny scene render manager that allows you to set up various scenes to render in a 'play list' of sorts, and then performs them. It has a special switch for baking in the bottom right corner. When this is enabled, all the scenes that are added will bake the GI first, then reload and render the scene. Very handy!

The RenderQ panel You need to use the 'close RenderQ' button to stop the panel from popping up every time you start LW.

Cache Tips
There are many ways to use the cache. Here are some tips that might indicate some uses, and some tips:

• Bake a cache of a scene, then set the preprocessing to 'locked' and now play with the colors and surfaces of the scene. You see that you can still change them, except that their color cast does not update. Usually color cast and bleed is subtle and for previewing is not necessary. This is a great way to discuss material selections with a client without doing a lengthy radiosity render over and over again. Just use the cache and once selections have been defined, re-render the cache to make sure all color bleeds and casts are performed using the correct surfaces.
• Do not use the animated radiosity when you do not need it. Firstly, it has more restrictions, and second, illumination is not stored, only sample placement, thus you might not have much speed gain compared to normal non-cached rendering.
• The cache frame step is remembered once a cache has been baked, even though you change it, which can be a bit confusing, as it won't actually perform that change.
• Even when doing random test renders, keep the cache on. You can always hit 'clear cache' to reset it fast, and it does not cost any render time to save the cache file.
• Cache data is saved to the cache even when a render is aborted, therefore you can pick it up where you left off, and it will reuse the data that was already rendered. This does mean you'll have to clear the cache if you make a significant change to your scene before rendering again or it might use incorrect cache data.
• If you have very highly irregular objects in your scene, it might be that the cache system keeps adding new samples because areas are per frame seen that were unseen, like grass, trees and so on. The cache may get choked, rendering goes increasingly slower and eventually might become unworkable. In these cases, reduce the problems by using high Angular Tolerance, and make sure 'use bumps is off. If that's not enough bake out just a few frames of the animation, enough to have full coverage of all large objects, and then set preprocessing to 'never'. That works well and you'll get a constant render time without choking. The samples will still be generated but discarded afterwards, and thus not create congestion further down. You do risk flickering here, so make sure you do a test run.

You have this one scene where you just can't get rid of the splotchies, and it's driving you mad. We know this scene. We've got one too. Juggling values is then bound to happen with many tests and many results. I've done this personally many times and the knowledge I gained from this is all over this guide. However, I wanted to re-iterate some important concepts. This test scene can be downloaded below.

Undefined or crude GI: MPS setting
First thing to set right is your MPS range. Depending on the scene you might want to lower your max-value. This forces more samples to be placed in the scene. This will also slow down rendering. Setting this too low does NOT lead to splotchies or artifacts usually, it will lead to undefined radiosity. The example below (click on it) shows the difference between a decent and a too low MPS setting. Note that it is still smooth. A very high RPE setting was used to discard this as a factor.

3000r - 100s - 10.0-200.0 MPS: 52s	3000r - 100s - 1.0-40.0 MPS: 5m20s

Splotchies: RPE and SBR setting
If you're getting splotchies, first thing to do is crank up the primary rays amount. Try doubling it first, then continue on. Or if you have enough time, and want to be sure, choose something between 1000-2000 for complex interior scenes. This does not necessarily render slow, but of course it'll affect render time. If this doesn't work, increase SBR, but if you're going higher than 100 with SBR, consider other causes for the problem. Modeling errors can give faults as well, and so can incompatible plugins.

200rpe - 100sbr - 1.0-100.0 MPS: 56s	1000rpe - 100sbr - 1.0-100.0 MPS: 2m16s

Remember that SBR only has very subtle influence over the scene and that it need not be increased when RPE is increased. In fact, sometimes a value as low as 10 cannot be distinguished from much higher ones, except in render time. The right render of the above example takes 2 minutes and 16 seconds, but when I drop the SBR to 20, only a tiny change in the splotchies is visible, while the render time drops by almost a minute. You can invest this render time in a higher RPE for a much smoother result.

1000rpe - 20sbr - 1.0-100.0 MPS: 1m34s

Optimize: Multiplier setting
So you have found settings that make your render look good, but it renders too slow for you still... we all want faster and faster, don't we? Okay, Multiplier to the rescue. The multiplier calculates GI with the same settings but scaled down in resolution compared to the camera resolution. So, if your camera is set to 1024x768, and your multiplier to 50%, your GI will be calculated at 512x384. This can reduce render time by 4 (at 50%), while sometimes hardly sacrificing quality. In the case of this chapel, I can crank up the RPE to 3000, and the MPS to 1.0-40, and get a render time that's over 5 minutes. When I then set the multiplier to 50%, I get virtually the same result in less than 2 minutes.

3000r - 100s - 1.0-40.0 MPS @ 100% : 5m20s	3000r - 100s - 1.0-40.0 MPS @ 50%: 1m50s

Lots of trees!
Specific applications require some other settings to be taken into account. One example is objects which are highly irregular, like plants, trees and grass. They eat up samples like crazy and the safety built into LW to have overlapping polygons not blend together accidentally will start to cost a lot in terms of render time. For these objects you want to disable the 'Behind Test', and make sure they have a high Angular Tolerance. Lucky for us, the AT setting controls both. Setting it to 46 degrees or above disables the behind test. Use the per-object GI settings in object properties if you don't wish to do this for all objects in the scene (but that's usually okay).

Test Scene
For your enjoyment I have provided the above test scene, with some additions. It's a useful scene to experiment with various settings and effects with quick render times. It's a demanding scene due to the thin detail of the wall skirting, and the completely indirectly lighted interior. The radiosity settings reflect a nice balance between speed and accuracy, and this scene renders at this resolution in 25 seconds on a Quad Core2 at 2,66Ghz. This image is re-exposed at 65% black point. Download the scene here.

GI Test Chapel scene, MC int., R 400, S 50, AT 50, Min 1.0, Max 100, M 50%

The radiosity flags are diagnostic tools designed to show some of the internal workings of the render engine, for analysis, troubleshooting and learning reasons. A list of these is provided below, and an example render for each provided. The caching section above already uses one mode to clarify some operations.

You can combine these flags to show the data you need for analysis.

Some examples:

"Nodes" - Octree nodes as random colors	"Cells" - Nearest sample cell shade
"Color Cells" - Nearest sample cell shade with random colors	"Samples" - Sample locations (green)
"Missing Preprocess" - Shows the samples which were missing during preprocessing (cyan)	"Missing Render Samples" - Shows the samples which were missing during rendering (purple, hard to see)
"Second Bounce" - Shows the second bounce cells	"Behind" - Shows the behind test operation

If this tutorial proves especially handy for you, would like to support the creation of more of these tutorials and new developments, or would just like to express your thanks, you can make a donation by clicking on the following button, or alternatively just send me an email.

Go To Presentation Resources page

Go to Except Web site

This guide is Copyright 2008 Except Design, and written by Tom Bosschaert. Nothing from this website can be copied, transferred, published or distributed in any way without prior written consent from the author.