An argument for re-introducing Blender Internal in version 2.81 (or, 2.80 final)

“Simply stated, I need it.” I really can’t do without it, because I have many projects that I am still paid to support and to enhance which were built using this rendering technology. I’m frankly not willing to accept that I cannot enjoy the benefits of 2.80-and-beyond with regards to these “legacy” projects.

I’ll also suggest that – now that BI has been cleanly removed from the code-base and all of the loose-ends have been tidied up, it might well now be much easier to re-introduce this renderer in a new and much-cleaner way. (For instance, when you switch to this renderer-type in your project, controls in the user interface can switch implementations, and the selection of other controls and menu-items can change also.)

If you can introduce something as “marvelously new” as Eevee, you can also make-over something that is [still …] “marvelously old” but still needed by your customers, making it better and cleaner than it ever was.

Even though Blender quite-rightly says that renderers such as Eevee and Cycles are “better,” there are many thousands of existing Blender projects out there – many of them revenue-producing – that simply can’t be left behind. We still need to produce those same outputs for our clients, and to work with all those hundreds of files, and we shouldn’t have to be “stuck in the past” to continue to do so.

(Feel free to build logic that will re-save the files in a “not backward-compatible” way, and to re-imagine BI operations in a manner consistent with the new metaphors that you have introduced. Just give me a way to continue to use this render engine.)

Furthermore, I would argue that the rendering principles embraced by BI are still just as “valid” as they ever were.

I’m entirely confident that the Blender developers can find a way to achieve this, once they again put their minds to it. And, I have a business($$) need for it that will not go away anytime soon.


So, reintroduce as an add-on/external render engine with all the bells and whistles as before in 2.79 etc.


That’s an interesting and valid-to-me idea.

I don’t mind changing a project (especially if I can write scripts to help me do it). But what I can’t afford to do is to leave this renderer behind me: its handling of materials and textures, and its ray-traced handling of light, including the “node-based” things that it did.

To satisfy my business requirement, the final outputs have to appear as they do now with 2.79. That’s what my customers paid for – and, still do.

The user-interface particulars can change, as long as there’s some intelligent way to handle e.g. “those infernal layer-buttons” which were never a friend to me.

The 2.80 architecture already introduces “very different” renderers side-by-side – that is to say, Workbench – so I’m entirely confident that Blender Internal can be re-introduced in comparable fashion … “better than ever it was.”

“Chewie, get in there! I don’t care how it smells!” – Han Solo, Star Wars.

Please give me a “new and much-improved” BI that is still … the BI renderer. Because my business just can’t do without it.


If you need BI is there anything wrong with sticking to 2.79?


Nothing wrong with it, but OP wants to reap the benefits and improvements in 2.8 in addition to still being able to use Blender Internal without having to import/export and so on and so forth.

1 Like

I vote yes on including the BI renderer. I use it in paying work; it’s a great environment for animated technical drawings and line work that resembles tech drawings, blueprints, and explanatory drawings. Cycles and Evee are more troublesome because they don’t show FreeStyle in the viewport Shade: Rendered mode.


Stuff like this, which coincidentally just won a challenge contest, is easiest to build in the BI renderer, in my experience. I love this, btw, really nice work.

I don’t know if that piece relied on the BI renderer, but I use it heavily for toon line stylings similar to this (but humbler than this outstanding work).

Keeping all of the legacy stuff around is what causes a lot of commercial software to become bloated, which makes it heavier on hardware (ie. eating tons of RAM) and more prone to regressions.

There is almost nothing that BI can do that Eevee can’t (with the notable exception being anisotropic highlights). If we want Blender to be lightweight and compact compared to the big applications, then old stuff that has since been surpassed needs to be removed every now and then.


If you have a business need for blender internal, then why don’t you pay developers to update blender internal and integrate in into 2.8 or use a different software? It’s called investment. Also I don’t really understand why you need blender internal, given the artwork you showed as an example may very well have been created in cycles or eevee…


It’s all open source, you can just hire a developer to do it for you. :slight_smile:

I suspect it’s going to be far more difficult than you think and switching to eevee/cycles would cost less money in time/effort, or just sticking with 2.79, but that’s a cost calculation you would have to make.


I obviously do not have the money to pay developers (nor, to be one) to attempt such an integration “myself.” Instead, I’m trying to make the business case that BI should not be fully removed from 2.8 but should be re-introduced to it or to its successor.

If you have a similar business case – chime in.

1 Like

I don’t think the foundation would have removed blender internal from blender if it could help it. They said it was involved in a lot of the blender codebase (ex: freestyle used it even when the scene was set to cycles), and had design issues that made it hard to upgrade.

They supposedly had a really hard time maintaining it and adding features to it, so that is probably the main reason it wasn’t ported to 2.8. Basically it was too hard for them to just isolate blender internal from blender, then re-implement it as an addon.

I’m not a developer, but I imagine it was essentially what they call “spaghetti code”. It’s when your code is too convoluted to be easily understood. Think of a bag of string where everything inside has become tangled into a bundle of knots. Sure they could spend a lot of time trying to unknot everything, but it is easier to just get some fresh string.


