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

[Geraldine Chua]

Hi!


> Did both generate the same mesh?
>

The mesh are identical (checking the look and size), which makes sense
conversion to sparse grid shouldn't destroy any significant data. The ~35
second time difference is based on how long it takes to iterate through the
entire example VDB grid. For larger VDBs, this may well be worth the extra
time saved in rendering, but that depends on the exported VDB. What the two
storage methods have in common is the ~25 seconds of vertex deduplication,
which your patch resolves :)

If we follow the paper it's actually two velocity loops, see formula (7).
> One velocity lookup works as well, just lower quality I guess.
>
> 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.
>

Oops, I wasn't thinking too straight when I wrote this last email >.< Yes,
for eulerian motion blur it should be 1 velocity lookup, plus 1 pair of
velocity and density lookups per sample. And the second suggestion doesn't
work with interpolation, don't know what I was thinking.

Correct. That’s how we sample every motion effect in Cycles. The trick to
> get the “smear” is that each camera ray gets a different (pseudo-)random
> time associated with it (ShaderData::time and Ray::time) and we sample
> everything at exactly that point in time. Given enough primary rays, the
> result approaches the integral over the open shutter interval. Adding
> motion blur should turn one density lookup into one velocity + one density
> lookup.
>

Oh, so I was a little confused about sampling since the old patch didn't
seem to give the blur effect, but trying now with only one sample still
gives the effect. I guess the location of the advection has to do with it.
So altogether, only 3 lookups are needed for motion blur compared to 1
without.

I see. I used the SIGGRAPH 2017 Volume Rendering Course notes as reference,
> see equation 43:
> http://graphics.pixar.com/library/ProductionVolumeRendering/paper.pdf
>

Hmm, it looks like the same formula, but this references a different paper.

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.
>

Having another look at the volume I tested, it seems like it has strange
clipping even without motion blur so the visual bug may just be due to
that. I'll need to do more testing to see what's causing this but it
doesn't seem to be the motion blur (smoke with no motion blur:
http://pasteall.org/pic/3dfcfc3c3be2aaf49a11b96c412a5733)

For blurred smoke, since velocity grid is taken into account when
generating the mesh, we basically end up with a mesh similar to the
original bounding box since usually every velocity voxel is active. Since
the volume shouldn't reach out of the domain anyway, I'm not sure what
padding is for?

Best regards,
Geraldine


On Wed, Jul 25, 2018 at 8:31 PM, Brecht Van Lommel <
brechtvanlommel at gmail.com> wrote:

> 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.
>
>
> --
> Soc-2018-dev mailing list
> Soc-2018-dev at blender.org
> https://lists.blender.org/mailman/listinfo/soc-2018-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.blender.org/pipermail/soc-2018-dev/attachments/20180726/22a8c081/attachment-0001.html>