Blender Default Settings: Preferences #37518
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
44 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#37518
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?
Accepted Changes
These changes have been discussed and approved by UI leads. Add your own suggestions and/or arguments for/against any items in the comments.
Continuous Grab: ON
This makes it possible to freely drag number values even if the value is close to the edge of the screen.
Also fixes issues with the number fields where they exponentially loose precision the more you drag them.
(This was previously left off by default because of an issue with Wacom tablets on OSX that is now fixed.)
Save Versions: 1
Having both .blend1 and .blend2 is a bit much when we also have autosave.
Auto Save Timer: 2mins (down from 5)
Cursor Depth: ON
More intuitive to have 3D cursor snap to surface under mouse and more useful for placing objects.
Ask to Save: ON
This is a Windows only feature, but should be enabled. It's on for OS X but quitting from the File Menu does not ask. Linux does not yet have the feature. Added task here: #37602
Mesh Option: Double Sided - OFF
Double sided geometry causes significant slow downs on most Nvidia machines, due to a bug in their driver. Until this is fixed by Nvidia double sided off gives much greater performance.
Rejected Changes
These changes have been discussed and the decision has been made to leave as is.
Auto Perspective: ON
Most of the time when switching to a side view or top view, you'd want it to be orthogonal.
Guessing perspective/ortho for the user can be problematic especially when mixing camera switching and axis-snapping, its not always possible to make a good guess, so better keep behavior deterministic & pradictable. See: #40153
MultiSample: 4
Anti-Aliasing in the 3D View improves visual clarity, and is calmer to look at for long periods of time. This is very slow on some systems
44fe9fe17bRegion Overlap: ON - the current implementation is too slow
This means that the content of views don't move around when you enable Tool (T-key) or Region (N-key) panels.
Python Tooltips: OFF - these are used by both developers and artists alike, and also essential for riggers working with drivers.
Python tooltips can be distracting for users that do not need them. But this would also force many people that do use them (approx 16% according to @AndrewPrice's survey) to re-enable them. Needs more discussion and waits on improvements from #37478 before determining.
Allow Negative Frames: ON - this can cause problem with audio sync.
Proposed below, but we don't really know the pros/cons, need feedback from animation module team.
Rotate Around Selection: ON - the current method causes problems when working with large scenes and many people find it to be quite annoying.
Makes view rotation focus on selected objects.
Changed status to: 'Open'
Added subscribers: @billrey, @brecht, @JonathanWilliamson, @pablovazquez, @AndrewPrice, @d-medvedev, @hjaarnio, @ThomasDinges, @oenvoyage, @PawelLyczkowski-1
I'm good with all of these.
In addition, I would add Rotate Around Selection. It's the first thing I turn on and makes navigating the view and keeping track of your selected object much easier.
Also, I suggest Trackball as the orbiting style. It provides much more versatile 3D View movement. However, I recognize that this is largely personal preference.
@billrey I agree with all of these.
I would add MultiSampling(Anti-Aliasing) if there are no major drawbacks - The programs looks much more modern with it. I don't think it affects the performance that much on current machines.
@JonathanWilliamson I disagree with Trackball - It is a more versatile orbiting style, but also harder to use - it is easy to get lost when using it, and hard to discover how to realign your view again. In Turntable up is always up. I think the defaults should put you in the easy modes, with the possibility to turn on the harder ones later on.
@PawelLyczkowski-1 that's a fair argument.
@JonathanWilliamson:
Rotate Around Selection I think makes sense.
Trackball I'm not sure about - I understand the added view flexibility, but it can easily get out of hand, because it relies of the exact cursor placement on the screen when dragging the view. Additionally, it's often confusing to have the orientation mangled :)
@PawelLyczkowski-1: I agree with Anti-Alilasing being on by default. I believe it automatically gets disabled on hardware that doesn't support it anyway.
@billrey @PawelLyczkowski-1, does Anti-Aliasing slow down performance much? It was my impression that it took a pretty significant hit.
@JonathanWilliamson: Would be useful to conduct some performance tests.
Anecdotally, I get the exact same framerate on an animation sequence I'm doing (20fps) with Anti-Aliasing off or set to 4. I know this is not full test, it'd be nice if you could do some tests too perhaps?
@billrey I'll try and do some tests soon. For now I'm good with making it on by default.
Added subscriber: @GabrielGazzan
Continuous Grab: ON
Auto Perspective: ON
Rotate Around Selection: ON
Compute Device: CUDA
I second those ones too.
..and I would suggest these ones also:
Python Tooltips: OFF
it makes tooltips harder to read and most people don't make use of them anyway.
Prompt Quit: ON
for security reasons. besides, people is not leaving Blender too often as to make a significant difference when the option is on.
Undo Steps: 64
New systems have plenty of memory, so why don't put it on a high value.
(also, why not raise the maximum possible value to something higher than 64?)
Greetings to all and thanks for your efforts!
My two cents as a user:
Cursor Depth: On
Is much more intuitive to click on a surface and have the 3D Cursor stick to it, rather than floating on the space. I've seen beginners do this expecting it to happen, until they know is an option that can be turned on.
Continuous Grab: Please oh please On
Tooltips: On
Automatic File Saving:
Save Versions: 1 (from 2)
.blend1 and .blend2 seems a bit much. I have rarely used .blend2, and it clutters the folders. But this might be because I save so often that .blend1 and .blend2 are almost useless, only .blend1 saved my life in many occasions.
**Timer (mins):**2 (from 5)
I have yet to see a time I've had noticed the time where Blender saves this file, I have it set to 1 min locally and never noticed Blender blocked or something because of this, not with a computer from the nineties nor one nowadays. Perhaps 1 is too much, but 2 might be a good number that will help when having crashes and having to recover (especially now that the recover systems works awesomely!)
About AA, is the problem with vertex selection fixed? I remember it being an issue but I haven't tested it enough (did quick test now and seems to work fine, will leave it on to test), because I was paranoid on it using resources. I just tested an animation file that runs at 21 FPS with or without AA, and looks gorgeous. There is only one small glitch while on Wireframe view, when (de)selecting all then transforming vertices, results in the whole mesh a bit thicker after (de)selecting, and gets back to normal while transforming (NVIDIA 460 GTX, Driver 319.32 on Ubuntu GNOME 13.10)
The CUDA default is already discussed in this task: #37474 (Blender Default Settings: Cycles).
Viewport AA: the problem with AA and selection should be fixed now, but it does use some extra GPU memory (which some people doing GPU rendering may not like). Enabling AA on modern cards should not give a big performance hit because Blender is so inefficient in OpenGL drawing in other ways that this is essentially free (except maybe with complex GLSL shaders). For older cards that just started supporting this feature I imagine that is not the case, but it's probably not too bad.
Edit: I just realized you are talking about the Region Overlap option which is poorly placed in the user preferences and is not related to the Window Draw Method at all.
I agree on Continuos grab, missed this since it was disabled back then. :)
@venomgfx: Good points, Cursor Depth is really nice to have on. Without it, the 3D cursor frequently tends to shoot off into space :)
@brecht: I thought the Region Overlap option was indeed related to the draw method, as it needs to do some kind of deferred rendering in order to composite the regions? Anyway, I've tested this option with all sorts of machines, and it seems to work fine.
Added subscriber: @Lapineige
Well this topic has been a great learning experience for me. Never even knew Cursor Depth or Region Overlap existed. And wow are they handy :) The Rotate around selection is too, but users will need a big heads up if it's made default (like most of these changes probably).
On a side-note, is there a way to make popup menus not shift? For example, when you're in edit mode and creating seams you hit Ctrl-E a lot, but when the cursor is too close to the edge of the screen the menu shifts, so you end up clicking something else by accident. Same happens a lot with the W menu.
Is this easily fixable?
Regrading popup menu location, see #32542 (Wrong auto choice in menus based on mouse position).
You could open a design task for that. If there is a design decision on that it's probably not hard to implement (depends on the chosen design of course but that's my guess).
Added subscriber: @sozap
I agree with much of ideas here, I'll add allow negative frame = ON , I was talking with an animator at lunch that found it useful , for example to store temporary keyframes , I don't see any downside to it...
@GabrielGazzan and @JonathanWilliamson : I thinkAuto-Perspective should beOFF , when it's enabled it's impossible to be in orthographic perspective, that I found useful to switch to from time to time. I think it can give a clearer view of a big set for example...
Also, maybe auto-run python script= OFF has 2 or 3 times get me some trouble. even if it's ON on my computer, it's not always the case in other's . One of my client think the rig I send him half worked because of that, and in one other case it was impossible to run an import camera script that we wanted to run (after effect to blender).
It's hard for beginners (even experienced users) to guess that things won't work out of the box.But it's also true that one's can do very bad hidden python black magic. I have just tried it OFF right now, the new error message is nice, maybe it's should be more visible, with a red background for instance ?
@sozap: you can easily get an orthographic perspective ("user view", should I say?) by pressing Numpad 5 key, and in my opinion is far less common to need that, than to be constantly having to switch from perspective to orthographic when you go to top/front/side views.
@GabrielGazzan , hum true, but when you rotate the view it switch back to perspective, that's really annoying. In fact it makes the 5 shortcut completely useless.
And on the other hand, if you work in ortho , you don't have to change when you switch to top/front view.
Current default work fine for me, but I guess it really depends on personal workflow.
@sozap The decisions made here are not based on single scenarios that are annoying, but rather on how often settings work well in various workflows. Rotating the view in orthographic mode is rather specific, so for this specific workflow the user can change the preferences.
Added subscriber: @BartekMoniewski
@brecht Okay thanks for the link. Wasn't aware it had been mentioned before. I'll have a think about the best way to implement it.
Since we're talking about Defaults, there are two big issues that I think should be discussed:
1. Python Tooltips
Ton recently stated that*"Blender is for artists"//, so I think the defaults of Blender should have artist's best interests in mind.
The problem with Python Tooltips is that:
1: The information isn't useful to artists
2: It makes the tooltips much larger and wordy then they need to be
To quote a UI book:
"Tell users explicitly and exactly what they need to know. Don’t expect them to deduce information. Don’t require them to figure things out by a process of elimination."
The danger of Python Tooltips [being on by default] is that it can scare new users at a time when they are most vulnerable; learning the functions of Blender.
I can understand their importance and usefulness from a developer's point of view, but since developers know Blender's functionality better than anyone, I think they would have an easier time turning it on, then new users discovering it and turning it off.
For user feedback, I surveyed the community and out of 4,546 votes,*84%were in favor of Python Tooltips beingturned off// by default. After the conference, Ton briefly mentioned that he was in favor of it too ("provided the people who use it know where to turn it on").
I realize the awkwardness of this request, since I'm asking developers to turn something off which they use everyday. But I think it will ultimately increase satisfaction for users, make Blender seem a little bit more friendly, and hopefully retain more users :)
2. Asking to Save
I addressed this thoroughly in an earlier video, but in a nutshell:
Blender asking to save on close is important because:
And for community feedback, 96% out of 10,331 were in favor of Blender asking to save by default.
Thoughts?
These were mentioned briefly above by others above, but I didn't see any replies so I wanted to address it fully and ask for thoughts. Yay or nay?
Added subscriber: @WilliamJack
Continuous grab: ON. Please Please Please. I have to turn it back on with every new release.
Almost reported it as a bug back when it was disabled.
Trackball: OFF !
I would almost go so far as to say remove trackball but that would be mean. We hates it precious yes we do.
Auto-Perspective: ON
Way more common to need ortho in the perpendicular views. I agree with @plyczkowski.
@AndrewPrice: Thank you for the surveys. Very helpful for these discussions.
@sozap: I'll have to agree the functionality of the Numpad 5 key is somewhat strange.
I think when the user is in a perpective view and switches it to an ortho view with the 5 key, the view should stay ortho when rotated.
On the contrary, if you enter a front, left or side view I find it useful that rotating it let's you go out of orthographic view mode into a normal perpective view.
But then, this discussion is about good defaults, not so about features.
@AndrewPrice:
I esentially agree on the two points.
@GabrielGazzan, @sozap, @WilliamJack, regarding Auto Perspective. I agree this should be on by default, but not until the behavior is improved. As pointed out already by @sozap it currently makes orbiting in orthographic next to impossible. Once this issue is fixed then I'm happy to add Auto-Perspective to the defaults list. I've added a bug report here: #37586
Ask to Save I believe this is a Windows only (and maybe Linux?) problem. Mac OSX does not have a ask to save option, it just always asks if the file hasn't been saved. But yes, it should be enabled by default.
Python Tooltips
This one seems to be split roughly down the middle between all of us. It's more useful to developers than artists, but there's a lot of technical artists (such as myself) that also use them constantly. I think Brecht and I may need to just make a call on this one. However, I don't think we'll do that until the improved tooltips are done: #37478
@JonathanWilliamson Currently when orbiting with MMB, when you start pressing alt, the view starts snapping to even views (Left, Right etc). But it's currently ignoring the Auto Perspective Setting. Maybe you could add it to the task.
@JonathanWilliamson
I understand that technical artists like yourself use python tooltips, but I think that's very much the exception. The number of users that dabble in Python is probably very low. 16% according to the survey.
We need to design for the average user, and I honestly think Python tooltips are strictly a 'power-user' function.
Thomas told me that you can save the user prefs to work across all revisions and new code (unless I'm mistaken), so I don't think having it off by default would inconvenience developers much.
@andrewprice. See #37478 (Improve Tooltips to provide more information) for the tooltip discussion.
But note that we are not designing for the average user, and only 16% of users wanting that feature is not a good reason to remove it. The majority of features in Microsoft Word are only used by an even smaller % of users, but you don't have options to disable them, it is a matter of organizing the UI well instead of hiding such things by default.
We should do a lot more to make Blender easier to learn, but the primary focus of Blender is very much to design something for people with a "serious interest in working with 3D software ".
For everyone: if you are an experienced in animation, compositing, video editing, physics simulation, etc, please do feel free to create a design task with a list of default settings that should be changed in that area.
@JonathanWilliamson and I should probably take a decision soon on these basic settings, otherwise we risk getting into bikeshedding too much.
I'm a bit disheartened to hear that you both see this as a trivial matter. Python Tooltip defaults are a very important issue as they are seen by everyone. I know you didn't intend to brush me off, but it does feel like it.
@brecht You mentioned that Microsoft Word has primarily features that few people use. But I've checked the Windows Official Guidelines , and I don't think this could be possible.
Some relevant passages:
//"Don't be all things to all people. Your program is going to be more successful by delighting its target users than attempting to satisfy everyone. Remember that it is literally impossible to focus on everything."
"...make the default experience the right experience for your target users."
"Solve distractions, not discoverability"
*-source: [Here ]] and [ http://msdn.microsoft.com/en-us/library/dd834141.aspx | Here .
So before we proceed any further, I think we need to be crystal clear on who Blender's target users are. Not just for this decision, but all future decisions. Making compromises in order to appease everyone rarely works and is more than likely to fail.
So who are our target users?
If we're using [Tons statement ]], the target users are clearly noted as artists. He acknowledges that developers use Blender too, but that development use is secondary to the goal:*""Blender is for artists” also means that’s it not a programming API or scripting environment, these are secondary to this goal." *The [ http:*wiki.blender.org/index.php/Dev:Source/UI/guidelines#Blender_Is_For_Artists | Blender UI guidelines by William Reynish state the same: "Blender is not a programming API or scripting environment; these are secondary to the main focus."
I'm not trying to make developers lives harder. I really do respect everything that you guys do, and your needs should definitely be considered. But we are only talking about defaults that can easily changed by those with the most experience.
If there's something I'm missing or not understanding in regards to what this would mean for developers, please let me know.
I think you may be misunderstanding who uses this feature, I never use it for example, for me searching the Blender source code is much faster. I don't know what other Blender developers do, but we indeed are not the target demographic. It is for people who create drivers for animation or automation, do rigging, want to do some quick automation with a script, and yes, also people who write more advanced python scripts like addons. Most of those people are artists, not developers.
In any advanced software most features will only be used by a small % of users, and 16% is a lot. Think of all the advanced software you have installed on your computer and which % of tools and options in them you have actually used, go over the menus and count them, it's not going to be much. If you only show features that are used by 30% of users for example, you're not going to have much left.
See the mockup in #37478#33. The first solution should always be to think about solving problems with design instead of hiding them by default, or even having an option to hide them.
Fair point. I thought it was primarily enabled for developers.
I still think it's an advanced 'power-user' function that should be disabled by default, but I guess we'll have to agree to disagree.
@AndrewPrice, certainly didn't mean to brush you off. Sorry if it came off that way. For now I think it's best we hold off on changing the default on this (not to necessarily keep it on) and to wait until the actual tooltips are improved via #37478. If we can improve the design so as to keep the python info but not make it so distracting to users that don't need it then I think we'll be better off. There's no way that we can make tooltips perfect for everyone, but we can try and present the information that many need within the tooltip.
Let's see where the design goes and then we can make a decision on the default state :)
Added subscriber: @alexjf
Can't a plus sign (or similar) be shown in the tooltip box for users wanting more advanced tips (like Python tooltips) to click on it?
Please discuss Tooltip related improvements in task #37478.
ok, sorry.
Added subscriber: @ideasman42
re: Rotate Around Selection: ON
Strongly disagree with this choice, did anyone try use this for any length of time? ... or for scenes with more then a handful of objects?
In fact I was involved in getting this option added (years ago), but found in general it can get very annoying.
Here is a patch which I think makes the functionality more generally useful.
It uses the selection for depth but always orbits around a point in the middle of the view.
http:www.graphicall.org/ftp/ideasman42/testview_center.diffalternative patch that uses mouse location, nice because if you click over the selection - you rotate about it still*http:*www.graphicall.org/ftp/ideasman42/testview_center_mouse.diff
Further improvements needed:
However this makes me wary of the other decisions too, perhaps we should make sure we have 1-2 weeks testing new defaults first.
Rotating around selection is useful mainly when modeling in Edit Mode.
Perhaps there should be a quick way to toggle between the two orbiting modes with a small button in the header of the 3D Vew or a modifier key while rotating.
Added subscriber: @krupa-2
Committed changes:
c5944812d6Note:
Rotate Around Selectionis currently ON, maybe its best to make some improvements there and see how uses like it.Noticed Brecht changes this after I committed
Thanks @campbellbarton.
Added subscriber: @Senshi
Here's my two cents:
Auto Perspective: ON
The main reason I don't like this feature (at all, but especially as on by default) is that it has Blender making decisions for the user. While this can be a great thing, it can also be very frustrating for a user. If they're in perspective mode they're probably there for a reason. I frequently switch between orthographic and perspective modes myself, also working in both when appropriate. I think it would be very frustrating having Blender switch views "on it's own" for some users, though I do recognize orthographic views are frequently used when switching to a "directional view", for lack of a better term.
Cursor Depth: ON
While I again recognize the problem, I'm also a bit wary that this may confuse some users. Imagine opening Blender for the very first time and trying to get familiar with the cursor. You think you've got it down and decide to place the cursor at the center of the default cube. You enter front view and click near the origin, perfect. You enter side view and click again, lovely! Now the user rotates and, to their surprise, it's not centered, despite having set it from all the needed directions.
Region Overlap: ON
I really don't mind region overlap as it's described here, but this one toggle also introduces transparent panel backgrounds (which are okay I guess, though also a bit less clear imho) and, my main concern, a fade-in and fade-out effect when toggling. Is this really nescessary? Imo it just makes the whole program feel slow and bulky.
It is definitely great to see some activity on this front though!
@Senshi, I agree about not having the panels transparent actually, was not aware this was the default. If we change this we should also change the default transparency on these region backgrounds I think.
Now that I think of it, these also have some performance issues doing too many redraws, I should inspect this code closer to see if it's actually implemented well enough to be on by default.
@Senshi,
Hi, I wasnt so much involved with these decisions, the reasons you give are likely why these options were not enabled by default before.
re:
Auto Perspective: ONagree
re:
Cursor Depth: ONalso agree
re:
Region Overlap: ONno strong opinion, but as brecht says, this has performance issues (runs py scripts to redraw on every update, slowing down animation playback for eg - and general redraw speed)
re: Region Overlap Transparency
This was not intended as part of the change, but is there because the theme color is by default transparent. It's just that the transparency isn't otherwise supported so it wasn't shown. I also vote to make these opaque by default.
As to the others, Auto Perspective, Cursor Depth, personally I don't feel too strongly either way. I think there's very valid arguments for and against each of these. Thanks for the feedback. Let's continue to monitor feedback on each of these. If, after being implemented, there's strong feedback one way or the other then we can either leave changes as they are or change them.
Added subscriber: @GregZaal
I like the proposed changes (though I'd change a few myself, but that's why they're called "preferences" right? :) )
The only issue I see is with anti-aliasing samples on 4 - I noticed a significant performance drop on heavy scenes (from 16 fps to about 4). I'm happy for this change, but I would like to see a wiki page with a list of things that can be turned on/off to improve viewport performance. Perhaps something like this exists, so this could then just be added to it.
I'm also not sure about the 2 minute auto-save - if there's no delay or pause in user-interaction when it saves, it's probably fine. But there has to be some significance right? Does it save during a long render at all, or check if there's changes in the scene first? If it does just save every 2 minutes without checks, that means 30 saves an hour, around 360 saves in one night - that'll probably have some hit in long render times.
Added subscriber: @piotao
Region Overlap ON is messing strongly with Motion Tracker screen. The blue cache line at the bottom of the movie editor is partially hidden by the tools and the properties panels and therefore it is inaccessible, so I have to use Timeliner for scrubbing. This is the only place I noticed that Region Overlap is messing more than it helps.
Cursor Depth really does not belong in the Preferences, as the user can prefer to put the cursor inside an object or on it's surface according to what he is doing at the time. So it can change frequently during one modeling session for example.
But atm, this setting to off feels more natural - the user did not activate any options, so why is the cursor sticking to an object's surface, and not going where he clicked?
I'm not sure about Rotate Around Selection, I will try it soon. Personally I have it off, and use View Selected frequently that is mapped to the spacebar, which gives me 100% control over the view.
Added subscriber: @mark.b.tomlinson
I would add my concerns to those of Greg regarding the 2 minute auto save, this is a lot of saves and on a large file is going to cause lag and potential interruptions to workflow with large blend files. 5 min seems fine with an option to increase the frequency.
Added subscriber: @ConstantinRahn
I like most of the changes.
My 2ct.:
1.)
I suggest to change two colors in the interface:
Preferences->Themes->UserInterface->Regular->InnerSelect
and
Preferences->Themes->UserInterface->Tool->InnerSelect
should have the same color as
Preferences->Themes->UserInterface->RadioButtons->InnerSelected
From POV of the user all buttons are just buttons, and activated buttons should all have the same look (if pressed).
2.)
As default cycles should use "Full Screen" to render the image to. In all other cases cycles has some problems with the refresh of the render progress in combination with the other views/editors. (observed on Windows)
3.) Would it make sense to activate vbo by default? Or are there some side effects?
4.) I would suggest to activate Preferences->File->Compress File. Or are there known problems with it?
Added subscriber: @neXyon
Regarding negative frames: that's very problematic with audio! AV-sync might work with some backends, but I'm pretty sure jack doesn't support negative playback times (jack transport). Also the audio animation doesn't support negative frames, as the animation cache of the audio system uses a cache to store the animation values for each frame. This cache currently grows from frame 0 to the length of the animation, having it grow in the other direction will make things more complicated and performance lower.
Added subscriber: @MikhailRachinskiy
VBOs: ON
I'd like to see this enabled.
Checked out Rotate Around Selected. Seems quite hard to get used to, especially in Object mode, when you objects have their origins not in the center. I vote for Off.
I also propose to turn Rotate Around Selected OFF for now. This feature will be great it rotates on objects bounding box centers instead of pivots.
And I vote to turn VBOs ON, like @MikhailRachinskiy said.
Makes sense to leave it off, agreed. VBO's set to ON seems to speed up display - Is there an issue with VBO's or a reason it was ever set to off?
Added subscriber: @marcog
Tried Rotate around selection deeply in the past but then disabled, quite annoying in lot of situations, for example when visually cecking your verts zoomed in, but a long edgeloop is selected, orbiting around a specific vert is a pain, you just can't.
Example n°2: You're checking/looking at a face or an object unselected, but you have a selected item on the opposite non visivble side of your mesh, again orbiting around to check comfortably is really a PITA.
Side note: There is a quite unknown/obscure function to set the view "pivot" point where you need, it's shift-B (zoom border) it sets comfortably a point in space where you orbit around (and it also zoom of course), though i suspect it's little used/hard to discover, the shift+B keymap isn't that quick. Activating Rotate around selection disable this nice function
@marcog This and View Selected. I use View Selected because it's quicker, but would actually prefer a solution that did not require a selection. I stumbled upon a great one in Unity - alt-MMB-click on any surface, and the view pivot is placed there - very comfortable.
@billrey - Some very old graphics card don't support VBOs. However, today nobody produce GPUs without support of this, even cheap smartphones have it. Question for @brecht- What if someone open blender with VBOs enabled and his 10 years old hardware don't support it? Maybe testing GPU support for OGL version before loading scene can prevent from VBOs errors?
@PawelLyczkowski-1 - indeed agree, a fast keymap to place view pivot would be great, i used it all the time in another package back in the days, now shift+B does this + zooming, works ok but isn't quick.
Even AMD and NVIDIA ain't supporting their 2 years old graphic cards, why should BF do it?
"Del" on numpad is kinda like that
One thing about VBO. According to [this post ]] on cobe.blender blog we move to OpenGL 2.1 now. This mean VBO have to be enabled by default because they are from [ http:*en.wikipedia.org/wiki/Vertex_Buffer_Object | OGL1.5 specification . We can remove them from preferences panel. Be sure to enable it first! ;D
Regrading VBO: the only reason it was not enabled by default is because it was quite unstable when it was added. Now it should be ok to enable, and it will fall back to immediate mode if the GPU does not support VBO's. The only downside is extra GPU memory usage which you might prefer to use for image textures or GPU rendering with cycles.
Regrading Compress File: it's quite slow to save big files with this. If we supported LZO compression instead it could be fast but from experience the GZip we use now slows things down too much when you save often during work.
As far as i know VBO is core feature since OpenGL 1.5 so there should be no problem with older video cards and there is possibility to gracefully degrade.
It provides much better performance in terms of geometry however takes some VRAM.
I vote for making it on by default.
@MikhailRachinskiy
Del on Numpad is View Selected.
Added subscriber: @STEP-ANI-MOTION
@PawelLyczkowski-1 @marcog
You can use ALT-F in object mode to snap the view to the mouse position (with depth).
I've changed the shortcut to "Q" (wich also works in edit mode!) and use it all the time.
Added subscriber: @MarkTitchener
O It's part of the secret knowledge I see - it's not even listed in the View menu.
It's lovely.
I say extend this to all modes, map to modifier+MMB, and advertise as a new feature.
Wow, this is awesome. I found the operator, it's Center View To Mouse (view3d.view_center_pick), I mapped it to Alt-MMB, and it works smoothly in all modes.
Added subscriber: @ZsoltStefan
@STEP-ANI-MOTION Alt-F? Wow thanks for that, I had looked for something like that once or twice and then thought it's simply not implemented in Blender, and used the numpad DEL instead. @PawelLyczkowski-1 I agree, map it rather to a modifier key + mouse click as default, and BAM! great new feature.
Removed subscriber: @GregZaal
Removed subscriber: @mark.b.tomlinson
Yep, Alt+MMB instead of Alt+F is pretty cool, considering Alt+F did not even work in Edit Mode since it is "Fill" operator. Could be a nice Default, tested a bit.
Sadly alt+MMB don't work with third mouse button emulation.
We are going off-topic. ;) This things are for keymap task.
Added subscriber: @cessen
If I may be so bold as to make another suggestion:
The default viewport lens length is currently 35, which is a tad on the wide-angle side of things. Wide-angle lenses (and telephoto lenses) are great for artistic effect, but aren't good for accurately understanding the shape and proportions of what you're looking at. Given the purpose of the 3d viewport, I think we should set its lens size for accurate perception.
For "accurate" perception, it's best for the fov of the viewport to match the portion of the user's fov that the viewport occupies. This can vary quite a bit, of course, depending on a variety of factors:
So there is no perfect setting. But I think somewhere between 45-50 is a good compromise between small subdivided viewports and large monitors with full-screen viewports. So perhaps 45 to be conservative about the change.
@cessen I agree. Perspective distortion is bad for many things, especially for character work. If someone never stopped to wonder why it's hard for them to find good proportions for their characters - it maybe that the default lens length is making things harder for them. I have it on 50, I guess 45 would be a good compromise.
Oh yes. I always change it across all my scenes!
Vote for 45 lens length.Edit: Vote for 50 lens length. ;)
@PawelLyczkowski-1
Yeah, on my (large-ish) laptop I actually have mine set to 55, even. But on my workstation at work, with ungodly huge monitors, I tend to have it set to 40. Again, there's no perfect setting that will work for all setups, so it's just about finding the best compromise between common setups, since most people I suspect don't really adjust that setting.
Perhaps 50 is actually a better default than 45. I just suggested 45 because I was trying not to rock the boat too much. So let's put 50 on the table as well. 50 would work better in subdivided setups and with smaller monitors.
But honestly, I suspect anything in the 45-50 range will probably be a decent compromise.
Added subscriber: @WimdenBoer
@brecht
Let's be generous and presume these 16% pro users will be scripting 20% of their time on average. After all, most of them are artists, not developers. So, the actual use of the python tooltips will be 3%. That's not a lot.
Point is that this help information, that is very smart and usefull for one task, is blurring our view for all other tasks.
What makes advanced software a pleasure to use, is getting context and task related information and tools at the right moment, when it really is of use. The rest of the time it should not get in the way. I think that's a solid design principle for Blender too. I don't mind switching things on when I need them. That is just what we do with a lot of the addons.
Guys, the decision on Python Tooltips has been made. http://developer.blender.org/T37456
We will improve the look of the Tooltips (improve it, highlight the relevant information for the user more) first. http://developer.blender.org/T37478
Until then, debating this topic (Python tooltips on/off) will not help. :)
@ThomasDinges
Missed that decision ;-)
@neXyon : for negative frame, I've just tested it with default output and a .wav file, I was not aware of that issue.
I think it's convenient to be able to scrub in negative time and eventually store some temporary keyframes here. But if it creates some confusion it's maybe not a good idea to enable it by default, unless people know what they are doing.
In the end, I think the majority of people won't store keyframe + audio in this "negative time", but the ones who will do may have a little time guessing what's going on.
And there are chances if someone do some video/audio editing that he want to use this temporary space like with animation keys.
Maybe then it's better to leave the option offas it make a safer default, unless other people find this option useful in general ?
I'll ask some pro video editors and animators what they think about all this and post an ultimate comment if I think it's needed :)
@Everyone, the settings shown in the task description have been committed for testing for a few weeks now. Has anyone found any issues with these settings that cause problems?
I know that Rotate Around Selection and Auto Perspective are still quite contentious. If you feel strongly about either of these, or any of the others, please test, speakup, and provide feedback. We're testing everything but there will always be use cases for some users that are outside of our testing.
Rotate Around Selection implementation is awkward indeed, but I can always turn it off so no big deal really.
I have a much bigger complain about this feature, a few months ago some developer have merged a really great feature called Rotate Around the Stroke (in Sculpt Mode) in to the Rotate Around Selection.
So now I turn Rotate Around Selection: ON to rotate around the stoke while I'm sculpting, and turn it OFF When I'm in Object Mode! It's insanely frustrating guys!
And what's about VBO's? Brecht says it's ok to enable it by default.
I stick to have Rotate Around Selection OFF
Recently I've been playing with LDK_DrawBox addon . Nice piece of code for level design and architectural purposes. Once boxes are created they have pivot point on place when we started drawing. And there comes Rotate Around Selection part. Navigation behave like crazy when pivot point is out of screen. Situations like that are quite common when we have big objects on scene or we work on details.
Rotating this way works nice when we got character or some props but it's almost unusable to work with big sets or game levels.
Added subscriber: @cheleb
Rotate Around Selection OFF
As already said before, this gets really awkward with big sets/objects and even if it worked perfectly in these scenarios, the current selection is rarely the point I want to rotate around. IMO, viewport navigation should not be dependent on anything other than a position explicitly set by the user, for which there are several operators available. This is one of the features where blender really shines and gives absolute control over your 3D view - in stark contrast to another 3D package we use in our studio which always tries to do the "smart" thing in every navigation mode and fails miserably to give the user control over navigation.
If at all, this should be an alternate mode of the normal orbit navigation - temporarily activated via modifier key.
Auto Perspective ON
Personally, I always turn this on and so does anyone else I know. Orthogonal 3D views are preferable in some cases - Architecture/CAD for example - but as an artist, I want to see my work in a natural way and I think most of the user base would agree here.
For a more natural perspective, I would agree with @cessen, @PawelLyczkowski-1 and @BartekMoniewski to set the viewport lens length to something around 45-50 by default.
Added subscriber: @lamoot
My vote would be on Rotate Around Selection to OFF. As cheleb already said it nicely, the current selection is very rarely the point I want to rotate my view around. I tried the option a while ago and it didn't work well enough for me to keep it enabled. The selection can be off-screen, causing wild view controls. Often I rotate the view to select additional elements, in which case the current selection (which I don't want to deselect) interferes with my goal to select other things. Another situation is being in object mode and wanting to check out a specific part of the model, with the view rotating around object origin.
There's of course still the need to set the view rotation point to something specific and for that I use the Center View to Mouse operator (by default mapped to alt+F). I have it mapped to alt + MMB click and it works really well when I wish to set a specific point to rotate my view around. It also combines well with other view controls mapped to MMB, to have them all in one place.
Rotate Around Selection
Perhaps more useful than to have it turned ON or OFF by default would be to include a small icon in the 3D View's header to activate/deactivate the function, since during a working session it's common to see benefits of the two modes at different times, and a quick way of changing it could be more useful than having the option ON or OFF all the time.
Added subscriber: @rattyredemption
i personally don't mind rotate around selection and continuous grab etc to be on by default, but in the latest builds from builder.blender.org those preferences can no longer be saved to the startup file, meaning some of us will have to turn them off every time we run blender. i hope that's not intended?
Note,
9a623daf9cI've disabled
Added subscriber: @DataDay
@ideasman42 can you please fix the bug/design decision that prevents user preferences from being saved to the startup.blendfiles.
i first reported this on the 8th dec and it seems redundant to have "user preference options" if we can no longer save them.
@rattyredemption
AFAIK the user preferences are no longer saved to the startup file, but to a separate one. This solves the problem that caused the saving of the scene content to the startup blend, when the user simply wanted to save the preferences.
Added subscriber: @scottyp
These sound good to me.
For the discussion:
+1 for python tooltips staying ON. If a new user quits using Blender, having some weird information below the main tooltip isn't going to be very high on the list. It is really helpful for new developers as well when they are learning it (I have heard Blender has a hard time getting new developers).
No preference for the negative animation frames.
@billrey - should this many items be included as one task? it is going to make it hard to decide when this task is "done" with this many items along with other suggestions. If something is approved by the leads, why is there a need for further discussion? Further issues can be brought up separately in a separate design task. Just my thought in keeping these more manageable and "closeable". It starts turning into "design by committee" with these open forums.
@PawelLyczkowski-1 oh, cool. thanks very much... and i can confirm they appear to all be saved now to userpref.blend
the build i was using from the 3rd of dec still had them being saved to the startup.blend
edit: wow, i just noticed how small that userpref file is compared to my current startup file, it's about 1/10 of the size. so this is definitely an improvement.
@scottyp, "+1 for python tooltips staying ON. If a new user quits using Blender, having some weird information below the main tooltip isn't going to be very high on the list. It is really helpful for new developers as well when they are learning it."
I honestly think its best to not show the python info in the tool tip by default for one simple reason, Blender will have far more artist using it (for art) than it will have developers using it for development. I dont think it is what makes or breaks whether or not developers will flock to blender. It is these little things that exist, that when summed up have a much larger impact on the usability side of things. Best to keep it simple and consistent across the board.
That said, there is perhaps an obvious compromise that fits within the push for context sensitive design choices. There could be a condition that checks to see if any python console is open, and if so then it should toggle python tooltip info on. When there is no python console open via the editor picker, then turn it off. Have a toggle in the properties window to enable python tooltips regardless of python console being open.
python console: http://wiki.blender.org/index.php/Doc:2.6/Manual/Extensions/Python/Console
@DataDay - There are not simply artists and developers,
There are artists who write small scripts sometimes, or animators that write drivers - these more technical users are still artists.
Attempting to auto detect this I consider very bad design, making Blender a tool that (from the users perspective acts unpredictably), and means users have to second-guess how Blender might behave based on some internal logic which is hidden in some attempt to know what the user wants.
If you have a Python script open in the text editor should it show Py-tooltips too? what if you have a PyDriver on display?, what about Python logic bricks for the game engine? What if you have a Python console but the 3D view is full-screen?... it gets ridiculous.
Further, it causes users to have to do stupid things like keep a tiny console open (even if they dont want to use a console) so Blender acts how they want it to.
@ideasman42,
I didnt say there were simply those two, but the vast majority of users will fall into the art side, thus the use of (parenthesis). Obviously there are technical artist positions, and coming from a Maya background I know full well how scripting becomes a part of the workflow for those technical artist out there. I myself made full use of Maya's expression system.
Consider this though, you dont just jump into scripting for a program you not familiar with, as such it makes sense that you expect them to have familiarity with the interface and how the program works first. If so, then its obvious they would be competent enough to find a toggle in the user preferences to enable the python code if they need it at all times. When you do begin to start using code, well it makes sense you would have the console open, at least at first, especially if they are trying to learn the python scripting side of blender.
That said, auto detect makes it sound far more complicated than it really is. My experience is limited as far as coding goes, but even I know that all it takes is a condition to check if a python console window is open. If its open, enable true for python in the tool tips. The user preferences can have a simple toggle that over rides that to be true at all times.
I dont see how this is bad design. Its context sensitive, good design will focus on user centric principles. Start thinking like a new user or the "artist" who wont be scripting in blender (or at least at first). The more simple and streamlined the interface, the easier it will be for them to work within the application. The new user shouldnt have to look for toggles to turn off elements they are not even familiar with but know they dont want. IN the same vein, even if the user wont be using pycodes, if they are being displayed that is still something their brain will process, it adds more visual clutter to the UI.
If your reasoning is that you think (subjective) that users would second guess why this display is going on and off based on the python console being present, then obviously you find a way to communicate to the user why that is. Common sense. For example, in the very same tool tip that pops up from selecting the python console, you can add "Turns on python code for tool tips". 1. Its communicated to the user, 2. its communicated using the very same method that it deals with, aka tool tips. You can even include it always being on with the game engine being selected from the list with Blender Internal and Cycles.
Also please dont say it causes the user to do stupid things like leave a console open. I just said in the post you are responding to there can and should be an option to always have it on in the user preferences, which is probably one of the most opened windows in any 3d application, thus not making it obscure or hidden.
@DataDay Are we making blender for blender users or for novice users? Why we have to start thinking like user that wont be scripting if simple scripting is needed for proper rigging? We should make new users curious about them and not hide them.
The python tooltips issue has been discussed above already with the same arguments, I don't think it's worth repeating them. The decision has already been made to keep the python tooltips.
@BartekMoniewski, The "blender is for blender users" is just empty rhetoric though, it has no meaning outside of generating some pre-concieved sentimental notion of exclusivity, and its used to make excuses for any non-conventional design choice. Blender should be for artist and those that create, not something to isolate to some notion of a one size fits all user base. So I oppose the use of the blender is for blender users rhetoric to excuse poor design choices. That rhetoric also serves to drive people away, not bring them in. Anyways, I digress... I already covered why I think they are not needed to be on by default and its not exclusive to novice users.
Like its been said though, it all boils down to agreeing to disagree. Python tool tips on by default is not the end the world, or the most damaging UI choice. The mentality used to come to that conclusion is a bigger deal in my opinion.
@brecht, The task description should probably get fixed then, as it currently has this particular topic as "up for discussion". As for covering the same arguments, its a bit different than the one above, it was also bundled with a compromise based solution based on the notion of context sensitivity. If the decision is set in stone already, then the description needs to get fixed and it can be left alone.
@DataDay This is not poor design choice but standard blender rigging workflow. This paths are crucial for drivers, which are essential for proper rigs. If someday drivers system will be simplified somehow and will not use python paths then hiding tooltips can be considered again. Today they are necessary.
What are real drawbacks of having them for user that don't need them? And isn't rigging important enough to have keep them?
And please, don't speak about mentality or rhetorics. Just use proper arguments like everyone above.
Added subscriber: @NGMAT
Can I post here guys? sorry if i'm not supposed too. My concern was about the double-sidedon default for nvidia users. I was confused as to why this was on by default if it knowingly hurts viewport performance (a lot) I don't know the technicalities of it, so perhaps it can be discussed? I just thought it should be off by default. My other concern was the default viewport lens size of 35mm, its wide and creates distortion quite easily, I was thinking 50-55 mm would be better as its closer to human eye, and for modelling/sculpt purposes might be better to work with.
@NGMAT
The human eye typically sees 40-60 degrees (central angle of view). Source.
By default Blender's camera sees at almost 50 degrees (35mm) so it's actually pretty spot on as it is.
@BartekMoniewski
Discussions about who the UI is for, is an extremely important question. @DataDay has ever right to be concerned with statements like "blender is for blender users" as it's a [loaded question ]] and guilty of*[ http:*en.wikipedia.org/wiki/Ignoratio_elenchi | Ignoratio elenchi *:
"presenting an argument that may or may not be logically valid, but fails nonetheless to address the issue in question."
But as @brecht said, the Python Tooltips has already been decided upon (may want to edit the OP).
i'm not completely understood, but its not such a big deal. Any thoughts on disabling double-sided at object creation?
It is a very big deal, I manged to speedup my scenes from 15 FPS up to the point where I do not see FPS drops by simply disabling doublesided normals.
An obvious solution for me would be a Globalsetting in System Preferences which will be ONor OFF****automatically depending on current graphic card (or OFFby default if it's to complicated to make it automatic).
And Local per object setting (like now) which will override Globalsetting and will be OFF by default.
You should see how Softimage handles viewport settings, it's marvelous.
@MikhailRachinskiy
Wow seriously? That's a really big deal. Had no idea that double-sided normals would affect FPS.
Is there a downside to it?
@AndrewPrice
It would affect only NVIDIA gaming cards as support of double sided normals have been disabled in the hardware since Fermi. AMD cards and NVIDIA Quadro series should no be affected by it.
There is only one aesthetic downside resulting in ugly dark shading on the back side of the polygon.
@AndrewPrice and NGMAT
Regarding 3D view focal length , Andrew's arguments to match the human eye make sense , but I think we still need to make a much higher focal length value . Because there also another factor to take into account that is distance to the subject.
For example, if you watch at a face in real life, and watch one in the 3D view while modeling for example. In the 3D view you will try to have that face in the full frame of the screen. In real life you look at people and things from much more far. To have a face in "full frame" of the eye in real life you have to be at ~10 cm from each other :) And that create an extreme perspective distortion...
So in the end we have to compensate the distance difference and have a higher focal length value.
@AndrewPrice as szap says, it depends on what hardware you have, but all you have to do is subdivide a cube in multires 6 times ( at least a couple of million) and performance will drop in the viewport, but once double sided is off, speed increase is significant. Theres not really a downside to turning it off, as far i've heard from other users. I also wonder, why is the default lamp behind the subject?
@MikhailRachinskiy changing preferences based on hardware seems risky, Its quite possible someone does a tutorial where the there is supposed to be a plane/grid visible but it wont show up on the users computer because double sided is disabled.
Unlike over-sampling or VBO's - This setting changes what you see in the view-port.
This kind of unpredictable behavior should be avoided since it really makes Blender look shoddy/broken.
Its also kind of arbitrary - What if they fix their drivers in 2 months? What if next year some other drawing setting causes a large slowdown? - do we add some option to auto-disable that too?
@ideasman42 Your point is correct, automatic behavior of this setting could be confusing.
But isn't it already confusing? Curves (and similar geometry) have doublesided OFF by default, but Mesh objects ON by default.
One way or another I believe Globalsetting should be implemented.
@MikhailRachinskiy, my bad, I was thinking backface-culling when double-sided was mentioned. (Where backface culling could make an object totally invisible).
You're right that its already confusing.
@ideasman42 I think the performance increase is so much that its not so "arbitrary" to have mesh objects have it off by default. I read that double-sided is pretty much deprecated in modern graphics.
@MikhailRachinskiy @ideasman42, making Double Sided off by default would make things more consistent and give most Nvidia users a big speed boost. I have no real problem with this.
Added subscriber: @AndyDavies-3
It would be nice if we could we add something like FXAA as an option in addition to MSAA. Its way cheaper to run and similar in the look of MSAA with some minor differences, but obviously the user would have to be in GLSL mode to use it.
Also +1 for double sided off by default. That would really help Nvidia GPUs :)
FXAA is just a post process which blurs the edges so that the final picture looks blurry. Besides, I have no slowdown with MSAA even with complex scenes.
Nevertheless this discussion is not about new features, but default settings of existing ones.
@MikhailRachinskiy, mmhm, try loading a scene with 40 million tris of raw geo and see what happens :)
I'm suggesting it because it is proven to be much faster than MSAA & figured that this was a good place to make a quick suggestion seeing as people were already talking about AA.
I have a 680gtx and Blender does slowdown substantially with MSAA x4. On a simple polysphere with 800k tris I go from 60+fps to 28fps in object mode when compared to no AA.
The fact is that MSAAx4 will kill performance on heavy scenes if enabled on by default, so I was offering an alternative solution. Nothing more.
I'm honestly glad that you don't get slowdown, but you must understand that other people may be using Blender for more intensive work than yourself so please try and be mindful of that.
Cheers.
Added subscriber: @karja
Hello,
Related to double-sided shading:
Solidifymodifier use "Flip normals" to change the Offsetmaterial direction.
This option is in conflict with double-sided off by default, as it is also with Backface-Culling.
But i would love to see a solution for this inside the modifier, to independently flip material direction. I think that would solve both.
@MikhailRachinskiy, to be fair even discussing something along the lines of these features, even if its not necessarily in Blender yet, can lead to new tasks being created. Also in case you dont know of Metalliandy, he has some good "street cred" to name and his post carry some weight, at least in my opinion. He is the Admin at Eat3d and has his hands in the $100-$200 piece of software known as Knald. Depending on the type of scene you are working on, you will experience slow downs and Blender does does need a viewport rendering boost so anything that speeds it up is a good thing.
@AndyDavies-3, glad you are here. Hope you can have a hand in shaping Blender 2.7+
@DataDay, Glad to be here, mate! :)
@AndrewPrice:
It only makes sense to calibrate Blender's viewport to the FOV of the human eye (however you define that) if it's actually occupying the entire FOV of the human eye. But even with fairly large monitors, that is typically not the case. The viewport should be calibrated for the portion of a person's FOV we expect the viewport to typically occupy.
Think of it this way: imagine the viewport is a "window" into an actual 3d world. What would that look like? To get that affect, the FOV of the viewport needs to match the portion of the user's FOV that the viewport takes up.
In other words, if the viewport only takes up 30 degrees of the user's visual field, then it should be calibrated to display a 30 degree FOV. Realistically, of course, that number is going to vary depending on a variety of factors (monitor size, window size, etc.), so we have to compromise. 45-50mm seems likely to be a decent compromise.
Added subscriber: @CarstenWartmann
Added subscriber: @michaelknubben
Added subscriber: @MichaelParucha
Please NO MultiSample: 4. Leave it as it is, because the vertices are really harder to see if the edges are anti-aliased. It looks better, but it's not so pleasent to work with that option turned on.
Just make the vertices bigger, the anti-alliasing visually shrinks them.
Are the default viewport lights being considered for change? I think they look bad, and a simple, single light is much more professional. Similarly, the defaultmaterial could stand to be a little bit darker so the specular shows the shape of your model better.
It seems everybody have agreed on Doublesided Normals OFF by default. Why decision still haven't been made?
@MikhailRachinskiy, re: "everybody have agreed"
Its not clear who is making decisions here, @JonathanWilliamson didnt have a strong opinion, and I didn't see a response from any any others from UI team (billrey or brecht).
Also, note that this isn't a user preference, its a default for new mesh data-blocks.
I'm not on the UI team, but weighing in none the less: If Blender handled high polycounts better I'd leave this on, but as it's not and this setting has a profound effect on how well Blender works for my daily work, I vote for turning doublesided normals off by default.
Additionally I wonder, is this setting available to users anywhere, or must it be changed in source?
Regarding double sided I think as there is no performance gain to having it on but a vast performance gain to having it off by default we should do just that. Perhaps it will make little difference to AMD/ATI uses (from what I hear) but for Nvidia GPUs it makes a huge difference in performance. Perhaps we could have an option in the prefs to allow people to choose?
@michaelknubben yes, its available under object data in the properties panel (as a checkbox). Also doublesided is a depreciated feature in most cases i've read about. So most outside of blender"agree" that it should probably be avoided in modern cg.
@ideasman42
Yes I am aware about that this change will not affect already created scenes.
You (I mean UI team) can go other way: just make this change right now and see for a negative feedback here and BA.
To all:
There is no downsides of having Doublesided Normals OFF in technical terms for any GPU.
But there is a great speed boost for NVIDIA users.
NGMAT: I don't know any way to change the defaults there, though. I've wanted to change the 'Dissolve Verts' settings in the 'Dissolve Edges' properties forever, but haven't found a way.
@michaelknubben me neither. You probably can't, its a per-object thing for double-sided. So it will have to be done by one of the UI team.
I have no problem setting Double Sided to off by default for all new objects. I personally tend to turn it off, as I have a NVidia GPU.
I've not really seen any solid arguments for keeping it on by default (other than visually nicer mesh display), so unless someone has a very good reason then I'd suggest we turn it off.
If Double Sided gets disabled, would it make sense to enable backface culling in the 3d view by default then? It would avoid the weirdly lit faces without Double Sided.
Blender Internal and Cycles render double sided so it does make things a bit less consistent, but that I wouldn't consider much of an issue. Mainly I'm concerned about it being annoying to have to flip normals during mesh modeling, or it being confusing for new users. On the other hand having some visual indication of which way the normal is pointing does have advantages too, because the normal direction does have an influence in various places and it is quite hidden, so making it more visible may be helpful too.
I can't really estimate well which of the two is better. If @JonathanWilliamson and @ideasman42 think it's fine, I'm fine with it as well. I consider it more of a mesh modeling issue than a UI issue.
@lamoot I don't think that backface culling should be changed tbh. It's often very useful to see geometry that is only lit from one side just so you can see that there is geometry there an that would be removed if culling was enabled. It's better to see a black face than no face at all and it is easy enough to flip/recalc normals, which is something all artists should be aware of anyway.
Double sided off should be enough I think. :)
@AndyDavies-3 : Agreed, it's good to at least see it's there, and realise it's only being lit from one side.
I also vote turning Double-sided off, by default.
But as @brecht said, we'll need a strong way to tell the user that a wrong sided face is pointing outwards. Otherwise there will be a lot of confused and angry faces after it's released.
Perhaps making the underside a black (or very dark grey) would do the trick.
In addition, I'd propose making some objects exempt from the rule, and have it double-sided by default, like the plane. The reason being that the plane is often used for mesh lighting or displaying a texture, so the rotation is rarely considered. I think making planes double-sided would prevent a lot of confusion and errors.
The main problem with double-sided off by default is: currently you can model flat objects (architectural - models, solid shapes), and not be concerned with normal flipping, it renders fine and looks fine modeling.
@andrew- prefer not to have different defaults for different primitives, issue is users will not realize the difference and start asking why a model made from a plane draws slower/differently, prefer predictable outcomes for users, if they want to change defaults they can always do so, but if we try to guess that they will do it can backfire by users thinking blender randomly draws objects differently/faster/slower.
How about a different solution: Leave double-sided on by default, but add an option in the preferences "Create objects with double-sided off", and a way to easily set all objects in your scene to double-sided off, for instance by copying this setting from the active object.
This way there will be no headache for new users, and power users will be able to easily use double-sided off.
@ideasman42 AFAIK architectural modeling uses lots of a Solidify (and probably Boolean) modifier, which is normal dependent.
@PawelLyczkowski-1 and be prepared for new tutorials "...but before we start modeling/sculpting, we need to tweak some user settings for better performance".
Did you guys ever heard someone complained about 3ds max, Maya, C4D, Softimage etc. doesn't draw doublesided normals?
@MikhailRachinskiy that could be because Maya and 3ds Max, draw double sided by default? ;)
@GabrielGazzan I am sorry, it seems that Maya indeed has doublesided on by default, but I am sure that 3ds Max have doublesided off since 2008 version.
I really don't understand the problem with turning off double sided to be honest. It's super obvious when a normal is pointed inward as the face already renders black and people should always be modelling with normals outwards anyway as a matter of course, unless they have specifically chosen to do otherwise on purpose.
If they don't then it is just them being lazy and if/when they get issues they should really be blaming their technique rather than Blender itself. We really shouldn't be making these choices based on poor user knowledge or technique by allowing for their mistakes because they will never learn the correct way to model by devs re-enforcing bad practice.
Rendering with double sided on and using the solidify modifier wouldn't change the results of the modifier and it would still give incorrect results if normals are pointing inward. Plus it's a easy fix to flip normals without breaking flow.
If Blenders viewport performance was better then it wouldn't be such an issue but as it stands I think it is reasonable to say that well over 50% of Blenders users are getting much poorer performance than they could be due to double sided being on by default.
As it stands Max and Maya have much better viewport performance than Blender anyway so there isn't much of a comparison, although they do have some of the same speed issues with nvidia cards afaik.
@MikhailRachinskiy Both Maya and 3ds Max draw double sided in the viewport by default. On the render side of things, Maya does it double sided too, whereas 3ds Max does not.
Perhaps when Blender detected a certain threshold is surpassed, it could warn the user about the fact of double sided faces, offering at the same time a button to convert all objects to single sided?
Or is it too complicated to do that?
...just an idea.
Maya and 3dmax viewport is faster in general compared to blender, regardless of graphics card. So I don't know why they are being mentioned. I brought up this topic because we are talking about default blender settings, my reasoning for it being default, was that the performance hit is HUGE on nvidia cards, so huge that it should be addressed in some shape or form, even if nvidia decide to update in the future. Also makes no difference to AMD users, other than visually. Anything else is to do with blender slow viewport in general, which is another topic.
@NGMAT They are being mentioned as part of what the user could expect in terms of visual presentation of the data on the screen, as it is done by other popular applications, I think. (Though, I didn't bring the comparison to the table, anyway, so it's just an assumption.)
@GabrielGazzan so 3ds Max provide doublesided shading with backface culling enabled by default? Having doublesided shading with invisible backside of the poltygon seems kinda pointless.
I believe having a visual distinction between front and back sides of the polygon would only help beginners to understand the concept of normals and see they're own mistakes right away.
And I just want to remind you, that right now Curves, Surfaces, Textand Metaballshave Doublesided OFF by default. So if we talking about consistency for user convince, Doublesidedshould be OFFeverywhere, or ON everywhere.
Okay it seems that most people are quite happy with Double Sided being off, and no one adamantly opposed. Let's turn it off.
@ideasman42 has agreed via IRC to commit the change.
Is anyone against VBOs ON by default?
committed disabling doublesided shading by default:
0e97550fb3Please change startup.blend too, the default Cube is still doublesided.
@MikhailRachinskiy done
f9a60ecacdre: VBO, it came up before in this thread.. I don't have a strong opinion.
@ideasman42 Thanks!
Regarding VBOs, so far there was only two neutral opinions from the developers team, yours and Brecht's. No certain negative nor positive answer.
VBOs ON give me better viewport in non-animations and a loss of ~10% fps in playing the timeline.
I have a HD 5770.
I am not against it. :P
Just wanted to mention it.
Added subscriber: @koilz
Cursor Depth, OFF please.
In edit mode I rotate and scale the mesh around the 3d cursor often to modify a mesh, this requires the 3D cursor to be inside the mesh.
Also with the option enabled by default, the 3d cursor is limited to the outside of objects, until the user finds the option.
Ive read through all posts that may want the option on.
Description.
"More intuitive to have 3D cursor snap to surface under mouse and more useful for placing objects."
Placing objects on objects in object mode.. I dont think this a better reason.
I agree it could be useful for placing objects on objects, but only if it can be turned on and off quickly.
I dont think it should be enabled by default.
I propose adding the option to the 3D View > Properties region > 3D Cursor panel, or somewhere more useful, so it can be switched on and off easier.
#37518#26
"Good points, Cursor Depth is really nice to have on. Without it, the 3D cursor frequently tends to shoot off into space :)"
It doesnt shoot off in to space, it is set by the 2D plane of the view.
So usually, you set the 3d cursor in the front then side view.
#37518#19
"Is much more intuitive to click on a surface and have the 3D Cursor stick to it, rather than floating on the space. I've seen beginners do this expecting it to happen, until they know is an option that can be turned on."
For what reason.. Also I dont class that as valid evidence.
#37518#28
"Never even knew Cursor Depth or Region Overlap existed. And wow are they handy :)"
I agree its nice to know Cursor Depth exists, but I think setting Cursor Depth as default is not a good idear.
#37518#73
If you read senshi's post, he actually wants the option off.. I agree with what senshi said.
He was miss quoted below.
#37518#82
"Cursor Depth really does not belong in the Preferences, as the user can prefer to put the cursor inside an object or on it's surface according to what he is doing at the time. So it can change frequently during one modeling session for example."
I agree, I think it would be better in the 3D View > Properties region > 3D Cursor panel, or somewhere more useful.
"But atm, this setting to off feels more natural - the user did not activate any options, so why is the cursor sticking to an object's surface, and not going where he clicked?"
I agree.. Off feels more natural.
VBO's On IMHO. There doesnt seems to be any downsides to this really.
Any consensus on AA yet?
@koilz - Thats minority opinion. Most of the people are happy with Cursor Depth enabled and it probably won't change for now. Debate on this can be raised after 2.70 release, when regular users gives us feedback.
Also I agree that this option should be in 3D cursor properties but that will be separate task.
@BartekMoniewski
I'm interested what do you base this on.
On this topic. To be accurate:
6 positive votes (after adding mine here)
1 neutral (@JonathanWilliamson)
2 negative (you and @koilz)
Will be great if this option go to cursor properties but for now we voted to have it enabled in 2.70. If you don't like it you can just disable it, thats idea of user setting, right? ;)
@BartekMoniewski I may have missed a few, but doing a cmd+F search for "cursor depth" finds me:
On:
venomgfx
billrey
Off:
senshi
campbellbarton
plyczkowski
koilz
Neutral:
carter2422
Regardless, a lot of people agree this option should be moved to a quick toggle, possibly in the footer. Since even seasoned Blender users (see Andrew Price's comment) didn't know this preference existed, how can we expect new users to find it?
I fear that the frustration of a new user not getting the cursor to go where they're clicking could be major turn-off for them. I know it would be for me; I would feel incredibly frustrated if I "can't even get the cursor to do what I want" in a complex 3D program.
Additionally, if I had to make a hard-choice between on or off (which is essentially what we're doing here for at least the first period of most new users) I feel like this feature is less essential than being able to properly being able to set the cursor. It may be cumbersome in some cases, I admit, but I feel it's easier to work around no cursor depth with snapping tools and "cursor to X" tricks than the other way around.
I would therefore like to propose putting off switching this preference to on until the toggle has been moved to a more easily accessible location.
My bad, but you and Campbell ware writing "CURSOR DEPTH: ON" in bold and this looks like actual voting, like everyone in this topic did. I thought descriptions below was just secondary things. ;)
Then turn this OFF. More important we all agree that this option needs its place in 3d cursor properties.
Ah, I can see how that could cause some confusion, my apologies! I'll be using just the feature name as headers in the future to prevent this. =)
re the cursor depth having both a preference option and a toggle in the 3d cursor properties panel, could we also have a shortcut key mapped to it?
Vote for Cursor Depth: ON
Could I propose to change the Image type Empty object defaults, If it is not too late?
The default Offset X and Offset Y settings set to 0 which places Empty's origin on the corner of an image, which make it difficult to rotate and scale.
I want to propose to set these settings to -0.5which placesEmpty's origin right on the center of an image.
Here is simple gif animation to visualize the issue:
open in new tab to see the animation
+1 to the changing of the Image type Empty defaults to @MikhailRachinskiy's suggestions above. :)
Also +1 from me; center-based manipulation feels far more natural i.m.h.o.
+1
well, to be honest, now that I think of it twice...
I guess it depends on what purpose you have them image for.
if it is for holding a blueprint, and you need to scale it up/down, I guess it'd be more practical if a "known" border stays in place, such as the lower left/right. because if the origin is at the center, you'd have to scale it and then move it back into position afterwards.
@GabrielGazzan,
It really depends on if people are using concept art/reference or as you say a blueprint. I would assume that we have more regular artists vs arch viz peeps so I would still think the change would be a good one.
Thoughts?
well, I was really thinking about character model sheets, when I said "blueprints". I'm no arch/viz guy.
usually front and side views from model sheets have a common "ground plane" that would remain fixed when scaling the pictures, if the origin was at their bottom edge.
as Empties are created (by default) at the world origin, it should be just loading the images, scale them up/down a bit and off you go.
@GabrielGazzan,
I would still say your request is valid. I'm an env artist and all the concepts/blueprints I use need to be centred in Blender before using them. :)
Added subscriber: @lopataasdf
Is there a Text Editor Preferences thread? I know it's startup.blend business rather than User Pref, but still would like to throw them here.
I always forget to enable "Highlight Line", which I love when scrolling around the script, but it might cause noise to others.
A little late, for 2.70
but I think it´d be good to raise the Undo steps by default.
AND also to allow a highr number of them as maximum.
Removed subscriber: @WimdenBoer
Not sure if this is the right place, but:
Currently Auto Perspective does not work on viewport snapping (pressing alt while orbiting). My feeling is that it should, but I thought I'd get your opinions.
Hi guys, where there any talks on the lamps? it doesn't seem clear to the user what the values relate too... yesterday I turned up a spot/area light to something ridiculous like 100000 to get the right brightness, will this be addressed? please direct me to right task if this is the wrong place.
@venomgfx +1 for text editor changes (but maybe some non python devs would disagree).
@GabrielGazzan no strong opinion on undo steps.
@michaelknubben tested and autoperspective + snapping works here, this kind of thing should be reported as a bug.
@NGMAT, This thread is about defaults, your post is IMHO off topic.
@ideasman42: With the prominence of the "Run Script" button + "Register" option in the header, and Format/Templates menus, I'd say that the Text Editor is already leaning towards Python scripting by nature. Other than rare notes, I haven't really seen it being used for something else than .py startup scripts (on production files, to override settings and so on) or operators to be run in the blend file.
+1 to have Wrap for search, Syntax Highlighting and Line Number turned on as default on the Text Editor.
Campbell: Are you absolutely certain? I've tested it on multiple setups, including just now on someone elses pc with a freshly downloaded Blender. It doesn't switch to ortho, but maybe that's intentional?
That's what I thought at least, and I'd propose that it should change to ortho.
@michaelknubben - Your right, its not switching to ortho.
Think this should be kept as-is since the view can be rotated so you snap to an axis with the view 90d rotated - which would't be set to an axis view...
Best report this stuff as separate issues, This thread is noisy enough without bugs being reported here too which may end up needing discussions of their own.
@venomgfx - point well made, unless someone gives good reason not to do this Ill change after 2.70 release.
Undo Steps:
Definitely for raising the allowed number of steps.
I have a question:
Is it possible to exclude "select"-steps (object/bone/vertice...etc) from the undo history and only take real edit tasks in account? (with a checkbox)
The most time i am running out of steps is because the selection jumps through the mesh and eats my history.
@karja Absolutely no! Without undo selection we will have start over again if we select something wrong or search for accidentally selected things.
Yes, no implementation without checkbox. Was a spontaneous idea and i am still curious about what other people think of it.
I guess for my current workflow it would fit very nicely, but cant tell for sure.
Removed subscriber: @neXyon
Added subscriber: @mont29
Added subscriber: @AngelPat
One thing I really want to change is the simpify option...Why on earth is set by default to 6 subdivisions? if I activate this is because my computer can't handle too much poligons so I expect to be on 1 or 2 max...
Added subscriber: @macouno-3
Hi guys...
A late comment... only because I only just switched to 2.70a.
I have to wonder why Auto perspective has been switched on by default. I see way more arguments against than for in this thread.
Personally I don't mind the view switching to ortho whenever I go into a top/side/front view. But... whenever I middle mouse away from that view it switches me to perspective view (also if I was in ortho before going into top view)... which actually... I never want. So I now have to hit num5 all the time (to return to ortho view)... really.... way often.
I also agree with multiple people above that already mention blender guestimating what users want is a a crappy idea.
@macouno-3, Auto-Perspective has been turned back off in 2.71.
Jonathan,
yeah that was completely my bad!
I think what happened was...
I downloaded 2.70a... and didn't use my "previous settings" so it was switched on.
Then downloaded 2.71 and DID use previous settings so it was still switched on.
shees... sorry... good job guys!
Changed status from 'Open' to: 'Archived'
Suggested changes have been applied to master, archiving.