thanks! 
@kakapo
i wonder if they could force cycles to borrow BIâs rasterizer or something like that. Or an addon that isolates the freestyle strokes and composites them on the cycles render all behind the curtains.
as for the game engine part, freestyle would need to be made a lot faster to keep up with the game speed. If that happens, iâll even consider using BGE for my future game projects
setting up nodes for materials is a nightmare.
Node setups are far superior to the BI way of setting materials, for my personal taste.
However, in the properties editor material tab, the Cycles node based method is a complete disaster.
Having a quick access to some properties in that tab is really great, but I think it could have been designed in a far better way⊠Maybe I will write a paper on that sometime laterâŠ
People say that we need a good rasterizer in blender.
On realtime shaders, like GLSL - Completely agree. But why do we need something like BI?
It isnât the method of rendering that matters, itâs the result, speed and comfort. And Cycles can bring identical images to BI, even if itâs not a rasterizer, so why bother? If Cycles was as fast for the same result, what would the point of BI or introducing a new BI-like rasterizer be?
âifâ answers your question
@Freemind
if the important settings could all be exposed to the properties editor, i agree that could take out some of the work from cycles
but then thereâs also the issue of the previews. my pc is a slow single-processor integrated-gpu kind of pc. i have to wait an eternity to see any changes. Moreover, the âscramblingâ that happens before seeing the changes would make it difficult to accurately pin-point the difference. youâd literally have to take âbefore and afterâ screenshots just to see what changed.
I bet BI could theoretically produce identical images to cycles. Weâve all seen Vickyâs Sketchbook http://www.blenderartists.org/forum/showthread.php?294117-VickyM72-s-Sketchbook. that doesnât make cycles useless.
BI is faster in most simple scenes. BI isnât grainy for the most part. BI gives more control over lights.
Not to mention the NPR side of things.
BI is still the default renderer for a reason. Just like the default cube, camera and point light, BI allows new users to jump in without having to spin spider webs in the node editor.
+1 Michael
â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â
Ace, Cycles is becoming a nice little renderer but itâs not magic. Of course poly count makes a significant difference in render times. Just take the default cube add a plane and then add several more cubes on another layer and you can see that with just 19 faces. Furthermore you can move two cubes just off camera and see where they are still affecting the render time slightly.
But, even more poly count can drive a scene into the CPU since the vast majority of users with designated graphics cards probably have 1GB still or 2GBs tops. If you are attempting to animate you just fell into deep doo-doo. And, will discover youâre not in Kansas anymore.
i have to wait an eternity to see any changes
so, is it any faster on BI to see the changes?
Look at the material preview in the materials tab, donât render the whole scene.
I bet BI could theoretically produce identical images to cycles. Weâve all seen Vickyâs Sketchbook
BI doesnât have GI, so itâs never going to be as accurate and realistic as Cycles is. Some realism is possible if you are skilled, sure, but never to the same degree.
However, you can turn off GI in cycles and pretty much do everything BI can.
BI allows new users to jump in without having to spin spider webs in the node editor.
Why people think nodes are difficult boggles my mind.
I found it to be very intuitive.
But hey, if thatâs how it is, thatâs how it isâŠ
âifâ answers your question
So, if that is even possible (probably not) to achieve, that is where all the effort should go.
There would be no point in keeping or developing BI at all.
yeah, i was talking about the material previews. on BI i see an almost instant change. no scrambling of the preview window⊠no noise in my preview. on cycles, even a change as little as diffuse color would scramble the whole preview, making it hard to see how exactly it has changed.
GI or not, iâve seen a lot of realistic-looking BI renders. The point however, was that they both have their uses. if you want to use cycles, fine. but you canât just go around saying BI is useless and should be removed. Itâs simplicity is enough reason for its existence.
With great power comes great responsibility. the power of nodes is no different. Theyâre not particularly difficult⊠just unnecessarily complicated for simple materials. But they still have their uses, so i wonât start saying nodes should be removed 
When i started with blender, no one taught me how to configure mats or whatever. it was straight forward. i just picked it up right away. thatâs not the case with new users and nodes, unless theyâve used nodes before. and even so, theyâd still have a lot of learning to do.
now isnât that all unnecessary for someone who just wants to render a colorful plastic default cube?
@eye208 what is this Half-Lambert shading you speak of. I have not a damn clue to what you are referring to but since my interest is animating I sure would like to know. Nor am I a Cycles virtuoso so please start at the top if you would. And, could it be used in a completely enclosed area since it isnât GI.
Itâs the bright half of the Lambertian reflectance falloff curve wrapped around the entire object, all the way to the back.
Full Lambert on the left, half Lambert on the right.
Hemi lamps in BI produce this effect by default, but they are useless for indoor scenes. However, itâs possible to implement Half-Lambert for point lamps, and with just one such lamp in a room you can turn thisâŠ
into this:
The cave scene posted earlier uses two of these point lamps.
The point however, was that they both have their uses.
BI - Works great for unrealistic images. Trying to do realism is going against the nature of the beast and is difficult to achieve.
Cycles - Works great for both, realistic and unrealistic images.
but you canât just go around saying BI is useless and should be removed. Itâs simplicity is enough reason for its existence.
BI is not simpler than Cycles. They are just different.
But it kinda depends on how you define âSimpleâ.
If we look at it as âEasy to get the result I want (excluding render time)â, then Cycles seems far simpler to me.
But I guess that depends on the user and his way of thinking.
just unnecessarily complicated for simple materials
Define âSimple materialsâ.
Because when i think of âSimple materialsâ i imagine, for example: Image texture > Diffuse shader > Material output. Three nodes. How could you get more straight forward than that?
just as âunrealisticâ is against the nature of cyclesâŠ
i donât know what else to say without repeating myself. letâs just agree to disagree 
as for the simple materials part, add a new mat in BI and just change its diffuse color. thatâs a simple material. how could you get more straight forward than that? It has itâs diffuse and spec values right in your face.
pretend youâre a new user on your first blender adventure without any knowledge from any blender tutorial at all. youâve never used nodes. you just wanna play around with different mats⊠or perhaps youâve just downloaded a blend file of your favorite game character and youâd like to give his eyes a bit of shine, or maybe you wanna remove the specularity on his clothes.
i think you get the idea already.
even as someone whoâs been familiar with blender nodes for a long time, some nodes still give me a hard time when using for the first time. i remember when cycles hair rendering came out. despite all my experience with nodes, i couldnât really get it until i saw andrew priceâs tutorial on the matter. and i assure you, i wasnât the only one
or when cycles sss came out⊠if something is straight forward, an experienced user shouldnât need to rely on tutorials for every step, right?
simplicity is directly proportional to speed. and i donât like spending more than 5-7 hours on any one character (renders included). thatâs why most of my cycles experiments end with a loss of motivation. the longer i spend on the technical side of things, the easier it is for me to lose sight of my artistic goals
just as âunrealisticâ is against the nature of cyclesâŠ
No it isnât.
By âgoing against natureâ, i mean - Trying to fake light bounces with clever lighting and so on. That is because Blender doesnât have real GI calculations, you have to do tricks to get something that looks like GI. AO kinda works, sure, but you and I know, thatâs not the same thing.
In Cycles case - you can actually turn off GI for real. That is not an extra tricks to fake a feature that is not supported by the engine.
Yes, but in BI these âtricksâ are easy to set up. In Cycles they require a degree in rocket science.
AO kinda works, sure, but you and I know, thatâs not the same thing.
In Cycles case - you can actually turn off GI for real. That is not an extra tricks to fake a feature that is not supported by the engine.
Sure, you can turn off GI, and then Cycles will be âonlyâ two times slower than BI and produce renders that look worse, with terminator issues all over the place.
Cycles is âbetterâ only if your time isnât worth anything. Itâs âphotorealisticâ only if you like film grain or can afford to wait an hour for each photo to develop. :rolleyes:
Yes, but in BI these âtricksâ are easy to set up. In Cycles they require a degree in rocket science.
Itâs literally just a matter of changing the values in the Bounce count numberboxes.
Change Diffuse bounces to 0 and you instantly get a BI look.
And when it comes to setting up a fake GI in BI, itâs really figuritively rocket science⊠For example, You have a red cube on a white plane, you have to place a red light to fake a red indirect light from the cube⊠This is tedious and still never as good as real GI.
Sure, you can turn off GI, and then Cycles will be âonlyâ two times slower than BI and produce renders that look worse, with terminator issues all over the place.
How is Cycles without GI looking worse than BI? Itâs identical.
What are âTerminator issuesâ?
And I am talking about features, not speed.
I know that BI is far faster than Cycles for no GI renders, which is why BI should stay in Blender for now.
But I am arguing for a scenario where BI and Cycles are as fast for the same result.
What I said was: âIf cycles was as fast as BI, having BI would be pointlessâ and âIf itâs possible to make Cycles as fast as BI, this is where all effort should go, instead of upgrading BI or developing another BI-like rasterizerâ.
Is it a pissing contest yet. A sure enough Cycles - BI pissing contest. Actually, I keep coming back to this thread because some seem intent on steering it away from that. However, it seems to me we are operating with a few misunderstanding in the compartment here as some have mentioned so well. Or, misunderstandings to some of us.
First off photorealism is not some damn holy grail. If youâre intent on spending all your creative time pursuing that well enjoy.
Secondly many people simply hate nodes and can work much faster and more intuitively from a panel. And, I might add it seems many of those folks are professionals going by the ads for other render engines. Houdini is not exactly kicking ass out there.
No I canât make identical looking images in Cycles nor as I mentioned would I want to play in Nodesville for hours trying.
Cycles has got the same damn limitations every other raytracer has. My current project is completely enclosed. And, I want to be able to animate the camera 360 degrees at will and the overhead / ceiling is part of the overall design. Take Cycles into that environment and see what you have. What youâd better have is YafaRay with Photon Mapping or Direct Lighting possibly using AO.
So it would seem Cycles is a nice little raytracer, if you like to use nodes, with all the limitations of a raytracer thatâs not a hybrid of sorts. Including the unreal render times for Caustics.
Add to that all the folks who donât even have a designated graphics card much less a Nvidia and it sounds like a scanline to me.
"What I said was: âIf cycles was as fast as BI, having BI would be pointlessâ and âIf itâs possible to make Cycles as fast as BI, this is where all effort should go, instead of upgrading BI or developing another BI-like rasterizerâ."I would suggest that the first point is based on a matter of opinion only - Blender Internal doesnât just work faster that cycles, it is also simpler in set up for some effects. Even if both renderers were equal speeds, I would contend that some use cases are just not easy to arrive at in both, with each having specific strengths. Internal is easier to set up fast shadow-only materials and shadeless materials for overlays in compositing in video. Cycles has better overall light bounces, period. For realism, yes, Cycles can be faster to arrive at a solution - but a good node setup for all the possible settings that Internal has in one texture panel is a nightmare to set up even for an experienced user. Of course, lots of node groups have been shared that now make it easier, but there is still some effort to learn what these nodes do to get them to work correctly.I like both and use both, and I think that taking out Internal or saying that it is useless once Cycles gets up to speed is a little off because of how it works and what it doesnât do. It doesnât allow fast transparent non-ray traced material for example, or shadow buffer spot lamps⊠and of course, plenty of stuff that works better in Cycles - like the new baking that Dalai Felinto is working on, and box mapped image textures ftwâŠSorry if this comes off a little wonky, Iâm trying to type and talk the kids at the same time 
no problem. youâve made some rock-solid points along with theoldghost.
This GI thing⊠is it really the magic button for realism?
BI has indirect lighting, right? iâve never had a reason to use either, but arenât they similar (ignoring the âphysically-correctâ part)?
And i remember hearing somewhere (andrew priceâs outdoor lighting tutorial, i think), that even the pros (pixar) avoid using real indirect lighting due to the computation costs involved. So why all the fuss over something thatâs not worth the time it takes to use?
Iâm making a lowpoly character at work and had to do some promo renders but was imposible with cycles due terminator issue unless I switched off shadows.
I really think se should have a good npr render like Bi, also for motion graphics is crucial. Why not to code a fresh npr/raster?
Salvador Ureña
but about the terminator issues againâŠ
is this a general problem with renderers like cycles or is it a cycles specific problem?
what do brecht and the other cycles developers say about it? can it be improved?
Itâs a general problem with all renderers as itâs a precision issue due to low polycount. Itâs just that BI has a work around for it(the auto-ray bias) which interpolates the precision. Cycles on the other hand doesnât and itâs difficult to think of one due to Cyclesâ raytracing nature. Upping the polycount is the correct solution to the problem in both, but that of course has itâs own disadvantages.