[Bf-cycles] Remove old Sky Model

[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