Hi, 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 realtime. Thomas 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 - [email protected] - 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 <[email protected]> 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 <[email protected]> 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 - [email protected] - www.blender.org >>>> Chairman Blender Foundation - Producer Blender Institute >>>> Entrepotdok 57A - 1018AD Amsterdam - The Netherlands >>>> >>>> >>>> >>>> _______________________________________________ >>>> Bf-committers mailing list >>>> [email protected] >>>> https://lists.blender.org/mailman/listinfo/bf-committers >>>> >>> _______________________________________________ >>> Bf-committers mailing list >>> [email protected] >>> https://lists.blender.org/mailman/listinfo/bf-committers >> _______________________________________________ >> Bf-committers mailing list >> [email protected] >> https://lists.blender.org/mailman/listinfo/bf-committers _______________________________________________ Bf-committers mailing list [email protected] https://lists.blender.org/mailman/listinfo/bf-committers
