Blender Git Loki

Cycles: Move all unaligned boundbox to the parent node

Now parent node contains unaligned bounding box of it's children,
which is more friendly for applying SIMD optimization.

This currently only solves inner nodes being intersected twice,
actual vectorization is coming next.

Merge branch 'master' into cycles_hair_bvh

Cycles: Use affine space for unaligned nodes

This way we always know node's boundbox is within 0..1 which simplifies
intersection check and saves some per-node memory.

Merge branch 'master' into cycles_hair_bvh

Cycles: Couple of fixes for hair BVH

- Use proper boudbox offset for primitive packing
- Use proper-ish boundbox for object nodes.

Merge branch 'master' into cycles_hair_bvh

Cycles: Proof-of-concept unaligned BVH traversal code

This a commit which breaks regular non-development work broken,
this is due to accumulated TODOs in the code, solving which is
not fully trivial and trying to stub them will lead to some
nasty code. That being said, only final renders are working
stable, perhaps only for hair tho (mixed hair and triangles
could behave flackey).

In any way, the code is mainly here to see how much traversal
steps we can save using oriented bounding boxes in hair BVH,
it is not optimized or vectorized. In fact, it does evaluation
of particular things multiple times. This means only traversal
steps pass could be used to quantify possible improvements.

But that being said some quick tests seems promising. Here is
a camera rays traversal heatmap for suzanne with 8000 hair:

Master: http://www.pasteall.org/pic/show.php?id=102281
Branch: http://www.pasteall.org/pic/show.php?id=102282

Btw, only regular BVH was modified to support OBB.

Now we need to work on vectorization and QBVH support to see
if we can beat performance of AABB by a measurable matter.

Merge branch 'master' into cycles_hair_bvh

Cycles: Initial implementation of unaligned BVH builder

The idea is to use unaligned boundbox nodes for hair BVH, which should
in theory improve performance of ray-to-hair intersection.

Only tree building is done currently, still needed to work on packing
and traversal code.

The idea oh builder is the following:

- We calculate SAH of regular split
- Then we calculate alignment orientation for the BVH range, using
first curve from the range to define orientation.
- Then we calculate SAH using alignment from the previous step.
- If SAH calculated for a found orientation is better than regular
orientation we create unaligned node.
- All leaf nodes are unaligned.

There is some code duplication which we can avoid, and some parts are
not really optimized yet.

Merge branch 'master' into cycles_hair_bvh

Merge branch 'master' into cycles_hair_bvh

Cycles: Use dedicated BVH for triangles and hair

This is a required step forward OBB type of BVH which will be more optimal
for hair but less optimal for triangles. Which means, we'll need to have
dedicated hair BVH once we'll start working on OBB BVH.

This commits does exactly that: there are now two separate BVH, one is
fully dedicated to triangles and another one is fully dedicated to hair.
They are built separately and also traversed separately.

This allows:

- Get rid of triangle storage for curve primitives, which solves memory
usage issue without slowdown of triangles intersection test.

- Perform test against triangles for shadow rays, which will often lead
to som speed gain because ray often hits opaque triangle and in this
case it's not needed to do any ray-to-curve intersections.

Unfortunately, current implementation used 7 more textures, which is quite
bad on lower end GPUs due to tight number of textures limit, which means
less image textures can be used now.

Here are some numbers:

Master Patch
Koro.blend
Memory during render(Mb): 910 814
Peak memory(Mb): 984 963
Render time: 5m 51s 5m 21s

Bunny.blend
Memory during render(Mb): 8034 6375
Peak memory(Mb): 9058 7713
Render time: 9, 25s 7m 44s

There are some render result difference with low number of samples,
probably because of different order of geometry hits when there are
multiple primitives at the same depth. But that's to be doublechecked.

There should be no affect on scenes with just triangles.

Since there are some interesting results already decided to put it
online for some more tests.