If you’ve ever opened a fresh, official build of Blender, you may be familiar with that button at the top-middle of the window that says “Blender Render”. You probably only know this button because it’s the button that you switch to “Cycles”. But why do we switch it to Cycles? What’s the “Blender Render” all about?
Related Blender Tutorials
- Fundamentals of Lighting in Blender,
- Fundamentals of Blender Materials and Shading
- Cycles vs Eevee - 15 limitations of real-time rendering in Blender
- Rendering and finishing a Blender animation
Blender Render
Also known as “blender internal” (or BI), this is Blender’s original render engine with source code dating back to the early 90’s. It’s a hodge-podge of new(ish) and old render technology crammed together that includes ray-tracing, subsurface scattering, glossy reflections, and even a primitive global illumination feature.In general, it’s a very fast render engine for most of its features and it excels with non-photo-realistic (NPR) rendering. But it suffers substantially with photo-realism. BI was forged in a time when realism could only be achieved through illusion; with tricks and hacks to fake reality’s characteristics.But you likely haven’t heard much mention of Blender Internal, if any, in recent years. And depending on when you discovered Blender, you may have never used it before. The reason for BI’s diminished spot light?
Cycles
As of 2011 Blender has a new-fangled, cutting-edge renderer called Cycles. It’s a tremendous leap forward in terms of realistic rendering, with full-fledged global illumination and physically accurate calculations.You might be asking, “Why is it a separate engine and not an upgrade to Blender Internal?” Well, sometimes it’s easier to start from scratch than to modify an existing thing. BI has been through years of development with lots of features and upgrades tacked on. Over time this made it increasingly difficult to continue its development and thus Brecht decided to write a new engine from scratch.It’s proved to be wildly popular and has quickly become Blender’s premier render engine. Cycles has garnered notable respect from the computer graphics industry. In fact, other 3D software developers have even ported it to other applications, like Cinema 4D and Rhino.
So why keep both engines around?
I’ll answer that question with another question: Since when is having options a bad thing? The reality is BI and Cycles do things differently enough that they’re not really competing. Rather they’re two tools that are both [still] powerful in their own respects.
When Blender Render is a good choice:
- Fast Renders: If you ever need a basic render quickly, BI should be your first option. By “basic render” I mean simply lights + materials. As a scanline renderer, sample noise is mostly a non-issue. Where Cycles is a progressively refining engine and noise is always a factor.
- NPR: In short, BI is a great option for any kind of non-photorealistic rendering. This can mean motion graphics, cartoony animations, and information visualizations among others situations.
- Texture Painting: Both Cycles and BI offer texture painting features with some key differences. BI’s texture painting in-viewport has, in my opinion, a better interface for painting multiple types of textures at the same time, called “Texture Slots”. Cycles only allows for one texture to be painted at a time.
- Texture Baking Speed: Common texture baking types like ambient occlusion and geometry normals bake faster with BI than Cycles.
When Cycles is a good choice:
- Realism, realism, realism: Without question, Cycles is the best choice for realistic rendering. And since it’s built on physically-based principles, it’s very easy to use from an artistic standpoint. To even attempt realism with non physically-based scanline renders, like BI, artists must engage in a seemingly never-ending game of tricks and parameter-experimenting. Think of it this way: Cycles’ default settings are essentially photo-realistic out of the box - I know they’re not 100% perfect, but to the majority of human eyes, it’s pretty darn close. Then as you progress and commonly want to optimize your render, you have the option to tweak your settings for the sake of speed, usually at the cost of physical accuracy. Then you have BI where default settings are far from realistic and you have to add and tweak new parameters to have any hope of getting a decently realistic result.
- GPU-acceleration: Even though Cycles’ development results in faster and faster rendering speeds over time, it’s biggest negative is still that general render times are long. Because hey, emulating reality’s complex system of light is kinda hard! However, to combat this, Cycles’ offers GPU acceleration that can drastically reduce render times. If you can afford an expensive graphics card, your Cycles engines can fly. This is especially cool when viewport rendering for real-time lighting and material creation.
Final Thoughts
Don’t let the number of bullets fool you - More in the list doesn’t mean better and fewer doesn’t mean worse. Cycles’ ability to spearhead realistic rendering is an enormous benefit. But hopefully you can also see that BI isn’t an old geezer to ignore. Each of Blender’s engine’s has its uses and you will be a better artist if you know how to use them both.
Even though the Blender Developer Fund no longer supports further development of the Blender Internal engine, development continues through the Blender NPR / BEER project. Follow the link to find out more and consider donating!
I think they're separate engines because they inherently work differently. Cycles is a pure compute path-tracer, while internal is mostly OpenGL based - and really legacy OpenGL algorithms at that. With the OpenGL API, you wouldn't have the ability to run the same type of code that Cycles needs.
And I also think Cycles was the main proof-of-concept for having completely 3rd party renderers seamlessly integrate with Blender(?) - I could be wrong about this though. But, if I'm right about that, then it's also kept separate to help design the framework for Blender to integrate with other 3rd party renderers (such as the LuxRender and Renderman plugins).
For me, I mostly use internal when rasterization makes more sense, such as when I'm rendering unlit 2D texture plates and motion graphics - not only for speed reasons, but casting path-tracing rays when doing something that is essentially using Blender as an animate-able Photoshop would be awkward.
Maybe they could fork BI and the Game engine into separate programs. Then those of us who are happy with NPR can just have what we want.
I don't think it's more complicated. The node system, while not mandatory, helps out with achieving specific results.
As long as you know how the nodes sockets are color coded, you know when to break using one with another. The rest is using nodes like you would a language, where each node is like a word. If I say"door", you know what I mean, but what about the door, what door, etc? A node setup essentially describes what you want. I say stick with it. You'll get it. Definitely don't forget Blender Internal though.
Yikes, you are correct. Things have changed since I used Freestyle a while back. My fault - article updated!
Really glad to hear it! Thanks for reading.
Thanks Kent! This is very helpful!
Yeah I was wondering why he said that.
The renders in Cycles are spectacular, but frankly, I've tried to use Cycles a couple of times and I just can't figure it out, even if I tried it with tutorials, way too complicated to use for me and with my old Mac, I'll stick with BI awhile longer.
Maybe when I'll get a new computer, I'll try a bit harder...
Though, if you are right now getting into rendering cycles should be the obvious choice. If I didn't entirely misunderstand the 2.8 viewport blog then BI will soon be legacy feature and unless you have actually paying commissions right now that require BI I don't think the learning curve is worth it over cycles P:
Cycles has freestyle support for a while now.
Apart from this nice article.