[Bf-committers] Blender developers meeting notes, 9 April 2016

Thomas Dinges blender at dingto.org
Tue Apr 12 11:06:58 CEST 2016

first of all, there are no real plans atm to remove Blender Internal, at 
least not among core developers.
We surely want to move towards a PBR viewport / GLSL renderer, but that 
doesn't mean that BI will be kicked anytime soon.

Second, Cycles is certainly not "underdeveloped", it never aimed for 
realtime rendering. It's a production renderer for VFX and Films, not 


Am 12.04.2016 um 10:49 schrieb Alexander Romanov:
> Hi all!
> I have some thoughts about removing BI in Blender 2.8.
> 1) I've tried to remove BI code and found that there must be some active
> render engine, so, at least one always should be built in the core and
> for now it is BI. We can select Cycles, but it is an addon, which can be
> disabled. Should we isolate the common part of all Viewport engines? For
> example, solid and wireframe modes could be common. For now the Cycles
> and BI shading in solid mode is different.
> 2) BI(CPU side) has a more strong reliance with the core then Cycles.
> They are just parts of monolithic kernel. But this reliance can be weakened.
> 3) Blend4Web developers don't really like the idea of BI permanent
> removal. Because the future is still not clear and we don't know what
> functionality the future Viewport will have and how soon it will
> cover/replace the current capabilities.
> 4) In addition BI Viewport at the moment is the only self-sufficient
> real time renderer for Blender. Cycles so far is underdeveloped. Also,
> it is not known what would be the basis for the future Viewport system.
> Clement's work? Or some other system with new nodes, that is more
> compatible with the deferred shading technology?
> 5) So, my proposal is to reduce relationship between the core and BI and
> put BI into an addon. I want to keep the old node system, at least for
> the first time. Of course, OpenGL BI code will stay in the core, since
> we have no infrastructure to build it separately (and probably we will
> never exclude the viewport from the core into a module because of
> monolithic kernel policy). So I would like to help to refactor Viewport
> in order to keep the old node system.
> On 10.04.2016 13:29, Ton Roosendaal wrote:
>> Hi,
>> Before we get upset (or happy) about the removing bizz, let's be very clear.
>> There are two types of "remove". One is a temporary remove (for refactor, recode or redesign), and the other is a permanent removal.
>> The first category will be quite easy to agree on. For the second category we can do a long review and insist on a wide consensus by the teams.
>> The "remove" sequencer or game engine thefore should be read as "recode".
>> -Ton-
>> --------------------------------------------------------
>> Ton Roosendaal  -  ton at blender.org   -   www.blender.org
>> Chairman Blender Foundation, Producer Blender Institute/Studio
>> Entrepotdok 57A  -  1018AD Amsterdam  -  The Netherlands
>>> On 09 Apr 2016, at 22:23, Aaron Carlisle <carlisle.b3d at gmail.com> wrote:
>>> I think that blender internal should be removed, permanently.
>>> And instead be replaced by the improved view port.
>>> Just my two cents :)
>>> On Sat, Apr 9, 2016 at 2:35 PM, Ton Roosendaal <ton at blender.org> wrote:
>>>> Hi all,
>>>> Here are the notes from today's LA 10 AM timezone meeting, #blendercoders
>>>> irc.freenode.
>>>> 1) Blender 2.77a release
>>>> - The release went out last week, all is fine with it. No showstoppers in
>>>> bug tracker.
>>>> 2) Blender 2.78 (or 2.8)
>>>> - There are a couple of ongoing projects we can do a new release for. No
>>>> planning yet.
>>>>    (VR rendering, Headmounted disply support, Alembic, etc)
>>>> - Main meeting topic was brought in by Thomas Dinges: where are the plans
>>>> for 2.8!?
>>>> Meeting agreed on not planning any new release before we (also) have a
>>>> solid planning for 2.8.
>>>> - A good way to get this started is to open a (first) 2.8 branch with all
>>>> of the code we
>>>> want to refactor or redesign removed. That could mean: no viewport code,
>>>> no particles, no
>>>> game engine, no sequencer, etc. It's OK if the branch is dysfunctional for
>>>> a while.
>>>> Developers who then need to do even more radical work can fork this branch
>>>> and work on
>>>> their modules.
>>>> We did something similar back then for 2.5. In the end we just put back a
>>>> lot of old code
>>>> still - for the sake of having things work - but we could also fix a lot
>>>> of design flaws.
>>>> Next meeting (18 April) we aim at having a 2.8 branch proposal for the
>>>> meeting to agree on.
>>>> 3) Other projects
>>>> - Kevin Dietrich has an Alembic patch ready for review:
>>>> https://developer.blender.org/T48075
>>>> - Mai Lavelle submitted Cycles microdisplacement code. Brecht van Lommel
>>>> reviews.
>>>> https://github.com/maiself/blender/tree/microdisp
>>>> -Ton-
>>>> --------------------------------------------------------
>>>> Ton Roosendaal  -  ton at blender.org   -   www.blender.org
>>>> Chairman Blender Foundation - Producer Blender Institute
>>>> Entrepotdok 57A  -  1018AD Amsterdam  -  The Netherlands
>>>> _______________________________________________
>>>> Bf-committers mailing list
>>>> Bf-committers at blender.org
>>>> https://lists.blender.org/mailman/listinfo/bf-committers
>>> _______________________________________________
>>> Bf-committers mailing list
>>> Bf-committers at blender.org
>>> https://lists.blender.org/mailman/listinfo/bf-committers
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> https://lists.blender.org/mailman/listinfo/bf-committers

More information about the Bf-committers mailing list