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

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.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.

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 @Duarte Farrajota Ramos (duarteframos) , 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.

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.

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

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

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?

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

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.

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


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.

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

@TheRedWaxPolice (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.


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.

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.

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.

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

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.

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.

YAFU (YAFU) added a comment.EditedOct 10 2018, 1:39 AM

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.

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

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:


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.

-L0Lock- added a comment.EditedOct 11 2018, 12:38 PM

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

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 :


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.

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.

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

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

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

Mets 3D (Mets) added a subscriber: Mets 3D (Mets).EditedJan 20 2019, 8:59 PM

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.

@Mets 3D (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.