Blender Default Settings: Cycles #37474

New Issue

Brecht Van Lommel · 2013-11-15T16:15:03+01:00

Brecht Van Lommel commented

2013-11-15 16:15:03 +01:00

This is the subtask to discuss changes to Cycles default settings for 2.70, copied from the parent task:

Light Paths: Limited Global Illumination (renders faster, looks the same most of the time)
Film: Transparent ON
Performance: Persistent Images ON (faster animation renders)
Performance: Cache BVH ON (faster animation renders)
Performance: Set tiles to larger size when using GPU (renders faster)

World
Multiple Importance Sampling: ON (removes noise when using Environment images)

Preferences
Compute Device: CUDA (if possible. Users expect their CUDA cards to accelerate rendering, and it's annoying to set every time)

This is the subtask to discuss changes to Cycles default settings for 2.70, copied from the parent task: **Light Paths**: Limited Global Illumination (renders faster, looks the same most of the time) **Film**: Transparent ON **Performance:** Persistent Images ON (faster animation renders) **Performance:** Cache BVH ON (faster animation renders) **Performance:** Set tiles to larger size when using GPU (renders faster) **World** **Multiple Importance Sampling:** ON (removes noise when using Environment images) **Preferences** **Compute Device:** CUDA (if possible. Users expect their CUDA cards to accelerate rendering, and it's annoying to set every time)

Brecht Van Lommel commented

2013-11-15 16:15:03 +01:00

Changed status to: 'Open'

Brecht Van Lommel commented

2013-11-15 16:15:03 +01:00

Added subscribers: @billrey, @brecht, @JonathanWilliamson, @pablovazquez, @AndrewPrice, @d-medvedev, @hjaarnio, @ThomasDinges, @oenvoyage

Thomas Dinges commented

2013-11-15 23:39:09 +01:00

Light Paths: I just decreased the default bounces, this was discussed with the Cycles Module Artist Team. The Limited GI preset only uses 1 GI bounce, and that's not enough for a decent default.

Film Transparency: Disagree, when you use things like "Sky" or a HDR you usually want to see that and not have a transparent background.

Persistent Images: No strong opinion, but as this will be used for more in the future (Mesh Data, Shaders etc etc) I would not set it to enabled now.

Cache BVH: Our BVH builder is really fast since 2.63, and in most scenes usually faster/on par to the cache. On the other hand, if you have a slow HDD things could slow down even.

Tiles: This will probably be handled differently anyways, likely more clever or automatic in the future. I would not change the current values, as on the CPU smaller tile sizes are better, so there is no clear winner here. If you need high Tiles Sizes all the time, set that in your Startup Blend.

World MIS: Will lead to a slight slowdown with one color/simple backgrounds...

Light Paths: I just decreased the default bounces, this was discussed with the Cycles Module Artist Team. The Limited GI preset only uses 1 GI bounce, and that's not enough for a decent default. Film Transparency: Disagree, when you use things like "Sky" or a HDR you usually want to see that and not have a transparent background. Persistent Images: No strong opinion, but as this will be used for more in the future (Mesh Data, Shaders etc etc) I would not set it to enabled now. Cache BVH: Our BVH builder is really fast since 2.63, and in most scenes usually faster/on par to the cache. On the other hand, if you have a slow HDD things could slow down even. Tiles: This will probably be handled differently anyways, likely more clever or automatic in the future. I would not change the current values, as on the CPU smaller tile sizes are better, so there is no clear winner here. If you need high Tiles Sizes all the time, set that in your Startup Blend. World MIS: Will lead to a slight slowdown with one color/simple backgrounds...

Lord Odin commented

2013-11-16 09:49:41 +01:00

Added subscriber: @derekbarker

Lord Odin commented

2013-11-16 09:49:41 +01:00

@ThomasDinges i think that when you switch to GPU the tiles should be bigger. that is if you dont do that smart tile thing first

looking at benchmarks i cant count how many Titans render slower than my GTX 560 ti (120 - 200 usd) because they dont even know what the tiles do.

@ThomasDinges i think that when you switch to GPU the tiles should be bigger. that is if you dont do that smart tile thing first looking at benchmarks i cant count how many Titans render slower than my GTX 560 ti (120 - 200 usd) because they dont even know what the tiles do.

Brecht Van Lommel commented

2013-11-16 14:47:56 +01:00

Light Paths: this was changed recently, but looking at the current state 4 diffuse bounces actually seems very high to me, I would expect maybe 2 bounces as default. I can't remember the discussion, and I feel kind of bad coming back on this but we might want to lower the default bounces still.

Film Transparency: agree with Thomas, I think having transparency disabled is the more common case to start rendering with?

Cache BVH: agree with Thomas.

Persistent Images: it's a memory vs. speed trade-off. In this particular case I think keeping memory usage lower is more important until maybe we add a smarter tiled image caching system, but having those images take up memory between renders I'm not so happy with. It's one of those things were it's maybe not so bad in one case but if all of Blender would do this kind of thing by default you'd be getting out of memory errors often.

Tiles: this will indeed be solved in another way, I prefer to not spend development time on making some smart algorithm to pick tile sizes since it will never be very good. Basically this is an issue we should document as is and make time to improve the implementation.

World MIS: I'm ok enabling this by default if we add code to detect the single color background case. It can easily be a 10% slowdown, which may not sound like much, but that kind of thing adds up.

CUDA: GPU rendering is very fast but also limited and I consider it somewhat of an advanced feature. Most laptop users will not have a very powerful GPU and when they open .blend files with GPU render enabled it can easily crash Blender or freeze their OS for a few seconds. I would like all that to be handled more gracefully but it's difficult, for now I consider this something we should leave disabled by default.

Light Paths: this was changed recently, but looking at the current state 4 diffuse bounces actually seems very high to me, I would expect maybe 2 bounces as default. I can't remember the discussion, and I feel kind of bad coming back on this but we might want to lower the default bounces still. Film Transparency: agree with Thomas, I think having transparency disabled is the more common case to start rendering with? Cache BVH: agree with Thomas. Persistent Images: it's a memory vs. speed trade-off. In this particular case I think keeping memory usage lower is more important until maybe we add a smarter tiled image caching system, but having those images take up memory between renders I'm not so happy with. It's one of those things were it's maybe not so bad in one case but if all of Blender would do this kind of thing by default you'd be getting out of memory errors often. Tiles: this will indeed be solved in another way, I prefer to not spend development time on making some smart algorithm to pick tile sizes since it will never be very good. Basically this is an issue we should document as is and make time to improve the implementation. World MIS: I'm ok enabling this by default if we add code to detect the single color background case. It can easily be a 10% slowdown, which may not sound like much, but that kind of thing adds up. CUDA: GPU rendering is very fast but also limited and I consider it somewhat of an advanced feature. Most laptop users will not have a very powerful GPU and when they open .blend files with GPU render enabled it can easily crash Blender or freeze their OS for a few seconds. I would like all that to be handled more gracefully but it's difficult, for now I consider this something we should leave disabled by default.

Thomas Dinges commented

2013-11-16 21:49:22 +01:00

Added subscribers: @MatthewHeimlich, @GregZaal, @marcog

Thomas Dinges commented

2013-11-16 21:49:22 +01:00

Bounces: I discussed this via direct mail with our 3 artist members. I don't mind changing it again, but going below 4, I don't know. :)

Matt Heimlich commented

2013-11-16 22:35:57 +01:00

Light Paths: I agree that 4 is high. It adds a lot of noise and render time with very little change in scene quality. The cases where 4 bounces would be necessary (indoor scenes with heavy indirect lighting) are very outweighed by other common scenes.

Transparency: I normally end up turning it on anyway, as it's easier to have the background as a separate render layer, especially for adjusting in post. But I can see how this could spawn a lot of confusion for new users, and it's not hard to turn on and off. I think the default should show the background. However, I do think that it could be better placed and be better named. I think it's common for even experienced users to overlook this setting because of its placement and name.

Cache: Haven't used it once since the BVH improvements. Even with my SSD the benefits are hardly noticeable.

World MIS: When using an image, it's always on. It would also be nice if the size of the map would automatically be set to the larger dimension of the input environment map. Even with HUGE HDRI images the build is almost instant, and I've found this technique (suggested in the Arnold documentation) to give the best speeds and noise cleanup when using environment maps.

Light Paths: I agree that 4 is high. It adds a lot of noise and render time with very little change in scene quality. The cases where 4 bounces would be necessary (indoor scenes with heavy indirect lighting) are very outweighed by other common scenes. Transparency: I normally end up turning it on anyway, as it's easier to have the background as a separate render layer, especially for adjusting in post. But I can see how this could spawn a lot of confusion for new users, and it's not hard to turn on and off. I think the default should show the background. However, I do think that it could be better placed and be better named. I think it's common for even experienced users to overlook this setting because of its placement and name. Cache: Haven't used it once since the BVH improvements. Even with my SSD the benefits are hardly noticeable. World MIS: When using an image, it's always on. It would also be nice if the size of the map would automatically be set to the larger dimension of the input environment map. Even with HUGE HDRI images the build is almost instant, and I've found this technique (suggested in the Arnold documentation) to give the best speeds and noise cleanup when using environment maps.

Greg Zaal commented

2013-11-16 22:48:41 +01:00

I think 2 bounces is a bit low as well. 3 might be enough though?

If we can detect whether there's something connected to the background shader's inputs and only use MIS then, then turning it on by default would be good yeah.

As for tile sizes, the best solution at the moment would be to store the tile size for CPU and GPU separately, and have different defaults for each. For the moment though, how about a generic default of 128 or so? I know smaller tiles are better for CPU especially in the case when there are some small objects in the scene that take longer to render and you may get that last-tile issue with wasted cores.
However I did some generic tests , and the difference between 64x64 and 128x128 for CPU was less significant than the difference between 64x64 and 128x128 for GPU (about 3% difference on CPU, and 27% on GPU). I realize most people use their CPU, but a 27% speed up on gpu is worth a 3% sacrifice on CPU in my opinion.

I think 2 bounces is a bit low as well. 3 might be enough though? If we can detect whether there's something connected to the background shader's inputs and only use MIS then, then turning it on by default would be good yeah. As for tile sizes, the best solution at the moment would be to store the tile size for CPU and GPU separately, and have different defaults for each. For the moment though, how about a generic default of 128 or so? I know smaller tiles are better for CPU especially in the case when there are some small objects in the scene that take longer to render and you may get that last-tile issue with wasted cores. However I did some [generic tests ](http://adaptivesamples.files.wordpress.com/2013/11/tile_size_stats1.png), and the difference between 64x64 and 128x128 for CPU was less significant than the difference between 64x64 and 128x128 for GPU (about 3% difference on CPU, and 27% on GPU). I realize most people use their CPU, but a 27% speed up on gpu is worth a 3% sacrifice on CPU in my opinion.

Marco G commented

2013-11-17 15:46:08 +01:00

Depends on the user case, 4 bounces could be too much for studio-like setup indeed, characters showcasing etc.. i don't think there will be a situation where everybody happy. 2 bounces darken indirect light scene quite a lot. Perhaps adding another preset? On with 2 bounces for mostly direct lit scenes, one with 4 bounces for a good balance for interior/indirect light scenes.

About MIS auto size using the larger dimension i strongly disagree actually, eats lot of memory, rendering a cube and using a 6000 px hdr, setting MIS resolution to 6000 runs out of memory immediately on 1,3 Gb card here.

About tile size, for cpu i always use 32px or 64px, for gpu though i always set like the old method with perfect number of tiles (3x3 for example), writing 1920/3 and 1080/3 for a full hd render for example. The number of tiles was optimal for gpu imho, but really crappy for cpu though.

Depends on the user case, 4 bounces could be too much for studio-like setup indeed, characters showcasing etc.. i don't think there will be a situation where everybody happy. 2 bounces darken indirect light scene quite a lot. Perhaps adding another preset? On with 2 bounces for mostly direct lit scenes, one with 4 bounces for a good balance for interior/indirect light scenes. About MIS auto size using the larger dimension i strongly disagree actually, eats lot of memory, rendering a cube and using a 6000 px hdr, setting MIS resolution to 6000 runs out of memory immediately on 1,3 Gb card here. About tile size, for cpu i always use 32px or 64px, for gpu though i always set like the old method with perfect number of tiles (3x3 for example), writing 1920/3 and 1080/3 for a full hd render for example. The number of tiles was optimal for gpu imho, but really crappy for cpu though.

William Reynish commented

2013-11-17 16:38:44 +01:00

Ok, good arguments all round.

As for tile sizes, perhaps it can be simplified, like so:

If CPU: default to 64px
If GPU: default to 512px

I know this is an over-simplification of the optimal settings, but in most cases would you agree this would be a better default? The user could still change those settings.

Things like setting optimal tile sizes is very difficult for the user to determine. You need to understand how Cycles works at a deeper level to have a good idea of what might work best, and most users don't. In practice, most users will leave such a setting as the default, because he/she has no obvious way to determine it.
In an optimal world, the user would not have to be asked such a question, because it is inherrently system-centric, not user-centric. The renderer itself has the best prerequisite for determining what makes it run fastest, rather than putting the burden of the user to make a guess.

Ok, good arguments all round. As for tile sizes, perhaps it can be simplified, like so: If CPU: default to 64px If GPU: default to 512px I know this is an over-simplification of the optimal settings, but in most cases would you agree this would be a better default? The user could still change those settings. Things like setting optimal tile sizes is very difficult for the user to determine. You need to understand how Cycles works at a deeper level to have a good idea of what might work best, and most users don't. In practice, most users will leave such a setting as the default, because he/she has no obvious way to determine it. In an optimal world, the user would not have to be asked such a question, because it is inherrently system-centric, not user-centric. The renderer itself has the best prerequisite for determining what makes it run fastest, rather than putting the burden of the user to make a guess.

Thomas Dinges commented

2013-11-17 16:52:23 +01:00

Regarding the tile size I also wonder if we shouldn't just go with 1 value, instead of X/Y. We added it to have more control I guess, but when do you really use non-square tile sizes?

Greg Zaal commented

2013-11-17 16:55:04 +01:00

I think forcing square tiles with just one value will often cause long thin tiles on the borders - bad for gpu ;)

Diego Gangl commented

2013-11-17 22:31:43 +01:00

Added subscriber: @Januz

Diego Gangl commented

2013-11-17 22:31:43 +01:00

About Tiles, why not incorporate the code from greg's Auto Tile Size addon ?

About Tiles, why not incorporate the code from greg's [Auto Tile Size addon ](http://adaptivesamples.com/2013/11/05/auto-tile-size-addon-updated-again/)?

William Reynish commented

2013-11-17 23:15:31 +01:00

@Januz: Yes, that makes sense.

@brecht, here I'll refer to your post about tile sizes:
http://www.systemagnostic.com/faqs/adjusting-cycles-tile-sizes-for-increased-speed-and-reduced-vram/

As the article concludes, it's really too hard for users to determine optimal tile sizes, and the Add-on provides a better starting point.

Additionally, renders are faster with divisions of the final image resolution so that all tiles are of equal size - also something users can not be expected to know, in addition to the required step of performing math to get the correct result:)

