[Bf-viewport] Updates for the week of May 30th - June 6th

Brecht Van Lommel brechtvanlommel at pandora.be
Sat Jun 11 14:54:42 CEST 2016


On Fri, Jun 10, 2016 at 2:23 PM, Clément FOUCAULT
<foucault.clem at gmail.com> wrote:
>> GGX + area light preview would be useful I think, even if it's an
>> approximation it still seems better than assuming it's a point light.
>
> Well the sun light approximation is still far off when radius is getting big
> due to the non uniform Light intensity over the radius.

Sounds like a corner case that isn't so important, sun lights tend to
have small radii. For other cases an environment map seems more
typical.

I'm not sure why we have non-uniform light intensity here though,
maybe that can be changed in Cycles.

> By the way would you (Brecht) help me to derive a diffuse formula for the
> sun light edge brightening? I've somehting in mind but I need someone better
> than me in math to acheive it.

I can try, though I'm not a great mathematician either :)

>> The reason to use simpler approximations would be for better
>> performance, or if the approximation is so bad that it makes things
>> worse, or if it the more advanced approximation requires some kind of
>> manual tweaking / setup to make it work right.
>
> I think you are talking about the environment cubemap parallax correction or
> others things that needs manual setup.

I didn't have anything specific in mind, but that sounds like a good
example. There's a difference in workflow for someone who just wants
to see approximate lighting when they are texture painting or
animating but will still do final renders with raytracing, and someone
who wants to do all kinds of tweaking and baking to get the best
possible realtime render because that's their target.

> Thinking out loud is to have scene wide settings (maybe inside render
> settings?) for approximations methods.
> (in order from cheap to accurate)
> Lights : Point light > MRP > LTC (uses 2 textures slots)
> Environment : Prefiltered Envmap > Filtered Importance sampled
> AO : Fast AO > Accurate AO
> and so on.

That makes sense. Ideally we want to have single rendering algorithms
that smoothly scale up/down in quality, so there's fewer options for
users and less code to maintain, but that's not always possible to do
well.


More information about the Bf-viewport mailing list