<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div>Are you sure ?</div><div><br class=""></div><div><a href="https://www.jstor.org/stable/27594084?seq=1#fndtn-page_scan_tab_contents" class="">https://www.jstor.org/stable/27594084?seq=1#fndtn-page_scan_tab_contents</a></div><div><a href="http://pages.cs.wisc.edu/~yu-chi/res..._files/pmc.pdf" class="">http://pages.cs.wisc.edu/~yu-chi/res..._files/pmc.pdf</a></div><div><a href="http://arxiv.org/pdf/cond-mat/0008226.pdf" class="">http://arxiv.org/pdf/cond-mat/0008226.pdf</a></div><div><br class=""></div><div>Reading them, they are very, very old coffee papers. I doubt that Nvidia has the rights to the PMC.</div><div>Their implementation is mainly in Optix and iRay libs, which is not PMC AFAIK.</div><div><br class=""></div><div>Yes of course there needs to be a coding in CUDA/OpenCL and CPU, but that is just a new programming in GPL, nobody is copying code.</div><div>So…</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">I believe that most (all?) PMC techniques are under nvidia's legal umbrella.<br class=""><br class="">On Nov 7, 2016 6:14 PM, "<a href="mailto:x3108@chello.at" class="">x3108@chello.at</a>" &lt;<a href="mailto:x3108@chello.at" class="">x3108@chello.at</a>&gt; wrote:<br class=""><br class=""><blockquote type="cite" class="">Hi,<br class=""><br class="">guys, why not use a PMC kernel like in Octane Render ?<br class="">PMC is fully PT pipeline compliant and doesn't break Cycles versatility<br class="">AFAIK.<br class="">It solves scene transversal rays extremely efficient and can be expanded<br class="">even to spectral rendering.<br class="">Brecht knows PMC i guess very well. :-)<br class=""><br class="">PMC is even in some cases superior to BDPT and faster while ?finding? all<br class="">lights with the flexibility of Cycles untouched.<br class=""><br class="">So unless there are no legal stuffs (Otoy?), why not doing it with a PMC<br class="">kernel ?<br class="">PMC with the upcoming denoiser would be a mind-blower of the first order!<br class=""><br class="">Correct me if im wrong, but why reinvent the wheel ?<br class=""><br class="">@Brecht et al.:<br class="">Is PMC a too complicated step to implement ? Any barriers with actual<br class="">Cycles ? Just a rough estimate.<br class=""><br class="">Best regards,<br class="">Enilnacs<br class=""><br class=""><br class=""><blockquote type="cite" class="">Message: 8<br class="">Date: Sun, 6 Nov 2016 01:35:37 +0100<br class="">From: Brecht Van Lommel &lt;<a href="mailto:brechtvanlommel@pandora.be" class="">brechtvanlommel@pandora.be</a>&gt;<br class="">Subject: Re: [Bf-cycles] Cycles contributor meeting notes<br class="">To: Discussion list to assist Cycles render engine developers<br class=""> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;<a href="mailto:bf-cycles@blender.org" class="">bf-cycles@blender.org</a>&gt;<br class="">Message-ID:<br class=""> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;CAKFUgC3YU7zj2auLccooLCD2HYaWPo1oqGupBJvxYZJNXAV2og@mail.<br class=""></blockquote><a href="http://gmail.com" class="">gmail.com</a>&gt;<br class=""><blockquote type="cite" class="">Content-Type: text/plain; charset=UTF-8<br class=""><br class="">Hi,<br class=""><br class="">MNEE does not solve most PT light transport problems, it's just one of<br class="">many algorithms with various trade-offs. The paper only deals with<br class="">refraction, though in principle it could be generalized and then we'd<br class="">need to see how well that works compared to other algorithms. Being<br class="">able to explore around light paths is great, but for many light paths<br class="">the problem is finding them in the first place, and I think for that<br class="">you need to go bidirectional.<br class=""><br class="">It's also not obvious to me that MNEE would be entirely compatible<br class="">with light path nodes.<br class=""><br class="">Agreed about multi-step object motion blur, I would be happy to see<br class="">someone working on that.<br class=""><br class="">Regards,<br class="">Brecht.<br class=""><br class="">On Sat, Nov 5, 2016 at 10:44 PM, Mohamed Sakr &lt;<a href="mailto:3dsakr@gmail.com" class="">3dsakr@gmail.com</a>&gt; wrote:<br class=""><blockquote type="cite" class="">Hi,<br class=""><br class="">great stuff, I wish I could join :)<br class="">my comment about BDPT:<br class="">why using BDPT or go toward that? most artists optimize the scene for<br class=""></blockquote></blockquote>PT!,<br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">although BDPT catch more lights/help with more/better light transport,<br class=""></blockquote></blockquote>they<br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">add huge complexity + they are not really compatible with the current<br class=""></blockquote></blockquote>light<br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">path node. (which is a core node in Cycles).<br class=""><br class="">what I would suggest instead:<br class="">using next event estimators!<br class=""><a href="https://jo.dreggn.org/home/" class="">https://jo.dreggn.org/home/</a><br class="">https://jo.dreggn.org/home/2015_mnee.pdf<br class=""><br class="">this simply solve most PT light transport problems with glossy/specular<br class="">surfaces, and still 100% PT, though the single sample takes about 3x<br class=""></blockquote></blockquote>time<br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">(for extra estimations), but with the upcoming denoiser, 128 good<br class=""></blockquote></blockquote>samples<br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">with denoise will be more than enough for production. (these 128<br class=""></blockquote></blockquote>samples can<br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">out perform 2k standard PT samples, with render time of about 400<br class=""></blockquote></blockquote>samples,<br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">with denoising they will surpass a 5k sampled PT). + these MNEE can<br class=""></blockquote></blockquote>handle<br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">caustics.(Cycles suffer from this badly).<br class=""><br class="">1 more comment about motion blur, I wish there will be curved motion<br class=""></blockquote></blockquote>blur<br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">(multiple transforms for object instead of linear pre/mid/post)<br class=""><br class="">keep the good work up :)<br class=""><br class="">cheers,<br class="">Mohamed Sakr<br class=""><br class="">On Sat, Nov 5, 2016 at 1:58 PM, Brecht Van Lommel<br class="">&lt;<a href="mailto:brechtvanlommel@pandora.be" class="">brechtvanlommel@pandora.be</a>&gt; wrote:<br class=""><blockquote type="cite" class=""><br class="">On Sat, Nov 5, 2016 at 9:52 AM, Nathan Letwory &lt;<a href="mailto:nathan@mcneel.com" class="">nathan@mcneel.com</a>&gt;<br class=""></blockquote></blockquote></blockquote>wrote:<br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class="">CONTINUOUS INTEGRATION<br class=""></blockquote><br class="">Perhaos this could be used also to automatically sync the stand-alone<br class="">repository. Yes, there is the script by Sergey, but that works on<br class=""></blockquote></blockquote></blockquote></blockquote>linux.<br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class="">And still is manual. CI can be used to automate that.<br class=""></blockquote><br class="">Maybe, but we'd need to automatically check there are no merge<br class="">conflicts, build errors or failing tests, and sometimes bump versions.<br class="">Committing code to me it seems more like a manual job for a developer<br class="">to do carefully, rather than something we can safely automate.<br class=""><br class="">Perhaps if the Cycles standalone repository contained the script, then<br class="">any developer could do the update themselves when they need it?<br class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">XML FILE FORMAT<br class=""><br class=""></blockquote>For Rhinoceros 3D we use this extensively also. This is also used for<br class="">Grasshopper 3D, and we'll be continuing to do so.<br class=""><br class="">That said, we currently use a C# implementation of the XML API, but<br class=""></blockquote></blockquote></blockquote></blockquote>we'd<br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class="">be really happy if this can be retained.<br class=""><br class=""><blockquote type="cite" class="">File format itself doesn't matter too much, might switch to something<br class="">else than XML if needed. But as long as the Cycles API can read/write<br class="">it, it's not a big deal.<br class=""></blockquote><br class="">I'd like to stick with XML, because currently a switch away from that<br class="">would mean re-implementing the parser.<br class=""></blockquote><br class="">So you have your own XML parser? I think generally a better system is<br class="">to let Cycles read and write the files, then you have only a single<br class="">code path to export data for interactive renders and for renders from<br class="">an XML file.<br class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">UDIM / PTEX<br class="">OPENVDB AND VOLUME RENDERING<br class=""></blockquote><br class="">Not of very much importance to us at the moment. I guess this will<br class=""></blockquote></blockquote></blockquote></blockquote>stay<br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class="">optional when building Cycles code...<br class=""></blockquote><br class="">I expect so, external libraries normally have options to turn them off.<br class=""><br class=""><blockquote type="cite" class="">Did the meeting talk about C++1x usage in an effort to drop boost<br class="">dependency? For our usage we have also essentially dropped<br class=""></blockquote></blockquote></blockquote></blockquote>OpenImageIO,<br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class="">since Rhino already has image reading code etc. Only the ustring part<br class=""></blockquote></blockquote></blockquote></blockquote>is<br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class="">really in use, so there is a heavily cut-down version of OIIO (just<br class=""></blockquote></blockquote></blockquote></blockquote>that<br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class="">what is needed minus all image reading code). Ideally we'd want a<br class=""></blockquote></blockquote></blockquote></blockquote>Cycles<br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class="">that has as few dependencies as possible, but I understand that isn't<br class="">necessarily the main focus :)<br class=""></blockquote><br class="">We didn't talk about it at the meeting, but we definitely want to get<br class="">rid of a direct dependency on Boost and use C++11 instead. It's just<br class="">waiting for Blender build script updates before we can make the<br class="">switch.<br class=""><br class="">Regards,<br class="">Brecht.<br class="">_______________________________________________<br class="">Bf-cycles mailing list<br class=""><a href="mailto:Bf-cycles@blender.org" class="">Bf-cycles@blender.org</a><br class="">https://lists.blender.org/mailman/listinfo/bf-cycles<br class=""></blockquote><br class=""><br class=""><br class="">_______________________________________________<br class="">Bf-cycles mailing list<br class=""><a href="mailto:Bf-cycles@blender.org" class="">Bf-cycles@blender.org</a><br class="">https://lists.blender.org/mailman/listinfo/bf-cycles<br class=""><br class=""></blockquote><br class=""></blockquote><br class="">_______________________________________________<br class="">Bf-cycles mailing list<br class=""><a href="mailto:Bf-cycles@blender.org" class="">Bf-cycles@blender.org</a><br class="">https://lists.blender.org/mailman/listinfo/bf-cycles<br class=""><br class=""></blockquote>-------------- next part --------------<br class="">An HTML attachment was scrubbed...<br class="">URL: <a href="http://lists.blender.org/pipermail/bf-cycles/attachments/20161107/579892f2/attachment-0001.htm" class="">http://lists.blender.org/pipermail/bf-cycles/attachments/20161107/579892f2/attachment-0001.htm</a> <br class=""><br class="">------------------------------<br class=""><br class="">_______________________________________________<br class="">Bf-cycles mailing list<br class=""><a href="mailto:Bf-cycles@blender.org" class="">Bf-cycles@blender.org</a><br class="">https://lists.blender.org/mailman/listinfo/bf-cycles<br class=""><br class=""><br class="">End of Bf-cycles Digest, Vol 67, Issue 6<br class="">****************************************<br class=""></div></div></blockquote></div><br class=""></body></html>