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