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