Page MenuHome

Status Bar & Statistics re-shuffling
Closed, ResolvedPublicDESIGN

Authored By
William Reynish (billreynish)
Apr 13 2020, 8:40 AM
Tokens
"Like" token, awarded by Fracture128."Dislike" token, awarded by StrictlyIncreasing."Y So Serious" token, awarded by gilberto_rodrigues."Love" token, awarded by ckohl_art."Dislike" token, awarded by SomeAB."Dislike" token, awarded by Dogway."Like" token, awarded by wevon."Dislike" token, awarded by hitrpr."Love" token, awarded by rlneumiller."Dislike" token, awarded by Alumx."Dislike" token, awarded by 1D_Inc."Love" token, awarded by Tetone."Love" token, awarded by jendrzych."Like" token, awarded by johnsyed.

Description

This is a design document related to recent patches to make changes to the Status Bar and Statistics display in Blender. Several patches will be submitted, so this document serves as an overview of the main reasons why, and the bigger picture of how things fit together.

Currently, the right hand side of the Status Bar is filled with a statistics section:

The issues with this are:

  • This is only relevant for the 3D View. If, for example, you are using the Sequencer, you still get a permanent display of the number of vertices in the 3D View, which serves no useful purpose in that case
  • While useful in some cases, for things like making game assets with polygon budgets, we don't need to permanently always show this information
  • It's hard to read visually, with many abbreviations and pipe symbols in between items
  • It takes up a lot of permanent room, which could be used to better notifications and also just to show the keyboard input for complex operators

For the above reasons, we would like to make a few changes:

1: Move 3D statistics to the 3D View

Moving the stats to the 3D View allows us to make sure this information only appears where it is relevant.
It also makes it possible to list the statistics in a more readable way that resembles a list:

An important change here, is that this information should not be enabled by default. If you need to see this, it can be enabled as an overlay option:

2: Status Bar changes

With the above change, that leaves the Status Bar with two items: The version number and the amount of memory used.
The version number is mainly something that tutorial makers could optionally enable if they wish, and is not necessary to keep visible by default. While using the app, you don't need a constant reminder of the current Blender version.

The amount of memory used can be useful in rare cases, but usually the system process monitor will give you a more useful display of this information. For this reason we should hide this by default, but we can still include in option to show it:

Right-clicking on the Status Bar here will allow you to show these items optionally, similar to adding items to a system tray.

Because the memory used is hidden by default, we can also include the option to show the amount of VRAM used, which Blender knows but is simply currently not shown.

When we *do* show this information, we can do so in a slightly nicer way than before, by removing the pipe symbols, which broke the spacing between items:


This is much easier to read.

These changes will leave the bottom right side of the Status Bar blank by default. This is intentional. This means we can move the notifications and progress bars here instead, which would allow us to use better notifications, always appearing in a consistent place, without interfering with the keyboard shortcuts:

Event Timeline

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

Remember this is only for 2.9x, not for 2.83.x. As time passes and this conversation continues, and I try to use the new stats, the more convinced I am that we should just re-expose the stats through python to at least allow addons to display them as necessary.

