<div dir="ltr"><div>Hi all,</div><div><br></div><div>Here's some Cycles development updates from the Blender Conference. Feel free to add anything I missed.</div><div><br></div><div><br></div><div>PRESENTATIONS</div><div><br></div><div>Tangent Animation (Stefan): <a href="https://www.youtube.com/watch?v=_2Ia4h8q3xs">https://www.youtube.com/watch?v=_2Ia4h8q3xs</a></div><div>Theory Studios (Lukas): <a href="https://www.youtube.com/watch?v=r_Gjx-rrIG0">https://www.youtube.com/watch?v=r_Gjx-rrIG0</a></div><div>Agent 327: <a href="https://www.youtube.com/watch?v=JKlgCnp_57M">https://www.youtube.com/watch?v=JKlgCnp_57M</a></div><div><br></div><div><br></div><div>MEETING</div><div><br></div><div>We had a meeting with Cycles developers present at the Blender conference. Mostly we exchanged what everyone was working on and discussed some implementation details. The roadmap has been updated:</div><div><a href="https://wiki.blender.org/index.php/Dev:Source/Render/Cycles/Roadmap">https://wiki.blender.org/index.php/Dev:Source/Render/Cycles/Roadmap</a></div><div><br></div><div><br></div><div>DESIGN</div><div><br></div><div>Some notes from discussions with other developers:</div><div><br></div><div>* Embree is planned to be integrated, replacing our BVH building code. Main speedups would be for motion blur and hair. For GPU BVH traversal we would translate the BVH to our own data structures and keep our own traversal. For the CPU it's not clear yet if it will end up being better to keep our own traversal code, depends on code complexity and performance. For more details on Embree benefits see Stefan's presentation.</div><div><br></div><div>* Adaptive sampling: there's a few challenges in implementing this, particularly around sharing information between neighboring tiles, and keeping the GPU occupied. Idea would be to do a basic (CPU) implementation that doesn't share information between tiles, but only to looks at denoising passes in neighborhood around pixel within a tile, to decide on the number of samples. Then we can evaluate what kind of artifacts there are compared to rendering with one big tile, and if the additional complexity is needed. If needed, sharing information between tiles could use the same mechanism as denoising to map neighboring tiles, perhaps just once after the minimum number of samples is taken.</div><div><br></div><div>* Denoising animations. We'll try to get a minimum viable implementation working, which would likely be a button in the Blender UI to denoise an sequence of rendered EXR files. The compositor will need to run afterwards, reading the denoising EXR files from disk with the Render Layers node. This is currently not supported, and will also be useful for compositing without re-rendering in general.</div><div><br></div><div>* Bevel shader using raytracing is ok to be added, even if it's probably too slow to advise using for animation rendering. We will add warnings about this in the documentation and the release notes.</div><div><br></div><div>* We'd like to make the code style more consistent, using clang-tidy. The main issue with such changes is that it can be a pain to merge existing branches. However, conflict resolution can be automated by running clang-tidy on the new code, so hopefully it would not be so bad.</div><div><br></div></div>