@Januz: Yes, that makes sense. @brecht, here I'll refer to your post about tile sizes: http://www.systemagnostic.com/faqs/adjusting-cycles-tile-sizes-for-increased-speed-and-reduced-vram/ As the article concludes, it's really too hard for users to determine optimal tile sizes, and the Add-on provides a better starting point. Additionally, renders are faster with divisions of the final image resolution so that all tiles are of equal size - also something users can not be expected to know, in addition to the required step of performing math to get the correct result:)

Brecht Van Lommel commented

2013-11-18 05:35:40 +01:00

I'm well aware of the tile issue, but it will be solved in a different way, not by trying to add smarter tile size picking. It is not an efficient use of my time to add intermediate hacks, I have to leave that to the community.

If someone wants to add a quick, "Compute Optimal Tile Size" button implemented in python they can send me a patch, but I will not change any builtin Blender settings for this.

I'm well aware of the tile issue, but it will be solved in a different way, not by trying to add smarter tile size picking. It is not an efficient use of my time to add intermediate hacks, I have to leave that to the community. If someone wants to add a quick, "Compute Optimal Tile Size" button implemented in python they can send me a patch, but I will not change any builtin Blender settings for this.

William Reynish commented

2013-11-18 13:54:16 +01:00

Ok, that's fine, a more wholistic, deeper solution to this issue sounds better.

