[Soc-2018-dev] Weekly Report #02 - Many Light Sampling

[Erik Englesson]

Hi all,

Thanks for the feedback!

Brecht: Sure, sounds like a plan! I just wanted to avoid having code that
does similar things, which might be a pain to maintain. I'll create a very
simple BVH in render/light_tree.cpp and have a look at render/light.cpp.
I'll get back to you with design ideas before I start implementing anything
next week.

Stefan: You are definitely right in saying that the data structures and
algorithms for a geometry BVH might be suboptimal for a light BVH. The paper
<https://sites.google.com/site/ckulla/home/many-lights> proposes a new node
data structure as well as a new build strategy(modification of SAH). To the
best of my knowledge, the construction and sampling of the light BVH are
both using top-down algorithms. So hopefully, a bottom-up traversal
algorithm should not be necessary.

Best,
Erik


On 26 May 2018 at 15:37, Stefan Werner <stewreo at gmail.com> wrote:

> The geometry BVH is also heavily optimised for one task, fast ray/geometry
> intersections, with a specific data layout, alignment and build strategy. A
> light BVH may benefit from different build strategies (Is a median split
> better than SAH there?)  and could require different data stored inside the
> nodes. If I remember correctly, you’ll need to also be able to traverse the
> tree from a leaf to its root to get a given light sample’s PDF. This would
> be difficult to do with the current geometry BVH.
>
> -Stefan
>
> On 26. May 2018, at 15:12, Brecht Van Lommel <brechtvanlommel at gmail.com>
> wrote:
>
> Hi Erik,
>
> I don't think we should reuse the geometry BVH code for light sampling.
> There is a bit of overlap but I expect it will end up making the code
> harder to understand and modify overall if that BVH code is used for two
> different purposes.
>
> Instead create your own simple (BVH) tree structure, in a new
> render/light_tree.cpp file and integrate it into render/light.cpp. There
> we already create a distribution from a list of lamps and emissive
> triangle. It's going to be faster to iterate and experiment than reusing
> the quite complex geometry BVH code.
>
> Regards,
> Brecht.
>
>
> On Sat, May 26, 2018 at 8:01 AM, Erik Englesson <erikenglesson at gmail.com>
> wrote:
>
>> Hi all,
>>
>> I hope you have had a good week!
>>
>> This week I had a look at the code related to the building of a bounding
>> volume hierarchy(BVH) in intern/cycles/bvh/. In my project, I will create a
>> BVH of light sources instead of geometry, which is why I had a look at this
>> part of the code. See below for some notes.
>>
>> */cycles/bvh/bvh.h/cpp*
>>
>> */cycles/bvh/bvh2.h/cpp/cycles/bvh/bvh4.h/cpp*:
>> Code for BVHs where each node has 2 or 4 children. (BVH2,BVH4 inherits
>> from BVH) It seems to have two functions of interest:
>> *BVH::create*: Based on the BVHParams input parameter a BVH2 or BVH4 is
>> created.
>> *BVH::build*: Builds the BVH by using a helper class called BVHBuilder
>>
>> */cycles/bvh/bvh_params.h*:
>> Parameters sent to the BVH::create algorithm, e.g. to use BVH2/BVH4,
>> splitting thresholds, min primitives in leaf nodes etc.
>>
>> */cycles/bvh/bvh_node.h/cpp:*
>> There is a node base class called BVHNode and then InnerNode and LeafNode
>> inherit from BVHNode. It seems each leaf stores indices to the first and
>> last triangle they contain in a linear array of triangles. InnerNodes
>> always stores two pointers to children. Is bvh4 using some other code or
>> what am I missing?
>>
>> */cycles/bvh/bvh_build.cpp:*
>> Creates the actual BVH in BVHBuilder::run(). The most interesting method
>> here seems to be build_node(). It is a recursive function that first checks
>> if it is deep enough to create a leaf, otherwise it splits the node into
>> child nodes and calls build_node on each child.
>>
>> BVHBuild takes a vector of Objects to its constructor, but from what I
>> can see in cycles/render/scene.h, the lights are not part of this array. I
>> will have to get them into my BVH in another way.
>>
>> */cycles/bvh/bvh_split.cpp:*
>> Algorithms to split a node into two child nodes. There is an object split
>> method and a spatial split method and a combination of both. This is where
>> the surface area heuristic(SAH) calculations happen.
>>
>> Note: BVHBuilder::run() decides which splitting method is used.
>>
>> *Plan for next week*
>> I have my final exam on Monday and then I can finally start this project
>> full-time!
>>
>> Next week I will have a look a bit more at the code in /cycles/bvh/ and
>> then start to build my own BVH of lamps. It should be possible to reuse a
>> lot of the code in bvh_build/bvh_split and I will have to figure out what
>> the best way to implement my parts will be. Create new classes that uses
>> code from existing classes either through inheritance or refactor or modify
>> existing classes, etc.
>>
>> I will have to get access to light sources in the bvh building process
>> somehow and create my own splitting method that uses a Surface Area
>> Orientation Heuristic(SAOH) instead of SAH. To be able to create the SAOH
>> splitting method, I need more information in each node related to lights,
>> so I will have to create/modify the node data structure too.
>>
>> I have planned for all of the mentioned steps to take two weeks to
>> implement.
>>
>> Thanks,
>> Erik
>>
>>
>> --
>> Soc-2018-dev mailing list
>> Soc-2018-dev at blender.org
>> https://lists.blender.org/mailman/listinfo/soc-2018-dev
>>
>>
> --
> Soc-2018-dev mailing list
> Soc-2018-dev at blender.org
> https://lists.blender.org/mailman/listinfo/soc-2018-dev
>
>
>
> --
> 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/20180526/80bfc85c/attachment.html>