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

[Sergey Sharybin]

Hi,

Answers are inlined.

On Sat, Apr 6, 2019 at 5:45 AM Alex Ozer <mail at alexozer.com> wrote:

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

Sounds about right.


> 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?)
>

It will limit us to AABB, with all motion steps per primitive in one node
(effectively limiting motion_steps to 1).

Before going to the next steps, verification of the render result of all
regression tests/scenes is to be done.

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

Both OBB and time steps for BVH nodes are to be converted from Embree.


> Do we choose not to try to export OBBs until after the initial converter
> task in order to keep the initial converter task simple?


Exactly.


> Additionally, where may I look in the Cycles codebase to get a good idea
> for where
> OBBs / hair are being used?
>

Main heuristic code for OBB builder can be found there:
https://developer.blender.org/diffusion/B/browse/master/intern/cycles/bvh/bvh_unaligned.cpp

Traversal code for OBB is using functions like
bvh_unaligned_node_intersect_child:
https://developer.blender.org/diffusion/B/browse/master/intern/cycles/kernel/bvh/bvh_nodes.h

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

Modifications in BVH structure needs to happen for both OBB and motion
blur. So while the implementation of those features is to happen
separately, might be good idea to plan modifications ahead, to avoid
duplicate work.

Other than that, rough plan seems fine.


> 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
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>


-- 
With best regards, Sergey Sharybin