Page MenuHome

Blender 2.8: Icons
Closed, ResolvedPublic

Description

Blender 2.8 has many new features that need icons, and in 2.7 already some icons were missing or reused.

This is an open call to anyone interested in contributing to the design of these icons. The list of needed icons is this. The ones marked in bold are the most important ones, others are lower priority but still great to have.

Properties Editor

  • Fake User
  • Delete and Unlink distinction (both are X currently)
  • Tool Settings
  • Preset
  • Icons for next to buttons: None, Animated, Keyframed, Driven, Linked, Overriden, Node Linked (see T54951)

3D viewport

  • Overlay
  • Transform Orientation (Global and View)

Outliner

  • Hide, Viewport Enable and Render Enable distinction
  • Orphan Data mode
  • (Static) Override (see T53500)
  • Complete Match (string search)
  • Case Sensitive (string search)

Node Editor

  • Snapping modes (Node X, Node Y, Node X / Y)

Assert Manager

  • Asset Manager in editors menu

Text Editor

  • Find Next
  • Replace

File Editor

  • 3D/Scene File (Alembic, Collada, ..)
  • Volume File

Future Features

  • Volume Object
  • Hair Object
  • Particle Object

The goal is to extend the current icon set. We are not looking for a re-design in this task, please follow the current icon style as close as possible.

Resources and Reference:


Note: This task is a follow up on the now 4-year old T38093

Details

Type
Design

Event Timeline

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

Does anyone know if there are problems when merge .svg files (blender_icons.svg)?

I'm not sure, but maybe we could merge the blender_icons.svg from greasepencil-object branch to Blender2.8 branch to avoid conflicts in the future.

Does anyone know if there are problems when merge .svg files (blender_icons.svg)?

I'm not sure, but maybe we could merge the blender_icons.svg from greasepencil-object branch to Blender2.8 branch to avoid conflicts in the future.

Sometimes yes there are merge conflicts. You can merge blender_icons.svg from greasepencil into 2.8 before greasepencil itself is ready. I did the same for multi-view for the exactly same reasons.

Does anyone know if there are problems when merge .svg files (blender_icons.svg)?

I'm not sure, but maybe we could merge the blender_icons.svg from greasepencil-object branch to Blender2.8 branch to avoid conflicts in the future.

When adding icons the blender_icons.svg, it tends to get *lots* of unneeded changes. Only a rather small & isolated subset of those are actually needed, e.g. see this commit which adds two icons. One has to manually remove most unwanted changes I'm afraid. This should however get rid of most merge conflicts.


We'll also need an icon for workspaces for 2.8.

@Julian Eisel (Severin) Add new icons is not the problem. The problem is that it's very easy to overwrite a new icon created in a different branch, because designer usually use the first free slot. The idea of merge is to "fill" these slots and avoid overwritten.

First attempt.

Concepts opc 1:
Object container box

Concepts opc 2:
Grouping of leaves with objects

I'm thinking new ideas for link, unlink, add and remove. It is not convenient that they are the same icons as the collections. It's confusing.

My proposal for the probes


I have made stickers for the Overrides. They are red as the record icon, I do not know if it is the best option.


About probes :
Ideally , their icons should be recognizable by their silhouette. They need a yellow variation to distinguish Object and Object Data.

About overrides :
It would be better to take color that will be used in default Theme UI. Red is generally used as a warning about something that is going wrong.
Maybe + and x are too small. If you take a look to File Menu icons. Additionnal green arrows are not discrete at all.
Silhouette of override icon should be recognizable if it is half masked by additionnal indication.

About probes :
Ideally , their icons should be recognizable by their silhouette. They need a yellow variation to distinguish Object and Object Data.

True. Here a new proposal.

About overrides :
It would be better to take color that will be used in default Theme UI. Red is generally used as a warning about something that is going wrong.

The red was to alert that it was overwritten, anyway I have done a test varying the tone and saturation.

