Page MenuHome

Blender 2.8 Defaults
Open, NormalPublic

Description

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:

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

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

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.

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.

@Ludvik Koutny (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

@Manuel Grad (manitwo): Yes I think that makes sense. I added these two items to the list..

@Ludvik Koutny (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.

@Ludvik Koutny (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.

@Ludvik Koutny (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:


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.

@Ludvik Koutny (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.

@Ludvik Koutny (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.

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.

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. :)

Dan Pool (dpdp) added a comment.EditedNov 28 2018, 1:47 AM

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 T54943#559093, @Ludvik Koutny (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 T54943#559093, @Ludvik Koutny (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.

@Zsolt Stefan (zsoltst) @Dan Pool (dpdp)

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.

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.

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.

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.

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.

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?

@Roger B (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

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

+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?

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.

Zukin (zuokre) added a subscriber: Zukin (zuokre).EditedJan 31 2019, 2:12 PM

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.

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:

With collapsed source list:


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.

@Demeter Dzadik (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.

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

-L0Lock- added a comment.EditedFeb 12 2019, 12:19 AM

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.

@Campbell Barton (campbellbarton) @Bastien Montagne (mont29) Can you agree on the following changes:

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

@William Reynish (billreynish) 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.

@Campbell Barton (campbellbarton) @Bastien Montagne (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.

@Campbell Barton (campbellbarton) @Bastien Montagne (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.

Anything against making "Zoom to Mouse Position" default?

4 people have suggested this so far.

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.

Anything against making "Zoom to Mouse Position" default?

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

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 @Ludvik Koutny (rawalanche) , maybe a poll on Blender Talk or something?

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).

@William Reynish (billreynish) 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.

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.)

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".
@Andrei Nadin (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

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.

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 is the default
in Solid Works Zoom to mouse position 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

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.

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.

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 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 seen @Harley Acheson (harley) and several other people ask for this too.

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.

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.

why the heck isn't there an option to have Load UI turned off by default?

There is:


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

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?

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).

Zoom to mouse position is pretty much unusable with a tablet, as it continually reframes the viewport as @Jean Da Costa (jeacom256) 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.

why the heck isn't there an option to have Load UI turned off by default?

There is:


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

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

why the heck isn't there an option to have Load UI turned off by default?

There is:


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

I do agree with @Gavin Scott (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