<div dir="ltr">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!, 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).<br><br>what I would suggest instead:<br>using next event estimators!<br><a href="https://jo.dreggn.org/home/">https://jo.dreggn.org/home/</a><br><a href="https://jo.dreggn.org/home/2015_mnee.pdf">https://jo.dreggn.org/home/2015_mnee.pdf</a><br><br>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).<br><br>1 more comment about motion blur, I wish there will be curved motion blur (multiple transforms for object instead of linear pre/mid/post)<br><br>keep the good work up :)<br><br>cheers,<br>Mohamed Sakr</div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Nov 5, 2016 at 1:58 PM, Brecht Van Lommel <span dir="ltr"><<a href="mailto:brechtvanlommel@pandora.be" target="_blank">brechtvanlommel@pandora.be</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">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>
</span>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>
<span class="">>><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>
</span>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>
<span class=""><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>
</span>I expect so, external libraries normally have options to turn them off.<br>
<span class=""><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>
</span>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>
<div class="HOEnZb"><div class="h5">______________________________<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>
</div></div></blockquote></div><br></div>