We’ve enjoyed providing this knowledge to you after years of testing and working with the great radiosity engine of LightWave. Much of our work on our artist impressions use Lw’s native GI system. Be sure to check out our other guides and freebies!
Introduction: Radiosity in LightWave. |
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 LightWave 9.6 Global Illumination Panel Layout. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
The Radiosity Process | |||||||||||||||||
|
The three radiosity methods | ||||||||||||||||||||||||
There are three 'modes' of radiosity in Lightwave. This section discusses their differences and application. In short: 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.
|
The Directional Rays and Use Transparency options | ||||||||
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. |
The Cache Radiosity Option | ||||||||||||||||||||||||||||||||||||||||
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 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:
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
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.
Using RenderQ
Cache Tips
|
Trouble Shooting | |||||||||||||||||
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
Splotchies: RPE and SBR setting
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.
Optimize: Multiplier setting
Lots of trees! Test Scene
|
The Radiosity Flags | ||||||||||||||||||||||
![]()
Some examples:
|
Links & other tutorials |
|
Tom Bosschaert
Director