Gabriel Gazzán commented

2013-11-19 02:24:25 +01:00

Added subscriber: @GabrielGazzan

Gabriel Gazzán commented

2013-11-19 02:24:25 +01:00

Transparent:

I think Blender is quite strange in the way it handles the background (World).
I think what users normally expect is that the World would not contribute to the render alpha channel.
If so, the Transparent option would never be needed.

When a render is made, actual objects in the scene contribute to the alpha channel, but the world would not.
That way, when a user wants to composite the render with other things in the compositor (or an external app) all it has to do is make use of the alpha channel to mask the objects out and separate them from the background.
If the user wants to make use of the entire render (with the World shown), then all he/she have to do is discard the alpha channel.

Transparent: I think Blender is quite strange in the way it handles the background (World). I think what users normally expect is that the World would not contribute to the render alpha channel. If so, the Transparent option would never be needed. When a render is made, actual objects in the scene contribute to the alpha channel, but the world would not. That way, when a user wants to composite the render with other things in the compositor (or an external app) all it has to do is make use of the alpha channel to mask the objects out and separate them from the background. If the user wants to make use of the entire render (with the World shown), then all he/she have to do is discard the alpha channel.

Brecht Van Lommel commented

2013-11-19 08:14:14 +01:00

@GabrielGazzan: there is a very good reason it works the way it does, and that's because it's impossible to render the world and objects into the same RGB channel and then separate them with an alpha channel without getting artifacts near edges and in transparent areas. This was a very common source of compositing errors with Blender Internal, and it's also quite standard to work the way Cycles does here.