Maybe + and x are too small. If you take a look to File Menu icons. Additionnal green arrows are not discrete at all.

I've done the test, but I think the crosses have to contrast their size with the main shape of the icon.

On the other hand I have modified the shape of the fold slightly and I have made a variant to show the dynamism of the overwritten one. There is also a test projecting shadow.

I group everything in a file in case someone wants to play.
Thanks for comment

The last of today

Filters

Children Objects (new filter in the Outliner)
Object Data (new filter in the Outliner, used to show/hide the datablock of each object)

Taking into account some criticisms I have adjusted the design of the overwritten ones.
I leave you alone until next weekend :)


I could not resist. Here is a completely different proposal for the Overrides.


Another attempt for static and dynamic overwriting.


I just started blender's icon redesign. LINK
Old icons design has a few afflictions:

  1. they were designed to be visible on any background - dark or light and thus some crucial space has to be dedicated to double outlines. It consumes a lot of precious space;
  2. old icons actually were not true 16x16 pix, but tad smaller - one pixel, two pixels… That’s further space loss;
  3. in real use, icons are apposed in UI in small bunches that are contextual. Colour ain’t that much needed here. Honestly, some of current icons pop out too much because of their colour, attracting user’s attention to particular parts of interface. It would be good to incorporate some colour codes though - in File Browser, Asset Manager or Outliner. In every place, where one has to manage big lists of items.

Developers input and feedback is highly appreciated, since some of UI concepts are going to change. New design should address listed problems and - by the way, parts of the UI must be retouched (width and height of space dedicated for icons + some border around).

Thanks all for the contributions so far!

I've updated the list of icons that we need. Light probe icons have been committed for a while already, collections use the group icon now since they are merged. Some other features got moved into menus which don't need icons for every operation anymore.

For the static overrides icon, it would be best if we could somehow make it related to the linked icon and redesign both if needed. Basically a datablock can be either local, linked or linked with overrides. In the outliner you right click on a linked object to add overrides to it, and then the document with the arrow in it turning into e.g. a badge would be a bit strange.

As I stated before, I work on new design (flat / monochrome) of icons for 2.8 release. It's independent effort, with no official support, but I stay in touch with William Reinish and Pablo Vazquez, who are interested in my work. Actually a couple of my new icons are in use already - the mice pictograms on the Status Bar. The longer I focus on my projects goals, the more I find: inconsistencies, temporal-once-a-time hacks, design flaws; simple patching up current icon set isn't a solution and - to be honest - is not in pair with all the great work on redesing and cleaning up the GUI. Next week I plan to release the latest mono-icons sheet, that gets more and more complete, but doesn't really fit real needs that 2.8 GUI renders. The release will be folowed by sort of list of changes that should be considered if we want clean an logically organized UI in Blender 2.8.
BTW, my new icons design proposal already contains:

  • Tool Settings,
  • Preset,
  • Complete Match (string search),
  • Case Sensitive (string search),
  • Hair Object,
  • View Transform Orientation,

and many other new icons, that already use inapropriate symbols...
Stay tuned on Blenderartists Thread

If you're doing all the icons, that's great. Mainly I wanted to update the task so we don't forgot to fix the missing icons before the beta.

@Andrzej Ambroz (jendrzych), the new icons seem to be a bit bigger. Do you expect the headers and buttons to become bigger as well to accommodate them, or are the icons being designed for the current button size?

@Brecht Van Lommel (brecht) - it's a problem that I reported back in time of 2.5 icons redesign. Current icons are tad smaller than 16x16 pixels - usually 1 or 2 pixels less, while some of pictograms utilize full 16x16 matrix. This causes size diversity across icon sheet. Some of pictograms are smaller, others are fullsize and buttons and other GUI elements are so. Removing black outlines and designing icons bigger leads to better use of available space and clearer symbol rendering. My icons design assumes the need of making headers and buttons at least two pixels bigger - pending massive GUI redesig seems to be perfect time for such tweaks, although I have no idea how big such change can be...