Barring that, then I'll throw support behind the following in hopes of having something that looks and works nice:

  • Column aligned stats
    • 10 digits of space between columns; allows 9,999,999_ to be displayed, higher values are allowed to shift without being aligned. Bonus points if you widen all columns as soon as one column exceeds 10 digits.
  • Show selected items before their totals. i.e. 5 30 for 5 selected verts out of 30 (not the other way around)
  • Allow the stats to be individually selected (e.g. I never care about Tris so I never want to see them ever. I don't care about Edges while in Object mode either)
  • Right aligned text labels
objects 1    2
  verts 5    30
  edges 2    20
  faces 0    15
   tris ...

But it would be much nicer to have checkboxes,

For sure, we are talking about optional checkboxes.

Vyacheslav (hitrpr) added a comment.EditedMay 6 2020, 2:59 AM

9,999,999

I know, quantity is always integers, but pleeeeease DON´T ever use comma or point to separate digits like this.

Just compare: «price is $9,999.99» and «price is $9’999.99»

For well-read fonts and high dpi (books) you should use thin spacing.
If it is not enough (font is small, very condenced, very irregular) other thin spacer as «’» (apostroph) or «'» (second) or «´» (unar quote, top comma)
If font very limited and have no thin spaces, no apostrophs, no seconds and minutes — regular spacing, but two spaces before and after digit.
It is very important for fast reading.
And this typographic rule is already broken in Blender.

@Vyacheslav (hitrpr) - ...you should use thin spacing....other thin spacer as «’» (apostroph) or «'» (second) or «´» (unar quote, top comma)

I would LOVE LOVE LOVE to change to using thinspace as digit group separator (yes, we have it in our fonts). I'd rather not consider the others though as they favor the convention in Switzerland and Liechtenstein and I'd rather we went to the new international standard favored by:

For sure, thinspace solution is better for subitizing perception ability.

@Harley Acheson (harley) what do you think about comma instead point as float/fraction separator?
Of course, for input point should remain as more familiar/habital mark.

@Vyacheslav (hitrpr) - what do you think about comma instead point as float/fraction separator?

I wish we could offer a choice for that... https://developer.blender.org/D7515

Okay, Now I see the Idea: statistics per viewport. May be It is nice. Perhaps it is less confusing, than stats in status bar only for active viewport.
But list of stats should be optional and readability over complex backgrounds should be improved.

I see using stats only this way:
No stats by default, I am pressing hotkey, looking at stats (they have solid background), releasing key, stats disappear.

It is very useful bahavior (shift-alike). It is already exist for sculpt (Ctrl for inverse brush and shift key for smooth).

But it have additional power, for example in Paint tool Sai: if key clicked — new brush selected permanently and for next click brush returns to previous.
if key pressed long enough, brush changes, but returns on key-release.
Useful for eraser, for example: sometimes you just need to erase small spot and sometimes you need to work wit eraser long.

The same for stats. Sometimes you want to see it once and sometimes you need to keep it in the corner.

No stats by default.

No stats by default - no new users knowing that stats exists.
Default stats are needed anyway.

Sometimes you want to see it once and sometimes you need to keep it in the corner.

This is why they need to switch between the status bar and the viewport.

CobraA (CobraA) added a comment.EditedMay 9 2020, 12:51 AM

Remember this is only for 2.9x, not for 2.83.x. As time passes and this conversation continues, and I try to use the new stats, the more convinced I am that we should just re-expose the stats through python to at least allow addons to display them as necessary.

Hmmm ,I am sure i have seen Pablo's stream showing stats in 2.83 unless that was reverted, i mainly compile 2.90 after the master branch was pushed to 2.90, but if stats are not yet in 2.83 then it's good because all these issues need to be resolved before the official release.

In the Sequencer is the only reason for having the Preferences in the workspace, checking on the render resolution and project FPS, until the user needs to render. If it is possible to have an option to expose these two values in the statusbar in the Sequencer, the Preferences could be removed from the workspace(for rendering, the users can switch to the render tab instead).

This is why they need to switch between the status bar and the viewport.

What variant do you suggest? Stats only for active viewport?
What is active viewport in this case? Clicked or just mouse over?
What stats it will show, when active area is not viewport?
Remind that we need local stats (selected, or local-space) too.

This is why they need to switch between the status bar and the viewport.

What variant do you suggest? Stats only for active viewport?
What is active viewport in this case? Clicked or just mouse over?
What stats it will show, when active area is not viewport?
Remind that we need local stats (selected, or local-space) too.

Last visited viewport.

Okay. So we ended up with:
Switch between status bar and viewport.
Custom list of properties (to have ability to exclude all unnecessary things).
Local/selected stats.

Another one question: should ram/version will be in the same list or separate?
I propose same but with separator.

Okay. So we ended up with:
Switch between status bar and viewport.
Custom list of properties (to have ability to exclude all unnecessary things).
Local/selected stats.

Well, it seems to satisfy most of possible cases and conditions in my opinion.

Separator

I think it would be nice.

To me, this would be way better in the Item panel when you press N.

I was not a fan of this info placement when I used Maya. Could there be an option to display it in a single line of text as it was before at the bottom of the 3d viewport?

Off topic: the whole info bar at the bottom of the overall window, any chance there could be an option to toggle it to the top of the window. It is often full of useful info for some tools (while other tools for some reason show their info within the top of the 3d viewport) and I'd see it better if I could move it to the top.

I was not a fan of this info placement when I used Maya.

Yes, it is well known Maya issue.

and I'd see it better if I could move it to the top.

Indeed, it was a readable way better when it was on top.

@thin soldier (thinsoldier) agree: it is not so handy when some info about current operation in the top of window, and another part (hotkeys) in the bottom.
Perhaps it would be nice to bring em closer to each other.

Frankly, I don't like this change for default. It can be an option, but no default. Vertex count in the status bar is a clear solution. I don't need statistics for all the time in the viewport. Sometimes I need to check vertex count or tris count - that's all. Now I will have to turn on statistics overlay and then turn it off? - that's a stupid idea. I need 3D viewport for 3D creation not for statistics, but I need to know how many vertexes I selected/ how many vertexes are in the loop. And why vertical not horizontal? Respect 3D viewport space and eyesight/vision

This comment was removed by Sebstian (bosman).

I have been working on an addon that provide similar functionality: https://github.com/muhuk/meshstats FYI

Perhaps you can highlight a few ideas from my proposal on rightclickselect
https://blender.community/c/rightclickselect/7qcbbc/

Frankly, I don't like this change for default. It can be an option, but no default. Vertex count in the status bar is a clear solution. I don't need statistics for all the time in the viewport. Sometimes I need to check vertex count or tris count - that's all. Now I will have to turn on statistics overlay and then turn it off? - that's a stupid idea. I need 3D viewport for 3D creation not for statistics, but I need to know how many vertexes I selected/ how many vertexes are in the loop. And why vertical not horizontal? Respect 3D viewport space and eyesight/vision

I actually agree. This looks so much Maya now... And I thought the stat info in the status bar was so elegant and way better when I switched from Maya. Now the status bar looks kinda sad and useless =)). I'd keep stat data horizontally in the bottom as it was previously, but make it an overlay inside the viewport along with the other info like tips for controls and get rid of the status bar.