Thomas Dinges commented

2013-11-19 09:07:09 +01:00

Bounces: Can we agree on setting Diffuse bounces down to 3 as the default (keep Glossy and Transmission at 4/12)?

Lapineige commented

2013-11-19 10:43:06 +01:00

Added subscriber: @Lapineige

Andrew Price commented

2013-11-19 11:01:21 +01:00

On the note of bounces, a minor UI glitch that has annoyed me for a while:
Can the Diffuse, Glossy and Transmission be greyed out if the "total maximum" is lower than their values? It seems it would help users understand it's functionality better.

On the note of bounces, a minor UI glitch that has annoyed me for a while: Can the Diffuse, Glossy and Transmission be greyed out if the "total maximum" is lower than their values? It seems it would help users understand it's functionality better.

Thomas Dinges commented

2013-11-19 11:03:26 +01:00

This could be done of course, but not sure about it. I think it's confusing to grey out a button, which you still can click, and which still has an effect.

Linus Wiklander commented

2013-11-19 11:12:09 +01:00

Added subscriber: @wiklander

Linus Wiklander commented

2013-11-19 11:12:09 +01:00

I think the Cycles sampling defaults should be changed from 10/10

Not sure what levels are good, but I suggest Preview: at least 20, perhaps 50 (I usually set it to 100)
Render: 100 or 200, at least double the preview number.