It's not so hard to make all the buttons bigger, you can try this yourself and see how it looks with the icons:

diff --git a/source/blender/windowmanager/intern/wm_window.c b/source/blender/windowmanager/intern/wm_window.c
index 4323185..596af5f 100644
--- a/source/blender/windowmanager/intern/wm_window.c
+++ b/source/blender/windowmanager/intern/wm_window.c
@@ -591,7 +591,7 @@ void WM_window_set_dpi(wmWindow *win)
        U.pixelsize = pixelsize;
        U.dpi = dpi / pixelsize;
        U.virtual_pixel = (pixelsize == 1) ? VIRTUAL_PIXEL_NATIVE : VIRTUAL_PIXEL_DOUBLE;
-       U.widget_unit = (U.pixelsize * U.dpi * 20 + 36) / 72;
+       U.widget_unit = (U.pixelsize * U.dpi * 22 + 36) / 72;
        U.dpi_fac = ((U.pixelsize * (float)U.dpi) / 72.0f);
 
        /* update font drawing */

If it only needs to be done in some places it will be more difficult.

However I'm not so sure it's a good change to make design wise. Buttons in the Blender UI are already quite big relative to similar software, and if anything I'd be inclined to make them smaller. The new layout in the properties editor also needs more space, adding another 10% to that is not ideal.

@venomgfx and @William Reynish (billreynish) are the UI designers though, I would like to hear their opinion on this.

I'm good with using all 16*16 points.

@Brecht Van Lommel (brecht): Don't really understand your image - here it looks like checkboxes are really big?

The patch makes all the buttons two pixels bigger as suggested by @Andrzej Ambroz (jendrzych), but keeps the text the same size. I think the screenshot shows roughly what that would look like, though some UI elements could be tweaked like making the checkboxes smaller. Alternatively setting the Display Scale in the user preferences to 1.1 scales everything.

ReferencePatch (buttons only)Display Scale 1.1 (everything)

I'm just trying to figure out if making the buttons 10% bigger is a good idea and what that would look like. To me it all looks much too big.

Yes, I see the issue. I have inserted a few of the new icons as replacements:

Before:

After:

Two observations:

  1. It's really nice that we can just use simply glyphs without shading and outlines
  2. They are a fair bit too big now to fit. There's not enough padding towards the edges.

As a demonstration, I decreased the size of these icons, here:

I don't think we need to increase the size of all our UI widgets. Instead, we could just decrease the size of our icons slightly. With the more simple and flat design, they should work even better than before at the same size.

I made smaller version of playback icons already - pictograms are tested. Update is coming.
Decreasing size of symbols is possible, but have no sense in most cases. Example provided by William is an extreme - other pictograms are really detailed and I believe they'll will lose from shrinking - mice icons for instance utilize whole 16x16 pix matrix. 2pix penalty in height per header isn't that much, but gives best icon quality.

Personally, I work with hi-res 13in display (not retina) most of time and 16x16 icons are way better tha 14x14 :D

The mice icons seem fine as-is. Maybe because they are largely hollow, and also because they are not contained within a button, so padding is less of an issue.

But, a few of the new icons, such as the camera icons, are very detailed at the pixel level - maybe they could be simplified further?

Another thing to consider is the UI widget outlines. If our outlines are less prominent, or same color as buttons, this will give an extra pixel of padding in each direction.

Actually increasing the size of all our UI widgets requires careful consideration, as it means we can display less information in headers and other places. The old icon sizes had that size so they would fit next to text, and be roughly the same height, just like an emoji or other symbols.

For an icon designer like you, it'd be really useful if we had an easier way for you to test your icons in Blender as you make them, otherwise you are fumbling a bit in the dark. Are you able to build Blender yourself?

Building software is a black magic for me, and - to be honest - I don't have extra time to dig into it.
Leaning over deign of a widget outline is great idea!
Vklidu form blenderartists.org is making great mockups with GUI with no prominent buttons. He has got couple of grat ideas in his thread "monoicons" (status and title bars in black, for example).

