Blender 2.8 Defaults #54943

Closed
opened 2018-05-03 17:23:16 +02:00 by William Reynish · 282 comments

This is a list of things we should change about Blender's default settings and behaviour.

The list will grow and change over time.

Commits:

  • 4d5b7696cb - prefs
  • bcf6cc1f6b - startup
  • Update: default preferences are now maintained in: ./release/datafiles/userdef/userdef_default.c

Preferences

    • Python tooltips OFF
    • Auto Perspective ON ***
    • Navigation Manipulator ON ***
    • Region Overlap ON (Could be removed completely, now that it's optimized) ***
    • To make transparent toolbars work better, we would like to:
      • Make the toolbar region height be limited to the contents.
      • Make the toolbar region a separate theme

Default Settings

    • Default Shader should be set to Principled BSDF
    • Default Lamp increased strength (10x stronger)
    • Playback set to AV Sync (reverted, breaks physics caching)
    • 3D View Lens = 50mm
    • Camera film size = 36x24mm Full Frame
    • Camera Focal Length = 50mm
    • Render Size Percentage = 100%
    • Render Display = New Window
    • Scene Units = Metric
    • Color Management View = Filmic
    • Workbench Object Overlap = ON
    • Absolute Shape Keys Interpolation = Linear
    • Curve Fill Mode = Full

Default Renderer

    • Viewport = Workbench + Studio Lighting

Layout

    • Headers on top for all editors, except the Timeline at the bottom
    • Default Properties tab = Object Properties

New Objects

    • Generate UV's = ON

Default Theme

    • Flat
    • Dark UI Chrome
    • Universal widget radius
    • Transparent header in 3D View
    • Transparent toolbar area in 3D View

Tools

Vertex Slide:

    • Correct UV's = ON

Extrude Along Normals:

    • Even Thickness = ON

Laplacian Smooth:

    • Lambda Factor = 1.000

UV/Image Editor

    • Normalized Coordinates

Weight Painting

    • Auto-Normalize = ON

Cycles

    • Dithering = 1
    • Image Sequence Auto Refresh = ON

New Objects

    • SubdivisionSurfaces = ON (via OpenSubdiv)
    • Shade Smooth = ON (Wait till we have OpenSubdiv)

Preferences

    • Compute Devices ON (Postpone until we can detect crappy GPU's)
    • Release Confirms Transform

Text Editor

    • Line Numbers ON

Addons

    • All exporters should be set to Only Selected by default
This is a list of things we should change about Blender's default settings and behaviour. The list will grow and change over time. Commits: - 4d5b7696cb - prefs - bcf6cc1f6b - startup - Update: default preferences are now maintained in: `./release/datafiles/userdef/userdef_default.c` ## Preferences - - [x] Python tooltips OFF - - [x] Auto Perspective ON *** - - [x] Navigation Manipulator ON *** - - [x] Region Overlap ON (Could be removed completely, now that it's optimized) *** - To make transparent toolbars work better, we would like to: - Make the toolbar region height be limited to the contents. - Make the toolbar region a separate theme ## Default Settings - - [x] Default Shader should be set to Principled BSDF - - [x] Default Lamp increased strength (10x stronger) - - [ ] Playback set to AV Sync (reverted, breaks physics caching) - - [x] 3D View Lens = 50mm - - [x] Camera film size = 36x24mm Full Frame - - [x] Camera Focal Length = 50mm - - [x] Render Size Percentage = 100% - - [x] Render Display = New Window - - [x] Scene Units = Metric - - [x] Color Management View = Filmic - - [x] Workbench Object Overlap = ON - - [x] Absolute Shape Keys Interpolation = Linear - - [x] Curve Fill Mode = Full ## Default Renderer - - [x] Viewport = Workbench + Studio Lighting ## Layout - - [x] Headers on top for all editors, except the Timeline at the bottom - - [x] Default Properties tab = Object Properties ## New Objects - - [x] Generate UV's = ON ## Default Theme - - [x] Flat - - [x] Dark UI Chrome - - [ ] Universal widget radius - - [x] Transparent header in 3D View - - [x] Transparent toolbar area in 3D View ## Tools Vertex Slide: - - [x] Correct UV's = ON Extrude Along Normals: - - [x] Even Thickness = ON Laplacian Smooth: - - [x] Lambda Factor = 1.000 ## UV/Image Editor - - [x] Normalized Coordinates ## Weight Painting - - [ ] Auto-Normalize = ON ## Cycles - - [x] Dithering = 1 - - [x] Image Sequence Auto Refresh = ON ## New Objects - - [ ] SubdivisionSurfaces = ON (via OpenSubdiv) - - [ ] Shade Smooth = ON (Wait till we have OpenSubdiv) ## Preferences - - [ ] Compute Devices ON (Postpone until we can detect crappy GPU's) - - [x] Release Confirms Transform ## Text Editor - - [x] Line Numbers ON ## Addons - - [ ] All exporters should be set to Only Selected by default
William Reynish self-assigned this 2018-05-03 17:23:16 +02:00

Added subscribers: @WilliamReynish, @pablovazquez

Added subscribers: @WilliamReynish, @pablovazquez
William Reynish changed title from Blender Defaults to Blender 2.8 Defaults 2018-05-03 17:24:23 +02:00

Added subscriber: @Sergey

Added subscriber: @Sergey

Added subscriber: @ErickNyanduKabongo

Added subscriber: @ErickNyanduKabongo

Replace default cube scene?

> Replace default cube scene? - Please don't at least for us people who do modeling (box modeling) and sculpting, it is the startup point. I have a thread full of default cube sculpting, -> https://blenderartists.org/forum/showthread.php?384289-Sculpt-a-head-starting-with-default-cube-(youtube) - The default cube is easy to do fast test. May i ask why do you want to change it? Is it because of the joke (delete default cube)? Well there are people who work with it as a starting point.

Added subscriber: @cedriclepiller

Added subscriber: @cedriclepiller

If I may :

Preferences > Interface :

  • Auto Perspective ON, if we go in ortho views 1,3,7 we want to be in ortho and exit the ortho when MMB. Working in ortho (5), even if some people like it, it's bad to see the forms of our object.
  • Rotate around Selection ON, it's difficult to rotate if the object disappear.

Preferences > system :

  • Anisotropic filtering and multi Sample to 4 or 8 to have an antialiased viewport (important to show that blender is great)
  • Opengl color, something grey, no fancy ugly purple please.

3DView :

View Lens to 70 or 80, to not have a deformed view, it's important to have the good lens to be exact, 35 is a really bad choice and the object is really deformed.

Splash Screen :

  • Add selection RMB/LMB, devs will keep RMB as selection, it's ok, but when people start learning blender they don't know they can change that.
    A lot of people, don't like it and give up blender because of that, so giving the possibility to choose like we can choose presets will allow more people to learn blender and after they can try and keep RMB.

Please consider this, it's really important.

If I may : Preferences > Interface : - Auto Perspective ON, if we go in ortho views 1,3,7 we want to be in ortho and exit the ortho when MMB. Working in ortho (5), even if some people like it, it's bad to see the forms of our object. - Rotate around Selection ON, it's difficult to rotate if the object disappear. Preferences > system : - Anisotropic filtering and multi Sample to 4 or 8 to have an antialiased viewport (important to show that blender is great) - Opengl color, something grey, no fancy ugly purple please. 3DView : View Lens to 70 or 80, to not have a deformed view, it's important to have the good lens to be exact, 35 is a really bad choice and the object is really deformed. Splash Screen : - Add selection RMB/LMB, devs will keep RMB as selection, it's ok, but when people start learning blender they don't know they can change that. A lot of people, don't like it and give up blender because of that, so giving the possibility to choose like we can choose presets will allow more people to learn blender and after they can try and keep RMB. Please consider this, it's really important.

Added subscriber: @VukGardasevic

Added subscriber: @VukGardasevic

For add-ons some quick outlines:

  • Cycles enabled (formally an add-on well no changes there)
  • OBJ I/O probably too with the inclusion of a few of other popular formats (what exact ones - should be postponed to later on stage)
  • Consider maybe the export UV layout as an useful option that probably should be a standard for UV editing (suggestion)
  • Consider including by default some additional mesh primitives that are now in add-ons (suggestion)
For add-ons some quick outlines: - Cycles enabled (formally an add-on well no changes there) - OBJ I/O probably too with the inclusion of a few of other popular formats (what exact ones - should be postponed to later on stage) - Consider maybe the export UV layout as an useful option that probably should be a standard for UV editing (suggestion) - Consider including by default some additional mesh primitives that are now in add-ons (suggestion)

Added subscriber: @mendio

Added subscriber: @mendio

Added subscriber: @L0Lock

Added subscriber: @L0Lock

Splash Screen :

  • Add selection RMB/LMB, devs will keep RMB as selection, it's ok, but when people start learning blender they don't know they can change that.

A lot of people, don't like it and give up blender because of that, so giving the possibility to choose like we can choose presets will allow more people to learn blender and after they can try and keep RMB.

And if not possible, at least something to clearly warn any new user about RMB and where to go in order to change that.

> Splash Screen : > - Add selection RMB/LMB, devs will keep RMB as selection, it's ok, but when people start learning blender they don't know they can change that. > > A lot of people, don't like it and give up blender because of that, so giving the possibility to choose like we can choose presets will allow more people to learn blender and after they can try and keep RMB. And if not possible, at least something to clearly warn any new user about RMB and where to go in order to change that.

Added subscriber: @Ghostil

Added subscriber: @Ghostil

1 In the new version, can presets be saved for default settings in all sections?
2 when resizing for example by cm, the dimensions will always be measured in cm, and not as now 100 cm automatically converted to 1 m?
3 Can I fine-tune the accuracy of a semi-comma
1.0cm 1.00cm 1.000cm size?
I will ask here because I do not know where it can be discussed.

1 In the new version, can presets be saved for default settings in all sections? 2 when resizing for example by cm, the dimensions will always be measured in cm, and not as now 100 cm automatically converted to 1 m? 3 Can I fine-tune the accuracy of a semi-comma 1.0cm 1.00cm 1.000cm size? I will ask here because I do not know where it can be discussed.

About default addons for 2.8, what about :

  • Node Wrangler on
  • Pie Menus (don't know which one, but i think it should have at least some enabled by default so newcomers actually know they exist...)
  • Import Image as Planes
  • Rigify (most other software does provide rigify equivalent by default, Blender should too in order to compete IMO. For now our Add → Armature menu is poor, can only add bones...)
About default addons for 2.8, what about : - Node Wrangler on - Pie Menus (don't know which one, but i think it should have at least some enabled by default so newcomers actually know they exist...) - Import Image as Planes - Rigify (most other software does provide rigify equivalent by default, Blender should too in order to compete IMO. For now our Add → Armature menu is poor, can only add bones...)

I asked a dev about this non-sense dimension behaviour and he said it's not modifiable, blender is done like that.

In Maya, if you create a 1cm cube and you change the system in meter, the cube is still 1cm, this is normal, in Blender, the size of the cube change, this is not normal.

I asked a dev about this non-sense dimension behaviour and he said it's not modifiable, blender is done like that. In Maya, if you create a 1cm cube and you change the system in meter, the cube is still 1cm, this is normal, in Blender, the size of the cube change, this is not normal.

2.jpg
If I specify the unit of measure, see why it does not write the size of the cube 200cm and 2m? Must be everywhere cm

![2.jpg](https://archive.blender.org/developer/F3283186/2.jpg) If I specify the unit of measure, see why it does not write the size of the cube 200cm and 2m? Must be everywhere cm

Vyacheslav: No. Because, setting the units to cm means that 1 unit = 1cm. It doesn't mean that you only ever see cm. That' something else, unrelated. 100cm = 1 meter.

Vyacheslav: No. Because, setting the units to cm means that 1 unit = 1cm. It doesn't mean that you only ever see cm. That' something else, unrelated. 100cm = 1 meter.

Added subscriber: @Okavango

Added subscriber: @Okavango

@WilliamReynish Actually, @Ghostil is right, it is a matter of UI / UX discipline - if i choose centimeters, that means that i want to see and work in centimeters - i want to input centimeters when moving, i want to read object attributes in centimeters, see them when measuring i want to eat them, sleep them and breathe them. That is how powerful that switch should be. Check the comments on that feature in Blenderartists, they all say the same thing, Blender has been a bit sloppy in this area.

@WilliamReynish Actually, @Ghostil is right, it is a matter of UI / UX discipline - if i choose centimeters, that means that i want to see and work in centimeters - i want to input centimeters when moving, i want to read object attributes in centimeters, see them when measuring i want to eat them, sleep them and breathe them. That is how powerful that switch should be. Check the comments on that feature in Blenderartists, they all say the same thing, Blender has been a bit sloppy in this area.

But it's actually quite a different thing though:

One is a setting for the scale of 1 unit. It can be 1 meter, 1 cm, 1km or so on.

What you are asking for is something completely different, which is a way to lock property values to always show the same unit. I'm not saying that's a bad idea necessarily, just that it's not actually related to the unit scale setting itself, and it's not a feature we currently have. I consider that somewhat off-topic.

But it's actually quite a different thing though: One is a setting for the scale of 1 unit. It can be 1 meter, 1 cm, 1km or so on. What you are asking for is something completely different, which is a way to lock property values to always show the same unit. I'm not saying that's a bad idea necessarily, just that it's not actually related to the unit scale setting itself, and it's not a feature we currently have. I consider that somewhat off-topic.

Added subscriber: @AnadinX

Added subscriber: @AnadinX

I'd like to add votes for

  • Cursor Depth
  • Auto Depth
  • Zoom To Mouse Position

very much agree with Auto Perspective defaulting to on

I'd like to add votes for - Cursor Depth - Auto Depth - Zoom To Mouse Position ``` ``` very much agree with Auto Perspective defaulting to on

Yes, it is unrelated to 'what measuring unit should be the default'. It is probably off topic in this task.

But it is a current Blender's UI issue. There is a lot of unit inconsistencies in the program, probably arising from the fact that 95 % users are artists. Technical users avoid Blender still, there is only a handful of us here, mainly out of principle. And we know about this stuff. I have constant problems when working with architectural projects.

And i would advise avoiding the term 'scale' when talking about units. This is probably what caused the problem in the first place. You should not be scaling anything when setting this.

You should simply be communicating all the values in a different language (cm / km / inch / feet). Everything in the file should remain the same size (check @cedriclepiller 's comment) .

Yes, it is unrelated to 'what measuring unit should be the default'. It is probably off topic in this task. But it is a current Blender's UI issue. There is a lot of unit inconsistencies in the program, probably arising from the fact that 95 % users are artists. Technical users avoid Blender still, there is only a handful of us here, mainly out of principle. And we know about this stuff. I have constant problems when working with architectural projects. And i would advise avoiding the term 'scale' when talking about units. This is probably what caused the problem in the first place. You should not be scaling anything when setting this. You should simply be communicating all the values in a different language (cm / km / inch / feet). Everything in the file should remain the same size (check @cedriclepiller 's comment) .

You can’t though. If you want to model the solar system to scale, your scale is different from if you want to model an ant. It has to be. That’s why there’s a scale setting, to say what 1 unit means. What you are talking about is something else, which is ability to only display a certain unit of measurement. We could add that, but it would have to be a separate setting.

You can’t though. If you want to model the solar system to scale, your scale is different from if you want to model an ant. It has to be. That’s why there’s a scale setting, to say what 1 unit means. What you are talking about is something else, which is ability to only *display* a certain unit of measurement. We could add that, but it would have to be a separate setting.

Bingo! That is the problem!

Actually, in a serious 3D app they are the same scale. You will make the ant in a different file, working in millimeters!

And if you need it inside the solar system you will link it without the problem. It will be the correct size and if you want, you can scroll your fingers off but you will find it at it's location correctly sized. Scaling would make this difficult and it currently does.

But as you said, this is off topic here, for a serious reconsideration sometime in the future.

Bingo! That is the problem! Actually, in a serious 3D app they ***are*** the same scale. You will make the ant in a different file, working in millimeters! And if you need it inside the solar system you will link it without the problem. It will be the correct size and if you want, you can scroll your fingers off but you will find it at it's location correctly sized. Scaling would make this difficult and it currently does. But as you said, this is off topic here, for a serious reconsideration sometime in the future.
Contributor

Added subscriber: @Rawalanche

Added subscriber: @Rawalanche
Contributor

Cycles reflective and Refractive caustics should definitely not be off by default. This goes against the usability, as renderer should deliver visually pleasing output by default. You won't achieve that by making sure glass shadows turn out completely black and metallic materials won't bounce a bit of light.

Instead, you should do what pretty much every other renderer on the market currently does, and that is clamp indirect lighting by default, to some reasonable value, which will eliminate most of the indirect noise and fireflies without such drastic reduction of output quality.

One good step towards better defaults would be to open Blender's properties panel on a different tab than Renderer one. When you start off with almost empty scene, rendering is not a first thing you will go to. Yet the first property panel a new users will be confronted with is one full of the most technical settings, such as Cycles' sampling settings :)

Cycles reflective and Refractive caustics should definitely not be off by default. This goes against the usability, as renderer should deliver visually pleasing output by default. You won't achieve that by making sure glass shadows turn out completely black and metallic materials won't bounce a bit of light. Instead, you should do what pretty much every other renderer on the market currently does, and that is clamp indirect lighting by default, to some reasonable value, which will eliminate most of the indirect noise and fireflies without such drastic reduction of output quality. One good step towards better defaults would be to open Blender's properties panel on a different tab than Renderer one. When you start off with almost empty scene, rendering is not a first thing you will go to. Yet the first property panel a new users will be confronted with is one full of the most technical settings, such as Cycles' sampling settings :)

Added subscriber: @AndrewPalmer

Added subscriber: @AndrewPalmer

I would love it if the default UV coordinate setting was to use normalized coords (single square is 0-1) instead of basing them on the texture resolution.

  • Easier to quickly move uvs by a fraction using numeric input (0.5, 0.25 etc.)
  • Texture resolution independence means moving uvs by fractions is always the same.
  • Presumably less issues with UDIMs, which can have per-tile resolution.
  • Normalized coordinates are used by almost every other app by default.
I would love it if the default UV coordinate setting was to use normalized coords (single square is 0-1) instead of basing them on the texture resolution. + Easier to quickly move uvs by a fraction using numeric input (0.5, 0.25 etc.) + Texture resolution independence means moving uvs by fractions is always the same. + Presumably less issues with UDIMs, which can have per-tile resolution. + Normalized coordinates are used by almost every other app by default.
Contributor

Here is another, practical example why turning off reflective and refractive caustics won't save us from noise:
https://forums.unrealengine.com/development-discussion/rendering/1460002-luoshuang-s-gpulightmass?p=1465988#post1465988

There quite a few scenarios where, even with completely diffuse scenes which make reflective and refractive caustics impossible to occur, you can still get a lot of noise without indirect lighting clamping.

Indirect lighting clamping is what universally protects you from noise, regardless of if the noise comes from caustics, indirect diffuse light or very small and strong emissive material. That's what should be changed by default. Current default is 0. Something like 2-5 would be most reasonable.

Here is another, practical example why turning off reflective and refractive caustics won't save us from noise: https://forums.unrealengine.com/development-discussion/rendering/1460002-luoshuang-s-gpulightmass?p=1465988#post1465988 There quite a few scenarios where, even with completely diffuse scenes which make reflective and refractive caustics impossible to occur, you can still get a lot of noise without indirect lighting clamping. Indirect lighting clamping is what universally protects you from noise, regardless of if the noise comes from caustics, indirect diffuse light or very small and strong emissive material. That's what should be changed by default. Current default is 0. Something like 2-5 would be most reasonable.

In #54943#500613, @WilliamReynish wrote:
You can’t though. If you want to model the solar system to scale, your scale is different from if you want to model an ant. It has to be. That’s why there’s a scale setting, to say what 1 unit means. What you are talking about is something else, which is ability to only display a certain unit of measurement. We could add that, but it would have to be a separate setting.

Good afternoon. You have all rightly said, these are only the names of the units of measurement and they should be separate from the real size. In 3Ds max for example, what defines the scale is called unit setup,
but the fact that I'm asking for this is just a display.
system unit scale 1 unit = 1cm in 3ds max this = size in blender.
Display Unit Scale = cm this only text no real size.
for example:
system unit scale 1 unit = 1cm
Display Unit Scale = m
in view i see cube size 1.0m 1.0m 1.0m real size 100cm, system unit scale 1 unit = 1cm this set real size for object.

 
> In #54943#500613, @WilliamReynish wrote: > You can’t though. If you want to model the solar system to scale, your scale is different from if you want to model an ant. It has to be. That’s why there’s a scale setting, to say what 1 unit means. What you are talking about is something else, which is ability to only *display* a certain unit of measurement. We could add that, but it would have to be a separate setting. Good afternoon. You have all rightly said, these are only the names of the units of measurement and they should be separate from the real size. In 3Ds max for example, what defines the scale is called unit setup, but the fact that I'm asking for this is just a display. system unit scale 1 unit = 1cm in 3ds max this = size in blender. Display Unit Scale = cm this only text no real size. for example: system unit scale 1 unit = 1cm Display Unit Scale = m in view i see cube size 1.0m 1.0m 1.0m real size 100cm, system unit scale 1 unit = 1cm this set real size for object. ``` ```

11505527191.jpg
this i find size for 3ds max in internet.
1 unit = 1.0m = default Scene Units = Metric
metric = millimetrs user see size in all field
sorry my english.

![11505527191.jpg](https://archive.blender.org/developer/F3298831/11505527191.jpg) this i find size for 3ds max in internet. 1 unit = 1.0m = default Scene Units = Metric metric = millimetrs user see size in all field sorry my english.

Just to put some more light on the terminology, i have a feeling we are being confused by two different words here:

Unit SCALE:

https:*businessjargons.com/interval-scale.html

SCALING in geometry :

https:*en.wikipedia.org/wiki/Scaling_(geometry)

A scene should not be scaled (2) when changing the measurement scale (1).

@Ghostil - the size in the display boxes is still the same real size that is in the scene, nothing is 'scaled' down or up when changing the unit 'scale'. There is just a different measurement language to show the exact same size.

Just to put some more light on the terminology, i have a feeling we are being confused by two different words here: Unit *SCALE*: [https:*businessjargons.com/interval-scale.html ](https:*businessjargons.com/interval-scale.html) *SCALING* in geometry : [https:*en.wikipedia.org/wiki/Scaling_(geometry) ](https:*en.wikipedia.org/wiki/Scaling_(geometry)) A scene should not be **scaled** (2) when changing the measurement **scale** (1). @Ghostil - the size in the display boxes is still the same real size that is in the scene, nothing is 'scaled' down or up when changing the unit 'scale'. There is just a different measurement language to show the exact same size.

But depending on how you look at it, it does (and should) scale. If you make a 1x1x1 unit cube, and tell Blender that you'd like to work in km, that cube is now 1km x 1km x 1km. If you then change it so you work in cm, that cube is now 1cm x 1cm x 1cm. Essentially, that cube is now way smaller. That's how it's intended to work, and that's how it should work. Otherwise, it'd be impossible to work at very large or very small scales.

But depending on how you look at it, it does (and should) scale. If you make a 1x1x1 unit cube, and tell Blender that you'd like to work in km, that cube is now 1km x 1km x 1km. If you then change it so you work in cm, that cube is now 1cm x 1cm x 1cm. Essentially, that cube is now way smaller. That's how it's intended to work, and that's how it *should* work. Otherwise, it'd be impossible to work at very large or very small scales.
Contributor

Being a 3ds Max user for almost 10 years, I can with confidence say that 3ds Max unit system is one of the worst way to go about it. It creates more problems than good. I find the best scale systems to be the ones that define precision of the scenes based on viewport/camera near and far clipping planes :)

Being a 3ds Max user for almost 10 years, I can with confidence say that 3ds Max unit system is one of the worst way to go about it. It creates more problems than good. I find the best scale systems to be the ones that define precision of the scenes based on viewport/camera near and far clipping planes :)

Added subscriber: @brecht

Added subscriber: @brecht

The default for Cycles indirect clamp was changed to 10.0 in master some time ago.

For units, there could an additional option for a preferred display unit (so that it e.g. always uses cm unless the number is outside the 0.0001cm to 10000.0cm range and it becomes ridiculously long). But that's not a change to the default setttings and seems off topic here.

The default for Cycles indirect clamp was changed to 10.0 in master some time ago. For units, there could an additional option for a preferred display unit (so that it e.g. always uses cm unless the number is outside the 0.0001cm to 10000.0cm range and it becomes ridiculously long). But that's not a change to the default setttings and seems off topic here.

yes, agreed.

yes, agreed.

Added subscriber: @wiklander

Added subscriber: @wiklander

A detail but I'll weigh in on this.
I think keeping the Render Size Percentage at 50% would better convey that the function exists and I think it's more inviting to be changed and used.

Visually it communicates more as a half filled bar at 50% than a fully filled bar at 100%.

This could be a good time to up the default resolution to 4k though. Then you would get the same resolution at 50% as 1080@100% :)