I think the Cycles sampling defaults should be changed from 10/10 Not sure what levels are good, but I suggest Preview: at least 20, perhaps 50 (I usually set it to 100) Render: 100 or 200, at least double the preview number.

Diego Gangl commented

2013-11-19 12:46:50 +01:00

About the bounces, how about a warning (or info) icon next to the values? When you put your cursor over it you get a tooltip telling you about the total maximum.

Is there any downside to setting preview samples to 0? You'll always want the best quality possible, and it's not likely that users will leave the preview mode on and the scene untouched long enough for the continuous sampling to be a problem.

About the bounces, how about a warning (or info) icon next to the values? When you put your cursor over it you get a tooltip telling you about the total maximum. Is there any downside to setting preview samples to 0? You'll always want the best quality possible, and it's not likely that users will leave the preview mode on and the scene untouched long enough for the continuous sampling to be a problem.

Greg Zaal commented

2013-11-19 12:56:56 +01:00

This is already in the tooltip for Diffuse/Glossy/Transmission bounces, adding another warning would just create unnecessary UI clutter.

I don't think setting preview samples to 0 is a good idea, you assume the user knows what he's doing ;) Render and preview default samples are fine in my opinion, but 100 may be better. I'm sure there was some argument against this though, it's not the first time it's been discussed.

As for greying out the Diffuse/Glossy/Transmission bounces - I actually think this is a good idea. But how about instead of greying them out, you limit them entirely? When changing the value, it can't be set higher than the max bounce number. This of course is like a brick wall to a user who doesn't know about the total maximum, but this will prompt them I think to read the tooltip and find out why it stops. Otherwise they may change the diffuse bounces higher and keep re-rendering wondering why his changes have no effect.
Unless I misunderstand and these values do have some effect when set higher than the maximum?

