[Soc-2009-dev] Raytrace api

[André Pinto]

===Week 11 report===

==This week==
*Improved the data structures organization and support to SIMD.

The 2 main data structures are: svbvh, qbvh.
svbvh - is a variable childs bvh (each node can have any number of any
childs), adapted to group multiples of 4 childs to be able to use SIMD. (Its
built from a SAH binary tree, after performing some passes to increase tree
quality and then performing one pass to try to increase SIMD performance)
qbvh - is a binary tree build from SAH and later compressed into a
quad-tree.

http://andresp.no-ip.org/soc2009/btest/html/test_real
http://andresp.no-ip.org/soc2009/btest/html/test_concept
http://andresp.no-ip.org/soc2009/btest/html/test_regression

qbvh, is able to use SIMD quite eficiently, althouth vbvh is expected to
yield better performance when no SIMD is available. During this week I tried
to increase vbvh performance on SIMD and it got results pretty similar to
qbvh. (Although ~20-30% of svbvh nodes only have 2childs, so it might be
able to clearly surpass qbvh if the grouping of nodes is better exploited).


*Fixed bugs (almost all renders match / only 1 know bug left, noticiable on
ZanQdo cradle)
 I finaly understood the reason for the smooth faces that was introduced on
render code, because a bug appear related to it:
It seems the current way that blender uses to ignore neighbour hits is not
always correct, as so the banding effect on edges is created by raycasts
that the render code considers to hit the neighbour face.
I wasnt able to find a decent solution for this, as so I kept the same
behaviour as the old code.

*Some documentation on wiki updated:

http://wiki.blender.org/index.php/User:Jaguarandi/SummerOfCode2009/TestScenes
  http://wiki.blender.org/index.php/User:Jaguarandi/SummerOfCode2009/Notes(bugs
found, future optimizations)


==Next week==
Pencils down is 17. So there's not exactly a "next week".
Some documentation still needs to be improved.

My plans after SoC-2009:
*I would like to still spend some more time, until end August, polishing
some details and trying some things out.
*And then on September: work on having it merged on blender2.5 trunk.
*Maintaining the render acceleration strutures

==Schedule / Status==
All targets for the SoC proposal where archieved.
There's no doubt current code is faster rendering, and it scales better than
the old octree.

Expected speedup was in order of 2-10, and the balloon example described on
proposal (which exploited an octree worst case) got a speedup of ~39times
faster.

You can also see on the test results that the speedup was tested on a wide
variaty of scenes and it performs quite well.

---
André Susano Pinto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/soc-2009-dev/attachments/20090814/09ea2185/attachment.htm