[Bf-committers] Cycles as Default Engine

[Martijn Berger]

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 <
brechtvanlommel at 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 at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>