Regarding icons size - absolute size of pictogram is not all that has to be considered. It's not less complicated than kerning and font design - some pictograms can be 16x16 pix, but look rather small, just as a camera object does.

SVG with updated icons ready to grab: HERE

I've just compiled blender with a decreased size version of your icons (I tried 80% of the originals, it may be too much but I don't really know) @Andrzej Ambroz (jendrzych) and everything looks way better in my opinion.


There may be a couple of icons that would need a small adjustment, but overall they seems fine to me.

I have a concern about the design though, I like flat and shadeless stuff, but that comes with quite a big problem: having the icons solid white while having no outline makes it impossible to use a bright theme or a bright selection colour (this problem exist to some degree also in the current state of Flatty dark).

I saw that now the status bar icons are colourized according to the text colour, is this something planned to be implemented throughout the interface? Being able to select different colours for active / non-active buttons would resolve most of the problems.

@Alessio Monti di Sopra (a.monti)
This is not the way to go. 80% size of originals means shrinking icons from 16x16 to 12x12 pixels. It's not so easy, even though effective size of current icons is similar (14x14 with 1pix black outline), because 2.5 pictograms make intensive use of shadows, higlights, while flat design must use just one colour for fills and lines; to achieve cleariness, some white space between different parts ofi icon has to be preserved. In 2.5 symbols 3x3pix detail is easy, but in monoicons it has to be filled poligon to maintain clarity and filled items are preserved for strong accents (Objects) - common pictograms must stay hollow and it consumes space. Every icon has to be razor sharp, and thus every bit needs to be designed pixelwise from scratch. I don't know if I had enough time and power to do that again :( Several dozens of hours of work to do...

It's a shame to waste @Andrzej Ambroz (jendrzych) consistent icon work for not wanting to adjust the necessary button padding to accommodate the 16px pictograms. I hope you guys reconsider the idea.

I don't know if this discussion about icon size and sharpens based on pixel precise make any sense. Blender's "User preferences" has "Interface > Display > Scale" function. Icons can be any size. Doesn't matter if they are 12 or 16 or 32 (or whatever). The only one thing that can be taken into account by developers is space around each icon (%), so they are not visually merged.

These icons, because they use single pixel lines, can only be scaled well at certain increments. They work well with retina displays @2x too, but probably not so much @1.3x

@Filip Mond (vklidu)
Pixel precision is very important, since icons are raster files rather than vectors. Scalling will cause blurrines, which - in case of such small pictograms - isn't what GUI designers want to get.

Personally, I think the UI would look great with the 16x16 icons, and no buttons (no outline).

Here's a test with the new icons and outlines of buttons mostly removed:

Old IconsNew Icons

It helps and I like a UI that gets out of the way more by avoiding colors, but there are significant usability issues:

  • The outliner is much harder to read than before, it's not clear to me how to solve this without colors
  • The properties editor tabs are difficult to distinguish at a glance
  • Does this icon set work for light or middle gray themes?
  • Making it required for all themes to have no outlines is not a decision to take lightly, not everyone has great eyesight

There are trade-offs with any design, but we also have to be pragmatic. If this is going to be accepted at some point in the next few months or in a future release, the designers / developers who want this to go forward will need to take the responsibility to address the various issues that inevitably come with a major change like this, and if not argue why it's an acceptable trade-off. Show mockups or tests of how it should look like in a full Blender UI, with different theme colors. At the moment this does not look like a drop in replacement for our current icons, and if it's going to take development time to reorganize the UI, we need to understand the scope so that we can plan it or postpone it.

Brecht: Completely agree here.

To make them a drop-in replacement, I think we will need some way to add color to the icons. This could be built-in to the icon, or maybe ideally as part of the theme.
Also, the oblique cube design runs too close to the edges of buttons, and is parallel, which makes it hard to distinguish. Some of them are simply slightly too big to fit nicely within the size of the UI widgets we use currently. This creates a problem with negative space around the icons.

To demonstrate this, I've created two dummy icons that both fit within a certain size. The one on the left fills out the area completely, but leaves no negative space around it, and the lines are parallel to the button edges, causing a visual clash if put too close. The icon on the right also fills the area, but has negative space in the corners, which makes it easier to identify, and easier to read.

I like the general direction of these icons - esp for the simple, genereal UI chrome stuff, such as X, +, - search loupe, disclosure triangles etc, is a clean win.

Some of the more advanced icons for more specific areas, however, such as modifiers and outliner items, seem to lose some quick readability without adjustments to sizing and colors.

I agree with the Brecht Van Lommel (brecht), that not everyone has excellent vision to look at the icons. And even if the color old icons are not unified, but they are distinguishable and clear in both light and dark interface themes. So I'd like to keep the old icons version ,but not icons, which new type of white.

Maybe these large new icons would "pop" a bit less in this dark theme if they were a bit grey, instead of pure white, especially in the outliner.

@William Reynish (billreynish)
I changed axonometry type because of supposed future change in Toolbar icons, You've showed me some time ago. It's not a big problem to bring old axonometry icons back - they're backed up. I can try to redesign the set from scratch, but it will take some significant amount of time, and it would be really helpful to get some kind of temporal solution that would allow changing raster icon set without building app anytime I tweak sth in an icon.

Regarding the colour - as I stated many times before in my topic at blenderartists.org, this project focuses on shapes first of all. When we'll reach the point where all silhouettes work, then colour can be added and it can be done in several diferent ways - this is open topic. One of main goals of the design I'm working on is to make icons style/guidelines simpler for other designers to follow. Current set is hard as hell to mimic, even for me... So, shapes first, simple'n'flat colour codes next.

P.S. I think, that long lists of items, such as the one occupied by Modifiers, must be iconless. Pictograms doesn't help much in such massive stacks. Another question is the fact that's really hard to design so many tiny icons that are different enough from eachother. Mostly it's a problem of organisation of the list IMHO. Simple search function would be a blessing in such places.

Some say that icons can help here, but apparently not that much IMHO:

I generally like the direction Andrzej Ambroz work is taking, keep up the excellent work.

I think we will need some way to add color to the icons.

I wonder if some sort of system that used RGB color channels as masks would be feasible.

If we could agree on some type of "threefold color code system" where there would be a "main" color and two secondary "highlight" colors used across all icons, maybe we could establish sensible rules to highlight key elements of the pictograms (like actions, animations, tools, shading, families or groups, among others), using the same three colors consistently across all icons.

Since icons are mostly monochrome flat by designed, and we only need one color channel+Alpha to represent them correctly. Maybe the remaining green and blue channels could then be repurposed in a some sort of mask system where colors would be read at runtime from the current theme and overlayed according to the pixel values of each channel. Red could correspond to the "main" icon color (in this case it would be white but), for lighter themes it could be some shade of darker gray or black, always configurable from the theme to be as readable as desired.

filip mond (vklidu) added a comment.EditedJul 4 2018, 11:05 AM

@Andrzej Ambroz (jendrzych) Modifier list without icons +1 for me (faster to scan). I wasn't sure about properties panel, but from this gif example still looks like good way.

GIF - original / proposed modifier list to unified system / text only

I was thinking about the same, just in a way more radical :) When I see the list of needed icons – isn't it better to delete any icon represented already by text? And keep icons only for cases where text is not possible (wanted)?
There are cases like like Editor list, that looks easier to read only text (no icons), but without icon I'm not sure if its enough for new user to select by text and than see icon only in a corner of editor window.