This is already in the tooltip for Diffuse/Glossy/Transmission bounces, adding another warning would just create unnecessary UI clutter. I don't think setting preview samples to 0 is a good idea, you assume the user knows what he's doing ;) Render and preview default samples are fine in my opinion, but 100 may be better. I'm sure there was some argument against this though, it's not the first time it's been discussed. As for greying out the Diffuse/Glossy/Transmission bounces - I actually think this is a good idea. But how about instead of greying them out, you limit them entirely? When changing the value, it can't be set higher than the max bounce number. This of course is like a brick wall to a user who doesn't know about the total maximum, but this will prompt them I think to read the tooltip and find out why it stops. Otherwise they may change the diffuse bounces higher and keep re-rendering wondering why his changes have no effect. Unless I misunderstand and these values do have some effect when set higher than the maximum?

Lord Odin commented

2013-11-19 12:58:18 +01:00

@GregZaal +1

Diego Gangl commented

2013-11-19 14:46:20 +01:00

@GregZaal, I didn't understand what you meant. The user wouldn't know that rendering would go on and would wait for it to finish?

As for the bounces, what if the user lowers the total max after setting the other values? He wouldn't get limited and no warning either.

@GregZaal, I didn't understand what you meant. The user wouldn't know that rendering would go on and would wait for it to finish? As for the bounces, what if the user lowers the total max after setting the other values? He wouldn't get limited and no warning either.

Thomas Dinges commented

2013-11-19 15:36:06 +01:00

Bounces
I don't understand why adding icons, greying out or locking the range would help here?
A path tracer does not have many buttons for performance and quality, and we have pretty clear tooltips here, which says that those values are bounded by a total maximum. Adding more UI clutter or limiting the user's input is a bad idea.

If needed, I'd rather wait for improved (multi line) tooltips and provide more infos there. Everything else is just overhead.

Samples
Increasing the default samples could be done, but I don't think 100 is a good value, would keep it lower.

Setting the Preview samples to 0 (unlimited) is a bad idea. Not only is this amount of quality often not needed in a preview, but you also have a constant CPU/GPU workload with this.

**Bounces** I don't understand why adding icons, greying out or locking the range would help here? A path tracer does not have many buttons for performance and quality, and we have pretty clear tooltips here, which says that those values are bounded by a total maximum. Adding more UI clutter or limiting the user's input is a bad idea. If needed, I'd rather wait for improved (multi line) tooltips and provide more infos there. Everything else is just overhead. **Samples** Increasing the default samples could be done, but I don't think 100 is a good value, would keep it lower. Setting the Preview samples to 0 (unlimited) is a bad idea. Not only is this amount of quality often not needed in a preview, but you also have a constant CPU/GPU workload with this.

William Reynish commented

2013-11-19 16:50:34 +01:00

@ThomasDinges: Do you mean preview or render samples?

At least 100 sounds like a good value for rendered, but perhaps preview should be lower?

@ThomasDinges: Do you mean preview or render samples? At least 100 sounds like a good value for rendered, but perhaps preview should be lower?

Thomas Dinges commented

2013-11-19 21:06:00 +01:00

@billrey: I would keep preview samples low, maybe increase render samples a bit.

Still, for most scenes those values (50, 100?) will be too low, so people have to increase the amount anyway.

Also, beginners will open Blender, press F12, add a Monkey...press F12. For those scenarios I don't see a good reason to let the people wait a minute or so.
The Sample amount is always dependent on the scene and the bounces settings. If you just render with 0 bounces (no GI), 10 Samples will do the job even in more complex scenes.

@billrey: I would keep preview samples low, maybe increase render samples a bit. Still, for most scenes those values (50, 100?) will be too low, so people have to increase the amount anyway. Also, beginners will open Blender, press F12, add a Monkey...press F12. For those scenarios I don't see a good reason to let the people wait a minute or so. The Sample amount is always dependent on the scene and the bounces settings. If you just render with 0 bounces (no GI), 10 Samples will do the job even in more complex scenes.

Linus Wiklander commented

