<div dir="auto"><div>Hi,<div dir="auto"><br></div><div dir="auto">Great work fixing all those cases!</div><div dir="auto"><br></div><div dir="auto">You're certainly allowed to work on the code next week or any other time. There's just no obligation to do it from this point on.</div><div dir="auto"><br></div><div dir="auto">For documentation, for this project I expect mostly code comments.</div><div dir="auto"><br></div><div dir="auto">When we release this we'll also need end user documentation, which would be a few sentences explaining what the new settings do. But there's not a lot to explain here.</div><div dir="auto"><br></div><div dir="auto">Regards,</div><div dir="auto">Brecht.</div><br><br><div class="gmail_quote"><div dir="ltr">On Fri, Aug 3, 2018, 19:43 Erik Englesson <<a href="mailto:erikenglesson@gmail.com">erikenglesson@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi all,</div><div><br></div><div><b>This week</b> I have been trying my branch on some of the demo scenes and found bugs that I have started to fix. <br></div><div><br></div><div>In the Barcelona Pavillion scene, I noticed that instancing of mesh lights did not work. This was fixed in this <a href="https://developer.blender.org/rB84fec2152261" target="_blank" rel="noreferrer">commit</a>. In the same commit, I also fixed the emission to luminance conversion to use linear_rgb_to_gray() instead of my own. I also noted that mesh lights are double sided which I have not had time to do anything about(considered single sided right now). <br></div><div><br></div><div>When debugging the fishy cat scene that Brecht mentioned last week I found a bug in the energy calculations for each light source. If it did not have constant emission then I considered it to have no energy at all. This has now been changed so it uses an emission of (1,1,1) instead.</div><div>The light picking method uses a diffuse approximation term in the importance metric which depends on the surface normal at the point. This normal used to make sure that only lights in the same hemisphere as the normal is pointing towards got sampled. However, this should not be the case for any surface where refraction is possible. This case came to light from the transparent cornea of the cat. Both the energy and the normal issues have been fixed <a href="https://developer.blender.org/rB108594d8c844edb09afdac1a355f0b6d99cb80db" target="_blank" rel="noreferrer">here</a>.<br></div><div><br></div><div>The classroom scene is a very complex test scene. The window is a mesh light and a portal that has a normal pointing out from the room, there is a strong fill light just outside pointing away from the room, the blackboard lamp consists of a mesh light(non-constant emission) and an area light in front of it, there is a strong point light in the corridor that is not visible for most points and finally a strong distant light.<br></div><div>In this scene, I found that the bounding boxes I calculated for area lights were wrong. This was fixed <a href="https://developer.blender.org/rB5d344f43603ddba8f3a009915b92a5374066efeb" target="_blank" rel="noreferrer">here</a>.</div><div>There was a dustbin that was transparent which made me realize(with the help of Brecht) that the position and normal that is used for the light picking should be from the last non-transparent bounce. This change can be found <a href="https://developer.blender.org/rBe8e0669785cd" target="_blank" rel="noreferrer">here</a>.<br></div><div><br></div><div>Brecht mentioned that I use doubles in the split heuristic to avoid some precision and overflow issues but doubles will not work well for the GPU. I have now changed this to use floats instead but I am still using doubles to calculate the energy variance on the host which seems to be where the precision issues came from. The overflow problem was related to squaring the number of emitters in the node. When I saw that it overflowed I think I used integers to calculate the square which has a much lower maximum value than floats. It does not seem to overflow anymore at least. This change can be found <a href="https://developer.blender.org/rBf6305047f44bf3168b1da8601307d78015ad8f65" target="_blank" rel="noreferrer">here</a>.<br></div><div><br></div><div>I have also continued the work on volumes. I think I have been able to only use the new light picking strategy for shading points that are not inside or on the boundary of a volume. For volume points, it is using the old picking method. This is until the volume part of the paper has been implemented. I also fixed a bug in light_background_sample() that used an index into the lights array as an index into the distribution array. The volume changes and the bug fix can be found <a href="https://developer.blender.org/rB94af4326e3fc22fe1b229a3e2435fb6ccfe36ce9" target="_blank" rel="noreferrer">here</a>.</div><div><br></div><div><b>Next week</b> is a bit unclear to me. Am I only supposed to write documentation and do the evaluation? If so, what kind of documentation do you want? There are still things I have not had time to fix, e.g. the clock in the classroom scene is darker using the light tree, branched vs normal path tracing has some brightness differences(I have not implemented splitting in light_bvh_pdf() ), doing something about mesh lights being double sided, add more comments to the code, splitting is not implemented for branched path tracing of volumes, add tests, try running on GPU, etc. Can I work on some of this next week? I would appreciate if someone could clarify this for me.</div><div><br></div><div>Have a great weekend!</div><div><br></div><div>Thanks,</div><div>Erik<br></div></div>
-- <br>
Soc-2018-dev mailing list<br>
<a href="mailto:Soc-2018-dev@blender.org" target="_blank" rel="noreferrer">Soc-2018-dev@blender.org</a><br>
<a href="https://lists.blender.org/mailman/listinfo/soc-2018-dev" rel="noreferrer noreferrer" target="_blank">https://lists.blender.org/mailman/listinfo/soc-2018-dev</a><br>
</blockquote></div></div></div>