June 14, 2016, 12:56 (GMT) |
Cycles: Fixes for regular BVH since previous commit |
June 14, 2016, 12:29 (GMT) |
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(). |
June 14, 2016, 10:21 (GMT) |
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. |
June 14, 2016, 09:53 (GMT) |
Merge branch 'master' into cycles_bvh |
June 13, 2016, 16:21 (GMT) |
Cycles: Some more comments |
June 13, 2016, 16:00 (GMT) |
Cycles: Fix crash rendering mesh with hair |
June 13, 2016, 15:13 (GMT) |
Cycles: Some comments |
June 13, 2016, 14:28 (GMT) |
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), |
June 13, 2016, 13:18 (GMT) |
Merge branch 'master' into cycles_bvh |
June 13, 2016, 08:16 (GMT) |
Merge branch 'master' into cycles_bvh |
June 10, 2016, 14:13 (GMT) |
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. |
June 10, 2016, 08:27 (GMT) |
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. |
|