Well tbh I never used maya or max extensively, but I like the changes that are presented here. Instead of saying No to this change maybe you guys could try to give some suggestions to improve the new implementation

With the following patch you have the (current) option of showing the stats in the 3D viewport OR in the statusbar as it used to be. Just right-click on the statusbar to see the options:

https://developer.blender.org/D7557

showing the stats in the 3D viewport OR in the statusbar

Gorgeous. Thank you)

showing the stats in the 3D viewport OR in the statusbar

Goooood~
Will wait for custom statistic list to get rid of quantity of vertices and edges.

@Vyacheslav (hitrpr) - Will wait for custom statistic list to get rid of quantity of vertices and edges.

What exactly do you want to see in the statusbar stats?

Vyacheslav (hitrpr) added a comment.EditedJun 18 2020, 7:38 PM

What exactly do you want to see in the statusbar stats?

In object mode and most of the time it is important (for me) to see amount of tris (selected, full-total, instance-reduced, local view) to keep scene not overloaded. And memory use ofc.
Rarely (in obj mode) I need to know how many vertices or polys I have on the mesh (when I emit hairs/particles for example).

In sculpt mode — triscount mainly. May be quadcount for multires. For current sculpt and total visible in the scene.

In edit mode I also use quantity of selected edges or vertices (for checker deselect or mesh analisis).

@Vyacheslav (hitrpr) ...tris (selected, full-total, instance-reduced, local view) to...

Local View is a per-3d view type of thing. We can (hopefully) one day show local view-specific data in the 3Dview overlay version, but will take some work to get there. But there is only one statusbar for a window that could contain more than one 3Dview so those stats can't take local view in account. Being able to (one day) show differing stats per 3d view was one of the reasons for starting on that overlay version.

I'm mostly asking what you like to see in the statusbar stats in case this is an opportunity to turn that one "Show Scene Statistics" into one or two separate checkboxes. But not really seeing any way that breaks up into any logical groupings.

@Harley Acheson (harley)
In status bar I prefer to see tris selected/total in object mode, in sculpt mode polys on current mesh + total visible. If it is dyntopo polys==tris. If it is quadmesh, polys==quads. Pretty simple.

In edit mode: faces selected/total, tris total, vertices selected, edges selected.

But there is only one statusbar

I thought about it and asked Paul (here, higher). And the idea is pretty simple: you use only one active viewport in every single moment. So you can show stats for one and cache stats until viewport will change.

I am not against statistic per viewport. Idea is nice. But it is hardly readable sometimes. And that is the problem.
Statistics in two or more viewports can benefit only ability to compare em faster. Nothing more.

May be, the solution is switching temporary statistics-background for all visible viewports: if there is noisy scene, you can switch it on and see stats clear.
@Paul Kotelevets (1D_Inc) what do you think about this variant?