2013-11-20 00:25:09 +01:00

@ThomasDinges I rather think beginners will open blender, move the cursor around a few times because they want to select stuff, rotate the view a bit, then move on to a tutorial if they are still interested... :)

Joking aside, I think the default render settings should allow a very simple scene with a glossy or glass material to look ok out of the box (i.e. not too much noise).

Some quick trials just now leaves me at 25 for preview and 100 for render.

Still very moderate for people worried about time/performance, but much better defaults than 10/10 that you have to change straight away. We also can't assume that beginners will know that samples is a major setting for reducing noise/raising quality, a higher default than today would enable people to experiment a bit more with creating stuff before they address this issue.

@ThomasDinges I rather think beginners will open blender, move the cursor around a few times because they want to select stuff, rotate the view a bit, then move on to a tutorial if they are still interested... :) Joking aside, I think the default render settings should allow a very simple scene with a glossy or glass material to look ok out of the box (i.e. not too much noise). Some quick trials just now leaves me at **25 for preview and 100 for render**. Still very moderate for people worried about time/performance, but much better defaults than 10/10 that you have to change straight away. We also can't assume that beginners will know that samples is a major setting for reducing noise/raising quality, a higher default than today would enable people to experiment a bit more with creating stuff before they address this issue.

Gabriel Gazzán commented

2013-11-20 15:07:38 +01:00

@brecht:
"there is a very good reason it (Transparent) works the way it does, and that's because it's impossible to render the world and objects into the same RGB channel and then separate them with an alpha channel without getting artifacts near edges and in transparent areas. This was a very common source of compositing errors with Blender Internal, and it's also quite standard to work the way Cycles does here."

well, that's just what Straight Alpha is for. Other programs make good use of it, why Blender can't?
just to test it I've rendered out a simple image (in Maya) of a Ball against the mental ray Sky and then composited it over another background in After Effects, and it doesn't have any artifacts as you can see in the attached file .

@brecht: "there is a very good reason it (Transparent) works the way it does, and that's because it's impossible to render the world and objects into the same RGB channel and then separate them with an alpha channel without getting artifacts near edges and in transparent areas. This was a very common source of compositing errors with Blender Internal, and it's also quite standard to work the way Cycles does here." well, that's just what Straight Alpha is for. Other programs make good use of it, why Blender can't? just to test it I've rendered out a simple image (in Maya) of a Ball against the mental ray Sky and then composited it over another background in After Effects, and it doesn't have any artifacts as you can see in the attached file ![ball_sky.png](https://archive.blender.org/developer/F29659/ball_sky.png).

Gabriel Gazzán commented

2013-11-20 15:09:43 +01:00

this is the original rendered file if you want to try it for yourself
ball_sky.tga

this is the original rendered file if you want to try it for yourself [ball_sky.tga](https://archive.blender.org/developer/F29661/ball_sky.tga)

Brecht Van Lommel commented

2013-11-20 17:40:23 +01:00

@GabrielGazzan: we should really not go into this discussion because this is about picking the defaults values, for other discussion the bf-cycles mailing list is the place. But try a motion blurred green object rendered over a red background, and compositing that in an image editor over a blue background. Less extreme but also clear issues you will find on actual production scenes too.

The solution is to use the Environment pass if you want to separate foreground and background cleanly. It's a bit more work to set up in some cases but the intention here is to build for the accurate color and alpha pipeline.

@GabrielGazzan: we should really not go into this discussion because this is about picking the defaults values, for other discussion the bf-cycles mailing list is the place. But try a motion blurred green object rendered over a red background, and compositing that in an image editor over a blue background. Less extreme but also clear issues you will find on actual production scenes too. The solution is to use the Environment pass if you want to separate foreground and background cleanly. It's a bit more work to set up in some cases but the intention here is to build for the accurate color and alpha pipeline.

Gabriel Gazzán commented

2013-11-20 19:54:10 +01:00

@brecht:
Thanks for the example!
I see there is still some red left in the image after removing the background with the straight alpha.
So current method seems to be better.
Great! :)

@brecht: Thanks for the example! I see there is still some red left in the image after removing the background with the straight alpha. So current method seems to be better. Great! :)

Diego Gangl commented

2013-11-20 20:01:07 +01:00

