<div dir="ltr"><div>Hi all,</div><div><br></div><div><b>This week </b>I have tried to find and fix as many bugs as possible. I also did a quick optimization and had a look at volumes.</div><div><br></div><div><u>Bugs</u></div><div><u><br></u></div><div>In last weeks email, I was discussing some discontinuities in the lighting in one of my test scenes that used mesh lights. These were caused by a bug coming from the PDF restructure I did a few weeks ago. Lukas helped me pinpoint this bug. Thanks!</div><div><br></div><div>I also found and fixed an indexing issue in the background MIS calculations.<br></div><div><u></u></div><div><u><br></u></div><div>This work can be found in this <a href="https://developer.blender.org/rB00b90ede1b8cba0d47a4cdc7c6d48f49ed15d677">commit</a>.</div><div><br></div><div><u>Optimization</u></div><div><u><br></u></div><div>I ran the code through a profiler(perf) and found that most of the time was spent in cosine and arccosine functions. These functions are used heavily in the importance calculations so I changed them to fast_cos() and fast_acos() instead. I got a 1.4x speedup in the scene I was testing without any visual difference. <br></div><div><br></div><div>After this optimization, I could not find any more low hanging fruit. I also did not want to spend too much time optimizing at this point in time. Now, most of the time was spent in the recursive tree traversal function. This could potentially be due to the overhead of recursion and if so it would be interesting to implement a stack traversal similar to what the geometry BVH traversal is doing. I do not think recursion works well on the GPU which is another reason to do this.<br></div><div><br></div><div>This change can be found <a href="https://developer.blender.org/rB6045fc40f4cd1d89f326a2d937e07752f5e3ad7c">here</a>.</div><div><br></div><div><u>Volumes</u></div><div><u><br></u></div><div>I have not really considered volumes up till now. The paper proposes another importance metric for volumes that I have not implemented yet. I tried to use the current implementation of the paper for the volumes too but ran into issues with MIS calculations. It was able to find lights that the light tree would give zero probability of sampling which resulted in fireflies. For now, I am disabling the light tree picking method if the shading point is inside volume or on the volume boundary. Currently, I check if a shading point is inside or on a volume boundary by looking at the volume_bounce and volume_bounds_bounce counters to see if any of them are non-zero. Is there a better way? This will be needed when the proper volume importance metric is implemented too.<br></div><div><br></div><div>I also spent a lot of time trying to make sure the MIS calculations are using the correct shading point and normal, i.e. from the vertex before the light. This is actually really tricky in the current code, due to all the possible code paths that call the MIS calculations. To do this properly for all the code paths will take some time.</div><div><br></div><div><br></div><div><b>Next week</b> I want to</div><div><ul><li>Make sure volumes looks OK when rendering with the light tree</li><li>Continue fixing MIS calculations</li><li>Find and fix as many bugs as possible<br></li><li>Have a look at the paper to see how hard it would be to implement the volume importance metric and potentially implement it</li><li>Add more comments in the code<br></li></ul>I would also like to compare renders and render times between my branch and master <u>without</u> using the light tree.  If my branch is slower then I might look into optimizing it.</div><div><br></div><div>Ideally, I would like this branch to be merged into master/2.8. If there is anything you can think of that is better to work on than what I have mentioned above then please let me know. Is it possible to add this work as an experimental feature?</div><div><br></div><div>Thanks,</div><div>Erik<br></div><div><br></div><div><br></div><div><br></div></div>