A detail but I'll weigh in on this. I think keeping the **Render Size Percentage** at 50% would better convey that the function exists and I think it's more inviting to be changed and used. Visually it communicates more as a half filled bar at 50% than a fully filled bar at 100%. This could be a good time to up the default resolution to 4k though. Then you would get the same resolution at 50% as 1080@100% :)
Member

Added subscriber: @JulianEisel

Added subscriber: @JulianEisel
Member

I actually agree on what @wiklander said, I'd also prefer keeping the Render Size Percentage at 50% to force people into discovering it ;)

Regarding other options:

  • Auto Perspective
With Auto Perspective enabled, changing to top/front/side views and then rotating the view always goes back to perspective projection, even if orthographic was set before. Seems to me like this should be addressed first.
  • 3D View Lens
What's the reason for suggesting 50mm here? Having it differ from the scene camera default value (35mm - which is a good default IMHO) causes a difference that may confuse users when switching between camera and perspective view.
However, I find it more troublesome that such a lens gives an rather orthographic projection. With a value like 35mm, it's quite obvious if you're in orthographic or in perspective projection mode, with 50mm, the distinction becomes much less apparent. You'll have to look at the on-screen label more often.
  • Default Properties tab
I think the object tab is used pretty rarely, the majority of its options aren't that interesting to change. Esp. if we also remove the Display panel. Things like the render engine or render resolution are some of the first things you'd want to change when starting a new file OTOH. Don't have that strong of an opinion though.
I actually agree on what @wiklander said, I'd also prefer keeping the Render Size Percentage at 50% to force people into discovering it ;) Regarding other options: * Auto Perspective ``` With Auto Perspective enabled, changing to top/front/side views and then rotating the view always goes back to perspective projection, even if orthographic was set before. Seems to me like this should be addressed first. ``` * 3D View Lens ``` What's the reason for suggesting 50mm here? Having it differ from the scene camera default value (35mm - which is a good default IMHO) causes a difference that may confuse users when switching between camera and perspective view. ``` ``` However, I find it more troublesome that such a lens gives an rather orthographic projection. With a value like 35mm, it's quite obvious if you're in orthographic or in perspective projection mode, with 50mm, the distinction becomes much less apparent. You'll have to look at the on-screen label more often. ``` * Default Properties tab ``` I think the object tab is used pretty rarely, the majority of its options aren't that interesting to change. Esp. if we also remove the Display panel. Things like the render engine or render resolution are some of the first things you'd want to change when starting a new file OTOH. Don't have that strong of an opinion though.

Sorry but I disagree with you.

Ortho view is not what people should use for modelling, except if they do isometric work. Working on a character or an asset will give bad result since the camera is in perspective view.
I assume you work in ortho view, so it's not an issue for you, but I don't know any experienced user (except those who work only with blender) who use it.
Going from perspective view to ortho view (1,3,7) and not being in ortho view is a complete non-sense IMO.
You expect to go in ortho view and comeback in perspective view.
Ortho view should be used only in several cases, not every time.

I had a lot of people asking me why the ortho view is not in ortho, I always have to tell them to enable the auto perspective.

Same for the lens, in 3dview that deform your model and the camera should not be in 35 mm either but at 55 mm to have something that works on every situation, 35mm is not.
And having something not deformed is good for sculpting and to see the model.
putting a bad lens to show that people are in perspective is bad, they should be in perspective since it's de the default.

lens.jpg

As an artist I would never ever use 35 mm for the view, it's bad and deformed!
And remember people can see in which view they are, ortho or persp.

blender_2018-05-08_01-21-25.jpg

So putting 35 because of the confusion is not a good reason to use a bad default.

By the way, since we talk about default, the current ogl render is really bad, you should put something that helps to see the model.
There is an example.

shading (1).jpg

Default matcaps are bad too for characters, maybe for something else they are ok, but the default ogl shader should work for everything.
Look how good we can see the model at the right and how bad it is with blender 2.79 default shader.

Sorry but I disagree with you. Ortho view is not what people should use for modelling, except if they do isometric work. Working on a character or an asset will give bad result since the camera is in perspective view. I assume you work in ortho view, so it's not an issue for you, but I don't know any experienced user (except those who work only with blender) who use it. Going from perspective view to ortho view (1,3,7) and not being in ortho view is a complete non-sense IMO. You expect to go in ortho view and comeback in perspective view. Ortho view should be used only in several cases, not every time. I had a lot of people asking me why the ortho view is not in ortho, I always have to tell them to enable the auto perspective. Same for the lens, in 3dview that deform your model and the camera should not be in 35 mm either but at 55 mm to have something that works on every situation, 35mm is not. And having something not deformed is good for sculpting and to see the model. putting a bad lens to show that people are in perspective is bad, they should be in perspective since it's de the default. ![lens.jpg](https://archive.blender.org/developer/F3300402/lens.jpg) As an artist I would never ever use 35 mm for the view, it's bad and deformed! And remember people can see in which view they are, ortho or persp. ![blender_2018-05-08_01-21-25.jpg](https://archive.blender.org/developer/F3300419/blender_2018-05-08_01-21-25.jpg) So putting 35 because of the confusion is not a good reason to use a bad default. By the way, since we talk about default, the current ogl render is really bad, you should put something that helps to see the model. There is an example. ![shading (1).jpg](https://archive.blender.org/developer/F3300449/shading__1_.jpg) Default matcaps are bad too for characters, maybe for something else they are ok, but the default ogl shader should work for everything. Look how good we can see the model at the right and how bad it is with blender 2.79 default shader.

In #54943#500784, @JulianEisel wrote:
I actually agree on what @wiklander said, I'd also prefer keeping the Render Size Percentage at 50% to force people into discovering it ;)

So we should set a setting wrongly, just so that users discover that it’s wrong, and then change it? That does not seem right. If it’s set to 1080p, then it should render as 1080p, unless the user specifically wants to render half-res.

It’s the equivalent of asking a painter to paint your house white, but then he paints it grey. And then you paint it over. Yeah, you learned to change it, but only because it did something wrong in the first place.

Regarding other options:

  • Auto Perspective

    With Auto Perspective enabled, changing to top/front/side views and then rotating the view always goes back to perspective projection, even if orthographic was set before. Seems to me like this should be addressed first.

That is the intended behavior. It makes it so that artists can fluidly switch from orthographic side views and perspective. You pretty much never want to be in front view without ortho. And it makes it so that when you select a view, either from the view menu, or the viewport manipulator, it does the right thing.

  • 3D View Lens

    What's the reason for suggesting 50mm here? Having it differ from the scene camera default value (35mm - which is a good default IMHO) causes a difference that may confuse users when switching between camera and perspective view.

    However, I find it more troublesome that such a lens gives an rather orthographic projection. With a value like 35mm, it's quite obvious if you're in orthographic or in perspective projection mode, with 50mm, the distinction becomes much less apparent. You'll have to look at the on-screen label more often.

50mm is the standard camera perspective, and mirrors the human eye. 35mm is considered wide angle, and gives you a distorted perspective. It’s not a good default to have the view be distorted.

The default camera in Blender is also wrong. It has a completely non-standard film size. Probably makes sense to go with super35mm, with a 35mm focal length (which is equivalent to 50mm in full frame terms)

Dunno how much you are into cameras and camera terminology, but this is an area that needs to change, to give users useable defaults.

  • Default Properties tab

    I think the object tab is used pretty rarely, the majority of its options aren't that interesting to change. Esp. if we also remove the Display panel. Things like the render engine or render resolution are some of the first things you'd want to change when starting a new file OTOH. Don't have that strong of an opinion though.

Reasoning is two-fold:
1: users don’t immediately care about rendering as they start a new scene. They care about adding and manipulating objects. Rendering happens later. It’s like having an export panel as the first thing you see, which makes no sense. You haven’t even started yet.
2: it makes it so that when users add objects, they can immediately see their location, rotation & scale in 3D space, which is the first thing you are likely to modify.

> In #54943#500784, @JulianEisel wrote: > I actually agree on what @wiklander said, I'd also prefer keeping the Render Size Percentage at 50% to force people into discovering it ;) So we should set a setting wrongly, just so that users discover that it’s wrong, and then change it? That does not seem right. If it’s set to 1080p, then it should render as 1080p, unless the user specifically wants to render half-res. It’s the equivalent of asking a painter to paint your house white, but then he paints it grey. And then you paint it over. Yeah, you learned to change it, but only because it did something wrong in the first place. > Regarding other options: > * Auto Perspective > > With Auto Perspective enabled, changing to top/front/side views and then rotating the view always goes back to perspective projection, even if orthographic was set before. Seems to me like this should be addressed first. That is the intended behavior. It makes it so that artists can fluidly switch from orthographic side views and perspective. You pretty much never want to be in front view without ortho. And it makes it so that when you select a view, either from the view menu, or the viewport manipulator, it does the right thing. > > * 3D View Lens > > What's the reason for suggesting 50mm here? Having it differ from the scene camera default value (35mm - which is a good default IMHO) causes a difference that may confuse users when switching between camera and perspective view. > > However, I find it more troublesome that such a lens gives an rather orthographic projection. With a value like 35mm, it's quite obvious if you're in orthographic or in perspective projection mode, with 50mm, the distinction becomes much less apparent. You'll have to look at the on-screen label more often. 50mm is the standard camera perspective, and mirrors the human eye. 35mm is considered wide angle, and gives you a distorted perspective. It’s not a good default to have the view be distorted. The default camera in Blender is also wrong. It has a completely non-standard film size. Probably makes sense to go with super35mm, with a 35mm focal length (which is equivalent to 50mm in full frame terms) Dunno how much you are into cameras and camera terminology, but this is an area that needs to change, to give users useable defaults. > > * Default Properties tab > > I think the object tab is used pretty rarely, the majority of its options aren't that interesting to change. Esp. if we also remove the Display panel. Things like the render engine or render resolution are some of the first things you'd want to change when starting a new file OTOH. Don't have that strong of an opinion though. Reasoning is two-fold: 1: users don’t immediately care about rendering as they start a new scene. They care about adding and manipulating objects. Rendering happens later. It’s like having an export panel as the first thing you see, which makes no sense. You haven’t even started yet. 2: it makes it so that when users add objects, they can immediately see their location, rotation & scale in 3D space, which is the first thing you are likely to modify.

Added subscriber: @MikhailRachinskiy

Added subscriber: @MikhailRachinskiy

Hi, please let me propose default value for Empty Image Offset property.

Current default of 0 offset places origin to bottom left corner of the image, which makes it awkward to rotate and scale.
Setting offset to -0.5 puts origin to the center of the image and makes it behave more natural during transformations.

It is especially important since Viewport background images will be removed from 2.8 and Empty Image remain the only way to set up reference images in the viewport.

empty_offset.png

Hi, please let me propose default value for Empty Image Offset property. Current default of 0 offset places origin to bottom left corner of the image, which makes it awkward to rotate and scale. Setting offset to -0.5 puts origin to the center of the image and makes it behave more natural during transformations. It is especially important since Viewport background images will be removed from 2.8 and Empty Image remain the only way to set up reference images in the viewport. ![empty_offset.png](https://archive.blender.org/developer/F3302043/empty_offset.png)

Added subscriber: @bdp

Added subscriber: @bdp

suggest : in timeline show keyframes only to selected objects

suggest : in timeline show keyframes only to selected objects

But depending on how you look at it, it does (and should) scale. If you make a 1x1x1 unit cube, and tell Blender that you'd like to work in km, that cube is now 1km x 1km x 1km. If you then change it so you work in cm, that cube is now 1cm x 1cm x 1cm. Essentially, that cube is now way smaller. That's how it's intended to work, and that's how it should work. Otherwise, it'd be impossible to work at very large or very small scales.

Well, that is a pretty strong and clear stated opinion that is in my opinion flat out wrong. But with me being clearly outnumbered here, you having a lot more to do and this being off topic, i will give no more comment on that. For Blender defaults i give my voice for System: metric, Unit: meters.

This was mainly a remark from a technical and CAD user who does have experience of drawing nuts and bolts inside city sized files :) The CAD apps simply do not allow scaling when changing units and do everything in real world size, adjusting viewport navigation and work context to current zoom. It is possible and now i realize, brilliant. But if you say that Blender is not capable of that, again, i will have to trust you. It would in any case, probably take a whole new code quest to venture into Blender's code and put all the system's unit - using parameters into feasible order.

Anyway, you guys are doing a tremendous job, and since @WilliamReynish you are the UX guy i invite you to take a look at another topic probably also out of scope right now but extremely important for the future. I think i suffocated Brecht with my gibberish :)

[[ https://developer.blender.org/T54842#500538 |
https://developer.blender.org/T54842#500538 ]]

> But depending on how you look at it, it does (and should) scale. If you make a 1x1x1 unit cube, and tell Blender that you'd like to work in km, that cube is now 1km x 1km x 1km. If you then change it so you work in cm, that cube is now 1cm x 1cm x 1cm. Essentially, that cube is now way smaller. That's how it's intended to work, and that's how it should work. Otherwise, it'd be impossible to work at very large or very small scales. Well, that is a pretty strong and clear stated opinion that is in my opinion flat out wrong. But with me being clearly outnumbered here, you having a lot more to do and this being off topic, i will give no more comment on that. For Blender defaults i give my voice for System: metric, Unit: meters. This was mainly a remark from a technical and CAD user who does have experience of drawing nuts and bolts inside city sized files :) The CAD apps simply do not allow scaling when changing units and do everything in real world size, adjusting viewport navigation and work context to current zoom. It ***is*** possible and now i realize, brilliant. But if you say that Blender is not capable of that, again, i will have to trust you. It would in any case, probably take a whole new code quest to venture into Blender's code and put all the system's unit - using parameters into feasible order. Anyway, you guys are doing a tremendous job, and since @WilliamReynish you are the UX guy i invite you to take a look at another topic probably also out of scope right now but extremely important for the future. I think i suffocated Brecht with my gibberish :) [[ https://developer.blender.org/T54842#500538 | https://developer.blender.org/T54842#500538 ]]
Contributor

One question: Why have you decided to default background to Sky when Sky in Cycles has remained unfinished in years?

The Sky in Cycles is based on Hosek and Wilkie physical sky model, but that model requires also implementation of a physical sun light, to work with conjunction with it.

Sky in Cycles does not have a Physical Sun light to go with it, and Sky in Cycles does not even have any straightforward way to pick a light source to serve as sunlight and change Sky time of the day based on it (which is the whole point of Hosek and Wilkie physical sky model).

It has very little use in its current state, arguably even less use than solid background color.

One question: Why have you decided to default background to Sky when Sky in Cycles has remained unfinished in years? The Sky in Cycles is based on Hosek and Wilkie physical sky model, but that model requires also implementation of a physical sun light, to work with conjunction with it. Sky in Cycles does not have a Physical Sun light to go with it, and Sky in Cycles does not even have any straightforward way to pick a light source to serve as sunlight and change Sky time of the day based on it (which is the whole point of Hosek and Wilkie physical sky model). It has very little use in its current state, arguably even less use than solid background color.

This comment was removed by @MikhailRachinskiy

*This comment was removed by @MikhailRachinskiy*

Mikhail: There's a difference between the unit scale and the display units. We could add a feature to force a certain display unit, but that feature does not yet exist, and is different from the unit scale.

Mikhail: There's a difference between the *unit scale* and the *display units*. We *could* add a feature to force a certain display unit, but that feature does not yet exist, and is different from the unit scale.

@WilliamReynish I'm not saying unit scale should be removed, I'm saying that to work with different units Blender should move from using unit scale to using display units (or working units like in Maya).

Unit scale will still be available for extreme cases like kilometer scale.

@WilliamReynish I'm not saying unit scale should be removed, I'm saying that to work with different units Blender should move from using unit scale to using display units (or working units like in Maya). Unit scale will still be available for extreme cases like kilometer scale.

Again, that's a feature that does not exist, and it's a separate thing. Off topic.

Again, that's a feature that does not exist, and it's a separate thing. Off topic.
Member

Added subscriber: @pragma37

Added subscriber: @pragma37
Member

In #54943#500792, @WilliamReynish wrote:

In #54943#500784, @JulianEisel wrote:
With Auto Perspective enabled, changing to top/front/side views and then rotating the view always goes back to perspective projection, even if orthographic was set before. Seems to me like this should be addressed first.

That is the intended behavior. It makes it so that artists can fluidly switch from orthographic side views and perspective. You pretty much never want to be in front view without ortho. And it makes it so that when you select a view, either from the view menu, or the viewport manipulator, it does the right thing.

Yeah, but it should remember if you were in ortho view before.

So it would work something like this :

Perpective -> Front (Change to Ortho) -> Rotate view (Change back to Perspective)
Ortho -> Front (Keep Ortho) -> Rotate view (Keep Ortho)

> In #54943#500792, @WilliamReynish wrote: >> In #54943#500784, @JulianEisel wrote: >> With Auto Perspective enabled, changing to top/front/side views and then rotating the view always goes back to perspective projection, even if orthographic was set before. Seems to me like this should be addressed first. > > That is the intended behavior. It makes it so that artists can fluidly switch from orthographic side views and perspective. You pretty much never want to be in front view without ortho. And it makes it so that when you select a view, either from the view menu, or the viewport manipulator, it does the right thing. Yeah, but it should remember if you were in ortho view before. So it would work something like this : Perpective -> Front (Change to Ortho) -> Rotate view (Change back to Perspective) Ortho -> Front (Keep Ortho) -> Rotate view (Keep Ortho)

Indeed and when using ALT to snap to ortho view the view must go in ortho.
Right now it's still in persp.

Auto Perspective should not be an option in fact.

Indeed and when using ALT to snap to ortho view the view must go in ortho. Right now it's still in persp. Auto Perspective should not be an option in fact.

Correct, Aute Perspective fails for some reason if you use the view snapping feature by holding Alt. We should probably fix that.

Correct, Aute Perspective fails for some reason if you use the view snapping feature by holding Alt. We should probably fix that.

That's why I don't use it, I could use 1,3,7 for something else if it was fixed ^^

That's why I don't use it, I could use 1,3,7 for something else if it was fixed ^^

Added subscriber: @ZsoltStefan

Added subscriber: @ZsoltStefan

In #54943#500838, @Okavango wrote:
...
This was mainly a remark from a technical and CAD user who does have experience of drawing nuts and bolts inside city sized files :) The CAD apps simply do not allow scaling when changing units and do everything in real world size, adjusting viewport navigation and work context to current zoom. It is possible and now i realize, brilliant. But if you say that Blender is not capable of that, again, i will have to trust you. It would in any case, probably take a whole new code quest to venture into Blender's code and put all the system's unit - using parameters into feasible order.
...

There is a problem with this, and a reason why Blender works the way it does. I come from a CAD backgroud too, and I have had to get used to this behaviour.

    1. Many settings are hard-coded as a given number of Blender units, which makes scenes with very large objects or very small objects (measured in Blender units) hard to handle. Trying to make eg. a planet by leaving the Blender units as meters, and zooming out a thousandfold to model kilometers in the proper scale (as you would do with a CAD program), doesn't work, or at least you have to adjust a large number of settings. For example: the clipping distance in the viewport, the clipping distance of the camera, falloff values, Texture mapping values, etc. I've found that there is a sort of "sweet spot" in Blender for your model size: it should be between about 1 to 100 Blender units. If it's much smaller it's better to adjust the scale to eg. millimeters, if it's larger maybe kilometers.
    1. Second, and maybe more important: Blender does not have the same numerical precision for coordinates as dedicated CAD programs (double floating-point). Small models (eg 0,0001 units) will not be handled well.
> In #54943#500838, @Okavango wrote: > ... > This was mainly a remark from a technical and CAD user who does have experience of drawing nuts and bolts inside city sized files :) The CAD apps simply do not allow scaling when changing units and do everything in real world size, adjusting viewport navigation and work context to current zoom. It ***is*** possible and now i realize, brilliant. But if you say that Blender is not capable of that, again, i will have to trust you. It would in any case, probably take a whole new code quest to venture into Blender's code and put all the system's unit - using parameters into feasible order. > ... There is a problem with this, and a reason why Blender works the way it does. I come from a CAD backgroud too, and I have had to get used to this behaviour. - 1. Many settings are hard-coded as a given number of Blender units, which makes scenes with very large objects or very small objects (measured in Blender units) hard to handle. Trying to make eg. a planet by leaving the Blender units as meters, and zooming out a thousandfold to model kilometers in the proper scale (as you would do with a CAD program), doesn't work, or at least you have to adjust a large number of settings. For example: the clipping distance in the viewport, the clipping distance of the camera, falloff values, Texture mapping values, etc. I've found that there is a sort of "sweet spot" in Blender for your model size: it should be between about 1 to 100 Blender units. If it's much smaller it's better to adjust the scale to eg. millimeters, if it's larger maybe kilometers. - 2. Second, and maybe more important: Blender does not have the same numerical precision for coordinates as dedicated CAD programs (double floating-point). Small models (eg 0,0001 units) will not be handled well.

Yes, i presumed the problem was along those lines, thank you @ZsoltStefan . The first problem i saw in my mind when considering this was the clipping distance. There are also light calculations, material parameters and who-knows-what.

I was kinda hoping the sheer quality of the crew gathered now in Amsterdam could somehow take a 'swing' at that quality standard. They are already moving some hills around, so to speak ;)

It will happen sometime, i have a feeling that they're not afraid of anything now :)

Yes, i presumed the problem was along those lines, thank you @ZsoltStefan . The first problem i saw in my mind when considering this was the clipping distance. There are also light calculations, material parameters and who-knows-what. I was kinda hoping the sheer quality of the crew gathered now in Amsterdam could somehow take a 'swing' at that quality standard. They are already moving some hills around, so to speak ;) It will happen sometime, i have a feeling that they're not afraid of anything now :)

Added subscriber: @DavidKozma

Added subscriber: @DavidKozma

Ignore me if this was brought up before but could you please turn off curve normals by default?