Ok, samples to 0 was a bad idea. I agree with 25/100. Also, having different values for preview and renders could give users a clue that samples are related to quality.

@ThomasDinges I still think the UI should warn the user if he has entered an invalid value. Maybe not icons, but the slider could turn red or show a report in the info header when the user hits render.

Ok, samples to 0 was a bad idea. I agree with 25/100. Also, having different values for preview and renders could give users a clue that samples are related to quality. @ThomasDinges I still think the UI should warn the user if he has entered an invalid value. Maybe not icons, but the slider could turn red or show a report in the info header when the user hits render.

Thomas Dinges commented

2013-11-20 20:02:52 +01:00

What is a "invalid value"? Even if Diffuse/Glossy samples are higher than the Maximum, this is still not invalid, but a user choice.

William Reynish commented

2013-11-21 12:00:06 +01:00

@ThomasDinges The issue is that it's not currently clear which settings take preference.

Does Min/Max take preference, or does the explicit settings below for Diffuse take preference? Both might be the case, but it's not clearly communicated in the UI which it is.

@ThomasDinges The issue is that it's not currently clear which settings take preference. Does Min/Max take preference, or does the explicit settings below for Diffuse take preference? Both might be the case, but it's not clearly communicated in the UI which it is.

Thomas Dinges commented

2013-11-21 12:12:51 +01:00

It's clear in the tooltip of Diffuse/Glossy...Samples, that those values are bounded by the total maximum. I don't get the problem. :)

Greg Zaal commented

2013-11-21 12:13:53 +01:00

The tooltip for Diffuse/Glossy/Transmission says "Bounded by total Maximum". Makes perfect sense to me. I wouldn't mind a more visual cue, but I think after you've read the tooltip once, you've learnt it for good.

What do people think of changing the default roughness value of a new Glossy shader to 0.0? When adding a new node (not just changing another shader's type to Glossy in the properties editor), the default is 0.2. Without any roughness it'll render much quicker of course, and is consistent with a Glass shader and the mirror gloss in BI.

The tooltip for Diffuse/Glossy/Transmission says "Bounded by total Maximum". Makes perfect sense to me. I wouldn't mind a more visual cue, but I think after you've read the tooltip once, you've learnt it for good. What do people think of changing the default roughness value of a new Glossy shader to 0.0? When adding a new node (not just changing another shader's type to Glossy in the properties editor), the default is 0.2. Without any roughness it'll render much quicker of course, and is consistent with a Glass shader and the mirror gloss in BI.

Diego Gangl commented

2013-11-21 16:30:55 +01:00

@ThomasDinges If the value is bound by the total max but it's acually higher than the max, it's out of bounds. That's why I think it's invalid :P. It's like trying to set a negative value (gets clamped to 0). It's inconsistent with how out-of-bounds values are handled through the rest of the UI, that's why I think the user should get an instant cue.

@GregZaal I think the default is 0.2 because in some cases with solid backgrounds it looks like a diffuse (being a perfect mirror) and that would be confusing for new users.

@ThomasDinges If the value is bound by the total max but it's acually higher than the max, it's out of bounds. That's why I think it's invalid :P. It's like trying to set a negative value (gets clamped to 0). It's inconsistent with how out-of-bounds values are handled through the rest of the UI, that's why I think the user should get an instant cue. @GregZaal I think the default is 0.2 because in some cases with solid backgrounds it looks like a diffuse (being a perfect mirror) and that would be confusing for new users.

Jason Clarke commented

2013-11-21 18:13:40 +01:00

Added subscriber: @JasonClarke

Jason Clarke commented

2013-11-21 18:16:50 +01:00

@GregZaal I kinda like 0.2 as the default. Most of the time you don't actually want a perfect mirror. 0.2 is closer to the value i end up using a lot of the time.

Possible idea for min/max, does the overall max affect any other ray type besides diffuse/glossy/transmission? If it doesn't, then why not just do: min, diffuse max, glossy max, transmission max?

@GregZaal I kinda like 0.2 as the default. Most of the time you don't actually want a perfect mirror. 0.2 is closer to the value i end up using a lot of the time. Possible idea for min/max, does the overall max affect any other ray type besides diffuse/glossy/transmission? If it doesn't, then why not just do: min, diffuse max, glossy max, transmission max?

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Blender Default Settings: Cycles #37474