[Bf-cycles] BDPT alternative proposal > PMC kernel

Tue Nov 8 00:18:47 CET 2016

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.htm 