It is only the default setting, most existing blender users will not ever notice any change as they are likely to have a startup file that is tuned to their liking. This mostly applies to users who are new to blender. In that category there are 2 groups for both of which I think you could argue that cycles is a better default.
New to 3d software in general users. I would think this group is rather young and likely to find or be pointed to online tutorials. While their objective for starting blender might vary wildly I would still think that given the fact that the tutorial making people are not crazy and following the general trend the chances that they want to invest in learning cycles to start with versus learning internal ( yes you do need to learn stuff there) are so skewed in favour of cycles that it being the default makes sense. Migrating users from other software packages. Here I think the default is less important as in most packages I know advanced users will have to change a few settings anyway. I would expect this group to find the setting soon enough and figure out how to save these preferences. Still you could very well argue that some of these people might try Blender because of cycles and that that group is likely bigger then the people who leave other software to test this awesome new render engine called "Internal" in blender. In the end both engines no matter how cool they are are not perfect and guiding this discussion towards an if cycles can only do x,y,z it could become the default is obscuring the real issue. None of us can really see through the eyes of a true new user any more and we actually need that perspective to actually serve the group that this is likely to impact the most. I think the argument Brecht raises on consistency is a very valid and important argument for cycles as a default for both classes of new users. And while I think the arguments about in and exporters are important to I really feel even without addressing that cycles is likely the better default. On Mon, Oct 6, 2014 at 1:19 AM, Brecht Van Lommel < brechtvanlom...@pandora.be> wrote: > Yes, ID passes do not work with motion blur and depth of field, and the > only solution is deep compositing, just like it would be for Blender > Internal if it actually supported these features. > > The thing is that you can list many missing features in Blender Internal as > well. No depth of field, no 3D motion blur, no proper indirect light or > HDRI environment lighting, no diffuse glossy interactions, no emission from > volumes. > > And even more inconsistency problems like no SSS or hair curves in > reflections, render passes not working for node materials, wrong > transparent shadows from material nodes, no hair curve shadows with lights > other than spots, wrong fresnel and specular transparency, hair shading > that you have to light with separate lamps to get decent results, volume > stepping artifacts that are impossible to get rid of, very difficult to do > motion blur and depth of field with transparent objects, no way to texture > various settings, no correct light falloff, broken bump mapping in > reflections, no correct area lights, and so on. > > I'm not trying to say one is better than the other here, Blender Internal > certainly has more flexibility in some areas. But if the question is, do > feature X and Y work together properly, then the answer is yes *much* more > often in Cycles than it is in Blender Internal, and in fact I like to think > that this is the case when comparing Cycles to most other renderers as > well. > Hi Daniel, of course I know you can change that on the menu, what I'm > saying is that BI is a feature complete render engine (maybe not the best > quality ever but it's complete), Cycles is not complete, one more example: > > The render passes in cycles are most of the time unusable, try to get an > object ID or a material ID pass from an object with motion blur for > example. Some of the 'features' are on the UI but they are actually not > usable for production. In my opinion if you have a 'feature' that is > unusable is better to remove that feature from the UI until it's ready. I > started rendering a shot in cycles thinking that I could have material and > object passes with motion blur and I realize that these options are not > usable at all and I had to fake these passes in other ways. > > All I'm saying is... Yes, I'm looking forward to have Cycles as the main > engine BUT only when it's fully featured and not having inconsistency > problems as the ones I mention. Also it has more limitations from an artist > point of view to tweak the lighting and managing the light in comparison > with the BI. Even Arnold render fakes many things but in cycles is trying > to achieve realistic rendering results which is fine but not really > allowing the artist sometimes to adjust settings in a non-realistic way > (example: shadow color on the rendering). > _______________________________________________ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers