Blender Git Commits

Cycles: Fixes for regular BVH since previous commit

Cycles: Switch node address to absolute values in BVH tree

This seems to be straightforward way to support heterogeneous nodes
in the same tree.

There is some penalty related on 4gig limit of the address space now,
but here are the things:

- Traversal code was already using ints to store final offset, so
there can't be regressions really.

- We know that node size is 16 bytes aligned, so we use SHR/SHL magic
to increase address space of nodes still.

This is a required commit to make it possible to encode both aligned
and unaligned nodes in the same array. Also, in the future we can use
this to get rid of __leaf_nodes array (which is a bit tricky to do since
trickery in pack_instances().

Cycles: Commit heuristics and builders from hair branch

Not currently in use, will be hooked up to existing code shortly.

This commit also contains some traversal helpers, but those are also
not in real use.

Merge branch 'master' into cycles_bvh

Cycles: Some more comments

Cycles: Fix crash rendering mesh with hair

Cycles: Some comments

Cycles: Optimize aligned triangle storage a bit

The idea is to keep triangle storage aligned with the BVH traversal code.

This gives couple of percent speedup comparing to previous version and
reduces overall slowdown (which is now 4% on the barcelona file here on
own desktop, and half of it is caused by the inner BVH node visibility
commit),

Merge branch 'master' into cycles_bvh

Merge branch 'master' into cycles_bvh

Cycles: Reduce memory usage by de-duplicating triangle storage

There are several internal changes for this:

First idea is to make __tri_verts to behave similar to __tri_storage,
meaning, __tri_verts array now contains all vertices of all triangles
instead of just mesh vertices. This saves some lookup when reading
triangle coordinates in functions like triangle_smooth_normal().

In order to make it efficient needed to store global triangle offset
somewhere. So no __tri_vindex.w contains a global triangle index which
can be used to read triangle vertices.

Next idea was to use this __tri_verts instead of __tri_storage in
intersection code. Unfortunately, this is quite tricky to do without
noticeable speed loss. Current formulation of indices required doing
two level lookup, which destroys cache and leads to poor performance,
causing up to 8% slowdown here. In order to solve this couple of things
were made.

Firstly, added an array to look up global triangle offset directly from
primitive index. This doesn't affect on overall number of textures
because we're getting rid of _-tri_storage anyway.

Secondly, did some types changes to avoid casts which are not really
coming for free.

After doing those tricks it seems slowdown is withing 2% here on my
desktop, but today it behaves flackey and doesn't give totally
consistent results, so need to doublecheck that).

On a positive site we've achived:

- Few percent of memory save with triangle-only scenes. Actual save
in this case is close to size of all vertices.

On a more fine-subdivided scenes this benefit might become more
obvious.

- Huge memory save of hairy scenes. For example, on koro.blend
there is about 20% memory save. On bunny.blend it's hard to measure
against current master because beefy machine is occupied atm, but
let's put it this way: before this change i was unable to render
full bunny on my machine (and it is on 12gig machine, but remember
beefy machine was reporting 9 gig peak) and now the scene renders just
fine and using 3.3gig.

Cycles: Support visibility check for inner nodes of QBVH

It was initially unsupported because initial idea of checking visibility
of all children was slowing scenes down a lot. Now the idea has changed
and we only perform visibility check of current node. This avoids huge
slowdown (from tests here it seems to be withing 1-2%, but more tests
would never hurt) and gives nice speedup of ray traversal for complex
scenes which utilized ray visibility.

Here's timing of koro.blend:

Without visibility check With visibility check
Original file 4min 20sec 4min 23sec
Camera rays only 1min 43 sec 55sec

Unfortunately, this doesn't come for free and requires extra data in
BVH node, which increases memory usage of BVH nodes by 15%. This we
can solve with some future trickery of avoiding __tri_storage created
for curve segments.