I'm mostly asking what you like to see in the statusbar stats in case this is an opportunity to turn that one "Show Scene Statistics" into one or two separate checkboxes. But not really seeing any way that breaks up into any logical groupings.

Basically, stats are workflow-dependent.

  • Architectural/CAD/hardsurf/historic restauration modeling types are pretty much ok with the default vertices-oriented stats, because there is no need in exact tris values, and because there are vertices pointclouds as references.
  • Gamedev/web modeling is all about being tris-oriented. For example, when sketchfab stats were designed, we suggested to make it tris-oriented, since models there are web-compatible. As a result we has got system like

Triangles 404
Quads 173.7k
Ngons 32
Total triangles 347.8k
Vertices 187.3k

Also showing in the status bar statistics of the active viewport is a nice solution in my opinion.
Hopes I got question right.

With the following patch you have the (current) option of showing the stats in the 3D viewport OR in the statusbar as it used to be. Just right-click on the statusbar to see the options:

https://developer.blender.org/D7557

That is awesome! Waiting for it to be reviewed and implemented, having these options both in viewport for real-time editing and at the bottom for huge scenes with the ability to turn them off is the way to go!

I didn't want this piece of feedback above to be lost: As time passes and this conversation continues, and I try to use the new stats, the more convinced I am that we should just re-expose the stats through python to at least allow addons to display them as necessary.

Is it planned to add back the python scene.statistics API, in some form, so that addons can more flexibly put stuff in the viewport if desired? I feel it's a needless API break especially now that the stats string was added back to the status bar area.

Continuing a design discussion from D7557 here.

There's a question of at which level the status bar options should be:

  • Preferences -> Settings are "global" for a user
  • Status-bar -> Settings can vary for every .blend
  • Screen-layout (or workspace?) -> Settings can change with the screen-layout (or workspace).

A mixture is also possible. E.g. we could have a default defined in the preferences, but still have the actual settings in the status-bar, so per .blend.

I think the viewport overlay settings would stay where they are, so be per viewport.

I don't think that saving statusbar per .blend is a good idea - because it will make necessary to change it every time you've got some file from another person (like product manager from multiple artists during production process).
Also, statusbar is independent from the workspace, so statusbar is independent from workspace changes by definition.
So it will be better to make statusbar option saved per application, as a global preference.

Viewport statistics is ok to be saved as regular overlay, since it is a regular overlay.

This way the placement determines statistics saving behavior, and this is pretty much expectable solution.

it every time you've got some file from another person

Even working with different projects, I use similar settings for similar workspaces.

I think the viewport overlay settings would stay where they are, so be per viewport.

Agree.

Here a raw idea.

  1. Status bar statistics per application (On/off/what to show).
  2. Status bar settings per file (On/off/what to show)
  3. Checkbox for «override status bar» in the open dialog (same place as «Load UI» checkbox) and file browser will remember state of checkbox permanently (per application).
  1. Ability to switch on the fly (from status bar context menu) between two presets: by file by application. This settings will influence «overide status» checkbox in the filebrowser.

Need critique!

I don't remember that kind of switching override anywhere in the software.
Also, I don't see the reason to keep statusbar setup per file on the off-chance.

The question behind storing statusbar stats per file is "do I need to see statusbar setup made by someone for his purposes?"
I can't find cases, that could possibly bring other answer than "no".

Statusbar stats is always set up to provide info that is needed to your workflow. It is your tool, that you would like to see in the way and order, predictable by you.

It's not so much that per .blend file is important, but per workspace, which come along with .blend files by default. Statistics about the number of vertices would be disabled in e.g. the video editing workspace if we supported this.

How well that works for you depends if you use the Load UI option or not, but there is a use case even for individual users that use Blender for multiple purposes.

It's not so much that per .blend file is important, but per workspace, which come along with .blend files by default. Statistics about the number of vertices would be disabled in e.g. the video editing workspace if we supported this.

How well that works for you depends if you use the Load UI option or not, but there is a use case even for individual users that use Blender for multiple purposes.

This is fair for overlay viewport statistics, which, for sure, is and should be workspace dependent (as a regular overlay), while statusbar is not a part of a workspace system.
We are discussing statusbar one, which is used when viewport is overloaded or when realtime stats control is not needed.

The "Show Status Bar" option is per-workspace, by the current the design the statusbar is definitely part of the workspace.

