@Craig,
I agree, termination, (smooth shading issues) is a big disadvantage of Cycles. Especially after the implementation of toon shaders. practically, toon shader is useful only under a few lighting conditions. (eh… one lighting condition)
BTW, about the shadeless shader: It supposed to be the emission shader (strength 1), OK adding a mix shader after controlled by lightpath is diffuse ray. All these under min max bounces at 0. Cycles is much faster this way. (closer to BI)
However, is supposed to be. Because an emitter at 1 still insists to reflect light (and some noise with it) in shadow areas. I can’t find a way to stop it, any ideas?
Have you tried using is camera ray instead for your mix node?
I will experiment with it - I am using Cycles for some work on my own story with the mechanical parts, and I will need shadeless for some aspects of the background cards.
Since this thread is still going active, I might as well add my 2 cent, since some of the confusion might be due to my conversation with Ton, and DingTo reply to it. I think it was mis-communication.
When I said ‘dropped’, I didn’t mean it in ‘SQL’ way. I haven’t programmed for a long time and almost forgot that one already. Not until I managed to get a job as a DBA a month back. When I said ‘dropped’, I mean it was not being carried. I wish my google-fu is awesome, but it was one of blender main developer that said there will be no further development on BI except for bug-fix.
And so DingTo asked me to do more research, while on the same line is saying this “There were several reasons why Cycles development started, BI code base was just too old and difficult to extend.” Which is the main reason why that particular developer said there will be no more development, except for bug-fixes - it was just too difficult to extend.
Ton decided to hire Brecth full time for a while (and still is?) to work on Cycles. What would you do if your boss that is paying your salary ask you to rewrite / refactor Blender Internal instead? However, Ton decided on Cycles. And I don’t think we have enough developer to handle both renderer.
Personally, I’d prefer a refactor on BI and let LuxRender to focus on GPU (at that particular time, Lux was working on LuxGPU, and now already on their main render). I always said that Modo is fine despite their renderer is CPU only.
My 2 cent…
edit:
and in the same post, when I was talking about ‘just because’, I’m not saying developers are abandoning BI for no reason, but the inability to look at what they already have and try to get more, as in ‘one in hand is better than two in bush’. I mean, what money are being spent on right now is cool and all, but what about .psd support? On 64 bit windows? I already forgot that one.
I think by now BI also have simple interactive renderer, right? Ton added it if I recall correctly. I think if Ton added that back then and call for 'BI rewrite / refactor) I think it would get the same support cycles get.
Anyway, to cut things short, I really hope Blender the best. But I still wonder if spending Project Mango money on non-core 3D side of things a good idea or not. Nothing is wrong with that, but when particles didn’t work on n-gon (was that improved now or not?) I don’t think we should bite more than we can chew. I understand that Blender is open and therefore its open development, up to what people want to code. But when I saw how money were spent, I just felt sad.
It’s like using blender to make games, but all you see was money being spent on the animation side. I don’t know if it’s ironic for me to use that as a comparison, since I rarely use the game engine.
Have you tried using is camera ray instead for your mix node?
Where? On the object shader? It will return black. What else? Or, I maybe didn’t quite understand what you had in mind.
I thought one of the whole points of Cycles allowing one to put together basic components with the node system was so Brecht wouldn’t have to code an entire suite of specialized materials like seen with other apps. like Cinema 4D and engines like Luxrender.
You can easily pack your shadeless texture setup into a group node with which to use in any future projects (or even the existing one). I use group nodes to a large extent in my projects (appending the ones I need), and it saves me quite a lot of time as I don’t have to build a tree from scratch with every new material.
Ace, I am just answering to why the idea that it is pointless to use Internal - and no, just because you can set up a node group and import it, doesn’t mean that is an easy process in comparison to Internal’s purposed use. And for the record, Internal’s material property tab is like an ubershader in cycles - all the options are there, you just turn them on and off. I say over and over - Cycles is unfinished, and until then, there are task better left to Internal. I keep mentioning what I know of the uses for Internal because young users come here, read the misinformed bias, and then assume they don’t need Internal - then populate this forum and the ones on facebook with questions on how to achieve effects best left to Internal for now. Ace, you know much about this as well - you followed the Sintel project closely and reported back on what they did with the rendering there - and you know Cycles can’t do everything yet. I bought the Mango dvd just so I could look at all those nodes, and have yet to crack it open lol, I have been too busy with work - but I work with cycles so much at work that I have gotten plenty of experience with noise removal, node combination, lighting, etc. and yet I realized early on that Internal affords many things that are easier to set up, and faster to render with more control. Volumetric lighting, fast z transparent materials, halos, true shadeless materiasl with no noise, procedural textures that can be animated based on an Empty object’s position/rotation/scale, etc. There is much more, but I am not willing to copy the whole wiki into this post 
Why do I get the impression that you added a Freestyle pass only to distort the benchmark results and make Cycles appear competitive?
Here’s an example of what BI can render in less than 10 seconds – on a CPU slower than yours:
The scene uses a Hemi lamp for Half-Lambert shading (does not exist in Cycles) and a Spot lamp for shadow buffers (do not exist in Cycles). Note that both the reflection in the background and the refraction in the foreground are 100% noise-free and that the toon edges survive the raytracing because they are added via backface culling rather than postprocessing.
a Spot lamp for shadow buffers (do not exist in Cycles)
…which causes quite visible artifacts. Of course, doing light visibility with buffers is a huge performance gain. No pain, no gain.
The scene uses a Hemi lamp for Half-Lambert shading (does not exist in Cycles) and a Spot lamp for shadow buffers (do not exist in Cycles). Note that both the reflection in the background and the refraction in the foreground are 100% noise-free and that the toon edges survive the raytracing because they are added via backface culling rather than postprocessing.
BI is perfect for non-realistic…
if you need realistic render - soft shadows/shading, glossy, indirect light… cycles is faster than BI and look better.
Yeah, because this video done in Internal is no way looking realistic or rendered fast [sarcasm] I just think there is way more to be explored in both renderers
and how fast was each frame to render?
this video look really good
i can not see something that look wrong
This video was featured on blendernation last year I think, and there was also a breakdown video I still have yet to find - but it is the one strong example that comes to my mind whenever we start talking about this renderer versus that renderer, and I can’t help but think of how great both can be.
Think of Devs, At some point the new most advanced renderer will have to take over. But have no fear, such a massive chunk of Blender is still BI based (camera tracking, Post pro etc etc) until that changes Blender internal will still be there. Im not sure that’s a good thing (would rather Cycles was the engine within all Blender workflow but you can’t ask for miracles) but you still can’t complain about an app this powerfull now that cost £0. Just as a minimum a bake utility for cycles would solve many GPU render issue’s and Game production issues (not BGE which is now done, every product has a life span and BGE’s has lived too long).
Dunno … I utterly fail to see “what the problem is about!”
Be - cause …
The word, “or”, in my mind, “has n-o-t-h-i-n-g to do with it.” Instead, the word should be: “and.”
Until Cycles came along, Blender had two “built-in” renderers (the other being “Game”). Now, it has three, and someday there may be more. (On top of all that, it has always had numerous external interfaces.)
Welcome to the power of Open Source, coupled with a quite-literally worldwide community of CG fruitcakes. :yes:
Development resources being, of course, “limited,” it is inevitable not every part of “all that is Blender these days” will receive equal effort-scheduling priority. (There are only 24 hours in a day, and most of us have Real Jobs™ to pester and distract us …) But that should not be construed to reflect a lack of “importance,” let alone a draconian judgment of “on its way out.” That simply isn’t the way that it works here. Blender has advanced remarkably in the past years, yet, not every feature has advanced in parallel. (How could it, possibly?!) We should expect this trend to continue … and, if possible, to do our own small part.
I’ve been trying to hide the jaggies by tweaking the shadow buffer settings. Here’s what I found:
On the left is the previous render. On the right, I switched the buffer type from classic-halfway to classic and reduced the number of samples to 1. That’s acceptable here since I am going for a sharp look without soft edges. As a consequence, the scene renders slightly faster than before even if I dial the buffer size all the way up to 10240. Quality is still not perfect, but clearly improved.
For scenes where shadows don’t need to show up in raytraced mirrors and lenses, irregular buffers are the best option because they always produce flawless shadow edges:
Attachments
I think of BI vs Cycles like 3DSMax’s internal vs mentalray. There’s room for both so why not.
The problem with Blender internal is that is not supported and developed.
For example,where is the object info node for node shader in blender internal?
Or the new vector transform node?
Now we have 2 renderers with 2 subset of shading function,but the basic stuff should work on both.
As mentioned earlier, there are patches to BI in the patch tracker still waiting for reviews. If no one reviews them because everyone believes that BI is going away real soon now, then there is little incentive for developers to contribute more BI patches. This idea of BI being unmaintainable is nonsense, but it works like a self-fulfilling prophecy, because those who could maintain BI are getting the impression that it’s no longer worth doing so, and then there’s no one left to maintain BI. Of course the fact that people come here and demand that all developer attention be focused on Cycles doesn’t help either.
Two years ago, Cycles was expected to replace BI within 1-2 years. Apparently BI’s expiration date has passed by largely unnoticed. In the meantime, the list of things that Cycles cannot do has become shorter, but suddenly Freestyle made its way into Blender, people rediscovered the art of cartoon rendering, and now there is this growing realization that unbiased rendering might, after all, not be the answer to everything. Path tracing just doesn’t lend itself well to some artistic styles, and as far as I’m aware there are no efforts to add scanline rasterization to Cycles. That means BI is here to stay for a long time.