Renamed this from presets to defaults because we use the 'presets' term for something else in Blender. This task could be used to gather a list of smaller default settings that we want to change (i.e. let's leave default keymaps and screen layouts for another task).

Agreed! Lets keep this strictly for updated default settings. Many useful settings were added after 2.5 that actually make sense as the default, but are left off when you open Blender.

The big one being Cycles, but there are loads of there small ones too.

I suggest we add Subtasks for each default that needs updating. That way they can all be gathered here and not get a muddy comment feed.

We can create subtasks, but let's still group them a bit so we don't get one task for each property. For example Cycles Settings, Mesh Settings, Cloth Settings, ...

Updated the list with more items

Not sure if I'm allowed to comment here... am I?

Anyway, I love the idea of Emulate Numpad being on for the purpose of laptop users!
Now I'm wondering, from a development standpoint is there a way to know if they're using a laptop? If so, we could perhaps change even more defaults that suit them, since their use is different to desktop users.

Sure you can comment here, anyone is allowed to comment on any design task, we just like to keep creating new design tasks limited for now.

I fear there is no reliable way to detect if there is a numpad available, but I could be wrong.

Mac users for a couple of years are using shorten wireless apple keyboards. It'll be nice to make it default at least for mac users.
NUM. — zoom in on selection, please, provide some other default key for shorten keyboards, as it is used very often.

There's two things I'd like to comment about.
Emulate numpad doesn't really make sense as it is now as default. The navigation keys assume the grid order of real numpad, and the 2/4/6/8 keys for navigating simply make no sense. A bad and confusing way to navigae the view. When having to toggle it on the user at least knows that he's missing on something. I'm not arguing that there shouldn't be a better navigation option for laptop users, but forcing emulate numpad on everyone is not the solution.

Second one is the unit thing, which i don't agree with. Some of the world doesn't even used metres, and quite rarely do 3d scenes have to really relate to the real world. With current unit scheme the user doesn't have to limit himself to predefined scale, can reather pick a scale where the scene fits nicely in the grid and so.
Just my 2c.

I disagree with a lot of these suggestions in the original report, especially the Performance options for Cycles. Things like Cache BVH, Persistent Images should definitely be off by default.

Also, I just changed the default Light paths a few days ago, to have less Diffuse/Glossy Bounces.

Emulate Numpad although I use emulate numpad all the time personally, I would rather see this taken care of via the keymap refresh. With more and more people working on laptops, and many keyboards no longer including numpads, I think it makes more sense to try and make the default keymap work with both keyboard types. Like @Henrik Aarnio (hjaarnio) mentioned, the 1-0 top keys are not laid out well for navigation based on the numpad.

Let's do the emulate numpad discussion as part of the keymap discussion, it's clear this is not something we can just switch and make everyone happy with.

I've created two subtasks now for general Rendering and Cycles, otherwise we are going to loose oversight. If you want to propose more defaults changes, please created a subtask with a list of changes for some part of Blender.

Agreed about Emulate Numpad. It's more related to keymaps.

edit: never mind

I think that on by default should be:

• Auto Perspective - All the view commands (Front, Back, Left, Right etc.) are pretty useless without it.

• MultiSampling (Anti-Aliasing) - The programs looks much more modern with it. I don't think it affects the performance that much on current machines.

Billrey: See Cycles subtask for my answer.

Scene Properties
I don't mind going to Metric units by default, but if we do that then we need to totally revamp a lot of the transform functionality and such. Currently you cannot transform anything via the Viewport in the selected Units. Everything is just Blender units.

For example, if you grab an object and type 1.1 during the modal to move it 1.1 meters, it will move 1.1 Blender Units. Now in the case of Metric, this is not generally a problem. Unless you have adjusted the scale or if you are using Imperial. You also cannot type 1m 2cm during a modal, like you can in value fields.

I could be wrong, but I believe improving this system is a lot of work. It should be done I think, but is likely too large of a project for immediate focus.

@Brecht Van Lommel (brecht), do you have any insight into the Transform area?

Making the transform text input support units doesn't seem too complicated, we basically have functions to convert some string to blender units and back.

Perhaps somewhat tricky is that you are now also taking up key shortcuts that are not just numbers. So if you type yd for yards you need to be a bit clever knowing that the previous thing you typed was a number so you don't constraint on the y axis instead. Also each transform tool would need to indicate which units they are expecting (distance, rotation, ..). Ok, not super simple but a new developer could do this I think.

That's good to hear @Brecht Van Lommel (brecht). The lack of this kind of support is actually my biggest gripe with the Unit system currently. At the moment it's generally fast for me to convert my desired units into Blender Units than to work natively in the desired units.

If you think it's feasible for a new dev then I'll add a Design Task for unit work.

Heres some i would like.

Hair

Properties->Particles->Render: Strand_render
Enable.

Properties->Particles->Children: Simple
Use. mabey set the children to a smaller value.

Properties->Particles->Emission: Use Modifier Stack
Enable. This corrects the number of hairs generated from each face. Why this happens, it was a mystery till i found this button.

3D View

3D View->Header: Limit Selection to Visible
Disable. I dont often use this, and keep forgetting to turn it by default, then i open blender, extrude, then realise ive only extruded one side of the mesh faces.