[Bf-committers] [GSoC 2019] Embree BVH for GPU Questions

[Alex Ozer]

Thank you for the reply Sergey.

If you wouldn't mind I'd like to try going through the steps myself to
make sure I've got the right idea. Feel free to correct me if I'm
wrong and feel free to suggest more details I might be missing.

> Implement converter from Embree BVH to Cycles BVH data structures.

For this step, what we'd like to do here is attempt to use Embree's
BVH builder completely in-place-of Cycles' native BVH builder, without
using any fancy features of Embree's BVH data structure itself yet.
This wouldn't work for every type of BVH that Embree could produce
since we don't aim to support STBVH-esque features in Cycles' BVH just
yet. Packing the BVH for GPU, GPU traversal etc. stays the same.

I guess I am most fuzzy about which sacrifices exactly are we making
converting Embree's BVH to Cycles' without modifying Cycles' BVH much
(no OBBs? no motion?)

> Verify if Embree can export oriented bounding boxes and motion steps, and if needed improve Embree API.

In order to eventually implement something like the STVBH in Cycles'
BVH, we'll need to export all STBVH-related features from Embree,
including the time-varying bounding boxes and node time intervals. Do
we choose not to try to export OBBs until after the initial converter
task in order to keep the initial converter task simple? Additionally,
where may I look in the Cycles codebase to get a good idea for where
OBBs / hair are being used?

> Adjust Cycles kernel BVH traversal for faster motion blur.

In this step we aim to replace Cycles' internal BVH with one that
supports faster motion blur similar to Embree's. We need to:

* Modify Cycles' BVH data structure to support features which Embree's does
* Implement a more complete converter from Embree's BVH to a Cycles-internal BVH
* Modify the non-Embree BVH traversal code implemented in the Cycles
kernel to leverage Cycles' BVH redesign for faster motion blur. BVH
packing for the kernel  will also need to be modified.

Thanks again for the time and consideration; let me know if I should
direct follow-ups to this project to another place like the Cycles
mailing list.

Alex

On Fri, Apr 5, 2019 at 3:50 AM Sergey Sharybin <sergey.vfx at gmail.com> wrote:
>
> Hi,
>
> The answers are inlined.
>
> On Fri, Apr 5, 2019 at 6:53 AM Alex Ozer <thealexozer at gmail.com> wrote:
>
> > > Implement converter from Embree BVH to Cycles BVH data structures.
> > > Adjust Cycles kernel BVH traversal for faster motion blur.
> >
> > I'm not sure whether this means to convert Embree's BVH to Cycles' BVH
> > with or without modifying Cycles' BVH. At first I thought it was
> > "without", but I'm not sure what adjusting Cycles kernel BVH traversal
> > would specifically entail unless maybe it would be for taking
> > advantage of the special properties of the "Spacial-Temporal" type of
> > BVH which Embree constructs [3]. Essentially, would this task involve
> > implementing features of Embree's BVH (such as its time bounds) in
> > Cycles' BVH, and modifying the Cycles kernel to leverage this for
> > faster motion blur?
> >
>
> Those are two incremental steps.
>
> Cycles uses bare-arrays-alike data structures, which are easy to put and
> use on GPU. So first step of the project is to put Embrees data structures
> to Cycles with minimal changes on Cycles side. This eases testing and
> verification process before going more advanced.
>
> Then, since Embree has better builder for motion blur support (i.e. as
> you've pointed, STBVH), we can benefit from this as well by replacing
> multi-step BVH with more boundbox-interpolation alike approach. This would
> require changes in both data structures and travsersal code.
>
>
> > > Verify if Embree can export oriented bounding boxes and motion steps,
> > and if needed improve Embree API.
> >
> > I'm not sure what the purpose of this is; it seems to me that Cycles'
> > BVH uses axis-aligned bounding boxes. Also, I'm not sure on the
> > terminology "motion steps".
> >
>
> Cycles uses both AABB and OBB (oriented bounding box). Those are essential
> for fast hair rendering. Embree supports OBB but in the past it was only
> available for the Embree's traversal. This needs to be verified, and,
> possibly, implemented on Embree side.
>
> Motion step is basically bounding box of a node at a specific time step.
> Those are then interpolated to get bounding box for the ray's time during
> rendering.
>
> --
> With best regards, Sergey Sharybin
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers