[Bf-cycles] Cycles volume render status

Brecht Van Lommel brechtvanlommel at pandora.be
Sat Dec 28 05:24:45 CET 2013


Hi,

I started getting the branch ready to merge, but found it difficult to
verify the correctness and make changes by refactoring the code. What
I plan to do instead is integrate it in pieces. I will start by adding
rendering of homogeneous volumes with absorption. Then I will tweak,
verify and commit more volume rendering effects one by one.


Some more notes:

It took me a while to figure out how the scattering and absorption
coefficients were derived from the closures. From what I can tell it's
done like this, with the extinction coefficient named sigma,
absorption and scattering are handled implicitly by phase function
sampling/evaluation.

extinction coefficient = scattering coefficient + absorption
coefficient = closure.density
scattering coefficient = closure.weight * closure.density
absorption coefficient = (1 - closure.weight) * closure.density

This isn't quite flexible enough, there is e.g. no way to define a
colored absorption volume with no scattering. The extinction
coefficient is a scalar now, but it should be a float3 varying per
color channel.


Instead of this system, volume rendering will support 3 types of
closures: absorption, scattering and emission. The coefficients are
simply the weights of those closures. In OSL for example you could
combine them like this:

Ci = (Scattering_Color * Density) * henyey_greenstein(Anisotropy) +
(Absorption_Color * Density) * absorption() + (Emission_Color *
Density) * emission()

As you can see the density will be folded into the closure weight.
Note that these are nicely composable, adding more closures simply
makes the volume more dense. Using the Add Shader will be equivalent
to having two overlapping volumes.


Further, for transparent shadow and the simple case of only absorption
and/or emission we should render without noise (except step size
randomization / woodcock noise). Right now absorption/extinction is
handled by sampling, but we can attenuate the throughput instead of
stopping the path entirely.


Brecht.



On Sun, Dec 8, 2013 at 2:48 PM, Thomas Dinges <blender at dingto.org> wrote:
> Hi Brecht,
> thanks for the latest updates for Volume code. Works fine:
> http://archive.dingto.org/2013/blender/code/volume_new.jpg (quick test) :)
>
> There are indeed a lot of open items, but I think for 2.70 we should
> focus on the essentials, as you said.
>
> I think we definitely should do for 2.70:
> * Clean up and improve code further.
> * Fix Texture Coordinates for procedural textures.
> * UI: Keep/Remove the Experimental versions of the volume integrators
> (Stuart, your opinion here, as you wrote them, can the two versions be
> unified for example?)
>
> Nice to have for 2.70 but could also be done later:
> * Emissive Volumes
> * Camera Inside Volumes
> * Performance, better Importance Sampling (take a look at the Arnold
> papers from 2012?)
>
> Best regards,
> Thomas
>
> Am 08.12.2013 13:57, schrieb Brecht Van Lommel:
>> Hi all,
>>
>> We're trying to get volume render in master for 2.70, probably as an
>> experimental feature. I've moved the To Do list from Thomas' user page
>> to here and tweaked it:
>> http://wiki.blender.org/index.php/Dev:2.6/Source/Render/Cycles/Volume
>>
>> Still a bunch of work to be done but most of these items are not
>> planned for 2.70, mainly we need to get it into a state where it's not
>> causing any (performance) regressions for Cycles usage without volume
>> rendering, and to avoid having to do major design changes to the code
>> that is there and break compatibility.
>>
>> Brecht.
>> _______________________________________________
>> Bf-cycles mailing list
>> Bf-cycles at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-cycles
>
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> http://lists.blender.org/mailman/listinfo/bf-cycles


More information about the Bf-cycles mailing list