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

Ton Roosendaal ton at blender.org
Thu Nov 10 20:45:25 CET 2016


Hi,

Please don't discuss patents on blender.org mailing lists.
You can talk about that with your lawyers. Or with me in person.

Regards,

-Ton-

--------------------------------------------------------
Ton Roosendaal  -  ton at blender.org   -   www.blender.org
Chairman Blender Foundation, Director Blender Institute
Entrepotdok 57A, 1018 AD, Amsterdam, the Netherlands

> On 09 Nov 2016, at 18:15, Brecht Van Lommel <brechtvanlommel at pandora.be> wrote:
> 
> I don't think there are any major patent issues with PMC. There may
> exist patents for specific implementations, I'm not going to check,
> but the general idea is ok to use.
> 
> It's a useful algorithm, basically a variation of MLT that has some
> advantages for GPU rendering. Again, it works well in some cases and
> fails in others. MLT and PMC are generally considered to be
> problematic for production animation rendering (NMEE is a step towards
> towards solving that).
> 
> I think there's other more important optimizations for rendering the
> kinds of things I'm interested in, but if there's developers
> interested in working on more advanced rendering algorithms for other
> uses in Cycles then that can be discussed.
> 
> 
> 
> On Wed, Nov 9, 2016 at 12:11 AM, x3108 at chello.at <x3108 at chello.at> wrote:
>> Are you sure ?
>> 
>> 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://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
>> ****************************************
>> 
>> 
>> 
>> _______________________________________________
>> 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



More information about the Bf-cycles mailing list