Blender 2.8 Defaults #54943
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
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, Assets & 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
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
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
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
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
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#54943
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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- prefsbcf6cc1f6b- startup./release/datafiles/userdef/userdef_default.cPreferences
Default Settings
Default Renderer
Layout
New Objects
Default Theme
Tools
Vertex Slide:
Extrude Along Normals:
Laplacian Smooth:
UV/Image Editor
Weight Painting
Cycles
New Objects
Preferences
Text Editor
Addons
Added subscribers: @WilliamReynish, @pablovazquez
Blender Defaultsto Blender 2.8 DefaultsAdded subscriber: @Sergey
Added subscriber: @ErickNyanduKabongo
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
If I may :
Preferences > Interface :
Preferences > system :
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 :
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
For add-ons some quick outlines:
Added subscriber: @mendio
Added subscriber: @L0Lock
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
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 :
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.
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.
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.
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
I'd like to add votes for
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) .
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.
Added subscriber: @Rawalanche
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
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.
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.
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.
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.
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.
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
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.
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% :)
Added subscriber: @JulianEisel
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:
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.
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.
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.
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.
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.
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.
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.
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
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.
Added subscriber: @bdp
suggest : in timeline show keyframes only to selected objects
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 ]]
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
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.
Again, that's a feature that does not exist, and it's a separate thing. Off topic.
Added subscriber: @pragma37
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.
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 ^^
Added subscriber: @ZsoltStefan
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.
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
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.
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
Default settings
Layout
New Objects
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.
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 ;)
Added subscriber: @s12a
This comment was removed by @s12a
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
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
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.
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.
Concerning the transparent header, the text color (for the menu pop-overs):
It's very easy for it to blend with the current color in the viewport otherwise.
It's on the todo :)
Pose mode: relationship lines OFF
?
They just have to do something like this.
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
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.
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
My 2 Cents on this topic if i may:
Cycles
UV/Image Editor
Theme
Addons
Keymap
Display
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.
Added subscriber: @softyoda
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)
Node Wrangler enabled by default.
Some addons should be enabled by default.
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.
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 :)
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):
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.
Added subscriber: @Rickyx
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.
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 ;)
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).
Added subscriber: @ViktorJamrich
An outsiders opinion if I may:
Bevel
Rationale
Clamp Overlay OFF
Clamp Overlay ON
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
Removed subscriber: @DuarteRamos
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
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
more like this
Also toggle buttons could use some 2D/3D effect to emphasize their state.
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 :
Here is a proposal that seems more readable to me :
@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.
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.
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.
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.
If the similar is already in 2.8 it will be very good.
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 )
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
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.
Great news.
Cheers...
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.
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.
+1 for a fix on floating windows ^^
Could it be possible to add an option to show directly the HSV?
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
@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
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:
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?
(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
@gobb_blend As to if the metric system being the default; probably.
As to the units; it starts here:
And (in my view at least) it ends here:
Happy Reading!!!
RGB color can be made as in all editors by whole values?
Red 255
Green 255
Blue 255 = White color!
@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.
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
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.
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).
I suggest to have, in the user preferences, Zoom to mouse position active:
I can't see any particular side effect on having it on by default.
Thank you,
Riccardo
Removed subscriber: @gobb_blend
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.
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.
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.+ Newbutton 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.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
@DuarteRamos i totally second these improvements :), same with what @DanPool says.
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.
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
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.
Except this isn't how colour works, so a Very Bad Idea™.
Removed subscriber: @pragma37
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?
What does that even mean?
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.
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...
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.
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
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.
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
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
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
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.
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.
![9vbSh6J- [x].png](https://archive.blender.org/developer/F5024884/9vbSh6J_1_.png)
![Bdf9XIb- [x].png](https://archive.blender.org/developer/F5025007/Bdf9XIb_1_.png)
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.
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.
Added subscriber: @Ko
Maybe self-collision setting of cloth simulation ON by default?
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. ✌
This issue was referenced by
39b1e66afdAuto 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.
@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
@ManuelGrad: Yes I think that makes sense. I added these two items to the list..
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.
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.
@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.
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
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.
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.
@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
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
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.
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
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.
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.
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?
Removed subscriber: @moisessalvador
@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
That would be great :)
Added subscriber: @Mets
+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.
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.
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
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
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! ?
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 :
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
@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.
Added subscriber: @crantisz
Added subscriber: @GavinScott
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.
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
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 @Rawalanche , maybe a poll on Blender Talk or something?
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.
Added subscriber: @HooglyBoogly
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.)
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
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.
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.
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.
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.
Added subscriber: @Harley
I have seen @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.
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.
There is:
Requested many times to be disabled by default, but no luck. This is a nightmare, specially for new users.
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...
Another thing: is there any reason for lock object mode be enabled by default?
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).
Removed subscriber: @Jeroen-Bakker
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.
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
454c1a5de4adds two new object properties:Fix PolesandPreserve 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
Closing, since defaults are best discussed in the relevant module nowadays.