GIF - original / monoicons / tinted / text only

Ignore mono icons shape, just for illustration, (specially blue was quick hack).

To iconise everything is not a solution. Like this proposal https://developer.blender.org/T38656 - I don't think it helps (probably in case you want to keep only icons, but also in that case seems to me easier understand to text, than think what icons represent).

Maybe we could have the Editor list without icons, and the icons individually appear when we mouse hover over the text.

These icons, because they use single pixel lines, can only be scaled well at certain increments. They work well with retina displays @2x too, but probably not so much @1.3x

@Filip Mond (vklidu)
Pixel precision is very important, since icons are raster files rather than vectors. Scalling will cause blurrines, which - in case of such small pictograms - isn't what GUI designers want to get.

In theory I definitely agree, there is nothing to argue. But to keep "crystal" sharpness of pixel based icons you need to fix their size or give user ability to scale them in predefined steps. Like now user will set what ever value, just make them bigger or smaller. How many of them will care if they divide them equally? In reality it is always about dividing some amount of pixels, from that point of view doesn't matter if you divide icon 12x12 or 16x16 :)

For me UI set to 1 is too small on my 27inch screen I use 1.2 or 1.4 so I'm off :) , but I never had a problem with this kind of "unsharpness".
It was already discussed that default size "1" is small for most of the users (always hard t say what is the most, probably there is much bigger group of user that is quietly sitting satisfied with current size :).