It’s very likely not going to happen. I suggest investing in Cycles as soon as possible and learning new tricks, converting scenes, etc. For old work, you can stick to pre-2.8.

1 Like

You should stick to 2.79 or try to convert your old projects to 2.8.
Saying stuff like "just bring back BI because I want to use the good 2.8 stuff with my old projects " won’t bring you really far.

I’ve got 3 computers , two are too old to run 2.8 , should I ask Ton to code a pre OGL 3.3 Blender 2.8 so I can still use blender on my old hardware ? How long this will take and how much this will slow down good, new stuff coming into blender ?


Here’s my prolem, Hadriscus – “I’ve already sold‘this video’ … to them.” Said video was made using BI, and it looks great and they love it. Certainly I’m sure that I can offer them “new and amazing things that will blow their socks off” with respect to my next project, should there be one, but meanwhile sometimes I still need to make various tweaks to the content, while continuing to "give them what they paid for."

While I could, of course, continue to satisfy these requirements using “2.79 and 2.80,” I feel the honest (business) need to push back. “What is so infernally wrong, nowadays, about a renderer which has indeed served me so very well for so many years?” No, I’m certainly not a Luddite … I have no intention of using 2.79 for anything new, but I continue to find great (business) value in this rendering technology, and I don’t think that it should be entirely abandoned.

(Even today, as some of you may know, I’ve achieved useful results by combining BI and Cycles results. Before – uhh… – Eevee just “made me a Very Happy Boy.™” But, nonetheless, I can’t walk entirely away from what I’ve already sold.)

What I’d really like to see – is for it to be spit-shined. For it to be dusted-off, shed of the various bits of legacy baggage that held it back, and then re-introduced – better than ever(!!) – as a still, equally-legitimate contender for Blender rendering choices.

I look upon “Workbench” as being a re-imagination of OpenGL technology that I have lusted-after for many years, and I am therefore extremely excited to see it. But, I simply cannot believe that a software engineering team which has just achieved this cannot find a way to “similarly, re-imagine(!)” BI.

“And, pretty please, please understand that I am(!) willing to do some work!” I would love to experience a “re-imagined BI” that is “eversomuchmoreso better” than the BI that I have known up to now. (Especially if there are a few judicious Python scripts(?) provided to help me.) What I need to maintain are: visual results, and thus the technical methods used to produce them.

“In my humble, when you ‘looked again’ at OpenGL, you came up with Workbench.” Therefore: "look again … … again." This entirely-CPU-based, entirely GPU-unaware, technology … still has value that’s still (IMHO) worth saving.

The problem is that untangling everything could take countless days of potential development time away from Cycles and Eevee. Much of the engine would have to be rewritten and the BF just does have the resources to work on a legacy rendering product that is seeing a rapidly shrinking userbase.

It took Eevee a couple of years to get to where it is today, I honestly don’t see a much shorter timeframe to modernize and clean the code for BI considering that everything needs to be refactored, rewritten, and reworked.

By all means, I don’t think your contract will suffer if you continue to use 2.79 for rendering if the client already likes it.


Maybe write up a functional and illustrated request and post on to see if it gains traction with the user base and gets a response from dev side?

1 Like

For both technical a priority reasons, this is highly unlikely to happen.

Instead, what specifically can’t you do in Eevee or Cycles that you feel you need BI for?


I’ll chime in, since I help run an animation studio that uses blender exclusively.

Yes, there are features about Blender Internal that are not easily replicated in Eevee.

Two that come to mind quickly are Light Groups and the Edge Pass. Yes you can use Freestyle, but it isn’t as fast, simple, and real time as BI Edge. Secondly, the ability to make objects exclusive to Light Groups is a very handy feature not in Cycles or Eevee that allows for easy expressive rendering (I know the PBR folks take issue with the workflow about Light Groups, but NPR is just as an important style and requires different approaches and workflows).

That being said, I am in the process of porting all of our old shaders from both Cycles and BI over to Eevee. It isn’t a simple 1 to 1 process and takes some finesse and refactoring of our workflow. Though we will not able to 100% replicate some of our old material, their is a significant benefit to switching to 2.8 for most production.

That being said we’re still using 2.79 in production for certain things that are just easier done there.

I don’t mind having to use both versions for a while, and though I am not sure I would love to see all of Blender Internal reintroduced, OP does have a very valid point that there are features of it that simply are not available (nor any where close) to being available in Cycles or Eevee.


OP is right. There are BI features that Eeeve and Cycles cannot replicate at this time.

BUT! I am not sure reintroducing Blender Internal is the answer. As an artist and business operator, it is incumbent on me and my staff to seek the solutions to our creative problems, and not rely or expect to depend on Dev’s beyond offering feedback, support, and contributing to the dev fund.

But for dev’s listening, please consider Light Groups and Edge Pass for Eevee!


I sort of skipped learning blender internal in favor of learning cycles, so it’s a bit odd for me to defend it, but I think there is still a gap left with its removal. I think that the advantage it has over cycles and eevee is the fact it’s an old style render engine. Wouldn’t it be easier to support material definitions for .obj files (.mtl) using a non-physically based engine like blender internal? I think there are still people who use this format, and the last time I checked support for this was broken in cycles in blender 2.79.