Big Idea: Blender Render VS Cycles

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?

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?


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 realtime 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!

Newsletter Signup

Get fresh Blender content, training and offers straight to your inbox. Change your mind, unsubscribe at any time.

  • ozonek

    Yup, Blender Internal is greatly underestimated. Of course it's difficult to get photorealistic results with it, but it's much, much faster than cycles, amazing for cartoonish stuff, game-ready models and animations, and has far superior viewport.

  • crew
    Kent Trammell (theluthier)


  • David Frazier (pointoflife14)

    This is a great article. Very helpful and did what is was obviously written to do... answer a ton of "what for?" questions. Thanks Kent.

  • ralphi

    Cycles has freestyle support for a while now.
    Apart from this nice article.

  • 3rton

    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:

  • Stephane (beowulf71)

    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...

  • Jeremy Baker (metathought)

    Yeah I was wondering why he said that.

  • zonkerzebra

    Thanks Kent! This is very helpful!

  • crew
    Kent Trammell (theluthier)

    Really glad to hear it! Thanks for reading.

  • crew
    Kent Trammell (theluthier)

    Yikes, you are correct. Things have changed since I used Freestyle a while back. My fault - article updated!

  • Jeremy Baker (metathought)

    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.

  • Kim Bartholomew (kimba200)

    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.

  • reavenkhali

    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.

  • crew
    Wayne Dixon (waylow)

    Yes rendering an animation with cycles makes you re-think your choices in life.
    It is so much sloooowwwwer than BI.

  • Jasmine Wongus (jazze)

    I love your article, Kent! I wondered what I night want to use BI now I know what I can use for it, cuz I do want to make cartoony stuff too.

  • Robyn Hahn (robynsveil)

    Most of Cycles has now been integrated into Smith-Micro's Poser. Mind you, I use Poser for, um, posing, then bring the scene into Blender for rendering. Just getting my head around scripting with an add-on that will paint textures and (at this point, incredibly rudimentary) shader of Poser humanoid figures.
    Nodes is where it's at... even with all the cool stuff on Cycles shader nodes, there is still a lot of exciting new stuff happening!

  • Chuck Shultz (fxswan)

    Thanks for the article. As a beginner I stayed with Cycles for learning purposes. But now that I have a little time under my belt, I see the advantage of using BI for my "starter" blends as it speeds up my workflow...then once ready, I then switch to Cycles to advance it. I really appreciate this article so I can print it out for the Usage breakdown.
    Thanks Again

  • crew
    Kent Trammell (theluthier)

    Thanks for sharing this info, William!

  • crew
    Kent Trammell (theluthier)

    Thanks for reading, Jasmine!

  • crew
    Kent Trammell (theluthier)

    Oh nice, I didn't know it had been incorporated into Poser. Thanks for sharing, Robyn.

CG Cookie

Learn Art. Make Dough.

Enroll in to our digital arts program and choose from four different disciplines; each with quick paths to measured success baked just for you.

Get StartedorLearn More