I don’t know of an absolute definition of would a good renderer is.
As was said - The one that could give you the result you want, the fastest.
However, when it comes to BI and Cycles: Cycles can do everything BI can at this point, I think (Is there anything left?). BI can’t do everything Cycles can. So, Feature wise, Cycles is a far better render engine.
But the speed difference is huge.
So, which renderer is better kinda depends on what you are doing.
Simple, no GI renders - BI is better. You can do that in Cycles too, but it’s going to be slower to render.
Realistic renders - definitely Cycles. BI can’t do photorealism, unless you are willing to work real hard with lights everywhere, and that will still not give you as good of a result…
@vicky
OK, OK,
My point is, we won’t see any further development of a so useful renderer.
I also use BI, it’s irrelevant though.
I find it rather ridiculous. To turn this thread to a BI vs Cycles debate.
I would prefer a conversation about BI and the future of it.
IMO it doesn’t go anywhere (not really) and we do need such a modern raster, non physically correct (LOL) engine.
A further development of GLSL, as well.
(physically correct engines… I don’t know if they even exist, Cycles in not among them for sure)
The BEER project has hope last time I checked to do something with the Internal engine, as well as the Freestyle improvements. NPR is very good in internal, that is very obvious form the threads on those subjects.
I think the GLSL being a drop down by itself would hinge on whether the work is done to eventually turn the Game Engine into the Real Time Preview that they mentioned - since the GLSL is used in both Blender Render and Blender Game. An UI issue of course, but it would be interesting to combine the Texture Paint layers used in GLSL with that singular mode so that it isn’t dependent on the renderer - but I don’t have a clue what that entails program wise.
since BI does rasterizing and opengl does rasterizing…
is there anything BI can do (i mean without raytracing) that couldn’t be done with opengl?
i really would like to see a good and fast opengl renderer. it doesn’t have to be realtime. just fast (a few seconds per frame) for rendering animations.
if the BI codebase is so old and hard to work with… why not do a new opengl renderer instead as a companion for cycles? probably it would be a lot more work than i imagine?
Indeed Craig.
I would like to add,
photorealism is the approach of an artist, not the capabilities of a render engine.
Photorealism is an art movement. It happened (still happening) in traditional 2d art.
Neither a photograph, a camera, is able to capture what our eyes can.
Remember, we watch, we don’t just see.
(sorry for my english, really…)
@kakapo
Probably, it’s more difficult to develop such an engine than a “photoreal path tracer”
A lot of magic is needed. Lot of it. And a tremendous effort.
I have seen beautiful, magical renders posted on zbrush forum. Using their BPR engine.
So inaccurate, so a liar render engine, never trusted it… however, some magic there.
What about the modern videogame engines?
Not an easy task at all.
you should learn how to use the approximate AO… doesn’t require loads of lights and setup… gives a great single bounce GI and handles emmisive surfaces…
it’s just nonsense to say BI can’t do photoreal but there’s a crossover point with speed where if you need raytracing and blurred reflections cycles may be faster…
Cycles can’t do edge renders like BI, can’t do freestyle like BI… can’t help you for texture painting like BI GLSL… can’t do mist like BI, can’t bake normal/bump maps, and can’t do all the volumetric things BI can…
but then again, BI can’t do motion blur/DOF like cycles, cant’t do an equirectangular camera like cycles, can’t do multibounce raytraced GI like cycles…
Right Michael
Now, this normal/bumps baking maps. What do you mean?
Of course cycles can bake excellent, superior normal maps.
Bumps/displacements, or Bumps>normal maps? Be patient, under development.
They will be here, soon.
Cycles will be our basic bake engine.
In fact, it already is.
You aren’t a BI baking lover, are you? I don’t think so.
I feel like the things that BI can do that Cycles cant are artificially limited. I mean, there is no reason that the freestyle things or glsl support or edge rendering CAN’T be added to cycles, other than they’ve already been added to BI. However, the things BI cant do that Cycles can are deeper, architectural limitations.
Really, I think freestyle should be its own render engine (with a legacy edges mode to match BI edges). This is how I use freestyle. I just set up a copied scene with all the objects, then I do a fast render pass with BI (shadeless black) then I run the freestyle pass to the compositor and stack it into my final comp. BI (though fast) is still a stupid amount of overhead when I just want a freestyle pass. GLSL would also make sense to be it’s own render engine, specially set up as a part of a realtime pipeline.
All of the “features” that BI has are really separate modules that were just sort of lumped on to BI because it was the only render engine in blender-town.
yes, but in my imagination and limited graphics programming experience a game engine needs many tricky optimizations for being realtime and achieving a high enough frame rate. and an opengl offline renderer probably could be simpler and more brute force since being realtime doesn’t matter that much?
i did’nt say cycles couldn’t bake or do volumetrics… j
ust that it cant bake bump map normals and volumetrics is still early and not on parity with BI yet…
but as Michalis says PATIENCE…
i can use glsl in BI materials fine… just pointing out that cycles glsl support is so primitive that you have to use BI to texture paint…
Brecht considered that because of the realtime preview renderer that cycles didn’t need good glsl support… that’s useless for texture painting though… that use case means that even though glsl will never be a perfect preview of a cycles material it would certainly be better than having to set up both bi and cycles materials for a cycles project…
cycles is more “physically-correct”
cycles materials are 100% node-based
Personally
“physically-correct” has never really appealed to me as an artist. art isn’t about imitating reality. but rather, self-expression. expression of ideas from your imagination. And my imaginations are never physically-correct
setting up nodes for materials is a nightmare. normally, even on simple characters, i’d easily have over 50 different mats. yeah, setting up nodes for 50 mats is a nightmare!
When it comes to making games, hmmmm… i’m not sure how cycles mats would export. but my guess is BI mats would export a lot better
Lastly, to live is to Freestyle!
to Freestyle! is to use BI
but still, the cycles hair rendering is quite tempting
in animation look consistency is so much more important than photoreal… i mean when you look at vfx and animation even mixed with live action photoreal isn’t really the goal… cinematic is…
i was incredibly entertained by stu maschwicz blog over the last few years… (prolost blog)
amazing to see him rant about high frame rates, 3d tech etc… but cinema with its post pro and colour grading isn’t striving for photoreal it’s striving for something larger than that…
gone are the days when dvd boxes have warnings that the colour correction is a stylistic choice and not an encoding error… “3kings” made me lol with that one back in teh day…
just thought i’d mention it because when I say BI can do photoreal i mean it in teh sense of cinema…
tim burton’s alice in wonderland or pirates of teh carribean or the underated john carter (of mars) come to mind…
Brecht considered that because of the realtime preview renderer that cycles didn’t need good glsl support… that’s useless for texture painting though… that use case means that even though glsl will never be a perfect preview of a cycles material it would certainly be better than having to set up both bi and cycles materials for a cycles project…
When I set up material nodes for both, I found that to preview the GLSL you have to mute the Cycles node tree (at least back at ver. 2.68)
I’d much rather set up nodes rather than try to deal with BI’s awful texture stacking system. Setting up basic texture blending using a mask becomes a very convoluted process. Nodes are super awesome once you get used to them. I have much more artistic flexibility (physically based or not) using the nodes in cycles than I ever did with the materials in BI
and again, Freestyle is super awesome, but I don’t know why it has to be embedded in BI. It’s an entirely rendering operation that uses the same mesh data that BI or Cycles use. Couldn’t it be it’s own render engine?
yeah! freestyle could be so much more useful. imagine if i could use freestyle in a game engine! i really wish it could be much more portable. the possibilities would be endless.
the texture stack is definitely a pain to work with, sometimes. but i rarely have more than 3 textures per material. most times, i don’t even use textures at all.
i’m good with nodes, but for basic mats, they just keep getting in the way and slowing me down.
And even if i found myself needing the power of nodes, cycles still wouldn’t be an option until i’ve exhausted BI’s mat nodes
i agree. i always found BI and the texture stacking quite confusing. cycles’ nodes are easier to grasp.
i think freestyle needs a rasterizer. originally it used opengl and then it got converted to use the rasterizer of BI. cycles doesn’t rasterize so it would have to change back to opengl again or something?
Cycles nodes work the same way as BI Texture Stack - in the sense that the slot on top is actually on the bottom, same for inputs on nodes as well as the order of the textures in the stack.
Where they differ is in Internal, you have loaded all the textures into slot that are carried in the shader, and for each you can set their influence, but in Cycles, some of the image or texture nodes are directly fed to shaders and some of them are fed to mix fac inputs between shaders.
"cycles is more “physically-correct”
cycles materials are 100% node-based
"Personally
“physically-correct” has never really appealed to me as an artist. art isn’t about imitating reality. but rather, self-expression. expression of ideas from your imagination. And my imaginations are never physically-correct
setting up nodes for materials is a nightmare. normally, even on simple characters, i’d easily have over 50 different mats. yeah, setting up nodes for 50 mats is a nightmare!"
For me the biggest problem with Cycles is that there seems to be no way to store shader properties per lamp rather than per material.
For example, if I have a scene with 3 lamps and 50 materials in BI, I can turn any of those lamps into hemi lights, and all of the 50 materials will be shaded accordingly. Cycles doesn’t support hemi lights, and even if I recreate the Half-Lambert effect with emission shaders, I have to insert 50 instances of the corresponding node group, one per material. I have to either hard-code the lamp coordinates into the node group or set up Python drivers to extract the coordinates from the lamp objects dynamically. OSL doesn’t help here because shader scripts cannot iterate over a scene’s lamps and extract their properties. The result is a ridiculous amount of work compared to the two or three clicks it takes to do the same thing in BI.
Now some people will say, why use Half-Lambert shading if you have “real” global illumination? As a reminder, here’s why:
Node-based Half-Lambert shading in Cycles, after 26 seconds:
It’s a fact that in all but the most extreme lighting conditions, Half-Lambert will create a fake GI effect indistinguishable from the “real” thing, while cutting down render times from hours to seconds, literally. For still pictures this may not be a big deal, but for animated shorts it means you can render in a week what would otherwise take several months (or an expensive render farm).
