[Bf-cycles] Remove old Sky Model

[Thomas Dinges]

I need new glasses, I thought you were the other Nathan (Letwory). This 
is embarassing.

Back to coding, less chance to screw things up there. :)

Am 15.04.2016 um 20:42 schrieb Thomas Dinges:
> Hi Nathan,
>
> I agree, we should communicate feature removal clearly and in advance,
> and also reflect that in the version number of Cycles. I am fine with
> that! :) The Sky model removal was rushed from my end, lesson learned.
>
> My point is, that I don't want to start a policy of removing something
> from Blenders UI, but keep the code in Cycles.
> Either we remove something altogether, or we keep it. Again, if properly
> communicated, that should be fine.
>
> That being said, I think if we want to change some bigger things and
> remove stuff, now would be a good time for it. Rhino hasn't been
> released yet with Cycles officially, correct? So changing stuff now
> wouldn't hurt much. Once released, I am sure you will feel even stronger
> about these things.
>
> We are very happy to see Cycles in other programs, we hoped for that
> when we relicensed it. That is cool.
> The standalone git repository, the version numbering..., we introduced
> these for external projects. Nevertheless, all active Cycles developers
> come from the Blender side, so that should be our focus. I still hope
> that this will change though, and we'll get more contributions from
> Poser and Rhino ;)
>
> Best regards,
> Thomas
>
>
> Am 15.04.2016 um 20:00 schrieb Nathan Vegdahl:
>> Hi Thomas,
>>
>>> As long as feature removal is communicated well and long in advance, I
>>> don't see why we should do half-baked things.
>> The main point I'm trying to get across is that from a third-party
>> perspective, Cycles is a library.  And feature removal amounts to an
>> API breakage.  I don't have a problem with legacy feature removal
>> per-se, but doing so should follow software library best practices
>> (e.g. start with a long period of documented deprecation, save up
>> removals to be done all together on a major version bump where API
>> breakage is expected, and have a branch for continued maintenance of
>> old major version, etc.).
>>
>> That assumes, of course, that BF wants to promote Cycles being used by
>> third-party software.  If that isn't a goal, then it doesn't really
>> matter.  But I got the impression somewhere along the line that we'd
>> like Cycles to be used by more than just Blender.
>>
>> --Nathan
>>
>>
>> On Thu, Apr 14, 2016 at 10:19 AM, Thomas Dinges <blender at dingto.org> wrote:
>>> As long as feature removal is communicated well and long in advance, I
>>> don't see why we should do half-baked things.
>>>
>>> Sometimes removing features is not only a UI topic, removing larger
>>> parts is sometimes also helpful to cleanup code and decrease the kernel
>>> size (which is still an issue on the GPU). I rather not start with this
>>> policy, either we remove something or we keep it.
>>>
>>> Am 14.04.2016 um 19:02 schrieb Nathan Vegdahl:
>>>> Are we talking about removing this from Cycles, or removing it from
>>>> Blender?  Removing it from Cycles seems unnecessary to me.  As Stefan
>>>> illustrates, other software is now depending on Cycles as an engine,
>>>> so removing features impacts more than just Blender.
>>>>
>>>> However, we can still choose to simply not expose legacy features of
>>>> Cycles in the Blender UI.  Right?
>>>>
>>>> Is there some difficulty in approaching things that way?  Essentially,
>>>> treat Cycles like a library (avoid feature removal), but treat its
>>>> integration with Blender as a tool (hide legacy features in UI).  That
>>>> way we neither discourage others from integrating Cycles with their
>>>> tools, nor do we straight-jacket ourselves into a cluttered UI of
>>>> legacy features in Blender.
>>>>
>>>> --Nathan
>>>>
>>>> On Tue, Apr 5, 2016 at 3:34 AM, Thomas Dinges <blender at dingto.org> wrote:
>>>>> Hi,
>>>>> I reverted the commit now, so the Preetham Sky Model will still be
>>>>> available for the duration of 2.7x.
>>>>> I apologize for the inconvenience, I should have communicated the change
>>>>> better beforehand.
>>>>>
>>>>> For the 2.8x series of Blender, we can re-think this (and other things
>>>>> too), but best to make a list of changes first and discuss it.
>>>>>
>>>>> Best regards,
>>>>> Thomas
>>>>>
>>>>> Am 05.04.2016 um 10:55 schrieb Piotr Adamowicz:
>>>>>> Since Sergey mentioned there were not enough artists on the list -
>>>>>>
>>>>>> The removal of the old sky shader is no problem. Should there ever be
>>>>>> a need to render an old scene with the old sky in a new Blender
>>>>>> version, it's trivial to render the sky out to an environment texture
>>>>>> with an older Blender version. So IMHO it's fine to remove it for 2.8.
>>>>>>
>>>>>> On Tue, Apr 5, 2016 at 10:34 AM, Thomas Volkmann
>>>>>> <lists at thomasvolkmann.com> wrote:
>>>>>>>> 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)
>>>>>>> No one would complain for a new projects he (or she) is working on. However,
>>>>>>> if you replace shader completely, then you'll most likely have a complaint.
>>>>>>>
>>>>>>> It does happen when during movie production when you need to go back to a
>>>>>>> shot a re-render some frames. If they'll look different you'll be screwed to
>>>>>>> re-render full shot. This even happened during open movies here in the
>>>>>>> studio.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Usually you don't switch Software-versions during production. If you do on
>>>>>>> purpose then you are prepared to deal with changes. Once a project is
>>>>>>> finished it is tied to that software version, so if you're going to do some
>>>>>>> changes later, you dig out that old version of the Software (or you take
>>>>>>> your time to port it to a newer version).
>>>>>>>
>>>>>>> That said, minor version numbers should probably be consistent (e.g. the
>>>>>>> latest 2.7x can render render stuff done in 2.71). So best point for changes
>>>>>>> would be 2.8.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Just sayin',
>>>>>>>
>>>>>>> Thomas
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>> _______________________________________________
>>> 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