「利用者:UncleZeiv/SummerOfCode2008/FAQ」の版間の差分

提供: wiki
移動先: 案内検索
(New page: === Can I use lightcuts with whatever light type I want? === At its core, the Lightcuts algorithm works only with point lights (omnidirectional, directional and oriented, that is Lamp, Sun...)
 
(1版 をインポートしました)
 
(相違点なし)

2018年6月29日 (金) 03:37時点における最新版

Can I use lightcuts with whatever light type I want?

At its core, the Lightcuts algorithm works only with point lights (omnidirectional, directional and oriented, that is Lamp, Sun and 180° Spot in Blender parlance). Starting from revision 15415, area lights and environment maps get automatically converted behind the scenes in a huge number of point lights. Also textured area lights are now supported.

Doesn't that show banding?

Sometimes it does, depending on a number of circumstances. Tipically, it's not very noticeable. Using the "multiple representative" feature (from revision 16985), you can convert this in noise.

Are we required to duplivert lights like crazy?

"Fake" point lights are handled behind the scenes when you add environment lighting, area lights and similar stuff. If you duplivert pointlights yourself, though, Lightcuts does help as well. An interesting possibility would be to associate lights to particles.

What does "sublinear rendering time" mean?

In general, if you have N point lights and your image takes K seconds to render, doubling the number of lights to 2 * N would take something like 2 * K seconds to render: that is, rendering times are usually linear with the number of lights. On the contrary, with Lightcuts, if using N lights takes K seconds to render, using N * 2 lights takes <= K * 2 seconds. What's more, as the number of lights increases, the rendering time tends to stabilize, so that adding more lights doesn't increase the rendering time. (It does increase the initialization time though).

Are Lightcuts good also for animation?

They shouldn't flicker too much if you require low error rates. Moreover, if lighting doesn't change, you could reuse the lighting tree for several frames. This though is not a big deal unless the tree is really huge (like 1 million lights!), and I'm not sure if it's worth the trouble to implement. We'll see.

Is Lightcuts a GI technique?

No, it isn't. But since you can handle a large number of point lights, the technique known as "Instant Radiosity" comes to mind; this technique puts "secondary light sources" (virtual point lights) where primary lighting rays hit the scene, thus simulating pretty well 1st bounce indirect lighting; it's possible to simulate other bounces as well.

Does Lightcuts work with shadowmaps or without raytraced shadows?

No. This goes at the very core of the algorithm. Visibility is checked by tracing a single ray to the lamps. Fortunately this is done in a smart way, so that only a small percentage of lights triggers the ray casting. That's good news, though: no shadows would mean very poor visual quality, and shadowmap would be, in this case, more expensive than raytraced shadows, instead of less!

Does Lightcuts work with QMC?

No. Each light is single sampled. Considering all lights, though, the low quality of the shadow of a single light is stochastically compensated. As far as I can see you could have problems if in your light setting you have a single extremely bright light; I'll see how to cope with that when everything is in place.

Is Lightcuts prodution ready?

Of course not! It's still a work in progress.