And just logically, it makes sense that the statusbar can be customized for every workspace. If it's worth the trade-off is a decision to be made.

The "Show Status Bar" option is per-workspace, by the current the design the statusbar is definitely part of the workspace.

And just logically, it makes sense that the statusbar can be customized for every workspace. If it's worth the trade-off is a decision to be made.

I am a project manager, that works with multiple artists.
So, does that means that I should just lock "load ui" option forever to get predictable stats, to avoid having a deal with everyones creativity?

But that's already the case isn't it? Every artist can create their own custom workspace, have multi-window setups, etc. The statusbar doesn't seem like a big step beyond that.

So, everybody, including me and all our artists should keep that option off to work togerher on a complex project?
To simulate saving settings per application on every load instead of just having it?

If you care about having the same user interface layout every time you open a .blend file, then yes? If not, no? Or you can all use a shared set of workspaces? None of this is new.

I don't care particularly strongly about the choice here, there are pros and cons. I think in terms of consistent design it would have to be part of the workspace, but inconsistency is sometimes needed for practical reasons.

I mean, the flexibily of Blender setups, stored per file, makes Blender scene too much personal.
More flexibility - less control, more control - less flexibility.
Extensive flexibility makes issues during teamwork.

If there is no ability to provide defaults that will satisfy everyone, and everyone will create its own approach using providen flexibility, measures should be taken to avoid mess during intensive teamwork.
Teamwork should be taken into account during design.

For instance, if you provide a solution that requires "Load UI" checkbox state lock permanently, you should at least provide "Load UI" checkbox state lock option.

It is a preference already.

Yes, but this preference influences everything, including, for example, viewport layouts.
You are able to reset everything just to obtain proper stats or reset nothing and resetup stats manually every time.
So this question is not that simple.

Maybe we will end up with yet another "setup my blender" single button script that will control statusbar stats, normals display, facedots display, tweak tool selection and other things that are usually resetuped every time, to launch it on every scene opening.
A preset-driven personalizing setting over settings.
It will override setup stored in file, keeping windows layout.
It is hard to imagine other affordable solution.
Too much actions needs to be taken before you start working with someone else's scene at the moment.

The question behind storing statusbar stats per file is "do I need to see statusbar setup made by someone for his purposes?"

For me it sounds different: someone did settings, situable for this certain file and probably I would like it.
Or: I made different settings for this file (sculpt preset) and I don`t want to switch settings every time I go from sculpt to retopo preset.

I agree with Brecht it is more important per workspace and per pipeline.

@Paul Kotelevets (1D_Inc)
I suppose, We will end up with few presets for each workspace.
Now, when I add new workspace to existing file, It loads from default template with almost all settings
So you will have similar workspaces with your work group, but everyone can have his own tweaks via presets.

I agree with Brecht it is more important per workspace and per pipeline.

For sure, every artist will vote for such flexibility during single work, and start setup war during intense teamwork, driving project managers insane.
Known issue.

Now, when I add new workspace to existing file, It loads from default template with almost all settings

Do you mean for hundreds of views of different files per day?

I suppose, We will end up with few presets for each workspace.

Some of the people we work with do not even use workspaces.

Do you mean for hundreds of views of different files per day?

No, I use similar views and similar workspaces for different templates.
And it is obvious to use some standarts for studio work. But it is obvios too, that each artist wants a bit more comfort and tweaking workspace for himself.

And it is obvious to use some standarts for studio work.

Yes.

But it is obvios too, that each artist wants a bit more comfort and tweaking workspace for himself.

Yes.


Here is the conflict we are trying to make less painful.

@Paul Kotelevets (1D_Inc) So for you, the best solution will look like «override someone`s settings by defaults»
Is it right?
Probably, I would prefer the same in most cases.
But it is good to have ability to override settings per workspace + editable templates.

In general: theoretically we will have few levels of influence on settings: global (application), file-template, workspace
And common list of templates: each of them tell Blender what to show or not in the status bar.
So user can decide, what will rule.
Application? Okay — one for all, easy to manage.
File template? Spend time, set up once for each file, use it. I think, file templates usually used for one pipeline.
Workspace? Select existing template from previous tuning, change it a little, save.

Conditions.

  1. If application rules, no matter what settings are in file or workspaces. They saved there but ignored.
  2. If not: 2a. If workspace have own settings, use it or delete it. 2b. If workspace settings not exist, use file settings and you can create settings for workspace.

