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

[Brecht Van Lommel]

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
>