[Bf-cycles] Remove old Sky Model

Nathan Vegdahl cessen at cessen.com
Fri Apr 15 20:00:19 CEST 2016


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


More information about the Bf-cycles mailing list