I was really frightened by those centipedes when I first tried them in Blender.
(Despite the facts that I like insects and have been working professionally with vector graphics for close to 20 years :) )

Ignore me if this was brought up before but could you please turn off curve normals by default? I was really frightened by those centipedes when I first tried them in Blender. (Despite the facts that I like insects and have been working professionally with vector graphics for close to 20 years :) )

Haha, maybe we should :) We son't want to scare away folks with entomophobia.

Haha, maybe we should :) We son't want to scare away folks with entomophobia.

Added subscriber: @Ping

Added subscriber: @Ping

Because I oftenly switching machine using shared accounts at work, I try to always use default settings of blender, so I'm really interested on that topic. I'm definitly not an artist. I'm a developper so I'm using blender to batch some process on meshes using python, set up rendering settings, integrate 3d model in a video using motion tracking and other stuff that not needs very good artistic skills. I do sometimes use my awful modelling skills to make artists works compliant to my developper needs and even to model some simple meshes. That being said, almost all propositions seems good to me, but here are my humble thoughts about the other things...

Preferences

  • Python tooltips OFF: It really make sens but as a developper, I'm really sad ;)
  • Compute Devices ON: Great. Suggestion: what about OpenSubDiv = OpenMP or GLSL compute...

Default settings

  • Render Size Percentage = 100%: I agree with @wiklander and @JulianEisel . If the default settings's purpose is to reduce the number of settings to change when you're working on a project, then, you probably never need to to a 100% rendering at first. I personnaly use a 50% rendering for small scene while customizing samples parameters and 20%-40% for larger scene (or more complicated node materials). So, the 50% seems good to me. And I can't remember the first time I discovered this feature but I'm pretty sure I discovered it because it was setted at 50%. And if you don't know why the produce image is half resolution, I think the natural behaviour is to check at the rendering parameters. Then you see this parameter and understand why, so you're not filling that the result is not consistent.

Layout

  • Default Properties tab = Object Properties: Yes, for me, that totally make sense. But I'm thinking about the renderer choice since it's now in the rendering tab. Because for now, the first action I do in a blender new file is setting the renderer to cycle to get principled node and stuff like that. I guess it's not a problem anymore but I didn't use Eevee on real world project yet so I really don't know if there is no other issues...

New Objects

  • Auto-Smooth Normals = ON: OK but what will be the default angle (30° seems good to me).

Hope this helps...

Because I oftenly switching machine using shared accounts at work, I try to always use default settings of blender, so I'm really interested on that topic. I'm definitly not an artist. I'm a developper so I'm using blender to batch some process on meshes using python, set up rendering settings, integrate 3d model in a video using motion tracking and other stuff that not needs very good artistic skills. I do sometimes use my awful modelling skills to make artists works compliant to my developper needs and even to model some simple meshes. That being said, almost all propositions seems good to me, but here are my humble thoughts about the other things... ## Preferences * Python tooltips OFF: It really make sens but as a developper, I'm really sad ;) * Compute Devices ON: Great. Suggestion: what about OpenSubDiv = OpenMP or GLSL compute... ## Default settings * Render Size Percentage = 100%: I agree with @wiklander and @JulianEisel . If the default settings's purpose is to reduce the number of settings to change when you're working on a project, then, you probably never need to to a 100% rendering at first. I personnaly use a 50% rendering for small scene while customizing samples parameters and 20%-40% for larger scene (or more complicated node materials). So, the 50% seems good to me. And I can't remember the first time I discovered this feature but I'm pretty sure I discovered it because it was setted at 50%. And if you don't know why the produce image is half resolution, I think the natural behaviour is to check at the rendering parameters. Then you see this parameter and understand why, so you're not filling that the result is not consistent. ## Layout * Default Properties tab = Object Properties: Yes, for me, that totally make sense. But I'm thinking about the renderer choice since it's now in the rendering tab. Because for now, the first action I do in a blender new file is setting the renderer to cycle to get principled node and stuff like that. I guess it's not a problem anymore but I didn't use Eevee on real world project yet so I really don't know if there is no other issues... ## New Objects * Auto-Smooth Normals = ON: OK but what will be the default angle (30° seems good to me). Hope this helps...

Python tooltips can be turned on if you are a Python developer. For artists, it's better to keep them off by default.

As for OpenSubdiv, it will be implemented in 2.8 in a different way, so I'm not sure those old preferences will even stay.

As for setting the renderer, we will have a much better default renderer now, so you will already immediately be able to use node-based materials and BSDF's, so the problem you describe will no longer exist.

Auto-Smooth angle has to change to make it useable, yes.

Python tooltips can be turned on if you are a Python developer. For artists, it's better to keep them off by default. As for OpenSubdiv, it will be implemented in 2.8 in a different way, so I'm not sure those old preferences will even stay. As for setting the renderer, we will have a much better default renderer now, so you will already immediately be able to use node-based materials and BSDF's, so the problem you describe will no longer exist. Auto-Smooth angle has to change to make it useable, yes.

Forgot to mention re. the render = 50% thing.

That was a somewhat useful beginner setting back before we had Cycles and viewport preview rendering. Now, to preview your scene, you longer have to press F12 - you can just see it directly in the viewport. So, while that setting had some justification in the past, that justification has vanished in 2.8 after the removal of Blender Internal.

The only thing it does is serve as unneeded hindrance and confusion, because your rendered image is half the size it should be. We should keep the setting, but set it to 100% as a default value. If you really want to render 25%, 50% or even 200%, that should be explicitly set by the user.

Forgot to mention re. the render = 50% thing. That was a somewhat useful beginner setting back before we had Cycles and viewport preview rendering. Now, to preview your scene, you longer have to press F12 - you can just see it directly in the viewport. So, while that setting had some justification in the past, that justification has vanished in 2.8 after the removal of Blender Internal. The only thing it does is serve as unneeded hindrance and confusion, because your rendered image is half the size it should be. We should keep the setting, but set it to 100% as a default value. If you really want to render 25%, 50% or even 200%, that should be explicitly set by the user.

That's a really good point ;)

That's a really good point ;)

Added subscriber: @s12a

Added subscriber: @s12a

This comment was removed by @s12a

*This comment was removed by @s12a*

Added subscriber: @LucianoMunoz

Added subscriber: @LucianoMunoz

Why render display "new window", I thought one of the base ideas of blender was no obstructing overlapping windows... ?
I totally agree with the rest of your defaults, I've set them like this myself for years in 2.79

Why render display "new window", I thought one of the base ideas of blender was no obstructing overlapping windows... ? I totally agree with the rest of your defaults, I've set them like this myself for years in 2.79
Contributor

In #54943#501167, @LucianoMunoz wrote:
Why render display "new window", I thought one of the base ideas of blender was no obstructing overlapping windows... ?
I totally agree with the rest of your defaults, I've set them like this myself for years in 2.79

I absolutely love non-overlapping UIs. One of the reasons I like Blender's UI so much. However, for some reason, I just got accustomed to renderer framebuffer being separate window, so much that I change it even in Blender. I guess the reason for that is that non-preview rendering is something non-interactive. Once you start non-preview render, you can't really edit it much with the rest of the editors, like 3D view or timeline, so you don't want the render to take up your space. It just somehow makes sense to have it as a separate window.

> In #54943#501167, @LucianoMunoz wrote: > Why render display "new window", I thought one of the base ideas of blender was no obstructing overlapping windows... ? > I totally agree with the rest of your defaults, I've set them like this myself for years in 2.79 I absolutely love non-overlapping UIs. One of the reasons I like Blender's UI so much. However, for some reason, I just got accustomed to renderer framebuffer being separate window, so much that I change it even in Blender. I guess the reason for that is that non-preview rendering is something non-interactive. Once you start non-preview render, you can't really edit it much with the rest of the editors, like 3D view or timeline, so you don't want the render to take up your space. It just somehow makes sense to have it as a separate window.

Removed subscriber: @DavidKozma

Removed subscriber: @DavidKozma

Added subscriber: @YAFU

Added subscriber: @YAFU

Hi. I was testing a bit of animation in 2.8, mainly things that fall, and I found the big "Frame number indicator" in new Timeline somewhat distracting when playing animation in viewport. I have disabled "Show Frame number indicator" for Timeline (that is something that I will surely configure by default for me in 2.8). The problem here is that for some users "Frame number indicator" could be useful in Dope Sheet mode (and other modes) since frames are not shown in the bar like in Timeline mode.
Just commenting on that experience. Thank you very much for your hard work.

Hi. I was testing a bit of animation in 2.8, mainly things that fall, and I found the big "Frame number indicator" in new Timeline somewhat distracting when playing animation in viewport. I have disabled "Show Frame number indicator" for Timeline (that is something that I will surely configure by default for me in 2.8). The problem here is that for some users "Frame number indicator" could be useful in Dope Sheet mode (and other modes) since frames are not shown in the bar like in Timeline mode. Just commenting on that experience. Thank you very much for your hard work.

hey also when sliding or creating edge loops the "correct uv's" option should also be default... right?

hey also when sliding or creating edge loops the "correct uv's" option should also be default... right?

Yes, we should do that. Added a section for tools - there are a bunch of tools which need updated defaults.

Yes, we should do that. Added a section for tools - there are a bunch of tools which need updated defaults.

Concerning the transparent header, the text color (for the menu pop-overs):

  • has to have the possibility of changing color depending on the background or
  • have a box around it

It's very easy for it to blend with the current color in the viewport otherwise.

transparent_header_issue.png


Concerning the transparent header, the text color (for the menu pop-overs): - has to have the possibility of changing color depending on the background or - have a box around it It's very easy for it to blend with the current color in the viewport otherwise. ![transparent_header_issue.png](https://archive.blender.org/developer/F3370438/transparent_header_issue.png) ``` ```

It's on the todo :)

It's on the todo :)

Pose mode: relationship lines OFF
?

Pose mode: relationship lines OFF ?

In #54943#503029, @VukGardasevic wrote:
Concerning the transparent header, the text color (for the menu pop-overs):

  • has to have the possibility of changing color depending on the background or
  • have a box around it

It's very easy for it to blend with the current color in the viewport otherwise.

transparent_header_issue.png

They just have to do something like this.
Photoshop_2018-05-11_21-20-44.jpg

> In #54943#503029, @VukGardasevic wrote: > Concerning the transparent header, the text color (for the menu pop-overs): > - has to have the possibility of changing color depending on the background or > - have a box around it > > It's very easy for it to blend with the current color in the viewport otherwise. > > ![transparent_header_issue.png](https://archive.blender.org/developer/F3370438/transparent_header_issue.png) > They just have to do something like this. ![Photoshop_2018-05-11_21-20-44.jpg](https://archive.blender.org/developer/F3370664/Photoshop_2018-05-11_21-20-44.jpg)

Why not use double side as default?
We are not 10 years ago, PC's are far better now.
Or there will be something better than the back faces?

blender_2018-05-16_10-22-58.jpg

Why not use double side as default? We are not 10 years ago, PC's are far better now. Or there will be something better than the back faces? ![blender_2018-05-16_10-22-58.jpg](https://archive.blender.org/developer/F3374320/blender_2018-05-16_10-22-58.jpg)

In #54943#503114, @cedriclepiller wrote:
Why not use double side as default?
We are not 10 years ago, PC's are far better now.
Or there will be something better than the back faces?

We do not use double sided because we are not 10 years ago, non-professional video cards (NVIDIA GT/GTX) no longer have hardware acceleration for double sided, leading to drastic slowdowns.

> In #54943#503114, @cedriclepiller wrote: > Why not use double side as default? > We are not 10 years ago, PC's are far better now. > Or there will be something better than the back faces? We do not use double sided because we are not 10 years ago, non-professional video cards (NVIDIA GT/GTX) no longer have hardware acceleration for double sided, leading to drastic slowdowns.

Added subscriber: @Jeroen-Bakker

Added subscriber: @Jeroen-Bakker

Yes, that was the reason, though now that we have per-pixel shading we can enable it. It's only per-vertex shading where double sided lighting was problematic.

The option doesn't actually do anything in 2.8, and can probably be removed. @Jeroen-Bakker, I think we should change workbench/clay to always flip the shading normal towards the viewer.

Yes, that was the reason, though now that we have per-pixel shading we can enable it. It's only per-vertex shading where double sided lighting was problematic. The option doesn't actually do anything in 2.8, and can probably be removed. @Jeroen-Bakker, I think we should change workbench/clay to always flip the shading normal towards the viewer.
Contributor

I know I am probably old fashioned, but I really like back faces being shaded black, because I can constantly see the normal orientation. When one of the new 3ds Max versions made double sided material drawing default, at it was no longer possible to switch it back, I found that it was not an advantage, but a drawback, as I had to spend time constantly toggling diagnostic shading mode to see orientation of the normals.

I know I am probably old fashioned, but I really like back faces being shaded black, because I can constantly see the normal orientation. When one of the new 3ds Max versions made double sided material drawing default, at it was no longer possible to switch it back, I found that it was not an advantage, but a drawback, as I had to spend time constantly toggling diagnostic shading mode to see orientation of the normals.

Added subscriber: @ManuelGrad

Added subscriber: @ManuelGrad

My 2 Cents on this topic if i may:

Cycles

  • Dithering set to 1 (who wants ugly banding in their render?)
  • Start Resolution set to 128 (feels way smoother to preview)
  • Sun Lamp size set to 0.01 (0.1 is waaay to soft compared to the sun on earth)
  • Auto Refresh on for Image Sequence (current behaviour feels like a bug; if the user really needs this he could turn it on)

