<div dir="ltr">Hi,<div><br></div><div>I&#39;m not convinced in &quot;getting rid of legacy algorithms&quot; policy. There are surely other algorithms which are more than a decade old in Cycles which we simply can&#39;t get rid about. So where to draw a line?</div><div><br></div><div>Well, it&#39;s simple. Cycles is still a BF project and BF is primary developing it for Blender and we do have quite strict policy in there: no compatibility breaking without user-measurable good outcome. If Cycles ever becomes a project on it&#39;s own you can re-consider this rule, for until then just stick to it.</div><div><br></div><div>Thomas, now replying to some points which i find wrong.</div><div><br></div><div>&gt; If we would get a more realistic Glass shader (at the same performance level), no one would complain that the render looks different (aka backwards compat breakage)<br></div><div><br></div><div>No one would complain for a new projects he (or she) is working on. However, if you replace shader completely, then you&#39;ll most likely have a complaint.</div><div><br></div><div>It does happen when during movie production when you need to go back to a shot a re-render some frames. If they&#39;ll look different you&#39;ll be screwed to re-render full shot. This even happened during open movies here in the studio.</div><div><br></div><div>&gt; I can add it back for 2.7x (to keep compatibility, as Ton suggested)</div><div><br></div><div>That&#39;s what we agreed on in IRC i thought</div><div><br></div><div>&gt; but later I really like to remove it</div><div><br></div><div>Make it properly that time. I never told we don&#39;t have to simplify settings, but cutting stuff away immediately you have a developer&#39;s response in a list where we don&#39;t have enough Blender users is not a good approach.</div><div><br></div><div>Make it a list of things which will be removed / replaced, get feedback form actual artists. And only then make decisions.</div><div><br></div><div>There are quite some settings which could go into that simplification list.</div><div><br></div><div>&gt; I don&#39;t want to end up with a Blender Internal 2.0, which has gazillions of buttons and options after 5 years</div><div><br></div><div>Amount of buttons is not the issue of BI. If you ask artists, they love buttons and knobs. The real issue of BI is that it&#39;s design stressed quite a bit with all the extra effects which were added on top of simple rasterizer.</div><div><br></div><div>You are not avoiding BI destiny by removing something which perfectly fits into design.</div><div class="gmail_extra"><br></div><div class="gmail_extra">----</div><div class="gmail_extra"><br></div><div class="gmail_extra">Stefan,</div><div class="gmail_extra"><br></div><div class="gmail_extra">I&#39;m not sure what are we debating here about. Such a removal was quite against our 2.7x roadmap. That&#39;s just given and nothing to debate about.</div><div class="gmail_extra"><br></div><div class="gmail_extra">And at this point it&#39;s definitely not better for Blender to break things (surely sometimes you can&#39;t move forward without breaking something, but in that cases we are usually delivering something better).</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 5, 2016 at 7:51 AM, Stefan Werner <span dir="ltr">&lt;<a href="mailto:stewreo@gmail.com" target="_blank">stewreo@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi,<br>
<br>
I know we’re getting into a philosophical debate here, but in my opinion, what was good clean code two years ago, will still be good clean code ten years from now if you don’t touch it - code doesn’t rust. For what it’s worth, should the Preetham model get removed, most likely we will keep it in alive in our Poser version of the Cycles source code, so that we don’t take away features from the user. If it’s better for Blender and its users to remove the Preetham model, we’ll be able to work with it.<br>
<span><font color="#888888"><br>
-Stefan<br>
</font></span><span><br>
&gt; On 04.04.2016, at 18:11, Thomas Dinges &lt;<a href="mailto:blender@dingto.org" target="_blank">blender@dingto.org</a>&gt; wrote:<br>
&gt;<br>
&gt; Hi,<br>
&gt;<br>
&gt; The benefit is &quot;get rid of legacy algorithms&quot;. If we would get a more realistic Glass shader (at the same performance level), no one would complain that the render looks different (aka backwards compat breakage). We kinda have the same argument here. Even in the Hosek paper, it directly compares with the Preetham model.<br>
&gt;<br>
&gt; I can add it back for 2.7x (to keep compatibility, as Ton suggested), but later I really like to remove it. I don&#39;t want to end up with a Blender Internal 2.0, which has gazillions of buttons and options after 5 years.<br>
<br>
</span><div><div>_______________________________________________<br>
Bf-cycles mailing list<br>
<a href="mailto:Bf-cycles@blender.org" target="_blank">Bf-cycles@blender.org</a><br>
<a href="https://lists.blender.org/mailman/listinfo/bf-cycles" rel="noreferrer" target="_blank">https://lists.blender.org/mailman/listinfo/bf-cycles</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><div><span style="color:rgb(102,102,102)">With best regards, Sergey Sharybin</span></div></div>
</div></div>