[Bf-cycles] Cycles volume render status

[Thomas Dinges]

Hi Brecht,
that sounds reasonable.

I agree that the current code (especially integrator) is not easy to 
verify and there are a lot of commented variations of what might be 
correct. Your one by one approach makes sense.

Thanks,
Thomas

Am 28.12.2013 05:24, schrieb Brecht Van Lommel:
> 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
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> http://lists.blender.org/mailman/listinfo/bf-cycles