I’m about 92% sure Yafa is still raytracing in direct-light mode. It’s the same thing as Cycles with diffuse bounces set to 0.
i only use bi, but love the look of cycles. I just dont want to spend a year rendering an animation. My question to anyone is will cycles become more like bi. Ive heard some say cycles will increase speed by 3 times? Will its ability to add textures and so on be more push button as opposed to adding nodes all over the place like a spider web?
In my opinion the only reason anyone would want to use bi, is speed! Try getting bi to do indirect lighting and watch it slow right down. It seems bi is doomed.
“Millions of polygons alone can kill BI.” WHAT?
"In my opinion the only reason anyone would want to use bi, is speed! " WHAT?
Not everything has to be photo-real, and yes, if you need GI to do something, then by all means, use Cycles. Cycles = GI, BI = no GI. That’s really the difference.
Millions of polygons won’t ‘kill’ BI as in make it crash, but it will cause the rendering to slow down quite a bit compared to if you have a much lower polygon count (especially with raytracing).
In Cycles, the polygon count makes very little difference on rendering speed (only affecting the synchronization and BVH building stage), Cycles’ speed instead is mainly affected by the complexity of the shading and lighting interactions.
Along with what Ace said, Cycles (and most path tracers) follow a logarithmic slowdown when more polygons are added (IE twice as many polygons doesn’t increase the time to calculation a ray hit by 2).
Each additional polygon however would have to be rasterized (IIRC) by BI, and each additional lamp’s influence on as scene is essentially a separate render (again IIRC)
Cycles render isnt always photo real, as in as close to a photograph. It balaces out the light beatifully giving you a nicer image. More like pixar. In cycles you dont have to have relections and so on. If bump up bi it slows right down anyway. So outside speed i cant see the need for it.
This thread pops up all the time. BI is great, Cycles is great, and if you want to paint textures you better get used to using GLSL with Blender Internal material texture stack, because to use Cycles for texture painting with the same feedback is damn near impossible as far as I have found. I typically use Internal with GLSL for painting my textures, save the images, and then port them into Cycles shaders to get the best of them.
It isn’t just about speed, as Lord Odin would say - it’s the bounces 
“I’m about 92% sure Yafa is still raytracing in direct-light mode. It’s the same thing as Cycles with diffuse bounces set to 0.”
Well, J_the_Ninja it seems like you are about 8% right. I had to check this out as much as I use YafaRay. For all I knew just maybe they were sneaking a little GI in there somehow. Nope ‘Direct Lighting’ is exactly that.
The “code cleanup” for BI is called Cycles … 
Agree totally… for texture painting BI and GLSL is the way to go… even if you will do a final render in Cycles
(only affecting the synchronization and BVH building stage),
and this is not insignificant… can be a really bad bottle neck!
A lot of BI feels very similar to renderman style… indirect AO is such a win… raytracing gets expensive… same as renderman…
in BI i turbo charge things using indirect AO, spotlights with shadow maps and sss… reflections handles with environment maps (pre blurred as needed…)
using raytraced ao and sss is a total killer in BI though…
very tempted to try baking in cycles with BI as final renderer…
as always with renderers there are trade offs and using both renderers and comping seems like a goood option…
BI has lots of uses especially for animation and CAN give photo real results with the right fakes…
both renderers can be brought to their knees very quickly if you just turn on everything…
both renderers can be very fast and efficient if you play to their strengths…
cycles is much easier to get good results from at the expense of rendertime…
I use both all the time for different projects… nothing beats knowing how they work inside out!
I guess it would also be interesting to see how the new baking in cycles changes my workflow… just giving me more options in how to optimise rendertimes in a scene…
Cycles still suffers from the ugly termination issue… making it practically useless for toon shading (by example)
@michael w
very tempted to try baking in cycles with BI as final renderer…
Right. However, as an example, you may bake beautiful maps with all the nice GI effects. Unfortunately, you may also need some reflection effects.
So,
- GLSL is out (reflections?)
- BI has to use ray traced reflections.
- As a possible workaround, I tried the following.
Cycles render using baked cycles maps:
a. Select all objects and objectPropertiesPanel/ray visibility/uncheck diffuse !!
b. On all shaders, use emitter =1 (having diffuse visibility unchecked, emitter won’t shoot photons)
c. Bounces = 0, passes as ~ 4-10 (or 20 max)
d. glossy shader can still be mixed with these emitters, you might also add a little diffuse
With such settings, cycles will be twice faster than BI. (both engines on CPU)
Please, do your tests first, cycles is not noisy under such tuning, on high density scenes it may become 4x faster.
Blender render mode is very useful, GLSL is a must-to-have. However, I would like to see a more modern approach on this matter.
As long BI exists, I doubt if someone will have a look. This is my main concern regarding BI.
@Ace
Get rid of BI, yeah I posted a lot of such opinions in the past. It is too aggressive, agreed, however you see my point.
We need a better rasterizer. This is not cycles by all means.
BTW
For a GLSL rendering, we have to click BlenderRender. We also have to select GLSL on the N panel.
May I ask why? What about having GLSL on the top drop-down menu along with BI and Cycles? It is a UI related question.
(expecting a further development of the so useful GLSL engine)
what is the ugly termination issue?
yes, i also would like to see GLSL in the top drop-down along with BI and cycles.
Yep, sounds reasonable! cool setup idea.
Wishing cycles bake supported normal/bump maps!
I’m wondering what it would take to have better GLSL support of cycles node groups… at least on par with BI glsl previews… would make a cool GSOC project.
Actually I take back (partly) what i said about BI and reflections… its actually quick as long as they’re not blurred, but raytracing AO does kill SSS speed and you can always use blurred environment maps in BI for blurred reflections…
but I must test your cycles method… sounds really promising!
I do love BI edge render… will probably still use both renderers for quite some time yet
@kakapo
termination issue is the quad artifacts on a low poly mesh when using sharp lights - shadow casting. A typical setup for toon shading.
Subdivide a cube ~ 380 faces, use smooth shading, add a sharp point light and see.
As a workaround, you need to subdivide a lot. However, the artifacts are still there, they are just smaller.
Very nasty. As I said, makes cycles practically useless for toon shading/rendering.
edit: sorry michael, posting same time.
GLSL support of cycles nodes? I don’t think it is practical. It is different render engine. However, a simpler node system for GLSL is always welcome.
Now, we have to use BI UI for GLSL. Not the best, because only a few of the settings are valid for GLSL, making it a little confusing.
What about this awful GLSL shadow casting? (sun light).
What about sky background in GLSL when render only is checked?
Surprisingly, mist is working under GLSL (he he ) (yeah, it is possible to render depth mask - 8 bit sorry)
oh, now i saw it. it’s hard to get a nice border between light and shadow for low poly toon shading.
but is this a cycles specific problem? or a general problem with ray tracing / path tracing? could there be anything done to improve it?
edit: hm… it doesn’t seem to happen with the toon bsdf though? 
It’s a different renderer but there’s lots of mapping…
Diffuse bsdf could be a lambert shader in glsl, or oren nayer node if the roughness setting is used , glossy could become specular, most of the bsdfs could be mapped to glsl equivalent shaders… SSS may be a push but that’s not in BI glsl either…
What about this awful GLSL shadow casting? (sun light).
Yep, shadow maps only in GLSL… but the sunlight could be given some GLSL only settings (like a position and a cylinder shape for bounds then shadow mapping could be supported…)
What about sky background in GLSL when render only is checked?
Surprisingly, mist is working under GLSL (he he ) (yeah, it is possible to render depth mask - 8 bit sorry)
even the different mapping types from teh UV node could be supported, GLSL isn’t limited to just UVs (except inside blender)
I hadn’t noticed… i always use a skydome in GLSL rather than teh world settings…
on a seperate note Lightwave GLSL supported motion blur and DOF IIRC using a multipass trick in the viewport (took a few seconds to calculate…
It does.
Proper toon shading in Cycles is possible, but the toon BSDF is pretty much useless for that. Instead you have to set up an emission texture that emulates Half-Lambert shading, and run the result through a colour ramp.
However, once you’ve gone through the trouble of setting up something like that in Cycles, you’ll appreciate BI even more.
"BI has lots of uses especially for animation and CAN give photo real results with the right fakes…
both renderers can be brought to their knees very quickly if you just turn on everything…
both renderers can be very fast and efficient if you play to their strengths…"
Well said, especially the second line.
with the default settings the toon BSDF looked ok. only after playing around with the [size] and [smooth] parameters i noticed the problems.