Note to use outline as space - 2px wither space (without outline) doesn't help to read icons - like in properties header. It helps current 2.5 icons to be read better (not to the new jendrzch's one).

Now - to shrink icons, or not to shrink? That is a question!

That guideline article in the resources at the top is really a great detail.

I do like the minimal icons and the dark version. Yet i do now see this can cause big issue looking at that example @Brecht Van Lommel (brecht) made

I prefer much more current icons instead monochromatic and flat.

  1. in real use, icons are apposed in UI in small bunches that are contextual. Colour ain’t that much needed here. Honestly, some of current icons pop out too much because of their colour, attracting user’s attention to particular parts of interface. It would be good to incorporate some colour codes though - in File Browser, Asset Manager or Outliner. In every place, where one has to manage big lists of items.

I guesss I'm in the minority here to believe this is .. not correct? I always prefer icons that have colors because that makes them much easier to recognize. Also when you tell beginners "just click on the slightly red sphere" they always click correctly on the material tab in properties windows for example.

Mono and flat might look good in practice but it is of course less powerful..

There is a reason why humans see color. Also since the UI is in essence flat, why should the icons be also flat? So that they blend with the background?

@Adam Preisler (Alphisto): Colors will now be handled by the theme, not the icon glyph. This has many advantages - it makes them readable on both bright and dark themes, and it makes it possible to customize their colors to be strong or subtle.

Most likely we will flesh this out more, so colors can be used to identify items more easily. We already do this in the Outliner, where the theme gives the icons different colors for different types of data.

@William Reynish (billreynish) That's great news. Amazingly great news^^ Application template ready. So does this mean we could change color per icon if needed?
I will probably tune mine in Properties menu to corresond with the current general set of colors / greys.

Is the process from svg to Blender automated or is there a lot of manual work to split icons etc into seperate files?

I see this customizability of Blender pretty great for application templates as they will most likely want to "grey" out a lot of stuff or even introduce new icons of their own.

The Properties window is absolutely most icon reliant as it's one of the rare cases where there's so much different stacked into text-less tab menu.

Just throwing that out there as I haven't realized it previously.

When explaining I always say:
"the camera on the left" (render options)
"the blue wrench" (modifiers)
"the slightly red sphere" (materials)
"the blue sphere on the left" (world)
"the triangle" (mesh data)
"the movie camera" (camera data)
"the yellow light icon" (lamp data)
"the orange cube" (object data)

I know a lot of these are still kind of recognizable but to me, the different colors always meant a lot.

World (Environment) = BlueGreen Earth
Lamp = Yellow
Object = Orange
Modifier = Blue
Materials = Red
Camera = Is grey but could be purple and also purple in the viewport by default? (people have trouble finding it if it blends with the rest)

Like so:

Surprisingly one that I had most trouble with and I misclick often is Render Layer and Scene.. But not so much anymore.. but the rest weren't a problem in distinguishing.