利用者:UncleZeiv/SummerOfCode2008/Integration

This document is a blatant Work In Progress. Feel free to modify it, or to suggest improvements in the discussion page.

Introduction

This document discusses how to integrate Lightcuts in Blender, specifically from a user workflow point of view.

On the programming side, Lightcuts should be fairly easy to integrate, as most of its code lives in a separate module, and requires only minimal changes to the existing code base.

Objectives/requisites

• we don't want the user to be trapped in a "all-Lightcuts" workflow
  • existing scenes should be easily rendered with Lightcuts with minimal tweaking

  we want to make sure that, for instance, you don't have to change parameters to all of the lights to have a scene rendered with Lightcuts (currently this is still partly the case); on the other hand this requisite alone doesn't mean that the Lightcuts rendering would take full advantage of the algorithm; for instance, rendering time could be the same or slightly worse (see #Things_the_user_should_be_aware_of what the user should be aware of).

  • conversely, scenes setup with Lightcuts in mind should require minimal tweaking to render "similarly" without it

  again, this will be mostly achievable, but a scene that takes 15 mins to render in Lightcuts could easily take several hours in plain Blender Internal...

  • we don't want to be using render layers to get around technical limitations

  I don't completely agree with this one, but I guess the coder should listen to artists and do what they require...

Issues

• what is Lightcuts from a user point of view? how to enable it?
• what options/sliders will be available to the user?
• how does it interact with AO?

when environment mapping and/or indirect lighting is on, AO shouldn't be needed, but I can see that's not true in the general case.

• should it be possible for the user to mix Lightcuts-rendered lights with non-Lightcuts ones?

there could be reasons to do that, but is should be somewhat discouraged as in general that would decrease performance.

• what features are unsupported by Lightcuts? How does the user obtain them back?

Things the user should be aware of

• It doesn't make sense to use Lightcuts with a small number of lights; real benefits are to be gained when very complex lighting is available. Of course, environment mapping and area lights can be converted in an arbitrary large number of point lights. Still, the user must know that using Lightcuts to render a scene with, say, 10 or even 100 point lights, is going to be possibly slower (and lower quality) than the QMC counterpart.
• Lightcuts doesn't perform well in completely occluded areas. That's why environment lighting and/or indirect lighting should be "always" used along with Lightcuts. Since increasing the amount of lighting would paradoxically increase performance in those cases (or at least the render quality to performance ratio), the user should be well aware of that.

Future directions

• "Reconstruction cuts" is a technique, mentioned in the original paper, that allows to save additional rendering time while rendering an antialiased version of the image. I'm still not sure about this but, if implemented, could be "alternative" to the OSA setting.
• "Multidimentional lightcuts" is an interesting extension to the plain "Lightcuts" techniques that allows to achieve motion blur, depth of field, subsurface scattering, etc. I'm not sure how that could be integrated with Blender Internal, and if it tells something on how to expose the "plain technique" right now. (Let me clearly state that this is *not* part of the current Soc, nor something I plan to implement in the near future).

Notes (discussions from irc, email...)

Main issues to consider:

• not just how it fits in currently, but how it can fit in the future

i.e. what happens if we get photon mapping later on or other forms of IBL, GI methods

what happens later if instant radiosity etc comes in

• how does it interact with AO, ambient lighting, etc
• if someone changes something in the calculations, the bounding formulas would not work anymore; in general, changes to blender internal could have unexpected consequences in the lightcuts code
• is lightcuts a 'mode' that prevents any unsupported things from being used? or does it override other settings (i.e. shadows, lamps ,etc ) or is it purely something you can just switch on, and the scene renders as usual, but faster?

broken: "I like the idea that it doesn't actually impact the look (apart from noise etc), and just speeds things up, so you don't have to create the scene specifically with lightcuts in mind"

• does it make any sense to mix for example IBL from lightcuts and regular sampled arealights?

UncleZeiv:it shouldn't make sense because lightcuts works at its best with complex lighting... more lights, better performance

broken: but it would still be nice to be able to mix and match; in real world situations, I use all the tools that are available to me

• or is it perhaps settings per lamps? like sample type: constant / adaptive/ lightcuts  ? can you use it alongside other types of illumination or does it all need to be lightcuts ?
• anything that can be accelerated will be, others are left alone? or how does it impact if you use a shadowless spot for example?

Other stuff:

• use "samples" values for area lights as a base for light conversion in lightcuts (with global factor?)
• you don't want to be using render layers to get around technical limitations