[Soc-2018-dev] Weekly Report #10 - Further Development for Cycles' Volume Rendering

[Brecht Van Lommel]

On Tue, Jul 24, 2018 at 7:56 PM Geraldine Chua <chua.gsk at gmail.com> wrote:

> Alright! I originally thought to try to alter the ray shooting to gather
> more samples that way, since that is the approach mentioned by the paper,
> but I am very unfamiliar with that part of the kernel. This seemed like a
> decent approach to it. How would I go about caching the lookup? Maybe add a
> new member volume_velocity?
>

Yes, just add a new member.


> I remember seeing veloctiy grids being used to color smoke, so there may
> be a use for it aside from motion blur. The velocity attribute node is
> supposed to plug into a Color socket as well, so I don't think it needs to
> be removed when there's no motion blur.
>

If a shader uses the velocity grid it will be in the requested attributes
already. So it's not about removing, we just don't need to request velocity
if the object has motion blur disabled.


> There is an issue with smoke that (I think) happens when the smoke is near
> the edges of the bounding box (example:
> http://pasteall.org/pic/show.php?id=33ee8cb52f1b48a608bbbf1e8ba2faf4).
> Scaling the domain fixes the problem but greatly increases rendering time
> since every tile in the volume is now active. I wonder if padding can help
> with this?
>

Yes, padding would solve this. In mesh_volume.cpp there is a
volume_params.pad_size to add a global padding.

Ideally we'd do something smart where we take into account the velocity in
each voxel or tile and adaptively pad the bounds where needed, but this may
be complicated.


> Now that I think about it, it actually might be possible to also
> pre-calculate the density. I will have to try that out soon.
>

If it's precomputed at only a few samples it will not look good, if it's
done for many samples memory usage will be too much. When you try to make
this memory efficient I think you end up with something like TUVs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.blender.org/pipermail/soc-2018-dev/attachments/20180725/4a4d626a/attachment.html>