Now it works pretty similar with workspace settings: we can retune em, or delete workspace and create it back with settings from default file.
And if there is no template for them, blender uses factory settings.

@Paul Kotelevets (1D_Inc) So for you, the best solution will look like «override someone`s settings by defaults»
Is it right?
Probably, I would prefer the same in most cases.
But it is good to have ability to override settings per workspace + editable templates.

In general: theoretically we will have few levels of influence on settings: global (application), file-template, workspace
And common list of templates: each of them tell Blender what to show or not in the status bar.
So user can decide, what will rule.
Application? Okay — one for all, easy to manage.
File template? Spend time, set up once for each file, use it. I think, file templates usually used for one pipeline.
Workspace? Select existing template from previous tuning, change it a little, save.

Conditions.

  1. If application rules, no matter what settings are in file or workspaces. They saved there but ignored.
  2. If not: 2a. If workspace have own settings, use it or delete it. 2b. If workspace settings not exist, use file settings and you can create settings for workspace.

Now it works pretty similar with workspace settings: we can retune em, or delete workspace and create it back with settings from default file.
And if there is no template for them, blender uses factory settings.

It is pretty much complex proposal, I want to analyze it.

Turning Load ui checkbox off is an emergency option, so using emergency option for regular work is quite strange, and usually depicts that system have a problem.

I need some time to think about system requirements.

Vyacheslav (hitrpr) added a comment.EditedJul 10 2020, 3:02 AM

But turning off UI isn`t required. Just turning on override for status bar in settings.

p.s. I turn off UI not only in emergency cases (broken ui) but even if someones workspaces are too crumpled for me and it is easier to understand project structure without it, step by step with my own UI

But turning off UI isn`t required. Just turning on override for status bar in settings.

Yes, I mean, if developers propose solution, that requires permanent UI load lock as the main working tool, we need to look for better possible solutions, like, may be, your.
So we need to analyze it to check how much is it better, at what cost, and so one...

p.s. I turn off UI not only in emergency cases (broken ui) but even if someones workspaces are too crumpled for me and it is easier to understand project structure without it, step by step with my own UI

Guess you do not use it often, do you?
So is there really too much difference between broken UI, and UI that causes recognition problems from the point of usability, if you use the same tool for fixing them?

Guess you do not use it often, do you?

True
And yes, generally not so much difference: both are UIs causing problems.

With Harley's commit this is resolved!

This task almost needs a third part. Now that these bits are in I was hoping to see if we can make the 3dview overlays stats respect local view. I think it can be done efficiently, but haven’t looked in awhile. Maybe for 2.91.

Okay, thanks. At least we have a bit more than we had!

Are there talks about having a Pref option to not have the Status Bar text/output in 2.9, way over to the right side?
I have a 34" Monitor and i basically don't even see/notice that stuff anymore, because it's way over to the right. It would be nice to have a pref to keep it centered yet or move to side.

Are there talks about having a Pref option to not have the Status Bar text/output in 2.9, way over to the right side?
I have a 34" Monitor and i basically don't even see/notice that stuff anymore, because it's way over to the right. It would be nice to have a pref to keep it centered yet or move to side.

Well, there was two issues made during 2.8 design - stats was put from top to bottom, and aligned to the right to make them less readable as it is possible to make them useless and replace with onscreen version, which have well known ussues for all this time, so we now are still trying to fix all this convulsive design flaws made by no reason.

Would it be possible to add ngons to the Statistics ?

Would it be possible to add ngons to the Statistics ?

Not sure, but I can check.

Would this be wanted both in the 3DView overlay and also available the footer? Just in Edit Mode or Object mode too? Should any of these be included only in certain selection Modes?

@xan2622 (xan2622) it is better to check for n-gons with special tools like 3d print tool or CheckToolbox. Both are free and first is build in.

@Vyacheslav (hitrpr) : I already use Poly Source (https://gumroad.com/l/polysource).
ngons is a very useful information for 3D modelers, IMO it makes sense to display this information too. Since Statistics have been added onto this viewport overlay, adding ngons would be very convenient for Blender users who don't use these extra add-ons.

@Harley Acheson (harley): on the viewport (in the 3DView overlay) but mostly in Edit Mode. Would it be useful in Object Mode? I am not sure.
About the footer: I think it also might worth adding ngons to it (in Edit Mode).