Obviously, that would be a serious problem for me because (I think …) suddenly I would have to specify what I’d never had to specify before: which renderer should be used to render a particular file.
There’s a simple way to deal with this, of course: just let it be a user default. Let the user choose what selection he wants to appear for new projects, then save that preference as we already do. Introduce the ability to specify this setting (if it doesn’t exist already … I don’t know …), but don’t change the “shipped” default. Don’t “break” every single demo that has ever so-far been made.
It probably will be a shipped default… but as always the renderer is saved into the blend file… which means that older files should be fine (they wont magically switch the render)
You can also save your default renderer at the moment, and you will be able to override it.
If it’s just an issue with default settings, fine, but if this is real world decision to focus to Cycles, I would like to see real effort made to make at least most common imports and exports to support Cycles nodes. I have nothing against Cycles, as I said I use it a lot, but maybe that ubershader thingy is a part of real world solution…
Blender is hard enough for new users already without needing to have a PhD in Nodes just to render the default cube.
I don’t see any benefit to be had. Anyone good enough to use cycles is good enough to be able to change his render engine on his own. The only victims would be the poor newbies.
Actually, apart from a few exceptions (e.g. Modo, fixed by using Substance Designer plugin), in the Real World™ everybody is using nodal descriptions of materials.
What exactly is the meaning of such a proposal coming from DingTo? Isn’t enough to switch to the Cycles rendering engine and save the Startup file to have it as default? Or is this proposal a way to ask (once more) for BI dropping, or what else?
It must be time consuming to maintain two built-in renderers. I think Cycles should include legacy BI render options if it’s possible and then BI should be removed.
With the blender out of the box default settings the render engine at the top of the blender interface is set to Cycles Render instead of the Blender Render. That’s all. The Blender Renderer is not being dropped in any time scale that anyone needs to worry about.
BI will not be removed. All that’s being proposed is that Cycles is set as the renderer in the default start-up blend. If you’ve already saved your own start-up blend file before, then nothing will change for you (afaik). The only people who will be affected by this are people who are brand new to blender, or have never saved their own defaults.
Now: You open Blender, Blender Internal is set as default. If you want the Game Engine or Cycles, you have to go to the top menu and select them.
Future: You open Blender, Cycles is set as default. If you want the Game Engine or Blender Internal, you have to go to the top menu and select them.
This is just a default. Existing .blend files are not affected, backwards compatibility is all fine.
If you have your own startup blend saved, you are not affected. If not and you only use BI for example, it takes you 2s to save your own startup blend.
My reasons for making Cycles default:
Cycles is pretty much feature complete now. With Blender 2.72 even Volume and SSS are enabled on GPU. Also Freestyle now works with Cycles. It’s ready and we worked hard to make this happen.
Look at popular Tutorial sites, like CG Cookie or BlenderGuru. How many Blender Internal tutorials do you find. How many Cycles ones? So even for beginners, this is a step into the right direction.
I find it odd that Blender starts with an engine (BI), that mostly only receives bugfixes anymore, while the actively maintained and more modern engine is just “second”.
I hope it’s clear now. Again:
It’s just a default setting, nothing is lost, BI is still here and works fine as before.
To make the more modern and more used engine the default. Physically based engines are now the dominant render engines in film and VFX and Blender has a good one with OSL to boot. I say put your best foot forward.
BI isn’t going any where but really, and this is not just in Blender’s situation, things have swung to the physically based path tracing side of the equation.
@jpb06
“everyone’s doing it” doesn’t hold much value in this situation. the very first impression you get from the interface of a software goes a long way.
3d art is very broad and you want to limit as much as possible the the distractions so that the user can learn one thing at a time. he just wants to learn how to model… or he just wants to make simple adjustments to game assets… do not confuse him with unnecessary complexities.
if he already knows nodes, then he’s no longer a newbie. he can change his render engine by himself!
BI is light years more intuitive and simpler to get into. it’s faster and it allows an adrenaline-pumped user to play around with different mat settings. how many newbies will have the patience to do that with cycles?
not to mention, even experienced blender users need to watch tutorials whenever a new node comes out. new users already have enough on their plate, don’t bother them with that!
@dingto
if the tutorials all use cycles, then i’m sure they’ll tell the users how to change their render engine.
generally, most new users will attempt to actually use blender before investing time watching tutorials. a lot of them will give up before even getting to the stage of watching tutorials. it’s the job of the interface to prevent them from quitting. those that do make it to the tutorials-watching stage, well, they’ll learn how to change their render engine from the tutorials.
despite the lack of updates for BI, it’s still very far less likely to produce bugs than cycles. fireflies, terminator issues, imagine having to learn all that on your very first blender adventure
This is debatable, engines like BI require far more complex lighting rigs to emulate the missing GI that you get from cycles for even a single bounce. Materials can also be harder to handle because the not as portable across different lighting rigs. A material that looks great under sunlight might look horrible under artificial light. I remember one blender head who was working on a short suffering from this and having to make different skin shaders for his characters for different lighting situations. Cycle’s nodal materials are about the hardest part of it.
one thing that’s needed imo is to remove nodes from BI then add an automatic switch to the default render engines.
that is when you use cycles = nodes on, when you use blender = nodes off
For a beginner they won’t be worrying about GI
For BI, add a meterial, change its colour and you see the colour change in the viewport. Go down the different material sections one by one in a ordered way adjusting the specific material properties.
For Cycles, add a material and change its colour. Oh !, you don’t see the object change colour unless you change the viewport to rendered. Then what do you do ? people talk of nodes, what are those ? go and search for tutorials or ask here
For a new user the BI is I believe the most starightforward.
For the more experienced in blender or some other 3d application they should be more than capable enough to figure out what to do in either.
Whether you have BI or Cycles as the default will probably make little difference.
The plan is to have some kind of ubershader for 2.73 then as well. A group node with easy sliders for Diffuse, Glossy. This should make it easier to get into it.
Not sure I ever did a BI render of anything more than a test without resorting to nodes to get the results I needed.
Never understood the fuss when people complain about nodes being hard and un-intuitive… I’ve always seen them as much simpler and clearer to work with but clearly I’m in a minority.
Also when texture painting nodes are a godsend for certain projects giving excellent glsl previews… nodes in BI are what make it good.
The problem you are trying to solve could be handled much more transparently for the user (the rest of teh material properties change without issue when switching renderer, so why not have "use BI nodes as a new property for BI materials and “Use cycles nodes” as a new cycles material property… i’m sure updating old files may be problematic but easy to fix manually.
there’s no good reason for that one setting to be carried over from one renderer to the next other than technical debt.
