[Bf-cycles] Bf-cycles Digest, Vol 67, Issue 6

Wed Nov 9 00:11:27 CET 2016

Are you sure ?

https://www.jstor.org/stable/27594084?seq=1#fndtn-page_scan_tab_contents <https://www.jstor.org/stable/27594084?seq=1#fndtn-page_scan_tab_contents>
http://pages.cs.wisc.edu/~yu-chi/res..._files/pmc.pdf <http://pages.cs.wisc.edu/~yu-chi/res..._files/pmc.pdf>
http://arxiv.org/pdf/cond-mat/0008226.pdf <http://arxiv.org/pdf/cond-mat/0008226.pdf>

Reading them, they are very, very old coffee papers. I doubt that Nvidia has the rights to the PMC.
Their implementation is mainly in Optix and iRay libs, which is not PMC AFAIK.

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.
So…

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-cycles/attachments/20161109/1ebe04e1/attachment.htm 