UV/Image Editor

  • normalized Coordinates (i mean, come on)
  • 32 bit float on default for New Image (if this isn't ticked than the user is stuck in 8bit land which is not communicated at all!)

Theme

  • Noodle Curving set to 0 (really hard to see whats going on with a bigger nodesetups)

Addons

  • Node Wrangler enabled by default (productivity boost x100)

Keymap

  • Left Mouse Select (please)

Display

  • Draw all Edges on (the current default setting is so confusing for new Users and it's hidden really well)
  • Relationship lines off (visual clutter!)
  • Clipping distance set to a higher delta (why is it set so low anyways?)
  • less arbitrary initial orientation of the 3D View, like the image attached (purely stylistic and subjective)

3dView.JPG

My 2 Cents on this topic if i may: ## Cycles - Dithering set to 1 (who wants ugly banding in their render?) - Start Resolution set to 128 (feels way smoother to preview) - Sun Lamp size set to 0.01 (0.1 is waaay to soft compared to the sun on earth) - Auto Refresh on for Image Sequence (current behaviour feels like a bug; if the user really needs this he could turn it on) ## UV/Image Editor - normalized Coordinates (i mean, come on) - 32 bit float on default for New Image (if this isn't ticked than the user is stuck in 8bit land which is not communicated at all!) ## Theme - Noodle Curving set to 0 (really hard to see whats going on with a bigger nodesetups) ## Addons - Node Wrangler enabled by default (productivity boost x100) ## Keymap - Left Mouse Select (please) ## Display - Draw all Edges on (the current default setting is so confusing for new Users and it's hidden really well) - Relationship lines off (visual clutter!) - Clipping distance set to a higher delta (why is it set so low anyways?) - less arbitrary initial orientation of the 3D View, like the image attached (purely stylistic and subjective) ![3dView.JPG](https://archive.blender.org/developer/F3376960/3dView.JPG)

Manuel: Some good suggestions in there. I added some of them to the list. Will go over them with the team.

For the backface issue, perhaps the best solution is to display it, but significantly dimmed. This way you can still see your mesh, but it's clear that it's a backface. @brecht Would this kind of thing be slow?

Manuel: Some good suggestions in there. I added some of them to the list. Will go over them with the team. For the backface issue, perhaps the best solution is to display it, but significantly dimmed. This way you can still see your mesh, but it's clear that it's a backface. @brecht Would this kind of thing be slow?

Nice to hear! Thank you very much.

Nice to hear! Thank you very much.
Contributor

Added subscriber: @softyoda

Added subscriber: @softyoda
Contributor

Blender browser system bookmarks have already desktop, document, images, music, download, (3D bookmark if there is windows version) , video and fonts. (windows-os)

Blender small browser from install from file don't have yellow part too big (uneusefull) Capture.PNG

Node Wrangler enabled by default.

Blender browser system bookmarks have already desktop, document, images, music, download, (3D bookmark if there is windows version) , video and fonts. (windows-os) Blender small browser from install from file don't have yellow part too big (uneusefull) ![Capture.PNG](https://archive.blender.org/developer/F3378543/Capture.PNG) Node Wrangler enabled by default.

Some addons should be enabled by default.

  • Node Wrangle
  • F2 addon
  • Looptools
  • bsurface
Some addons should be enabled by default. - Node Wrangle - F2 addon - Looptools - bsurface

I wouldnt activate Node Wrangled by default, but i'd steal some of it functions and make them standard, like previewing node outputs (ctrl shift click), lazy connect, or switching nodes, but to me the rest seems kind of messy to have it as a default on, though those functions should definitelly come bundled.

I wouldnt activate Node Wrangled by default, but i'd steal some of it functions and make them standard, like previewing node outputs (ctrl shift click), lazy connect, or switching nodes, but to me the rest seems kind of messy to have it as a default on, though those functions should definitelly come bundled.

In #54943#501103, @WilliamReynish wrote:
Forgot to mention re. the render = 50% thing.

That was a somewhat useful beginner setting back before we had Cycles and viewport preview rendering. Now, to preview your scene, you longer have to press F12 - you can just see it directly in the viewport. So, while that setting had some justification in the past, that justification has vanished in 2.8 after the removal of Blender Internal.

This is a very good point. New tech enables new workflows. I haven't started working with EEVEE yet, looking forward to it though :)

From an affordance point of view, I still think 50% is better. When it also has synergies with sensible defaults and a preview render workflow I think it makes sense to increase the discoverability since it would be used more frequently. When those synergies are gone I yield to the 100% benefits :)

> In #54943#501103, @WilliamReynish wrote: > Forgot to mention re. the render = 50% thing. > > That was a somewhat useful beginner setting back before we had Cycles and viewport preview rendering. Now, to preview your scene, you longer have to press F12 - you can just see it directly in the viewport. So, while that setting had some justification in the past, that justification has vanished in 2.8 after the removal of Blender Internal. This is a very good point. New tech enables new workflows. I haven't started working with EEVEE yet, looking forward to it though :) From an affordance point of view, I still think 50% is better. When it also has synergies with *sensible defaults* and a *preview render workflow* I think it makes sense to increase the discoverability since it would be used more frequently. When those synergies are gone I yield to the 100% benefits :)
Contributor

I see that the proposal to have "Sky" map defaulting as background was indeed removed, as I suggested. I know resources for Code Quest are limited, but I would actually be very happy if Sky map was finally finished with proper Physical Sun light and easy to do linking between Physical Sun and Physical Sky, so that it could indeed become a default. There's already an Omni light present in the factory default Blender scene. That Omni could be replaced by Physical Sun once implemented, and background could default to Physical Sky linked to that sun. So every new user, who would just hit render straight away would get a nice simple day lighting in his scene out of the box :)

It'd look like this (without the plane of course):
PhySky.jpg

I see that the proposal to have "Sky" map defaulting as background was indeed removed, as I suggested. I know resources for Code Quest are limited, but I would actually be very happy if Sky map was finally finished with proper Physical Sun light and easy to do linking between Physical Sun and Physical Sky, so that it could indeed become a default. There's already an Omni light present in the factory default Blender scene. That Omni could be replaced by Physical Sun once implemented, and background could default to Physical Sky linked to that sun. So every new user, who would just hit render straight away would get a nice simple day lighting in his scene out of the box :) It'd look like this (without the plane of course): ![PhySky.jpg](https://archive.blender.org/developer/F3389321/PhySky.jpg)

It would be great to keep Floating windows on top to use the workflow or an option in the preferences.
We have floating windows and we cannot use it since the windows disappear.

stupid_blender.gif

It would be great to keep Floating windows on top to use the workflow or an option in the preferences. We have floating windows and we cannot use it since the windows disappear. ![stupid_blender.gif](https://archive.blender.org/developer/F3390663/stupid_blender.gif)

Added subscriber: @Rickyx

Added subscriber: @Rickyx

In #54943#501167, @LucianoMunoz wrote:
Why render display "new window", I thought one of the base ideas of blender was no obstructing overlapping windows... ?
I totally agree with the rest of your defaults, I've set them like this myself for years in 2.79

I totally agree, this is the first ui paradigm in blender:
https://wiki.blender.org/index.php/Dev:2.5/Source/UI/UIParadigms

For which situations is the user's habit changed and is this exception made?
Are there any examples where the proposed solution is best?

Thank you,
Riccardo

> In #54943#501167, @LucianoMunoz wrote: > Why render display "new window", I thought one of the base ideas of blender was no obstructing overlapping windows... ? > I totally agree with the rest of your defaults, I've set them like this myself for years in 2.79 I totally agree, this is the first ui paradigm in blender: https://wiki.blender.org/index.php/Dev:2.5/Source/UI/UIParadigms For which situations is the user's habit changed and is this exception made? Are there any examples where the proposed solution is best? Thank you, Riccardo

Having filmic by default is IMO a bad idea.

When creating shader you don't want it activated because it will change the colors, saturation etc.

To work shader we create lookdev scenes to make sure everything is correct.
Having a lut directly activated will make everything bad, especially for beginners who will think their renders will be better and will not have the good result.
The color of the shader in the node editor will not be the same as the render.

People should learn the correct way to make renders and shaders.

Having filmic by default is IMO a bad idea. When creating shader you don't want it activated because it will change the colors, saturation etc. To work shader we create lookdev scenes to make sure everything is correct. Having a lut directly activated will make everything bad, especially for beginners who will think their renders will be better and will not have the good result. The color of the shader in the node editor will not be the same as the render. People should learn the correct way to make renders and shaders.

I'm not sure how it would be bad to use a display transform that is closer to what will be in the final render, how else can you judge what the material will actually look like? When creating shaders with a LUT which doesn't properly handle HDR colors, users might avoid them and end up with dull materials in the final render.

As far as I know using the same LUT as the final render is usually considered the "correct way".

I'm not sure how it would be bad to use a display transform that is closer to what will be in the final render, how else can you judge what the material will actually look like? When creating shaders with a LUT which doesn't properly handle HDR colors, users might avoid them and end up with dull materials in the final render. As far as I know using the same LUT as the final render is usually considered the "correct way".

Indeed if you are sure to know wich type of render you want or if you want to match a camera.

I have mixed feelings with filmic on blender, it's like the saint graal of realitic rendering people use as hashtag and they don't know why.

You are the specialist so if it's ok for you, it's ok for me ;)

Indeed if you are sure to know wich type of render you want or if you want to match a camera. I have mixed feelings with filmic on blender, it's like the saint graal of realitic rendering people use as hashtag and they don't know why. You are the specialist so if it's ok for you, it's ok for me ;)

Added subscriber: @ideasman42

Added subscriber: @ideasman42

I noticed: "Pie Menus, Switching modes" is listed.

Does this mean tab key always opens a pie menu instead of toggling edit-mode?

From discussion w/ @WilliamReynish I was under the impression this was not desired behavior and pie menu should only be enabled using sticky keys (hold tab shows pie menu, click to toggle editmode - for eg).

I noticed: *"Pie Menus, Switching modes"* is listed. Does this mean tab key always opens a pie menu instead of toggling edit-mode? From discussion w/ @WilliamReynish I was under the impression this was not desired behavior and pie menu should only be enabled using sticky keys (hold tab shows pie menu, click to toggle editmode - for eg).

Added subscriber: @ViktorJamrich

Added subscriber: @ViktorJamrich

An outsiders opinion if I may:

Bevel

  • Clamp Overlap ON

Rationale

  • When a new user is trying to explore Blender by himself, going through toolbar and trying various tools, after the bevel tool is activated the user tends to drag the mouse rather fast to learn what the tool does. As the bevel tool is very sensitive, the mesh will overlay resulting in user's confusion about the tool's purpose.
  • Even though, I personally in my workflow don't have a use for clamp overlap being off, I am certain that some power users do. However, their Blender knowledge is most likely sufficient to enable it ON if needed.
  • Even though this is not totally comparable, but 'Clamp' is already set to 'ON' by default for other tools, such as 'Loop Cut' and 'Edge Slide'.

Clamp Overlay OFF
Screenshot_208.png

Clamp Overlay ON
Screenshot_209.png

An outsiders opinion if I may: **Bevel** - Clamp Overlap **ON** **Rationale** - When a new user is trying to explore Blender by himself, going through toolbar and trying various tools, after the bevel tool is activated the user tends to drag the mouse rather fast to learn what the tool does. As the bevel tool is very sensitive, the mesh will overlay resulting in user's confusion about the tool's purpose. - Even though, I personally in my workflow don't have a use for clamp overlap being off, I am certain that some power users do. However, their Blender knowledge is most likely sufficient to enable it ON if needed. - Even though this is not totally comparable, but 'Clamp' is already set to 'ON' by default for other tools, such as 'Loop Cut' and 'Edge Slide'. *Clamp Overlay OFF* ![Screenshot_208.png](https://archive.blender.org/developer/F3453643/Screenshot_208.png) *Clamp Overlay ON* ![Screenshot_209.png](https://archive.blender.org/developer/F3453644/Screenshot_209.png)

Make default's viewport simplify settings actually simplified. Like 0.1 of particles, 1 or even 0 subsurf, ...
BQ0o9I7- [x].png

I consider counter-intuitive that those settings are set at the highest level while they are meant to do the opposite.

Also, this has nothing to do here but maybe it would be nice to have something in the UI constantly warning that the viewport is being simplified. Maybe a simple "Simplified" under the "User Persp/Ortho" in the viewport.

Make default's viewport simplify settings actually simplified. Like 0.1 of particles, 1 or even 0 subsurf, ... ![BQ0o9I7- [x].png](https://archive.blender.org/developer/F3465004/BQ0o9I7_1_.png) I consider counter-intuitive that those settings are set at the highest level while they are meant to do the opposite. Also, this has nothing to do here but maybe it would be nice to have something in the UI constantly warning that the viewport is being simplified. Maybe a simple "*Simplified*" under the "*User Persp/Ortho*" in the viewport.

Added subscriber: @DuarteRamos

Added subscriber: @DuarteRamos

Removed subscriber: @DuarteRamos

Removed subscriber: @DuarteRamos

In #54943#504634, @ideasman42 wrote:
I noticed: "Pie Menus, Switching modes" is listed.

Does this mean tab key always opens a pie menu instead of toggling edit-mode?

From discussion w/ @WilliamReynish I was under the impression this was not desired behavior and pie menu should only be enabled using sticky keys (hold tab shows pie menu, click to toggle editmode - for eg).

I believe this should be the behaviour for modes, and hopefully many other things that can be grouped like pie menu for pivots.
in any case, I feel that using the numbers or whatever other combination for modes makes no sense first because blender uses a lot of hotkeys and taking out up to 6 of them for the modes seems bad, while you could have one pie menu.

thanks!

> In #54943#504634, @ideasman42 wrote: > I noticed: *"Pie Menus, Switching modes"* is listed. > > Does this mean tab key always opens a pie menu instead of toggling edit-mode? > > From discussion w/ @WilliamReynish I was under the impression this was not desired behavior and pie menu should only be enabled using sticky keys (hold tab shows pie menu, click to toggle editmode - for eg). I believe this should be the behaviour for modes, and hopefully many other things that can be grouped like pie menu for pivots. in any case, I feel that using the numbers or whatever other combination for modes makes no sense first because blender uses a lot of hotkeys and taking out up to 6 of them for the modes seems bad, while you could have one pie menu. thanks!

Added subscriber: @Zingam

Added subscriber: @Zingam

Please make the defaults have better contrast and clarity. I have checked the currently available themes and many are way too low contrast.
For example make the selected tab/toogle button instead of this Capture1.PNG
more like this
Capture2.PNG
Also toggle buttons could use some 2D/3D effect to emphasize their state.

Please make the defaults have better contrast and clarity. I have checked the currently available themes and many are way too low contrast. For example make the selected tab/toogle button instead of this ![Capture1.PNG](https://archive.blender.org/developer/F3528694/Capture1.PNG) more like this ![Capture2.PNG](https://archive.blender.org/developer/F3528699/Capture2.PNG) Also toggle buttons could use some 2D/3D effect to emphasize their state.
Contributor

Yes, I agree with Mongo, I don't know if there is a voting system to raise the relevance of certain ideas.

In any case I also feel quite lost in this new interface, what disturbs me the most is to have the name of the variable outside its label.

For people with asperger syndrome in particular, it will be much more difficult to find their way around.

Here is what you currently have in place : capture1.JPG

Here is a proposal that seems more readable to me : capture2.JPG

Yes, I agree with Mongo, I don't know if there is a voting system to raise the relevance of certain ideas. In any case I also feel quite lost in this new interface, what disturbs me the most is to have the name of the variable outside its label. For people with asperger syndrome in particular, it will be much more difficult to find their way around. Here is what you currently have in place : ![capture1.JPG](https://archive.blender.org/developer/F3531234/capture1.JPG) Here is a proposal that seems more readable to me : ![capture2.JPG](https://archive.blender.org/developer/F3531239/capture2.JPG)

@softyoda about the vertically centered position of "Location", "Rotation", and "Scale" in your example, i disagree, what if there are more than three values? Lets say 4. Where to put it then? Beside the second? Beside the third? Between the second and third value? This will look really messy! What if you have even more? 15 for example. This would make you scroll down to see what the numbers belong to. My understanding is that we are moving to a cleaner, more organized, and grid based layout and your suggestion would make it worse. You made the X, Y, and Z the same brightened color as the fields you can interact with, suggesting that you can click on them and something happens. Which is not the case afaik. So this makes it even more confusing.
About a subtle divider line, yeah, this could work, maybe as default or as a themable option.

Edit: This discussion seems off topic anyway, no?

@softyoda about the vertically centered position of "Location", "Rotation", and "Scale" in your example, i disagree, what if there are more than three values? Lets say 4. Where to put it then? Beside the second? Beside the third? Between the second and third value? This will look really messy! What if you have even more? 15 for example. This would make you scroll down to see what the numbers belong to. My understanding is that we are moving to a cleaner, more organized, and grid based layout and your suggestion would make it worse. You made the X, Y, and Z the same brightened color as the fields you can interact with, suggesting that you can click on them and something happens. Which is not the case afaik. So this makes it even more confusing. About a subtle divider line, yeah, this could work, maybe as default or as a themable option. Edit: This discussion seems off topic anyway, no?

also it would be really nice and useful to be able to select the attribute (not the value) and to be able to sync it with the graph editor, timeline and dopesheet, so if i select rotation x, it would only show rotation x for the selected object in the mentioned editors, that would ease and fasten the workflow of editing the intended attributes by a lot.

I know it doesnt seem like much but if i have 10 bones selected, having to go and select the property in the graph editor for each one of them and then having solo them to just edit the intended curves takes quite some time.
with this you could just select what you need and edit the keyframes in the synced timeline or graph editor directly.

also it would be really nice and useful to be able to select the attribute (not the value) and to be able to sync it with the graph editor, timeline and dopesheet, so if i select rotation x, it would only show rotation x for the selected object in the mentioned editors, that would ease and fasten the workflow of editing the intended attributes by a lot. I know it doesnt seem like much but if i have 10 bones selected, having to go and select the property in the graph editor for each one of them and then having solo them to just edit the intended curves takes quite some time. with this you could just select what you need and edit the keyframes in the synced timeline or graph editor directly.

You can not make a way to work with subobjects to activate the highlight of the active object?
2 options with connections,
1 only the side stroke of the object, now it is only in object mode.
2 stroke mode and solid illumination.
This mode can be turned off by default.
Colors and thickness should be customizable.
It would look nice and maybe it was.111.png

Preview options and Selection options
Selection previews highlight in yellow, and actual selections highlight in blue. There are two checkboxes for each of these states:
Overlay When on, the highlight includes a translucent overlay on the object. Default=off.
Outline When on, the highlight includes an outline of the object. Default=on.
Turning off both checkboxes for both options is equivalent to turning off the main Selection Preview Highlights checkbox.

GUID-E26D252D-68AB-4451-959A-4038A7A82221.png

You can not make a way to work with subobjects to activate the highlight of the active object? 2 options with connections, 1 only the side stroke of the object, now it is only in object mode. 2 stroke mode and solid illumination. This mode can be turned off by default. Colors and thickness should be customizable. It would look nice and maybe it was.![111.png](https://archive.blender.org/developer/F3533125/111.png) Preview options and Selection options Selection previews highlight in yellow, and actual selections highlight in blue. There are two checkboxes for each of these states: Overlay When on, the highlight includes a translucent overlay on the object. Default=off. Outline When on, the highlight includes an outline of the object. Default=on. Turning off both checkboxes for both options is equivalent to turning off the main Selection Preview Highlights checkbox. ![GUID-E26D252D-68AB-4451-959A-4038A7A82221.png](https://archive.blender.org/developer/F3533167/GUID-E26D252D-68AB-4451-959A-4038A7A82221.png)

There are two checkboxes for each of these states:
Overlay When on, the highlight includes a translucent overlay on the object. Default=off.
A similar option I would like for a blender.
This box select in 3ds max and true 2 settings.
1111aaa.jpg
If the similar is already in 2.8 it will be very good.

There are two checkboxes for each of these states: Overlay When on, the highlight includes a translucent overlay on the object. Default=off. A similar option I would like for a blender. This box select in 3ds max and true 2 settings. ![1111aaa.jpg](https://archive.blender.org/developer/F3533333/1111aaa.jpg) If the similar is already in 2.8 it will be very good.

Added subscriber: @Januz

Added subscriber: @Januz

Make the VSE strips use AlphaOver instead of Cross by default, so transparent areas don't show up black. (suggested in the forums )

Make the VSE strips use AlphaOver instead of Cross by default, so transparent areas don't show up black. ([suggested in the forums ](https://devtalk.blender.org/t/blender-2-8-video-editor-alphaover-by-default/576))

Not sure it fits the defaults settings, but could it be added an option to keep duplicate windows on top?

Since, now, the render is in a new window, it could be useful to keep it visible with an option in the preferences.

Not sure it fits the defaults settings, but could it be added an option to keep duplicate windows on top? Since, now, the render is in a new window, it could be useful to keep it visible with an option in the preferences.

Added subscriber: @TheRedWaxPolice

Added subscriber: @TheRedWaxPolice

In #54943#507566, @cedriclepiller wrote:
Not sure it fits the defaults settings, but could it be added an option to keep duplicate windows on top?

Since, now, the render is in a new window, it could be useful to keep it visible with an option in the preferences.

Definitely. Floating windows needs to stay on top.

> In #54943#507566, @cedriclepiller wrote: > Not sure it fits the defaults settings, but could it be added an option to keep duplicate windows on top? > > Since, now, the render is in a new window, it could be useful to keep it visible with an option in the preferences. Definitely. Floating windows needs to stay on top.

They should, yes. Currently, Blenders has no way to distinguish the various windows, but we are aware of the issue, and it can be solved.

They should, yes. Currently, Blenders has no way to distinguish the various windows, but we are aware of the issue, and it can be solved.

In #54943#508025, @WilliamReynish wrote:
They should, yes. Currently, Blenders has no way to distinguish the various windows, but we are aware of the issue, and it can be solved.

Great news.

Cheers...

> In #54943#508025, @WilliamReynish wrote: > They should, yes. Currently, Blenders has no way to distinguish the various windows, but we are aware of the issue, and it can be solved. Great news. Cheers...

In #54943#508025, @WilliamReynish wrote:
They should, yes. Currently, Blenders has no way to distinguish the various windows, but we are aware of the issue, and it can be solved.

What would be the logic for solving this?

For preferences it's obvious, for two windows each the same size on a different monitor - its not. maybe this should get its own design task.

> In #54943#508025, @WilliamReynish wrote: > They should, yes. Currently, Blenders has no way to distinguish the various windows, but we are aware of the issue, and it can be solved. What would be the logic for solving this? For preferences it's obvious, for two windows each the same size on a different monitor - its not. maybe this should get its own design task.

In #54943#508047, @ideasman42 wrote:

In #54943#508025, @WilliamReynish wrote:
They should, yes. Currently, Blenders has no way to distinguish the various windows, but we are aware of the issue, and it can be solved.

What would be the logic for solving this?

For preferences it's obvious, for two windows each the same size on a different monitor - its not. maybe this should get its own design task.

Well, why overcomplicate things? The base window sits at the bottom and everything that comes after that sits on top of that, no?
I don't care too much about floating things on my main window ... but it would be nice if Blender could work on multiple screens without the windows disappearing behind each other and the need for occasional double clicks when switching windows.

> In #54943#508047, @ideasman42 wrote: >> In #54943#508025, @WilliamReynish wrote: >> They should, yes. Currently, Blenders has no way to distinguish the various windows, but we are aware of the issue, and it can be solved. > > > What would be the logic for solving this? > > For preferences it's obvious, for two windows each the same size on a different monitor - its not. maybe this should get its own design task. Well, why overcomplicate things? The base window sits at the bottom and everything that comes after that sits on top of that, no? I don't care too much about floating things on my main window ... but it would be nice if Blender could work on multiple screens without the windows disappearing behind each other and the need for occasional double clicks when switching windows.
Contributor

In #54943#508047, @ideasman42 wrote:

In #54943#508025, @WilliamReynish wrote:
They should, yes. Currently, Blenders has no way to distinguish the various windows, but we are aware of the issue, and it can be solved.

What would be the logic for solving this?

For preferences it's obvious, for two windows each the same size on a different monitor - its not. maybe this should get its own design task.

I think what most people request is a simple window parenting. The first window which opens after launching Blender executable is a parent Window, and any window opened after it is a child window. Children windows have following behavior:

1, They are always displayed on top of the parent window.
2, Their focus is defined by the focus of parent window. If parent window is in focus, all children windows are in focus as well. This also solves the dual monitor issue.
3, Closing parent window closes all the children windows as well. Therefore, closing the parent window exits Blender instead of keeping the children windows open.

I don't see how floating user preferences window is any different than large window on a second monitor. If you move floating user preferences window to a second monitor and maximize it, then that's precisely the same thing.

> In #54943#508047, @ideasman42 wrote: >> In #54943#508025, @WilliamReynish wrote: >> They should, yes. Currently, Blenders has no way to distinguish the various windows, but we are aware of the issue, and it can be solved. > > > What would be the logic for solving this? > > For preferences it's obvious, for two windows each the same size on a different monitor - its not. maybe this should get its own design task. I think what most people request is a simple window parenting. The first window which opens after launching Blender executable is a parent Window, and any window opened after it is a child window. Children windows have following behavior: 1, They are always displayed on top of the parent window. 2, Their focus is defined by the focus of parent window. If parent window is in focus, all children windows are in focus as well. This also solves the dual monitor issue. 3, Closing parent window closes all the children windows as well. Therefore, closing the parent window exits Blender instead of keeping the children windows open. I don't see how floating user preferences window is any different than large window on a second monitor. If you move floating user preferences window to a second monitor and maximize it, then that's precisely the same thing.

Animation Timeout for pies should be lowered from 6 to maybe 2 or 3. Since the gesture can be done fast there are cases when the pie is still expanding in the animation, which can look a bit messy.

**Animation Timeout** for pies should be lowered from 6 to maybe 2 or 3. Since the gesture can be done fast there are cases when the pie is still expanding in the animation, which can look a bit messy.

+1 for a fix on floating windows ^^

Could it be possible to add an option to show directly the HSV?

image.png

+1 for a fix on floating windows ^^ Could it be possible to add an option to show directly the HSV? ![image.png](https://archive.blender.org/developer/F3634082/image.png)

Added subscriber: @JonDoe286

Added subscriber: @JonDoe286

Ill have to say that search should be spacebar again, its the only way that no matter what keyboard youre in, youll have it in front of you, it was one of the first things everyone teaches including me to their students because you can use it to learn hotkeys, or to find obscure things that regularly dont use.
with the tilde key that you chose, in my spanish keyboard i have no access to spacebar by default and i bet it happens to many other people.
also having that toolbar in the spacebar is very very very reduntant.
thanks guys. loving 2.8

Ill have to say that search should be spacebar again, its the only way that no matter what keyboard youre in, youll have it in front of you, it was one of the first things everyone teaches including me to their students because you can use it to learn hotkeys, or to find obscure things that regularly dont use. with the tilde key that you chose, in my spanish keyboard i have no access to spacebar by default and i bet it happens to many other people. also having that toolbar in the spacebar is very very very reduntant. thanks guys. loving 2.8

@LucianoMunoz I think your comment about search is more related to this task: https://developer.blender.org/T55162
I've made a proposal there to give it more discoveravility in the UI

@LucianoMunoz I think your comment about search is more related to this task: https://developer.blender.org/T55162 I've made a proposal there to give it more discoveravility in the UI

Added subscriber: @gobb_blend

Added subscriber: @gobb_blend

First time poster here.
I was absolutely shocked to see that you had made 'metric' the default unit system for Blender 2.8, and I was wondering if that decision was really final and widely approved by everyone, or if there was still a chance that you might change it back.
In my opinion, the metric units only require the user to do unnecessary calculations in their head, and they make typing very confusing. For example:

  1. type "1000", press Return, get "1". (km)
  2. type "0.001", press Return, get "1". (mm)
    I am bombarded with a range of different units. km, m, cm, mm.....
    If I wanted to work in millimeters, I'd have to calculate the correct decimal number in units in my head and then enter that, or I'd be forced to actually type the letters "mm" each time I change a value. Why would I ever want to type letters into a number field anyway?

I'm a game developer. Like most 3D artists, I think in abstract units. A unit can be anything I want. A tiny minority of blender users are architects who may approve of metric units as the default. Why cater to them and basically ruin usability for everybody else? (At least that is how I feel about this.) IMHO the only way to go are Blender units as the default setting. And wouldn't it also be a good idea to get rid of those excess decimal places when they're all zero?
units_.jpg
(I don't know how to best make myself heard in this place, so I made that clickbaity picture for you. I'm sorry.)

First time poster here. I was absolutely shocked to see that you had made 'metric' the default unit system for Blender 2.8, and I was wondering if that decision was really final and widely approved by everyone, or if there was still a chance that you might change it back. In my opinion, the metric units only require the user to do unnecessary calculations in their head, and they make typing very confusing. For example: 1) type "1000", press Return, get "1". (km) 2) type "0.001", press Return, get "1". (mm) I am bombarded with a range of different units. km, m, cm, mm..... If I wanted to work in millimeters, I'd have to calculate the correct decimal number in units in my head and then enter that, or I'd be forced to actually type the letters "mm" each time I change a value. Why would I ever want to type letters into a number field anyway? I'm a game developer. Like most 3D artists, I think in abstract units. A unit can be anything I want. A tiny minority of blender users are architects who may approve of metric units as the default. Why cater to them and basically ruin usability for everybody else? (At least that is how I feel about this.) IMHO the only way to go are Blender units as the default setting. And wouldn't it also be a good idea to get rid of those excess decimal places when they're all zero? ![units_.jpg](https://archive.blender.org/developer/F3836337/units_.jpg) (I don't know how to best make myself heard in this place, so I made that clickbaity picture for you. I'm sorry.)

Added subscriber: @ChristopherAnderssarian

Added subscriber: @ChristopherAnderssarian

@gobb_blend As to if the metric system being the default; probably.

As to the units; it starts here:

In #54943#500001, @Ghostil wrote:
1 In the new version, can presets be saved for default settings in all sections?
2 when resizing for example by cm, the dimensions will always be measured in cm, and not as now 100 cm automatically converted to 1 m?
3 Can I fine-tune the accuracy of a semi-comma
1.0cm 1.00cm 1.000cm size?

And (in my view at least) it ends here:

In #54943#500744, @brecht wrote:
For units, there could an additional option for a preferred display unit (so that it e.g. always uses cm unless the number is outside the 0.0001cm to 10000.0cm range and it becomes ridiculously long). But that's not a change to the default setttings and seems off topic here.

Happy Reading!!!

@gobb_blend As to if the metric system being the default; probably. As to the units; it starts here: > In #54943#500001, @Ghostil wrote: > 1 In the new version, can presets be saved for default settings in all sections? > 2 when resizing for example by cm, the dimensions will always be measured in cm, and not as now 100 cm automatically converted to 1 m? > 3 Can I fine-tune the accuracy of a semi-comma > 1.0cm 1.00cm 1.000cm size? And (in my view at least) it ends here: > In #54943#500744, @brecht wrote: > For units, there could an additional option for a preferred display unit (so that it e.g. always uses cm unless the number is outside the 0.0001cm to 10000.0cm range and it becomes ridiculously long). But that's not a change to the default setttings and seems off topic here. *Happy Reading!!!*

RGB color can be made as in all editors by whole values?
Red 255
Green 255
Blue 255 = White color!
111qqqq.jpg

RGB color can be made as in all editors by whole values? Red 255 Green 255 Blue 255 = White color! ![111qqqq.jpg](https://archive.blender.org/developer/F3836828/111qqqq.jpg)

@Ghostil only when it's 8bit/channel then.

@Ghostil only when it's 8bit/channel then.

Smoothing groups will not add normal as in 3d max?
If you make a model in some kind of game, these groups are often used, and they are not normally exported from the blender.

Smoothing groups will not add normal as in 3d max? If you make a model in some kind of game, these groups are often used, and they are not normally exported from the blender.

Yo @ideasman42 and @WilliamReynish Can we have a brush as an active tool in sculpt mode instead of the cursor as an active tool?

Yo @ideasman42 and @WilliamReynish Can we have a brush as an active tool in sculpt mode instead of the cursor as an active tool?

Added subscriber: @william-70

Added subscriber: @william-70

The 3D cursor tool will be removed from Sculpt mode.

The 3D cursor tool will be removed from Sculpt mode.

In #54943#514663, @WilliamReynish wrote:
The 3D cursor tool will be removed from Sculpt mode.

Please don't remove it yet, let wait till Grease Pencils lands in Blender2.8, we sculptors like to use GP as a tool in sculpt mode to define some forms, if using GP will need the cursor, removing the cursor will be a lost. This is what I m talking about https://youtu.be/714RowiBKsk

> In #54943#514663, @WilliamReynish wrote: > The 3D cursor tool will be removed from Sculpt mode. Please don't remove it yet, let wait till Grease Pencils lands in Blender2.8, we sculptors like to use GP as a tool in sculpt mode to define some forms, if using GP will need the cursor, removing the cursor will be a lost. This is what I m talking about https://youtu.be/714RowiBKsk

Hi. I think that Translate/Move widget should be by default instead of Cursor. Sorry if that was the plan, but I found nothing about it above.

Edit:
I did not mention Transform widget because it could be a bit heavy for the view to have it by default.

Hi. I think that Translate/Move widget should be by default instead of Cursor. Sorry if that was the plan, but I found nothing about it above. Edit: I did not mention Transform widget because it could be a bit heavy for the view to have it by default.

Added subscriber: @renderhjs

Added subscriber: @renderhjs

Just a small suggestion about the cycles rendering performance settings: It would be great to have different default tile size when switching the device (CPU <-> GPU).

Just a small suggestion about the cycles rendering performance settings: It would be great to have different default tile size when switching the device (CPU <-> GPU).

I suggest to have, in the user preferences, Zoom to mouse position active:

  • beginners can move around without learning how to pan (they should but right after...)
  • experienced users, coming from other software, can recover what they already know ( it is a standard behavior for 2d and 3d software to have the mouse zooming towards his position)
  • experienced Blender users often activate this option
  • about usability: you merge two actions (zoom and pan) into one.

I can't see any particular side effect on having it on by default.

Thank you,
Riccardo

I suggest to have, in the user preferences, **Zoom to mouse position** active: * beginners can move around without learning how to pan (they should but right after...) * experienced users, coming from other software, can recover what they already know ( it is a standard behavior for 2d and 3d software to have the mouse zooming towards his position) * experienced Blender users often activate this option * about usability: you merge two actions (zoom and pan) into one. I can't see any particular side effect on having it on by default. Thank you, Riccardo

Removed subscriber: @gobb_blend

Removed subscriber: @gobb_blend

Added subscriber: @DanPool

Added subscriber: @DanPool

The Cursor tool should be indicated in the interface on start. Right now when you start blender, Cursor is the active tool, but the tool isn't highlighted and the settings aren't displayed in the top bar.

The Cursor tool should be indicated in the interface on start. Right now when you start blender, Cursor is the active tool, but the tool isn't highlighted and the settings aren't displayed in the top bar.

A few suggestions if I may. They make sense for my use cases, but I'm not sure how they alight with the global vision or everyone else's workflow.

  • Empty object size to smaller value - Maybe 0.1 units for both empties and group instances? Working with the (officially recommended ?) metric scale where 1 BU = 1m, I rarely need empties that large, even for a human sized character or say a car.
  • Consistent shader node options - Properties for Cycles nodes added through the Properties Window > Materials don't match the same node added through the Node Editor, for example glossy roughness is 0 for the former but 0.2 for the later. This was already implemente, thanks a lot.
  • Consistent add slot behavior - When adding a new particle slot no new particle system should be created automatically (like no materials are created when adding material slots), particle systems are more critical for being resource heavy and potentially slow, so care should be taken not to add them lightly. It also quickly pollutes the list with useless stubs when there is a button below for this purpose.
  • Always respect the Link Materials To: option - When adding a new material to an object without slots directly through the + New button in the Properties Window the option set in User Preferences > Editing > Link Materials To: Object is not respected and materials are always linked to Object Data regardless, unlike when adding an empty slot first. Maybe materials could actually by default be linked to Object anyway, since it is the most flexible option.
  • Particle Scale 1 - By default particle size is set 0.05, assuming the user didn't model them to scale, which if he did will either get too small or be invisible, misleading the user to think it is not not working.
  • Auto Offset nodes to the left - The reason being node trees flow from left to right where the rightmost element is generally the "output" (Materials for shader trees, or Composite for post production), which is the immutable part of most trees, being there 99% of the time; unlike the rest which may grow or shrink and vary wildly between trees. By offsetting to the left instead the common outputs part will in all likelihood remain at the same relative spot in "Node World Space" between different trees, if unchanged by the user. This can be extremely convenient when switching often between similarly structured trees (like materials) leaving related elements at about the same place, potentially greatly reducing the need to constantly pan and adjust the view back and forth.

I'd like to hear your opinions. Not sure if everyone else agrees with these, or even if they are feasible or easy to implement, so I'll leave them for your consideration.

A few suggestions if I may. They make sense for my use cases, but I'm not sure how they alight with the global vision or everyone else's workflow. - **Empty object size to smaller value** - Maybe 0.1 units for both empties and group instances? Working with the (officially recommended ?) metric scale where 1 BU = 1m, I rarely need empties that large, even for a human sized character or say a car. - ~~**Consistent shader node options** - Properties for Cycles nodes added through the *Properties Window > Materials* don't match the same node added through the *Node Editor*, for example glossy roughness is 0 for the former but 0.2 for the later.~~ This was already implemente, thanks a lot. - **Consistent add slot behavior** - When adding a new particle slot no new particle system should be created automatically (like no materials are created when adding material slots), particle systems are more critical for being resource heavy and potentially slow, so care should be taken not to add them lightly. It also quickly pollutes the list with useless stubs when there is a button below for this purpose. - **Always respect the *Link Materials To:* option** - When adding a new material to an object without slots directly through the `+ New` button in the Properties Window the option set in *User Preferences > Editing > Link Materials To: Object* is not respected and materials are always linked to *Object Data* regardless, unlike when adding an empty slot first. Maybe materials could actually by default be linked to *Object* anyway, since it is the most flexible option. - **Particle Scale 1** - By default particle size is set 0.05, assuming the user didn't model them to scale, which if he did will either get too small or be invisible, misleading the user to think it is not not working. - **Auto Offset nodes to the left** - The reason being node trees flow from left to right where the rightmost element is generally the "output" (*Materials* for shader trees, or *Composite* for post production), which is the immutable part of most trees, being there 99% of the time; unlike the rest which may grow or shrink and vary wildly between trees. By offsetting to the left instead the common outputs part will in all likelihood remain at the same relative spot in "Node World Space" between different trees, if unchanged by the user. This can be extremely convenient when switching often between similarly structured trees (like materials) leaving related elements at about the same place, potentially greatly reducing the need to constantly pan and adjust the view back and forth. I'd like to hear your opinions. Not sure if everyone else agrees with these, or even if they are feasible or easy to implement, so I'll leave them for your consideration.

Added subscriber: @DuarteRamos

Added subscriber: @DuarteRamos

@DuarteRamos i totally second these improvements :), same with what @DanPool says.

@DuarteRamos i totally second these improvements :), same with what @DanPool says.

In #54943#523060, @DanPool wrote:
The Cursor tool should be indicated in the interface on start. Right now when you start blender, Cursor is the active tool, but the tool isn't highlighted and the settings aren't displayed in the top bar.

This is a bug, rather than a default.

> In #54943#523060, @DanPool wrote: > The Cursor tool should be indicated in the interface on start. Right now when you start blender, Cursor is the active tool, but the tool isn't highlighted and the settings aren't displayed in the top bar. This is a bug, rather than a default.

I do agree with @DuarteRamos , specially point 1, 3 and 5.
Personally I like materials to be linked to data.

I do agree with @DuarteRamos , specially point 1, 3 and 5. Personally I like materials to be linked to data.

Duarte: I agree with most of your points, I will go over them with some of the other guys on IRC.

Duarte: I agree with most of your points, I will go over them with some of the other guys on IRC.

Added subscriber: @troy_s

Added subscriber: @troy_s

Any chance of changing the cancerous format known as PNG to OpenEXR half with DWA for default? PNG compounds the accumulating alpha problems, as well as makes things very challenging moving forwards with proper scene referred streamlining.

In #54943#514635, @Ghostil wrote:
RGB color can be made as in all editors by whole values?
Red 255
Green 255
Blue 255 = White color!

Except this isn't how colour works, so a Very Bad Idea™.

Any chance of changing the cancerous format known as PNG to OpenEXR half with DWA for default? PNG compounds the accumulating alpha problems, as well as makes things very challenging moving forwards with proper scene referred streamlining. > In #54943#514635, @Ghostil wrote: > RGB color can be made as in all editors by whole values? > Red 255 > Green 255 > Blue 255 = White color! Except this isn't how colour works, so a Very Bad Idea™.
Member

Removed subscriber: @pragma37

Removed subscriber: @pragma37

In the Graph Editor, set the "Only Selected Keyframes Handles" off by default (or, at least in the animation workspaces).

UDW08UQ- [x].png

Currently, this option is On, so all the handles are hidden till the keyframe is selected. Meaning we can't select a particular handle and manipulate it in one click. We must select the key first, then unselect the unwanted parts, then manipulate. This is already quite long to do for a single handle, so imagine how it is when you need to manipulate several handles at once. I.E. I want to select all the entry handles of several keys and move them around.

TL;DR, this option enabled makes everything slower.

The only reasons I can think of why this option is On by default is for performance (I guess it's faster to update the Graph is there isn't handles everywhere) and to not clutter the view. And those are considerable choices. But IMO, for an efficient animation workflow, displaying those handles is more important.

In the Graph Editor, set the "Only Selected Keyframes Handles" off by default (or, at least in the animation workspaces). ![UDW08UQ- [x].png](https://archive.blender.org/developer/F4874953/UDW08UQ_1_.png) Currently, this option is On, so all the handles are hidden till the keyframe is selected. Meaning we can't select a particular handle and manipulate it in one click. We must select the key first, then unselect the unwanted parts, then manipulate. This is already quite long to do for a single handle, so imagine how it is when you need to manipulate several handles at once. I.E. I want to select all the entry handles of several keys and move them around. TL;DR, this option enabled makes everything slower. The only reasons I can think of why this option is On by default is for performance (I guess it's faster to update the Graph is there isn't handles everywhere) and to not clutter the view. And those are considerable choices. But IMO, for an efficient animation workflow, displaying those handles is more important.

Is it possible to have a new Spot Light preset included by default?

Is it possible to have a new Spot Light preset included by default?

What does that even mean?

What does that even mean?

In #54943#538552, @L0Lock wrote:
In the Graph Editor, set the "Only Selected Keyframes Handles" off by default (or, at least in the animation workspaces).

UDW08UQ- [x].png

Currently, this option is On, so all the handles are hidden till the keyframe is selected. Meaning we can't select a particular handle and manipulate it in one click. We must select the key first, then unselect the unwanted parts, then manipulate. This is already quite long to do for a single handle, so imagine how it is when you need to manipulate several handles at once. I.E. I want to select all the entry handles of several keys and move them around.

TL;DR, this option enabled makes everything slower.

The only reasons I can think of why this option is On by default is for performance (I guess it's faster to update the Graph is there isn't handles everywhere) and to not clutter the view. And those are considerable choices. But IMO, for an efficient animation workflow, displaying those handles is more important.

actually yes i think one of the reasons is performans, because its not a marginal hit in it, its actually quite big, a scene that can be running realtime, can easily go down to 1 or 2 fps.
to that I actually use "only show selected curves keyframes" so it will basically filter the curves by just clicking on the channel which is great behaviour.
things that should be addressed are the inconsistency with the channel colors, sometimes its rgb, sometimes some pastel colors sometimes no color whatsoever, it would be nice if XYZ is always RGB always, and W in the case of quaternions would have an other color, because it tends to be confusing and hard to read.

> In #54943#538552, @L0Lock wrote: > In the Graph Editor, set the "Only Selected Keyframes Handles" off by default (or, at least in the animation workspaces). > > ![UDW08UQ- [x].png](https://archive.blender.org/developer/F4874953/UDW08UQ_1_.png) > > Currently, this option is On, so all the handles are hidden till the keyframe is selected. Meaning we can't select a particular handle and manipulate it in one click. We must select the key first, then unselect the unwanted parts, then manipulate. This is already quite long to do for a single handle, so imagine how it is when you need to manipulate several handles at once. I.E. I want to select all the entry handles of several keys and move them around. > > TL;DR, this option enabled makes everything slower. > > The only reasons I can think of why this option is On by default is for performance (I guess it's faster to update the Graph is there isn't handles everywhere) and to not clutter the view. And those are considerable choices. But IMO, for an efficient animation workflow, displaying those handles is more important. actually yes i think one of the reasons is performans, because its not a marginal hit in it, its actually quite big, a scene that can be running realtime, can easily go down to 1 or 2 fps. to that I actually use "only show selected curves keyframes" so it will basically filter the curves by just clicking on the channel which is great behaviour. things that should be addressed are the inconsistency with the channel colors, sometimes its rgb, sometimes some pastel colors sometimes no color whatsoever, it would be nice if XYZ is always RGB always, and W in the case of quaternions would have an other color, because it tends to be confusing and hard to read.

@WilliamReynish Sorry, I didn't explain it well...
Is a very popular and useful type of light setup which consists of a light and a target object (usually an empty object). That light is always pointing at the target wherever you move the target or the light.
2018-10-08_03-36-58.gif
And since this setup is very popular but usually takes some steps to make it, some 3d packages already includes it by default, often they call it "target light" or something similar.

In Blender to achieve this you need to create a light (usually a spot light) and an empty object (plain axis is the favorite for this), then you select the spot light and add a "track to" constraint to it. Next, in the "track to" constraint settings you choose the empty object we created as the target, then set the "To" parameter to "Z" axis, and then set the "Up" parameter to "Y".
After this, the setup is done, but that's quite a lot of steps as you can see, that's why other apps are providing this setup as a separate type of light.
Also when creating this type of light it usually appears more or less in the following position already, with the empty object in the center of the world.
image.png

So it would be great if Blender could offer this setup in one click as a light type as well, it's very useful.
I'm not sure if such kind of "preset" system exists in Blender tho... but yeah, would be nice...

@WilliamReynish Sorry, I didn't explain it well... Is a very popular and useful type of light setup which consists of a light and a target object (usually an empty object). That light is always pointing at the target wherever you move the target or the light. ![2018-10-08_03-36-58.gif](https://archive.blender.org/developer/F4982696/2018-10-08_03-36-58.gif) And since this setup is very popular but usually takes some steps to make it, some 3d packages already includes it by default, often they call it "target light" or something similar. In Blender to achieve this you need to create a light (usually a spot light) and an empty object (plain axis is the favorite for this), then you select the spot light and add a "track to" constraint to it. Next, in the "track to" constraint settings you choose the empty object we created as the target, then set the "To" parameter to "Z" axis, and then set the "Up" parameter to "Y". After this, the setup is done, but that's quite a lot of steps as you can see, that's why other apps are providing this setup as a separate type of light. Also when creating this type of light it usually appears more or less in the following position already, with the empty object in the center of the world. ![image.png](https://archive.blender.org/developer/F4982726/image.png) So it would be great if Blender could offer this setup in one click as a light type as well, it's very useful. I'm not sure if such kind of "preset" system exists in Blender tho... but yeah, would be nice...

Added subscriber: @zeauro

Added subscriber: @zeauro

@TheRedWaxPolice , what you are asking for is already there. It is just buggy (It does not always work at first try.).
That is the yellow point.
Yellow_Point.jpg
It can be overlapped by cone angle arrow.
That is the first gizmo done to demonstrate them.
Lamps gizmo design should be improved. But everybody agree with that idea of a target for lamp direction.

@TheRedWaxPolice , what you are asking for is already there. It is just buggy (It does not always work at first try.). That is the yellow point. ![Yellow_Point.jpg](https://archive.blender.org/developer/F4984897/Yellow_Point.jpg) It can be overlapped by cone angle arrow. That is the first gizmo done to demonstrate them. Lamps gizmo design should be improved. But everybody agree with that idea of a target for lamp direction.

Added subscriber: @DotBow

Added subscriber: @DotBow

Is there possibility to change Select Linked to Shift + RMB Double Click and Select Linked All to RMB Double Click in case of user-friendly selecting workflow? I mean make it as default shortcuts, because now there is no easy way to discover how to select whole complements of the mesh.

Is there possibility to change **Select Linked** to **Shift + RMB Double Click** and **Select Linked All** to **RMB Double Click** in case of user-friendly selecting workflow? I mean make it as default shortcuts, because now there is no easy way to discover how to select whole complements of the mesh.

Shift L is used to enable Deselect option of Select Linked.
If you only change shortcut to shift+RMB Double click, you loose the ability to deselect.

Ctrl RMB -> Pick Shortest Path
Shit Ctrl RMB -> Pick Shortest Path Fill Region option
Alt RMB -> Select Loop
Ctrl Alt RMB -> Select Ring
Shift RMB -> Extend selection
Shift Alt RMB -> Extend Select Loop
Shit Ctrl Alt RMB -> Extend Select Ring

It may be weird but it does not hurt to re-use extend shortcuts for that. We could imagine Shift Alt RMB double click to deselect.
But if operator could understand that hovering selected elements means deselect and hovering unselected elements means select and hovering an empty space means select all.
We could be fine with just one RMB Double click shortcut.

Shift L is used to enable Deselect option of Select Linked. If you only change shortcut to shift+RMB Double click, you loose the ability to deselect. Ctrl RMB -> Pick Shortest Path Shit Ctrl RMB -> Pick Shortest Path Fill Region option Alt RMB -> Select Loop Ctrl Alt RMB -> Select Ring Shift RMB -> Extend selection Shift Alt RMB -> Extend Select Loop Shit Ctrl Alt RMB -> Extend Select Ring It may be weird but it does not hurt to re-use extend shortcuts for that. We could imagine Shift Alt RMB double click to deselect. But if operator could understand that hovering selected elements means deselect and hovering unselected elements means select and hovering an empty space means select all. We could be fine with just one RMB Double click shortcut.

Select Linked to Shift + RMB Double Click needed because then you can add it to selection, either way it will deselect everything before it.

**Select Linked to Shift + RMB Double Click** needed because then you can add it to selection, either way it will deselect everything before it.

TheRedWaxPolice: What you are asking for is not really a default setting per se. It's an asset. When the Asset Manager eventually arrives, we will start to flesh out a system to include built-in assets. But before that happens, we have no built-in way to store and browse them, so we can't include any until then.

TheRedWaxPolice: What you are asking for is not really a default setting per se. It's an asset. When the Asset Manager eventually arrives, we will start to flesh out a system to include built-in assets. But before that happens, we have no built-in way to store and browse them, so we can't include any until then.

zeauro: Nice feature, but quite different from the idea of a target light... But thanks for pointing that out.

billreynish: It can be considered a built-in asset, yeah. Too bad there's not a way to store this type of information built-in at moment. I'm wondering if it could be done with a python script... ?

**zeauro:** Nice feature, but quite different from the idea of a target light... But thanks for pointing that out. **billreynish:** It can be considered a built-in asset, yeah. Too bad there's not a way to store this type of information built-in at moment. I'm wondering if it could be done with a python script... ?
Contributor

One of the defaults that definitely should be changed for 2.8 is that "Release confirms" in Preferences should be off. Current state has this really weird behavior where if you drag an item, it sticks to your mouse until you click again to drop it. This feels much more like a bug or mouse malfunction rather than a feature.

One of the defaults that definitely should be changed for 2.8 is that "Release confirms" in Preferences should be off. Current state has this really weird behavior where if you drag an item, it sticks to your mouse until you click again to drop it. This feels much more like a bug or mouse malfunction rather than a feature.

Ludvik: I don't know what you mean. Release already confirms. If you enable the Move tool and drag, releasing then confirms the movement.

Ludvik: I don't know what you mean. Release already confirms. If you enable the Move tool and drag, releasing then confirms the movement.

In #54943#541195, @Rawalanche wrote:
One of the defaults that definitely should be changed for 2.8 is that "Release confirms" in Preferences should be off. Current state has this really weird behavior where if you drag an item, it sticks to your mouse until you click again to drop it. This feels much more like a bug or mouse malfunction rather than a feature.

This feature is actually disabled by default, that's why stuff sticks to the mouse. But yes, it should come enabled by default, as it is really an unexpected behavior.

William Reynish: This seem to only happen when you move things with the RMB.

> In #54943#541195, @Rawalanche wrote: > One of the defaults that definitely should be changed for 2.8 is that "Release confirms" in Preferences should be off. Current state has this really weird behavior where if you drag an item, it sticks to your mouse until you click again to drop it. This feels much more like a bug or mouse malfunction rather than a feature. This feature is actually disabled by default, that's why stuff sticks to the mouse. But yes, it should come enabled by default, as it is really an unexpected behavior. **William Reynish:** This seem to only happen when you move things with the RMB.

Removed subscriber: @troy_s

Removed subscriber: @troy_s

rawalanche , Hi.

If you are referring to Grab and not to Move, there is a MMB and Shift-MMB shortcut for constraint/lock to axes and plane after you start grabbing. If you "enable" Release Confirms (I think that is what you are really proposing) it becomes very difficult to use that feature with mouse, and almost impossible with usual mapping in graphics tablets.

rawalanche , Hi. If you are referring to Grab and not to Move, there is a MMB and Shift-MMB shortcut for constraint/lock to axes and plane after you start grabbing. If you "enable" Release Confirms (I think that is what you are really proposing) it becomes very difficult to use that feature with mouse, and almost impossible with usual mapping in graphics tablets.

Added subscriber: @rboxman

Added subscriber: @rboxman

Some things I've noticed that probably fall into this category of fixups:

Render Properties -> Cycles -> Light Paths : The values filled in by default are not part of any preset. This means that if you start switching between the included presets, you won't be able to go back to the default values unless you remember all of them. There should probably be a new preset added which corresponds to these values
Render Properties -> Cycles -> Sampling : The presets do not take into consideration the "Square samples" option. This means that you can select "Preview" or "Final" but the Squared Samples toggle remains set to whatever was there previously. This could be somewhat surprising. Additionally, I believe the presets that exist currently are only for the "Path tracing" integrator, not the Branched path tracer option; new presets are needed perhaps.

Presets in general : Would it be possible to include a "(default)" text next to any preset which is the default. For instance, the Cycles -> Dimensions defaults actually correspond to the "HDTV 1080p" preset. It would be nice if the preset was actually called "HDTV 1080p (default)"

Edit Mode -> Delete -> Edge Loops + Face Split option : Should be OFF by default. The Face split option is already OFF for Dissolve Vertices and Dissolve Edges and it produces more expected results in typical situations

Some things I've noticed that probably fall into this category of fixups: **Render Properties -> Cycles -> Light Paths** : The values filled in by default are not part of any preset. This means that if you start switching between the included presets, you won't be able to go back to the default values unless you remember all of them. There should probably be a new preset added which corresponds to these values **Render Properties -> Cycles -> Sampling** : The presets do not take into consideration the "Square samples" option. This means that you can select "Preview" or "Final" but the Squared Samples toggle remains set to whatever was there previously. This could be somewhat surprising. Additionally, I believe the presets that exist currently are only for the "Path tracing" integrator, not the Branched path tracer option; new presets are needed perhaps. **Presets in general** : Would it be possible to include a "(default)" text next to any preset which is the default. For instance, the Cycles -> Dimensions defaults actually correspond to the "HDTV 1080p" preset. It would be nice if the preset was actually called "HDTV 1080p (default)" **Edit Mode -> Delete -> Edge Loops + Face Split option** : Should be OFF by default. The Face split option is already OFF for Dissolve Vertices and Dissolve Edges and it produces more expected results in typical situations
Contributor

In #54943#541206, @WilliamReynish wrote:
Ludvik: I don't know what you mean. Release already confirms. If you enable the Move tool and drag, releasing then confirms the movement.

Hey, I mean this option:
image.png
When latest 2.8 is reset to factory defaults, this option is off. And then whenever you for example use tweak tool (Drag RMB) the item remains stuck to your mouse until you click again. It also seems to affect "Tweak" tool on a few other places around the UI, I don't know where exactly though.

> In #54943#541206, @WilliamReynish wrote: > Ludvik: I don't know what you mean. Release already confirms. If you enable the Move tool and drag, releasing then confirms the movement. Hey, I mean this option: ![image.png](https://archive.blender.org/developer/F5010534/image.png) When latest 2.8 is reset to factory defaults, this option is off. And then whenever you for example use tweak tool (Drag RMB) the item remains stuck to your mouse until you click again. It also seems to affect "Tweak" tool on a few other places around the UI, I don't know where exactly though.

Suggestion: change the default active tool.

Right now it is set on 3D Cursor, which newcomers don't know and may not understand what's happening on the firsts clicks. And even for regular blender users, this isn't the tool you need right away after launching nor that often while working.
I would suggest something more understandable and useful for everyone, such as the Move tool or the Transform tool.

Suggestion: change the default active tool. Right now it is set on 3D Cursor, which newcomers don't know and may not understand what's happening on the firsts clicks. And even for regular blender users, this isn't the tool you need right away after launching nor that often while working. I would suggest something more understandable and useful for everyone, such as the Move tool or the Transform tool.

In #54943#540596, @LucianoMunoz wrote:

In #54943#538552, @L0Lock wrote:
In the Graph Editor, set the "Only Selected Keyframes Handles" off by default (or, at least in the animation workspaces).

UDW08UQ- [x].png

Currently, this option is On, so all the handles are hidden till the keyframe is selected. Meaning we can't select a particular handle and manipulate it in one click. We must select the key first, then unselect the unwanted parts, then manipulate. This is already quite long to do for a single handle, so imagine how it is when you need to manipulate several handles at once. I.E. I want to select all the entry handles of several keys and move them around.

TL;DR, this option enabled makes everything slower.

The only reasons I can think of why this option is On by default is for performance (I guess it's faster to update the Graph is there isn't handles everywhere) and to not clutter the view. And those are considerable choices. But IMO, for an efficient animation workflow, displaying those handles is more important.

actually yes i think one of the reasons is performans, because its not a marginal hit in it, its actually quite big, a scene that can be running realtime, can easily go down to 1 or 2 fps.
to that I actually use "only show selected curves keyframes" so it will basically filter the curves by just clicking on the channel which is great behaviour.
things that should be addressed are the inconsistency with the channel colors, sometimes its rgb, sometimes some pastel colors sometimes no color whatsoever, it would be nice if XYZ is always RGB always, and W in the case of quaternions would have an other color, because it tends to be confusing and hard to read.

Yes, I don't say there can't be performance issues, I personally always have such issues as soon as there are a dozen curves displayed, handles or not.
But I can handle that via those buttons :
9vbSh6J- [x].png
Bdf9XIb- [x].png

These buttons are directly in front of my eyes instead of functions hidden in a menu, making them easy to acknowledge and use (just a look and a simple click to toggle them).
And those options don't reduce my efficiency, I work the same way with or without, they just let me do that without waiting for my computer. While the handles hiding option reduces the efficiency a lot: there are numerous actions that you simply can not do with that option enabled, and it forces you to do a considerable quantity of additional actions in order to do something otherwise simple. Unless I really struggle with performances and I'm out of solutions, I let this option Off and play with the other performance functions first. It is a solution of last resort.

If this option is only enabled for the sake of performance, I think it's not worth all the downsides as a default value and there are other functions that should be played with before needing to use it. If people really need that On, they can enable it anyway. But otherwise, efficiency and usability should prevail as long as possible.

> In #54943#540596, @LucianoMunoz wrote: >> In #54943#538552, @L0Lock wrote: >> In the Graph Editor, set the "Only Selected Keyframes Handles" off by default (or, at least in the animation workspaces). >> >> ![UDW08UQ- [x].png](https://archive.blender.org/developer/F4874953/UDW08UQ_1_.png) >> >> Currently, this option is On, so all the handles are hidden till the keyframe is selected. Meaning we can't select a particular handle and manipulate it in one click. We must select the key first, then unselect the unwanted parts, then manipulate. This is already quite long to do for a single handle, so imagine how it is when you need to manipulate several handles at once. I.E. I want to select all the entry handles of several keys and move them around. >> >> TL;DR, this option enabled makes everything slower. >> >> The only reasons I can think of why this option is On by default is for performance (I guess it's faster to update the Graph is there isn't handles everywhere) and to not clutter the view. And those are considerable choices. But IMO, for an efficient animation workflow, displaying those handles is more important. > > actually yes i think one of the reasons is performans, because its not a marginal hit in it, its actually quite big, a scene that can be running realtime, can easily go down to 1 or 2 fps. > to that I actually use "only show selected curves keyframes" so it will basically filter the curves by just clicking on the channel which is great behaviour. > things that should be addressed are the inconsistency with the channel colors, sometimes its rgb, sometimes some pastel colors sometimes no color whatsoever, it would be nice if XYZ is always RGB always, and W in the case of quaternions would have an other color, because it tends to be confusing and hard to read. Yes, I don't say there can't be performance issues, I personally always have such issues as soon as there are a dozen curves displayed, handles or not. But I can handle that via those buttons : ![9vbSh6J- [x].png](https://archive.blender.org/developer/F5024884/9vbSh6J_1_.png) ![Bdf9XIb- [x].png](https://archive.blender.org/developer/F5025007/Bdf9XIb_1_.png) These buttons are directly in front of my eyes instead of functions hidden in a menu, making them easy to acknowledge and use (just a look and a simple click to toggle them). And those options don't reduce my efficiency, I work the same way with or without, they just let me do that without waiting for my computer. While the handles hiding option reduces the efficiency a lot: there are numerous actions that you simply can not do with that option enabled, and it forces you to do a considerable quantity of additional actions in order to do something otherwise simple. Unless I really struggle with performances and I'm out of solutions, I let this option Off and play with the other performance functions first. It is a solution of last resort. If this option is only enabled for the sake of performance, I think it's not worth all the downsides as a default value and there are other functions that should be played with before needing to use it. If people really need that On, they can enable it anyway. But otherwise, efficiency and usability should prevail as long as possible.

In #54943#541669, @L0Lock wrote:
Suggestion: change the default active tool.

Right now it is set on 3D Cursor, which newcomers don't know and may not understand what's happening on the firsts clicks. And even for regular blender users, this isn't the tool you need right away after launching nor that often while working.
I would suggest something more understandable and useful for everyone, such as the Move tool or the Transform tool.

I second this, thought I'd say the default should hopefully be a safer selection tool instead, which is the most basic of tasks and probably the first thing new users are expecting to do on click (select and delete the default cube is a very common first step in many tutorials, and so is select and enter Edit Mode).
It is also a "safe startup state" where any misclick or accidental mouse action should be less likely to cause unintended changes or accidental damage; clicking or dragging only selects, unlike transform tools.

Consequently I believe the Border Selection tool (or whichever other "default state" we end up going with) should thus become the first and topmost icon in the toolbar to better communicate to the user that this is indeed a default and safe idle state.

General behavior while this "default tool" is active would also ideally match as close as possible the current 2.7# behavior while no other operators are running. For veterans this would mean a "home to return to" if they don't want to use the new tool system, or prefer the legacy hotkey oriented operators.

> In #54943#541669, @L0Lock wrote: > Suggestion: change the default active tool. > > Right now it is set on 3D Cursor, which newcomers don't know and may not understand what's happening on the firsts clicks. And even for regular blender users, this isn't the tool you need right away after launching nor that often while working. > I would suggest something more understandable and useful for everyone, such as the Move tool or the Transform tool. I second this, thought I'd say the default should hopefully be a safer selection tool instead, which is the most basic of tasks and probably the first thing new users are expecting to do on click (**select** and delete the default cube is a very common first step in many tutorials, and so is **select** and enter *Edit Mode*). It is also a "safe startup state" where any misclick or accidental mouse action should be less likely to cause unintended changes or accidental damage; clicking or dragging only selects, unlike transform tools. Consequently I believe the *Border Selection* tool (or whichever other "default state" we end up going with) should thus become the first and topmost icon in the toolbar to better communicate to the user that this is indeed a default and safe idle state. General behavior while this "default tool" is active would also ideally match as close as possible the current 2.7# behavior while no other operators are running. For veterans this would mean a "home to return to" if they don't want to use the new tool system, or prefer the legacy hotkey oriented operators.

I also thought about the Border select tool. But the issue is that for now, a simple click only moves the 3D cursor.

I also thought about the *Border select* tool. But the issue is that for now, a simple click only moves the 3D cursor.

Added subscriber: @Ko

Added subscriber: @Ko

Maybe self-collision setting of cloth simulation ON by default?

Maybe self-collision setting of cloth simulation ON by default?

Added subscriber: @ThinkingPolygons

Added subscriber: @ThinkingPolygons

IMO, the default collection should come expanded by default in the outliner. It's kinda weird not to see at a glance what's in your scene when you launch blender, also when you start adding objects it feels weird not to see the feedback in the outliner. ✌

IMO, the default collection should come expanded by default in the outliner. It's kinda weird not to see at a glance what's in your scene when you launch blender, also when you start adding objects it feels weird not to see the feedback in the outliner. ✌

This issue was referenced by 39b1e66afd

This issue was referenced by 39b1e66afd9132031aad2f20e236f631264db50a

Auto Save Temporary File is currently set to 2 minutes:
this may cause problems in slow computers and in huge scenes, causing a lot of writes (ssd consumption, battery drain...).

I propose to restore it to 5 minutes, as an acceptable amount of lost job because of a crash / error.

Auto Save Temporary File is currently set to 2 minutes: this may cause problems in slow computers and in huge scenes, causing a lot of writes (ssd consumption, battery drain...). I propose to restore it to 5 minutes, as an acceptable amount of lost job because of a crash / error.
Contributor

Hi,

I want to remind you that in 2.8, "Release confirms" in preferences is still set to be disabled by default, which results in quite default jarring behavior of tools for the new users, especially transform tools such as move, rotate and scale. Every time such an action is performed, the mode stick even upon releasing the mouse button, making it feel like the mouse has malfunctioned, requiring another click to confirm the action.

Hi, I want to remind you that in 2.8, "Release confirms" in preferences is still set to be disabled by default, which results in quite default jarring behavior of tools for the new users, especially transform tools such as move, rotate and scale. Every time such an action is performed, the mode stick even upon releasing the mouse button, making it feel like the mouse has malfunctioned, requiring another click to confirm the action.

@Rawalanche: I'm not sure what you mean. If you use any of the transform tools, you drag and release to translate. The action ends when the user releases the mouse button.

@Rawalanche: I'm not sure what you mean. If you use any of the transform tools, you drag and release to translate. The action ends when the user releases the mouse button.

Hi,

just sharing this here so it doesnt get forgotten:

Fill Mode full on Curves
Set the default fill mode from Half to Full for newly created curves. I have NEVER wanted to make my curves filled in half, nice to know its possible, but thats horrible for a default. You ALWAYS have to change it.
User kio posted this suggestion here: https://devtalk.blender.org/t/blender-ui-paper-cuts/2596/35

Selection only on exports
Setting "selection only" for exports (obj, alembic, ...) per default would save alot of headache most of the time.
SerjMaiorov posted it here on the devtalk forum: https://devtalk.blender.org/t/blender-ui-paper-cuts/2596/241

Hi, just sharing this here so it doesnt get forgotten: **Fill Mode full on Curves** Set the default fill mode from Half to Full for newly created curves. I have NEVER wanted to make my curves filled in half, nice to know its possible, but thats horrible for a default. You ALWAYS have to change it. User kio posted this suggestion here: https://devtalk.blender.org/t/blender-ui-paper-cuts/2596/35 **Selection only on exports** Setting "selection only" for exports (obj, alembic, ...) per default would save alot of headache most of the time. SerjMaiorov posted it here on the devtalk forum: https://devtalk.blender.org/t/blender-ui-paper-cuts/2596/241

@ManuelGrad: Yes I think that makes sense. I added these two items to the list..

@ManuelGrad: Yes I think that makes sense. I added these two items to the list..
Contributor

In #54943#553583, @WilliamReynish wrote:
@Rawalanche: I'm not sure what you mean. If you use any of the transform tools, you drag and release to translate. The action ends when the user releases the mouse button.

In latest 2.8 build, with factory defaults, in a new scene, with default cube, click and hold Right Mouse Button to perform "Tweak" action and notice that the cube sticks to your mouse until you hit RMB again.

You have to go to user preferences -> Editing tab and turn on "Release Confirms" checkbox to fix that behavior.

On top of that, it's inconsistent, as there seems to be special case just for tweak in viewport, if you tweak using RMB in for example shader editor, it doesn't stick to the mouse.

> In #54943#553583, @WilliamReynish wrote: > @Rawalanche: I'm not sure what you mean. If you use any of the transform tools, you drag and release to translate. The action ends when the user releases the mouse button. In latest 2.8 build, with factory defaults, in a new scene, with default cube, click and hold Right Mouse Button to perform "Tweak" action and notice that the cube sticks to your mouse until you hit RMB again. You have to go to user preferences -> Editing tab and turn on "Release Confirms" checkbox to fix that behavior. On top of that, it's inconsistent, as there seems to be special case just for tweak in viewport, if you tweak using RMB in for example shader editor, it doesn't stick to the mouse.

@Rawalanche: Well, that right-click drag feature is a way to engage the translate operator, just like tapping G. I don't particularly mind either way, but I'm not sure this feature was ever intended to work as you suggest? I don't think it ever acted that way, even going back to 2.4x and earlier where we had the left click gestures to engage this.

If you would like to drag and release to move, you could just enable the move tool. I also thought that we could add a 'Tweak' toggle for the Move tool so that you can just click and drag on elements to select and move them with one gesture, so you don't have to first select, then move.

Other apps have this kind of thing, sometimes as a separate tool, and other times as a tool setting.

@Rawalanche: Well, that right-click drag feature is a way to engage the translate operator, just like tapping G. I don't particularly mind either way, but I'm not sure this feature was ever intended to work as you suggest? I don't think it ever acted that way, even going back to 2.4x and earlier where we had the left click gestures to engage this. If you would like to drag and release to move, you could just enable the move tool. I also thought that we could add a 'Tweak' toggle for the Move tool so that you can just click and drag on elements to select and move them with one gesture, so you don't have to first select, then move. Other apps have this kind of thing, sometimes as a separate tool, and other times as a tool setting.
Contributor

In #54943#554605, @WilliamReynish wrote:
@Rawalanche: Well, that right-click drag feature is a way to engage the translate operator, just like tapping G. I don't particularly mind either way, but I'm not sure this feature was ever intended to work as you suggest? I don't think it ever acted that way, even going back to 2.4x and earlier where we had the left click gestures to engage this.

If you would like to drag and release to move, you could just enable the move tool. I also thought that we could add a 'Tweak' toggle for the Move tool so that you can just click and drag on elements to select and move them with one gesture, so you don't have to first select, then move.

Other apps have this kind of thing, sometimes as a separate tool, and other times as a tool setting.

Actually, there is a switch in preferences which changes that behavior, right here:
image.png
All I meant was that this "Release confirms" checkbox should ne ON by default, right now it's OFF by default. When it's off, then the tweak action triggered by right click drag will stick to your mouse until you perform another right click. That is quite unnatural behavior for many new users. So all I am suggesting is to make this little checkbox ON by default.

> In #54943#554605, @WilliamReynish wrote: > @Rawalanche: Well, that right-click drag feature is a way to engage the translate operator, just like tapping G. I don't particularly mind either way, but I'm not sure this feature was ever intended to work as you suggest? I don't think it ever acted that way, even going back to 2.4x and earlier where we had the left click gestures to engage this. > > If you would like to drag and release to move, you could just enable the move tool. I also thought that we could add a 'Tweak' toggle for the Move tool so that you can just click and drag on elements to select and move them with one gesture, so you don't have to first select, then move. > > Other apps have this kind of thing, sometimes as a separate tool, and other times as a tool setting. Actually, there is a switch in preferences which changes that behavior, right here: ![image.png](https://archive.blender.org/developer/F5600242/image.png) All I meant was that this "Release confirms" checkbox should ne ON by default, right now it's OFF by default. When it's off, then the tweak action triggered by right click drag will stick to your mouse until you perform another right click. That is quite unnatural behavior for many new users. So all I am suggesting is to make this little checkbox ON by default.

@Rawalanche: I know that, but my point was that we can solve this in a more consistent way that works for both RMB and LMB select modes, if we just make this a toggle for the Move tool, so that you can click and drag on any element to move it without selecting first.

The RMB feature you refer to, you have been using as though it was a tweak tool - what i’m saying is that I’m not sure this feature was ever meant to be that.

@Rawalanche: I know that, but my point was that we can solve this in a more consistent way that works for both RMB and LMB select modes, if we just make this a toggle for the Move tool, so that you can click and drag on any element to move it without selecting first. The RMB feature you refer to, you have been using as though it was a tweak tool - what i’m saying is that I’m not sure this feature was ever meant to be that.
Contributor

In #54943#554769, @WilliamReynish wrote:
@Rawalanche: I know that, but my point was that we can solve this in a more consistent way that works for both RMB and LMB select modes, if we just make this a toggle for the Move tool, so that you can click and drag on any element to move it without selecting first.

The RMB feature you refer to, you have been using as though it was a tweak tool - what i’m saying is that I’m not sure this feature was ever meant to be that.

I am a bit confused. I don't think we understand each other. I am not talking about any specific tools, such as move, rotate, etc... or LMB vs RMB. What I am talking about is that there is a "release confirms" option in the user preferences, which, for certain tools, defines if:
A: clicking, dragging and then releasing a mouse button performs and stops the action
or
B: when clicking, dragging and releasing mouse button, such action requires one more mouse button click (press and release) to stop the action

My point is that many new tools, such as move, rotate and scale tool have this behavior internally hardcoded at the A, while other, older tools, like "Tweak" tool (which is present in more editors that just 3D view, such as graph editor or node editor), have both A or B behaviors depending on the state "Release Confirms" checkbox in the user preferences. And "Release Confirms" checkbox has currently set default value to behavior B, which makes it inconsistent with behavior A, which is hardcoded in the new 2.8 tools, which do not respect the "Release Confirms" checkbox state.

My proposal is to just change the default state of the "Release Confirms" in user preferences to be on, that is all. So that the newbies are not confused and the behavior of the "Tweak" action based tools is consistent with the behavior of new 2.8 tools.

> In #54943#554769, @WilliamReynish wrote: > @Rawalanche: I know that, but my point was that we can solve this in a more consistent way that works for both RMB and LMB select modes, if we just make this a toggle for the Move tool, so that you can click and drag on any element to move it without selecting first. > > The RMB feature you refer to, you have been using as though it was a tweak tool - what i’m saying is that I’m not sure this feature was ever meant to be that. I am a bit confused. I don't think we understand each other. I am not talking about any specific tools, such as move, rotate, etc... or LMB vs RMB. What I am talking about is that there is a "release confirms" option in the user preferences, which, for certain tools, defines if: A: clicking, dragging and then releasing a mouse button performs and stops the action or B: when clicking, dragging and releasing mouse button, such action requires one more mouse button click (press and release) to stop the action My point is that many new tools, such as move, rotate and scale tool have this behavior internally hardcoded at the A, while other, older tools, like "Tweak" tool (which is present in more editors that just 3D view, such as graph editor or node editor), have both A or B behaviors depending on the state "Release Confirms" checkbox in the user preferences. And "Release Confirms" checkbox has currently set default value to behavior B, which makes it inconsistent with behavior A, which is hardcoded in the new 2.8 tools, which do not respect the "Release Confirms" checkbox state. My proposal is to just change the default state of the "Release Confirms" in user preferences to be on, that is all. So that the newbies are not confused and the behavior of the "Tweak" action based tools is consistent with the behavior of new 2.8 tools.

I've just been playing around with 2.8 to get used to the new shortcuts and noticed another thing that drives me nuts every time I install Blender: Snap defaults to grid snap. How useful is grid snap to most people? I think vertex snap is a much more useful and sensible default, and it's far easier to understand how things are snapping to new users because vertices are visible, whereas grid points are not.

I've just been playing around with 2.8 to get used to the new shortcuts and noticed another thing that drives me nuts every time I install Blender: Snap defaults to grid snap. How useful is grid snap to most people? I think vertex snap is a much more useful and sensible default, and it's far easier to understand how things are snapping to new users because vertices are visible, whereas grid points are not.

Another thing I noticed while unwrapping is the image editor defaults to image viewer. This led to some confusion after unwrapping a cube with an image editor open. Would it be better of defaulting to UV edit? What about if the selected object is in edit mode? What about when the image viewer is empty (looking very much the same as an empty UV editor window) and the user creates a new UV channel?

EDIT: I did just realise that this applies only to newly created UV editor windows, as opposed to switching to the UV edit workspace, which is correctly set up for UV editing. I guess I am just used to my old way of working, which is to open and close editors as I need them.

Another thing I noticed while unwrapping is the image editor defaults to image viewer. This led to some confusion after unwrapping a cube with an image editor open. Would it be better of defaulting to UV edit? What about if the selected object is in edit mode? What about when the image viewer is empty (looking very much the same as an empty UV editor window) and the user creates a new UV channel? EDIT: I did just realise that this applies only to newly created UV editor windows, as opposed to switching to the UV edit workspace, which is correctly set up for UV editing. I guess I am just used to my old way of working, which is to open and close editors as I need them.

Added subscriber: @tintwotin

Added subscriber: @tintwotin

If you want to improve the VSE defaults, here's a collection of suggestions: https://devtalk.blender.org/t/suggestions-for-vse-ui-cleanup-and-default-settings-in-2-8/2210

If you want to improve the VSE defaults, here's a collection of suggestions: https://devtalk.blender.org/t/suggestions-for-vse-ui-cleanup-and-default-settings-in-2-8/2210
Contributor

I'm happy to finally see release confirms added. One more I am sure many would appreciate is if "Load UI" when opening .blend file was off by default. I am sure most people dislike their UI being shuffled around randomly when opening someone else's .blend file.

What's worse is that 2.79 files opened in 2.8 flip those editor headers to the bottom, adding to the confusion. :)

I'm happy to finally see release confirms added. One more I am sure many would appreciate is if "Load UI" when opening .blend file was off by default. I am sure most people dislike their UI being shuffled around randomly when opening someone else's .blend file. What's worse is that 2.79 files opened in 2.8 flip those editor headers to the bottom, adding to the confusion. :)

Oh god please don’t turn off load ui by default. I would much prefer being able to pick up where I left off when I open my files. I think the defaults should be set based on what an independent user would need since Blender is obviously a strong choice of software for freelancers.

Edit: I could see that being a good choice for opening older files, though.

Oh god please don’t turn off load ui by default. I would much prefer being able to pick up where I left off when I open my files. I think the defaults should be set based on what an independent user would need since Blender is obviously a strong choice of software for freelancers. Edit: I could see that being a good choice for opening older files, though.

In #54943#559093, @Rawalanche wrote: One more I am sure many would appreciate is if "Load UI" when opening .blend file was off by default.

Exactly. True source of problems.
https://devtalk.blender.org/t/blender-ui-paper-cuts/2596/292?u=thinkingpolygons

> In #54943#559093, @Rawalanche wrote: One more I am sure many would appreciate is if "Load UI" when opening .blend file was off by default. Exactly. True source of problems. https://devtalk.blender.org/t/blender-ui-paper-cuts/2596/292?u=thinkingpolygons

In #54943#559169, @ThinkingPolygons wrote:

In #54943#559093, @Rawalanche wrote: One more I am sure many would appreciate is if "Load UI" when opening .blend file was off by default.

Exactly. True source of problems.
https://devtalk.blender.org/t/blender-ui-paper-cuts/2596/292?u=thinkingpolygons

?
I open my own files much much more often than files from others. Of course I want to continue where I left off.
Also, opening one of your latest projects from the file -> recent menu doesn't give the option to change this setting. Opening a blend file from someone else, you more probably use the file browser, where you can still turn Load UI off if you want.

> In #54943#559169, @ThinkingPolygons wrote: >> In #54943#559093, @Rawalanche wrote: One more I am sure many would appreciate is if "Load UI" when opening .blend file was off by default. > > Exactly. True source of problems. > https://devtalk.blender.org/t/blender-ui-paper-cuts/2596/292?u=thinkingpolygons ? I open my own files much much more often than files from others. Of course I want to continue where I left off. Also, opening one of your latest projects from the file -> recent menu doesn't give the option to change this setting. Opening a blend file from someone else, you more probably use the file browser, where you can still turn Load UI off if you want.
Contributor

@ZsoltStefan @DanPool

Yes, I guess that makes sense. In that case, I think that "Load UI" should be a persistent user preference, rather than something that resets every time you create a new scene or open blender.

@ZsoltStefan @DanPool Yes, I guess that makes sense. In that case, I think that "Load UI" should be a persistent user preference, rather than something that resets every time you create a new scene or open blender.

Removed subscriber: @tintwotin

Removed subscriber: @tintwotin

Maybe also set the weight paint mode's auto-normalize to ON by default. It's the default behavior in other softwares and one of the firsts things riggers do enable when they start the skinning phase.

Maybe also set the weight paint mode's auto-normalize to ON by default. It's the default behavior in other softwares and one of the firsts things riggers do enable when they start the skinning phase.

Added subscriber: @GeRo

Added subscriber: @GeRo

Is there a technical reason about why "Compress" option is not enabled by default when you save a .blend file? Slow hardware maybe? I do not think people can use very slow computers with Blender 2.8 anyway.
The option seems to greatly reduce the size even for eevee scenes with baked indirect lighting.

Is there a technical reason about why "Compress" option is not enabled by default when you save a .blend file? Slow hardware maybe? I do not think people can use very slow computers with Blender 2.8 anyway. The option seems to greatly reduce the size even for eevee scenes with baked indirect lighting.

The spacebar for play animation by default on beta is really weird. The toolbar was making sense even if I think search was more useful but I'm really surprise by this choice. But still, I really enjoy the beta, it's really a great job.

The spacebar for play animation by default on beta is really weird. The toolbar was making sense even if I think search was more useful but I'm really surprise by this choice. But still, I really enjoy the beta, it's really a great job.

Is there a technical reason about why "Compress" option is not enabled by default when you save a .blend file? Slow hardware maybe? I do not think people can use very slow computers with Blender 2.8 anyway.

This option makes file saving and loading significantly slower. With a faster compression algorithm it could be enabled perhaps, but right now it's not good enough.

Another downside is that if you are using a version control system, it will actually increase file size.

> Is there a technical reason about why "Compress" option is not enabled by default when you save a .blend file? Slow hardware maybe? I do not think people can use very slow computers with Blender 2.8 anyway. This option makes file saving and loading significantly slower. With a faster compression algorithm it could be enabled perhaps, but right now it's not good enough. Another downside is that if you are using a version control system, it will actually increase file size.

Added subscriber: @moisessalvador

Added subscriber: @moisessalvador

Suggestion. Overlap threshold in Boolean modifiers to 0, and merge threshold for the Intersect(Boolean) command in edit mode to 0 as well. For the longest time I thought the boolean algorithm wasn't good enough for some cases, producing non manifold meshes from my perfectly manifold ones, but it turns out that the merge threshold is what messes it up for me most of the time.

Suggestion. Overlap threshold in Boolean modifiers to 0, and merge threshold for the Intersect(Boolean) command in edit mode to 0 as well. For the longest time I thought the boolean algorithm wasn't good enough for some cases, producing non manifold meshes from my perfectly manifold ones, but it turns out that the merge threshold is what messes it up for me most of the time.

The spacebar for play animation by default on beta is really weird.

Not everyone agrees on what should be put here. Playback makes sense for a lot of people, starting by animators. Search bar is extremely usef by some, barely used by others, etc.

But the first start's splash screen is a fine compromise IMHO: you're invited from the first start's splash screen to choose what you will use the spacebar for.

> The spacebar for play animation by default on beta is really weird. Not everyone agrees on what should be put here. Playback makes sense for a lot of people, starting by animators. Search bar is extremely usef by some, barely used by others, etc. But the first start's splash screen is a fine compromise IMHO: you're invited from the first start's splash screen to choose what you will use the spacebar for.

Not everyone agrees on what should be put here. Playback makes sense for a lot of people, starting by animators. Search bar is extremely usef by some, barely used by others, etc.

I agree, it's not a big deal since you can change the spacebar behaviour almost instantly by splash screen. I love it. But I still think search or toolbar is a better choice as a default since you need to do some work before starting to animate things.

> Not everyone agrees on what should be put here. Playback makes sense for a lot of people, starting by animators. Search bar is extremely usef by some, barely used by others, etc. I agree, it's not a big deal since you can change the spacebar behaviour almost instantly by splash screen. I love it. But I still think search or toolbar is a better choice as a default since you need to do some work before starting to animate things.

It looks like some changes to the default startup.blend in recent builds has changed the Auto Perspective default to OFF -- is that by design?

It looks like some changes to the default startup.blend in recent builds has changed the Auto Perspective default to OFF -- is that by design?

Removed subscriber: @moisessalvador

Removed subscriber: @moisessalvador

@rboxman, it was not intentional, fixed now.

@rboxman, it was not intentional, fixed now.

Now that the precision of the grid has been increased, can we have the Clip Start distance in all the Workspaces be 0.01? https://developer.blender.org/rBb5bc2158a07140e5463e209839bcf36d2ce2cddc

Now that the precision of the grid has been increased, can we have the Clip Start distance in all the Workspaces be 0.01? https://developer.blender.org/rBb5bc2158a07140e5463e209839bcf36d2ce2cddc

Now that the precision of the grid has been increased, can we have the Clip Start distance in all the Workspaces be 0.01? https://developer.blender.org/rBb5bc2158a07140e5463e209839bcf36d2ce2cddc

That would be great :)

> Now that the precision of the grid has been increased, can we have the Clip Start distance in all the Workspaces be 0.01? https://developer.blender.org/rBb5bc2158a07140e5463e209839bcf36d2ce2cddc That would be great :)
Member

Added subscriber: @Mets

Added subscriber: @Mets
Member

Now that the precision of the grid has been increased, can we have the Clip Start distance in all the Workspaces be 0.01? https://developer.blender.org/rBb5bc2158a07140e5463e209839bcf36d2ce2cddc

+1 to my colleague here

I hope that Auto Normalize = ON will make it through because I think the tradeoff between its dangers(destroying weights) vs its benefits(the colors actually represent the influence) is worth it considering the reactions I've seen when I saw my college classmates first try weight painting.

Load UI = Off sounds bad to me because in many cases the UI of the file being shared is intentionally set up to help guide inexperienced users through the potentially complex file.

What about UV Editor "Keep UV and edit mode mesh selection in sync" = ON?

> Now that the precision of the grid has been increased, can we have the Clip Start distance in all the Workspaces be 0.01? https://developer.blender.org/rBb5bc2158a07140e5463e209839bcf36d2ce2cddc +1 to my colleague here I hope that **Auto Normalize = ON** will make it through because I think the tradeoff between its dangers(destroying weights) vs its benefits(the colors actually represent the influence) is worth it considering the reactions I've seen when I saw my college classmates first try weight painting. **Load UI = Off** sounds bad to me because in many cases the UI of the file being shared is intentionally set up to help guide inexperienced users through the potentially complex file. What about UV Editor **"Keep UV and edit mode mesh selection in sync" = ON**?
Member

Couple more things.

In weight paint mode, Zero Weights should absolutely be turned to Active by default. It boggles my mind why that hasn't always been the default, the other settings provide you with a massive disadvantage while weight painting as far as I know at least.

Speaking of weight painting, it is currently not possible to weight paint with an armature until Edit->Lock Object Modes is disabled. I think having one of the modes be completely locked behind a checkbox is not really great.

Couple more things. In weight paint mode, **Zero Weights should absolutely be turned to Active** by default. It boggles my mind why that hasn't always been the default, the other settings provide you with a massive disadvantage while weight painting as far as I know at least. Speaking of weight painting, it is currently not possible to weight paint with an armature until **Edit->Lock Object Modes** is disabled. I think having one of the modes be completely locked behind a checkbox is not really great.

Added subscriber: @zuokre

Added subscriber: @zuokre

I got some useful advice from this post which will help me a lot in my project :) My name is William and I have a car blog. Most of the time I work on my website . Occasionally, I work on blender and this guide really helpful for me.

I got some useful advice from this post which will help me a lot in my project :) My name is William and I have a car blog. Most of the time I work on my [website ](https://bestobd2scanners.com/). Occasionally, I work on blender and this guide really helpful for me.

Another default I think we should enable, is to make it so the default Timeline has the source list collapsed, so that you just see the Summary key by default.

Currently you see this in the Timeline by default:
Screenshot 2019-01-31 at 14.15.02.png

With collapsed source list:
Screenshot 2019-01-31 at 14.15.12.png

Another default I think we should enable, is to make it so the default Timeline has the source list collapsed, so that you just see the Summary key by default. Currently you see this in the Timeline by default: ![Screenshot 2019-01-31 at 14.15.02.png](https://archive.blender.org/developer/F6464703/Screenshot_2019-01-31_at_14.15.02.png) With collapsed source list: ![Screenshot 2019-01-31 at 14.15.12.png](https://archive.blender.org/developer/F6464707/Screenshot_2019-01-31_at_14.15.12.png)
Member

km07qRk.png
I think that Random Seed should be On by default, or even be completely removed and always be on because I think everyone who knows about it uses it anyways. Could be wrong ofc, I just can't think of a use case where you'd want it off.

![km07qRk.png](https://archive.blender.org/developer/F6568788/km07qRk.png) I think that Random Seed should be On by default, or even be completely removed and always be on because I think everyone who knows about it uses it anyways. Could be wrong ofc, I just can't think of a use case where you'd want it off.

Never consider removing an option just because you don't use it. It's up to the user to learn about it and decide whether to use it or not. There are some technical scenarios where it could be mandatory, not to mention subjective preferences.

Besides, I personally don't like to use this all the time. With low samples renders it does make the render look inconsistent, in some scenarios you would use that as a natural "noise" effect as you'd use in post-prod, but sometimes it's just better to have kind of a dithering effect. And with denoising it works better at low samples, enable this and you'll end up with an entire flickering animation.

**Never** consider removing an option just because you don't use it. It's up to the user to learn about it and decide whether to use it or not. There are some technical scenarios where it could be mandatory, not to mention subjective preferences. Besides, I personally don't like to use this all the time. With low samples renders it does make the render look inconsistent, in some scenarios you would use that as a natural "noise" effect as you'd use in post-prod, but sometimes it's just better to have kind of a dithering effect. And with denoising it works better at low samples, enable this and you'll end up with an entire flickering animation.
Contributor

@Mets
That option is very important. You probably don't posses enough experience with offline 3D rendering to be aware of all the use cases. When random seed is on, you will get noise variance between frames.

That will give you two benefits:
1, If your render has visible noise, that noise won't have a "dirty lens" type of look where the noise pattern slides along with camera.
2, If you are using some post processing denosier, such as NeatVideo, then such denoiser will be able to pick up the noise variance and denoise it. If it was static noise sliding with the camera, such denoiser can not resolve it at all, as it can not distinguish it from actual detail.

But it also comes with many disadvantages:
1, If you are using built-in Cycles denoiser, you want your noise pattern to be static, otherwise denoised animation will flicker heavily, as the source noise for denoising changes every frame.
2, If you are rendering an animation where scene moves, but camera is static, then static noise pattern will give you MUCH cleaner result. Especially for example when antialiasing very thin small objects, like wires, or tree leaves. With static noise pattern and static camera, they will be completely static and clean. With random noise pattern, thin wires, tree leaves, and such, will turn into dancing noise fest.
3, If you are rendering your animation with high enough samples that the resulting noise is almost invisible on still frame, then static noise pattern will make it almost invisible in animation as well, but random noise pattern will exaggerate that noise in motion.

So the setting is very important, and you choose which mode you use based on the factors above.

@L0Lock
Your answer is as silly as the one Mets 3D has posted. Yes, in this particular case it's true that this option should not be removed, but in general, you could not be more wrong. As soon as the option has either a superior value, or value which can be reliably detected/decided manually, that option should be immediately removed. The option hell is the reason Vray has lost so many users to Corona for example ;) What you are implying is that any option should stay as long as there is at least one user using it. That'd result into user interface that would be painful to use for majority of people.

@Mets That option is very important. You probably don't posses enough experience with offline 3D rendering to be aware of all the use cases. When random seed is on, you will get noise variance between frames. That will give you two benefits: 1, If your render has visible noise, that noise won't have a "dirty lens" type of look where the noise pattern slides along with camera. 2, If you are using some post processing denosier, such as NeatVideo, then such denoiser will be able to pick up the noise variance and denoise it. If it was static noise sliding with the camera, such denoiser can not resolve it at all, as it can not distinguish it from actual detail. But it also comes with many disadvantages: 1, If you are using built-in Cycles denoiser, you want your noise pattern to be static, otherwise denoised animation will flicker heavily, as the source noise for denoising changes every frame. 2, If you are rendering an animation where scene moves, but camera is static, then static noise pattern will give you MUCH cleaner result. Especially for example when antialiasing very thin small objects, like wires, or tree leaves. With static noise pattern and static camera, they will be completely static and clean. With random noise pattern, thin wires, tree leaves, and such, will turn into dancing noise fest. 3, If you are rendering your animation with high enough samples that the resulting noise is almost invisible on still frame, then static noise pattern will make it almost invisible in animation as well, but random noise pattern will exaggerate that noise in motion. So the setting is very important, and you choose which mode you use based on the factors above. @L0Lock Your answer is as silly as the one Mets 3D has posted. Yes, in this particular case it's true that this option should not be removed, but in general, you could not be more wrong. As soon as the option has either a superior value, or value which can be reliably detected/decided manually, that option should be immediately removed. The option hell is the reason Vray has lost so many users to Corona for example ;) What you are implying is that any option should stay as long as there is at least one user using it. That'd result into user interface that would be painful to use for majority of people.
Member

Good points from everyone, I didn't mean to derail the topic to removing buttons, afterall that's a completely different thing from changing defaults, which is the topic at hand. Either way I'm not too bothered by the random seed button's existence or its current default, just wanted to throw it out there for consideration! :P

Good points from everyone, I didn't mean to derail the topic to removing buttons, afterall that's a completely different thing from changing defaults, which is the topic at hand. Either way I'm not too bothered by the random seed button's existence or its current default, just wanted to throw it out there for consideration! :P

Yes, in this particular case it's true that this option should not be removed, but in general, you could not be more wrong.

I just wanted to illustrate my words with some scenarios I had and I didn't want to make any further explanation, precisely because it's not my domain anyway and because I know there are plenty other people out there knowing way more than me and which could give more accurate and complete explanations. Like you did. Which is great! ?

What you are implying is that any option should stay as long as there is at least one user using it. That'd result into user interface that would be painful to use for majority of people.

No, I just implied that an option should not be removed "just because some don't use it". I didn't mean that there is no other reason to remove an option.
Besides that, I don't totally agree with what you say here :

As soon as the option has either a superior value, or value which can be reliably detected/decided manually, that option should be immediately removed

Those are good points, for sure. But IMHO there are some others to be considered too.
Example (and for any software), for retro-compatibility reasons. A little option removal between two minor versions can break everything If you send your project to a render farm or if your company subcontracts part of the production to a service provider.
Still in that perspective, if the existence (or not) of this option doesn't impact the compatibility of files or data among versions, well there's way less to care about anyway.
Other examples, sometimes new features are just not 100% ready, even after years of dev there might be some (rare) scenarios where the legacy option works better (I remember the Bmesh and Carve debate with Blender's boolean modifier : bmesh was better, but still had some cases when it couldn't work while carve could). And if you fear about cluttered UI and option lists long as a NY skyscraper, well maybe the solution could be in the UI design itself.
But that's a complex topic I guess. I may not be even close to being barely relevant there. But meh, I like debating. I'll stop digressing here.

> Yes, in this particular case it's true that this option should not be removed, but in general, you could not be more wrong. I just wanted to illustrate my words with some scenarios I had and I didn't want to make any further explanation, precisely because it's not my domain anyway and because I know there are plenty other people out there knowing way more than me and which could give more accurate and complete explanations. Like you did. Which is great! ? > What you are implying is that any option should stay as long as there is at least one user using it. That'd result into user interface that would be painful to use for majority of people. No, I just implied that an option should not be removed "just because some don't use it". I didn't mean that there is no other reason to remove an option. Besides that, I don't totally agree with what you say here : > As soon as the option has either a superior value, or value which can be reliably detected/decided manually, that option should be immediately removed Those are good points, for sure. But IMHO there are some others to be considered too. Example (and for any software), for retro-compatibility reasons. A little option removal between two minor versions can break everything If you send your project to a render farm or if your company subcontracts part of the production to a service provider. Still in that perspective, if the existence (or not) of this option doesn't impact the compatibility of files or data among versions, well there's way less to care about anyway. Other examples, sometimes new features are just not 100% ready, even after years of dev there might be some (rare) scenarios where the legacy option works better (I remember the Bmesh and Carve debate with Blender's boolean modifier : bmesh was better, but still had some cases when it couldn't work while carve could). And if you fear about cluttered UI and option lists long as a NY skyscraper, well maybe the solution could be in the UI design itself. But that's a complex topic I guess. I may not be even close to being barely relevant there. But meh, I like debating. I'll stop digressing here.

Added subscriber: @mont29

Added subscriber: @mont29

@ideasman42 @mont29 Can you agree on the following changes:

Text Editor: Line Numbers ON
Addons: All exporters should be set to Only Selected by default

@ideasman42 @mont29 Can you agree on the following changes: Text Editor: Line Numbers ON Addons: All exporters should be set to Only Selected by default

@WilliamReynish is there any reason highlighting can’t be on by default in the text editor? That would be very helpful, but I’m not sure if there is a downside.

@WilliamReynish is there any reason highlighting can’t be on by default in the text editor? That would be very helpful, but I’m not sure if there is a downside.

Added subscriber: @crantisz

Added subscriber: @crantisz

Added subscriber: @GavinScott

Added subscriber: @GavinScott

In #54943#670483, @WilliamReynish wrote:
@ideasman42 @mont29 Can you agree on the following changes:

Text Editor: Line Numbers ON
Addons: All exporters should be set to Only Selected by default

  • Line numbers for text seems fine (although no strong opinion).
  • Selected Only for exporters was default years ago but IIRC there was a bug reported that nothing was exported.
Since for some use cases you would expect everything to be written. Similar to exporting an image in an image editor - you wouldn't expect to have to select all layers.
Export being WYSIWYG by default is useful for users who setup layers with a limited set of objects visible which are used for export, where as selection lost whenever you work on the scene, it needs to be set every time to get the same export.
I would like to hear from users who have exporting as part of there pipeline & see why setting up layers for the export is a worse solution for exporting compared to setting the selection each time.
> In #54943#670483, @WilliamReynish wrote: > @ideasman42 @mont29 Can you agree on the following changes: > > Text Editor: Line Numbers ON > Addons: All exporters should be set to Only Selected by default - Line numbers for text seems fine (although no strong opinion). - Selected Only for exporters was default years ago but IIRC there was a bug reported that nothing was exported. ``` Since for some use cases you would expect everything to be written. Similar to exporting an image in an image editor - you wouldn't expect to have to select all layers. ``` ``` Export being WYSIWYG by default is useful for users who setup layers with a limited set of objects visible which are used for export, where as selection lost whenever you work on the scene, it needs to be set every time to get the same export. ``` ``` I would like to hear from users who have exporting as part of there pipeline & see why setting up layers for the export is a worse solution for exporting compared to setting the selection each time.

In #54943#746221, @ideasman42 wrote:

In #54943#670483, @WilliamReynish wrote:
@ideasman42 @mont29 Can you agree on the following changes:

Text Editor: Line Numbers ON
Addons: All exporters should be set to Only Selected by default

  • Line numbers for text seems fine (although no strong opinion).

  • Selected Only for exporters was default years ago but IIRC there was a bug reported that nothing was exported.

    Since for some use cases you would expect everything to be written. Similar to exporting an image in an image editor - you wouldn't expect to have to select all layers.

    Export being WYSIWYG by default is useful for users who setup layers with a limited set of objects visible which are used for export, where as selection lost whenever you work on the scene, it needs to be set every time to get the same export.

    I would like to hear from users who have exporting as part of there pipeline & see why setting up layers for the export is a worse solution for exporting compared to setting the selection each time.

Using selected as default for export seems more intuitive and flexible for me. Beside that I never needed to export a full scene in my workflow for game assets.
Another point in favor of this default is the fact that I often make changes in to what is exported, rearranging the selection and I need to see all objects at all times. Plus, selecting by material, or by parenting, for example, is pretty straightforward.
On the other hand I get that this might confuse some users. So maybe a better solution to consider is a new menu item/operator similar to 3ds max's "Export selected" or even Photoshop's "Export layers to files" or Select layer(s)>RMB>Export.

> In #54943#746221, @ideasman42 wrote: >> In #54943#670483, @WilliamReynish wrote: >> @ideasman42 @mont29 Can you agree on the following changes: >> >> Text Editor: Line Numbers ON >> Addons: All exporters should be set to Only Selected by default > > - Line numbers for text seems fine (although no strong opinion). > - Selected Only for exporters was default years ago but IIRC there was a bug reported that nothing was exported. > > Since for some use cases you would expect everything to be written. Similar to exporting an image in an image editor - you wouldn't expect to have to select all layers. > > Export being WYSIWYG by default is useful for users who setup layers with a limited set of objects visible which are used for export, where as selection lost whenever you work on the scene, it needs to be set every time to get the same export. > > I would like to hear from users who have exporting as part of there pipeline & see why setting up layers for the export is a worse solution for exporting compared to setting the selection each time. Using selected as default for export seems more intuitive and flexible for me. Beside that I never needed to export a full scene in my workflow for game assets. Another point in favor of this default is the fact that I often make changes in to what is exported, rearranging the selection and I need to see all objects at all times. Plus, selecting by material, or by parenting, for example, is pretty straightforward. On the other hand I get that this might confuse some users. So maybe a better solution to consider is a new menu item/operator similar to 3ds max's "Export selected" or even Photoshop's "Export layers to files" or Select layer(s)>RMB>Export.

I can't count how often I wanted to export just one mesh instead of the whole scene just to realize I forgot to turn on "only selected" and end up having to kill blender because the export of the whole scene is unbareable slow (>30min) and deliberately loose work.

While you can argue that it was my fault to forget to turn it on, it would be less severe if I'd just need to export again.

I can't count how often I wanted to export just one mesh instead of the whole scene just to realize I forgot to turn on "only selected" and end up having to kill blender because the export of the whole scene is unbareable slow (>30min) and deliberately loose work. While you can argue that it was my fault to forget to turn it on, it would be less severe if I'd just need to export again.

Anything against making "Zoom to Mouse Position" default?

4 people have suggested this so far.

Anything against making "Zoom to Mouse Position" default? 4 people have suggested this so far. - #54943#520058 - #54943#500553 - [D5406](https://archive.blender.org/developer/D5406)#125083 - [D5406](https://archive.blender.org/developer/D5406)#125091

In #54943#753160, @ideasman42 wrote:
Anything against making "Zoom to Mouse Position" default?

Me for example. I find it extremely irritating when zooming outwards. It continually reframes my scene. I just want to zoom out to see more of my scene, not move it to the side.

Whatever I am working on is usually centered anyway, so I can zoom in any time with the mouse wheel, independently of where the cursor is. I use the Center View to Mouse command often (Alt-MMB), which is a very powerful tool, I find it replaces panning almost completely.

> In #54943#753160, @ideasman42 wrote: > Anything against making "Zoom to Mouse Position" default? > Me for example. I find it extremely irritating when zooming outwards. It continually reframes my scene. I just want to zoom out to see more of my scene, not move it to the side. Whatever I am working on is usually centered anyway, so I can zoom in any time with the mouse wheel, independently of where the cursor is. I use the Center View to Mouse command often (Alt-MMB), which is a very powerful tool, I find it replaces panning almost completely.

Added subscriber: @jeacom

Added subscriber: @jeacom

In #54943#753160, @ideasman42 wrote:
Anything against making "Zoom to Mouse Position" default?

No please no!, Its really frustrating and disorienting for who is used with it disabled.

> In #54943#753160, @ideasman42 wrote: > Anything against making "Zoom to Mouse Position" default? No please no!, Its really frustrating and disorienting for who is used with it disabled.
Contributor

I also don't like that behavior, and make sure to turn zoom to mouse position off in any app I use, BUT:

In general, defaults should always cover the majority of users, so this is one of those cases where a poll would be appropriate :)

If the new default would be ON, I am still fine with it knowing it takes me just one checkbox click every time I encounter Blender in factory default state. And I'd like Blender to work out of the box as well as possible for the largest amount of people possible.

I also don't like that behavior, and make sure to turn zoom to mouse position off in any app I use, BUT: In general, defaults should always cover the majority of users, so this is one of those cases where a poll would be appropriate :) If the new default would be ON, I am still fine with it knowing it takes me just one checkbox click every time I encounter Blender in factory default state. And I'd like Blender to work out of the box as well as possible for the largest amount of people possible.

Definitely a +1 for defaulting zoom to mouse position on. C4D made this default many versions ago, it went down pretty well with the majority as far as I can remember. I think its very intuitive but also appreciate that some don't like it, Kind of agree with @Rawalanche , maybe a poll on Blender Talk or something?

Definitely a +1 for defaulting zoom to mouse position on. C4D made this default many versions ago, it went down pretty well with the majority as far as I can remember. I think its very intuitive but also appreciate that some don't like it, Kind of agree with @Rawalanche , maybe a poll on Blender Talk or something?

In #54943#753160, @ideasman42 wrote:
Anything against making "Zoom to Mouse Position" default?

In the 3dview you might also want Auto Depth turned on as they go well together IMO.

While zoom to mouse may be controversial in the 3dview I really think it should be on by default in the node editor views where it feels completely natural and makes navigation much easier. Unfortunately, there's only the one preference currently that affects both. Perhaps there could be separate 2D and 3D preferences with the 2D editor option defaulting to zoom to mouse (I don't have a super-strong opinion about the 3dview default).

> In #54943#753160, @ideasman42 wrote: > Anything against making "Zoom to Mouse Position" default? In the 3dview you might also want Auto Depth turned on as they go well together IMO. While zoom to mouse may be controversial in the 3dview I really think it should be on by default in the node editor views where it feels completely natural and makes navigation much easier. Unfortunately, there's only the one preference currently that affects both. Perhaps there could be separate 2D and 3D preferences with the 2D editor option defaulting to zoom to mouse (I don't have a super-strong opinion about the 3dview default).

@WilliamReynish is there any reason highlighting can’t be on by default in the text editor? That would be very helpful, but I’m not sure if there is a downside.

+1 for zoom to mouse position as default.

@WilliamReynish is there any reason highlighting can’t be on by default in the text editor? That would be very helpful, but I’m not sure if there is a downside. +1 for zoom to mouse position as default.
Member

Added subscriber: @HooglyBoogly

Added subscriber: @HooglyBoogly
Member

In #54943#753352, @GavinScott wrote:
Perhaps there could be separate 2D and 3D preferences with the 2D editor option defaulting to zoom to mouse

See D5406.

Another #1 for the zoom to mouse position as default! (Although my comment is one of the 4 Campbell mentioned, so maybe this doesn't count.)

> In #54943#753352, @GavinScott wrote: >Perhaps there could be separate 2D and 3D preferences with the 2D editor option defaulting to zoom to mouse See [D5406](https://archive.blender.org/developer/D5406). Another #1 for the zoom to mouse position as default! (Although my comment is one of the 4 Campbell mentioned, so maybe this doesn't count.)

In #54943#753160, @ideasman42 wrote:
Anything against making "Zoom to Mouse Position" default?

I'm sure in every CAD application zoom to mouse position is the default (in many of them there is no option to zoom to center es. AutoCad, SketchUp, Rhino).

In 3dMax zoom to mouse position is the default and there are two options "*Zoom About Mouse Point//" (for Ortho and Persp).
In Modo I think zoom to mouse position is the default and there is an option "*Wheel Zoom at Mouse Cursor//".
@AnadinX said that zoom to mouse position is the default in Cinema4d.
In the printing application Cura the option "Zoom toward mouse direction" is on by default.

In Maya there is an options, but the default is to the center of the screen (but some people are changing it ).*Can someone confirm my research, specially for 3dMax and Modo, I did by mind and I can't check right now.//

Other than that, this is the default in every 2d application , ex. Adobe Suite (starting from Acrobat Reader to Photoshop to Illustrator, ecc...), Corel soite, Gis applications (ex. QGis, most of Esri Suite), Gimp, Inkscape, Krita, ecc... ( I don't like the words "industry default" but this is exactly the case, except for Maya ).
In audio editing this is the default and even in google maps or openstreetmap...

I agree to have this option default on because you can control two screen movement with a single hand, in a single operation.
More than that, I think that in Blender, having this option off, is a duplicate:
you can always zoom to center using Ctrl+mmb.

Thank you,
Rickyx

> In #54943#753160, @ideasman42 wrote: > Anything against making "Zoom to Mouse Position" default? I'm sure in every CAD application zoom to mouse position is the default (in many of them there is no option to zoom to center es. AutoCad, SketchUp, Rhino). In [3dMax ](http:*help.autodesk.com/view/3DSMAX/2018/ENU/?guid=GUID-75E03BAB-0D94-43E0-B281-3AE3299BD2B9) zoom to mouse position is the default and there are two options "*Zoom About Mouse Point//" (for Ortho and Persp). In [Modo ](http:*modo.docs.thefoundry.co.uk/modo/701/help/pages/modointerface/KeyboardShortcuts.html) I think zoom to mouse position is the default and there is an option "*Wheel Zoom at Mouse Cursor//". @AnadinX said that zoom to mouse position is the default in Cinema4d. In the printing application Cura the option "*Zoom toward mouse direction*" is on by default. In Maya there is an options, but the default is to the center of the screen (but some people are [changing it ](https:*forums.autodesk.com/t5/maya-modeling/how-to-zoom-to-mouse-cursor/td-p/4046022)).*Can someone confirm my research, specially for 3dMax and Modo, I did by mind and I can't check right now.// Other than that, this is the default in every 2d application , ex. Adobe Suite (starting from Acrobat Reader to Photoshop to Illustrator, ecc...), Corel soite, Gis applications (ex. QGis, most of Esri Suite), Gimp, Inkscape, Krita, ecc... ( I don't like the words "industry default" but this is exactly the case, except for Maya ). In audio editing this is the default and even in google maps or openstreetmap... I agree to have this option default on because you can control two screen movement with a single hand, in a single operation. More than that, I think that in Blender, having this option off, is a duplicate: **you can always zoom to center using Ctrl+mmb**. Thank you, Rickyx

In #54943#753815, @Rickyx wrote:

I'm sure in every CAD application zoom to mouse position is the default (in many of them there is no option to zoom to center es. AutoCad, SketchUp, Rhino).

That is a broad statement. The one I use (Catia) certainly doesn't have it as default. Some of the others, I'd need to check next week.

Notwithstanding, I think for 2D editors this type of behaviour makes sense.

> In #54943#753815, @Rickyx wrote: > > I'm sure in every CAD application zoom to mouse position is the default (in many of them there is no option to zoom to center es. AutoCad, SketchUp, Rhino). > That is a broad statement. The one I use (Catia) certainly doesn't have it as default. Some of the others, I'd need to check next week. Notwithstanding, I think for 2D editors this type of behaviour makes sense.
No description provided.
> In #54943#754118, @ZsoltStefan wrote: >> In #54943#753815, @Rickyx wrote: > >> > That is a broad statement. The one I use (Catia) certainly doesn't have it as default. Some of the others, I'd need to check next week. > Sorry, you're right, I didn't take Catia into consideration. However, by extending the list: in Inventor [Zoom to mouse position ](https://knowledge.autodesk.com/support/inventor-products/learn-explore/caas/CloudHelp/cloudhelp/2016/ENU/Inventor-Help/files/GUID-575A717E-1123-49B0-A3C4-2A66CEBFCAA7-htm.html) is the default in Solid Works [Zoom to mouse position ](http://help.solidworks.com/2017/English/SolidWorks/sldworks/t_zoom_in_out.htm) is the default In Revit, BricsCad, IntelliCad (and IntelliCad based software ex. ProgeCad) and FreeCad in the open source world, this is alse the default I couldn't find informations about SolidEdge. Thank you, Riccardo
Member

I use zoom to mouse therefore +1 to making it default, or at least trying, and then we can see if there is an outcry with any convincing arguments against it. Existing users can change it to whatever they want anyways, the important question in my mind is, what's best for new users? I think zoom to mouse is easier to use since it lets you spend less time panning the view to get to where you want to be.

you can always zoom to center using Ctrl+mmb

I think this isn't true though, the setting seems to affect ctrl+mmb zooming also.

I use zoom to mouse therefore +1 to making it default, or at least trying, and then we can see if there is an outcry with any convincing arguments against it. Existing users can change it to whatever they want anyways, the important question in my mind is, what's best for new users? I think zoom to mouse is easier to use since it lets you spend less time panning the view to get to where you want to be. > you can always zoom to center using Ctrl+mmb I think this isn't true though, the setting seems to affect ctrl+mmb zooming also.

In #54943#754355, @Mets wrote:

you can always zoom to center using Ctrl+mmb

I think this isn't true though, the setting seems to affect ctrl+mmb zooming also.

In the 2.80 you are right, in 2.81 alpha it is true, the Ctrl+mmb is unlinked from the option (tested just in Linux).

Having the default option enabled and the possibility of having a command to override it is an interesting possibility.

> In #54943#754355, @Mets wrote: >> you can always zoom to center using Ctrl+mmb > > I think this isn't true though, the setting seems to affect ctrl+mmb zooming also. In the 2.80 you are right, in 2.81 alpha it is true, the Ctrl+mmb is unlinked from the option (tested just in Linux). Having the default option enabled and the possibility of having a command to override it is an interesting possibility.

I am strongly averse to zoom to mouse position, it gives me chills!!
It doesn't feel right as the mouse can be anywhere on the screen and most of the time I am not consciously trying to control where the mouse is positioned for zoom. It causes dissonance as I see the zoom doing such an unpredictable movement.

In #54943#754355, @Mets wrote:
I think this isn't true though, the setting seems to affect ctrl+mmb zooming also.

This should be a separate setting, I can live with zoom to mouse position if Ctrl+mmb doesnt have it enabled by default.

I am strongly averse to zoom to mouse position, it gives me chills!! It doesn't feel right as the mouse can be anywhere on the screen and most of the time I am not consciously trying to control where the mouse is positioned for zoom. It causes dissonance as I see the zoom doing such an unpredictable movement. > In #54943#754355, @Mets wrote: > I think this isn't true though, the setting seems to affect ctrl+mmb zooming also. This should be a separate setting, I can live with zoom to mouse position if Ctrl+mmb doesnt have it enabled by default.

I would like to request the following default change: show renderability toggles in Outliner. This was the default before and I don't remember seeing any discussion before it was changed (correct me if I'm wrong).

Right now, only the visibility toggles are shown. I believe both toggles are needed to be able to work with the outliner. In fact, as far as I know there is no other way to turn objects on or off for rendering, than through the outliner.
The current situation leads to a (maybe new) user who turns objects on and off with the eye-toggles, then renders, and gets a completely different rendering, which is confusing. Basically, viewport rendering and F12 rendering get out of sync, and there is no way to see why or to remedy the situation.

I would like to request the following default change: show renderability toggles in Outliner. This was the default before and I don't remember seeing any discussion before it was changed (correct me if I'm wrong). Right now, only the visibility toggles are shown. I believe both toggles are needed to be able to work with the outliner. In fact, as far as I know there is no other way to turn objects on or off for rendering, than through the outliner. The current situation leads to a (maybe new) user who turns objects on and off with the eye-toggles, then renders, and gets a completely different rendering, which is confusing. Basically, viewport rendering and F12 rendering get out of sync, and there is no way to see why or to remedy the situation.
Member

I think those options(Selectability, Enable and Render toggles) were hidden by default because they were deemed to make the outliner look too confusing. I also disagree with the decision though. The render toggle at least should be there by default.

I think those options(Selectability, Enable and Render toggles) were hidden by default because they were deemed to make the outliner look too confusing. I also disagree with the decision though. The render toggle at least should be there by default.

Ok I have another request. In the file open dialog, the "Volumes" list is minimized. I think this should start out maximized, showing where you can navigate to your other hard (or logical) drives. I have witnessed it first hand more than once that newbies can't find where to change to another drive. The nonstandard file browser is already hard enough to learn. Hiding basic file browser functions like drives is making it worse.

Ok I have another request. In the file open dialog, the "Volumes" list is minimized. I think this should start out maximized, showing where you can navigate to your other hard (or logical) drives. I have witnessed it first hand more than once that newbies can't find where to change to another drive. The nonstandard file browser is already hard enough to learn. Hiding basic file browser functions like drives is making it worse.

Added subscriber: @Harley

Added subscriber: @Harley

In #54943#759256, @ZsoltStefan wrote:
Ok I have another request. In the file open dialog, the "Volumes" list is minimized. I think this should start out maximized, showing where you can navigate to your other hard (or logical) drives.

I have seen @Harley and several other people ask for this too.

> In #54943#759256, @ZsoltStefan wrote: > Ok I have another request. In the file open dialog, the "Volumes" list is minimized. I think this should start out maximized, showing where you can navigate to your other hard (or logical) drives. I have seen @Harley and several other people ask for this too.
Contributor

Yes, +1. Having volumes closed by default is very frustrating. All the more frustrating is the fact that things like these save per scene. Which rollouts are open and closed in the file browser is something that should be stored within user preferences, not within file. It's not something one wants to constantly configure per file.

Yes, +1. Having volumes closed by default is very frustrating. All the more frustrating is the fact that things like these save per scene. Which rollouts are open and closed in the file browser is something that should be stored within user preferences, not within file. It's not something one wants to constantly configure per file.

Added subscriber: @CarlG

Added subscriber: @CarlG

Agree that "zoom to mouse position" should be enabled by default. A colleague recently installed Blender and his first question was "how do you zoom in to where the mouse is", followed by "why would somebody leave this off" when I explained it.

Solidworks does have zoom to mouse position enabled by default as stated. But it also zooms out from center, which I have a really hard time getting used to. Devs there just decided for us that this is how they think it should be done.

So I would actually prefer two settings; zoom to mouse position - on by default, and zoom from mouse position - on by default.

And why the heck isn't there an option to have Load UI turned off by default? Every file I use, incl my own, I have turn off this thing. Only times I leave it on is if a problem .blend has been shared and it works with my gui and I want to double check using the icluded gui.

Agree that "zoom to mouse position" should be enabled by default. A colleague recently installed Blender and his first question was "how do you zoom in to where the mouse is", followed by "why would somebody leave this off" when I explained it. Solidworks does have zoom to mouse position enabled by default as stated. But it also zooms out from center, which I have a really hard time getting used to. Devs there just decided for us that this is how they think it should be done. So I would actually prefer two settings; zoom to mouse position - on by default, and zoom from mouse position - on by default. And why the heck isn't there an option to have Load UI turned off by default? Every file I use, incl my own, I have turn off this thing. Only times I leave it on is if a problem .blend has been shared and it works with my gui and I want to double check using the icluded gui.

In #54943#761681, @CarlG wrote:
why the heck isn't there an option to have Load UI turned off by default?

There is:
image.png
Requested many times to be disabled by default, but no luck. This is a nightmare, specially for new users.

> In #54943#761681, @CarlG wrote: >why the heck isn't there an option to have Load UI turned off by default? There is: ![image.png](https://archive.blender.org/developer/F7701874/image.png) Requested many times to be disabled by default, but no luck. This is a nightmare, specially for new users.

Added subscriber: @EmbassyOfTime

Added subscriber: @EmbassyOfTime

I recently found out it even existed, and I feel cheated for not having known about this wonderful thing before! I defintely feel making it default is worth it. It's easier to turn something off that you immediately know exists than to turn something on that you may not notice exists for a long time... Okay, that argumnt is ripe for abuse, but I still support making this default...

I recently found out it even existed, and I feel cheated for not having known about this wonderful thing before! I defintely feel making it default is worth it. It's easier to turn something off that you immediately know exists than to turn something on that you may not notice exists for a long time... Okay, that argumnt is ripe for abuse, but I still support making this default...

Another thing: is there any reason for lock object mode be enabled by default?

Another thing: is there any reason for lock object mode be enabled by default?

In #54943#761682, @TheRedWaxPolice wrote:
Requested many times to be disabled by default, but no luck. This is a nightmare, specially for new users.

I find the persistent UI is pretty fundamental to advanced work in Blender when you're using all the features of the customizable UI to their best effect. I would worry that in turning it off by default many users might never find out Blender has this rather powerful and unusual feature.

Absent a Blender 101 or a Beginner Profile, there could be a "How to setup Blender as a Beginner" document or video that recommends various Preference and config/default changes for those starting out (such things may already exist in the community).

I do feel that not loading the UI should be the default when you're about to load a pre-current-major-version .blend, specifically when you are loading a <=2.79 file into >=2.80, because the converted 2.79 UI elements and Spaces to Workspaces conversion leaves you with kind of a mess. And a lot of new 2.80 users will open a 2.79 file as their first action and lose a bunch of the 2.80 UI setup. Not sure how to implement this without a separate config option / Open option for "old files" or something, since we don't know until we open the file what version it is (maybe having the file browser peek into the file when you select it would be fine though).

> In #54943#761682, @TheRedWaxPolice wrote: > Requested many times to be disabled by default, but no luck. This is a nightmare, specially for new users. I find the persistent UI is pretty fundamental to advanced work in Blender when you're using all the features of the customizable UI to their best effect. I would worry that in turning it off by default many users might never find out Blender has this rather powerful and unusual feature. Absent a Blender 101 or a Beginner Profile, there could be a "How to setup Blender as a Beginner" document or video that recommends various Preference and config/default changes for those starting out (such things may already exist in the community). I do feel that not loading the UI should be the default when you're about to load a pre-current-major-version .blend, specifically when you are loading a <=2.79 file into >=2.80, because the converted 2.79 UI elements and Spaces to Workspaces conversion leaves you with kind of a mess. And a lot of new 2.80 users will open a 2.79 file as their first action and lose a bunch of the 2.80 UI setup. Not sure how to implement this without a separate config option / Open option for "old files" or something, since we don't know until we open the file what version it is (maybe having the file browser peek into the file when you select it would be fine though).
Member

Removed subscriber: @Jeroen-Bakker

Removed subscriber: @Jeroen-Bakker

Added subscriber: @hadrien

Added subscriber: @hadrien

Zoom to mouse position is pretty much unusable with a tablet, as it continually reframes the viewport as @jeacom said, but that's not the majority of users I guess. I personally keep it off but I couldn't care less about the default.

Zoom to mouse position is pretty much unusable with a tablet, as it continually reframes the viewport as @jeacom said, but that's not the majority of users I guess. I personally keep it off but I couldn't care less about the default.

In #54943#761682, @TheRedWaxPolice wrote:

In #54943#761681, @CarlG wrote:
why the heck isn't there an option to have Load UI turned off by default?

There is:
image.png
Requested many times to be disabled by default, but no luck. This is a nightmare, specially for new users.

I do agree with @Zoot.
Ex. if you open my file with the default interface you can hardly discover all the work I did on the text editor.

> In #54943#761682, @TheRedWaxPolice wrote: >> In #54943#761681, @CarlG wrote: >>why the heck isn't there an option to have Load UI turned off by default? > > There is: > ![image.png](https://archive.blender.org/developer/F7701874/image.png) > Requested many times to be disabled by default, but no luck. This is a nightmare, specially for new users. I do agree with @Zoot. Ex. if you open my file with the default interface you can hardly discover all the work I did on the text editor.

In #54943#765539, @Rickyx wrote:

In #54943#761682, @TheRedWaxPolice wrote:

In #54943#761681, @CarlG wrote:
why the heck isn't there an option to have Load UI turned off by default?

There is:
image.png
Requested many times to be disabled by default, but no luck. This is a nightmare, specially for new users.

I do agree with @Zoot.
Ex. if you open my file with the default interface you can hardly discover all the work I did on the text editor.

True, many users display the "Readme" in the file using the text editor

> In #54943#765539, @Rickyx wrote: >> In #54943#761682, @TheRedWaxPolice wrote: >>> In #54943#761681, @CarlG wrote: >>>why the heck isn't there an option to have Load UI turned off by default? >> >> There is: >> ![image.png](https://archive.blender.org/developer/F7701874/image.png) >> Requested many times to be disabled by default, but no luck. This is a nightmare, specially for new users. > > I do agree with @Zoot. > Ex. if you open my file with the default interface you can hardly discover all the work I did on the text editor. True, many users display the "Readme" in the file using the text editor

This commit 454c1a5de4 adds two new object properties: Fix Poles and Preserve Volume, which are enabled by default for the new objects, but remain disabled for default cube and quad sphere objects in General and Sculpting templates.

Maybe it's time to rethink how default scenes are created? So devs won't have to manually tweak default scenes when they get out of sync again.

This commit 454c1a5de4 adds two new object properties: `Fix Poles` and `Preserve Volume`, which are enabled by default for the new objects, but remain disabled for default cube and quad sphere objects in General and Sculpting templates. Maybe it's time to rethink how default scenes are created? So devs won't have to manually tweak default scenes when they get out of sync again.

Added subscriber: @xan2622

Added subscriber: @xan2622
Philipp Oeser removed the
Interest
User Interface
label 2023-02-10 09:26:14 +01:00
Member

Closing, since defaults are best discussed in the relevant module nowadays.

Closing, since defaults are best discussed in the relevant module nowadays.
Blender Bot added
Status
Archived
and removed
Status
Confirmed
labels 2024-03-03 04:58:13 +01:00
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset System
Interest
Audio
Interest
Automated Testing
Interest
BlendFile
Interest
Blender Asset Bundle
Interest
Code Documentation
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
FBX
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
USD
Interest
UV Editing
Interest
Undo
Interest
User Interface
Interest
VFX & Video
Interest
Video Sequencer
Interest
Viewport & EEVEE
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest
glTF
Interest: X11
Legacy
Asset Browser Project
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Asset System
Module
Core
Module
Development Management
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Module
Viewport & EEVEE
Platform
FreeBSD
Platform
Linux
Platform
Windows
Platform
macOS
Severity
High
Severity
Low
Severity
Normal
Severity
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
58 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#54943
No description provided.