Status Bar & Statistics re-shuffling #75672

New Issue

Closed

opened 2020-04-13 08:40:11 +02:00 by William Reynish · 116 comments

William Reynish commented 2020-04-13 08:40:11 +02:00

Copy Link

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:

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: 

William Reynish commented 2020-04-13 08:40:11 +02:00

Author

Copy Link

Added subscriber: @WilliamReynish

Added subscriber: @WilliamReynish

William Reynish commented 2020-04-13 08:41:14 +02:00

Author

Copy Link

Changed status from 'Needs Triage' to: 'Confirmed'

Changed status from 'Needs Triage' to: 'Confirmed'

Harley Acheson was assigned by William Reynish 2020-04-13 10:19:16 +02:00

Harley Acheson commented 2020-04-24 21:23:34 +02:00

Member

Copy Link

A couple suggestions noted:

We could always show the number of Objects. One good reason is that then a simple change from going from selected mesh object to editing the list would include the same items, rather than appearing to shift up one line. Another reason is because we allow multi-object editing. So if I select three objects and then enter Edit mode it might be nice to show number of Objects selected and total.

Another suggestion is to add thinspace on either side of the slash to make the numbers easier to read. Need a mockup or capture to confirm.

A couple suggestions noted: We could always show the number of Objects. One good reason is that then a simple change from going from selected mesh object to editing the list would include the same items, rather than appearing to shift up one line. Another reason is because we allow multi-object editing. So if I select three objects and then enter Edit mode it might be nice to show number of Objects selected and total. Another suggestion is to add thinspace on either side of the slash to make the numbers easier to read. Need a mockup or capture to confirm.

Paul Kotelevets commented 2020-04-25 17:15:42 +02:00

Copy Link

Added subscriber: @1D_Inc

Added subscriber: @1D_Inc

Paul Kotelevets commented 2020-04-25 17:15:42 +02:00

Copy Link

The concept, of course, is interesting and familiar, but among the displayed data there is no real-time data to be displayed in the viewport window.
Instances and particles are still not influencing that values, so you can't say how much geometry is generated, that could possibly be useful for realtime display.
These are just mesh statistics that you only need to look at from time to time. Once an hour to be sure that everything is ok.

The concept, of course, is interesting and familiar, but among the displayed data there is no real-time data to be displayed in the viewport window. Instances and particles are still not influencing that values, so you can't say how much geometry is generated, that could possibly be useful for realtime display. These are just mesh statistics that you only need to look at from time to time. Once an hour to be sure that everything is ok.

Steff Kempink commented 2020-04-25 20:58:49 +02:00

Copy Link

Added subscriber: @McSwiff

Added subscriber: @McSwiff

Steff Kempink commented 2020-04-25 20:58:49 +02:00

Copy Link

I just wanted to chip in as somebody who models for real time applications and pays attention to these stats constantly.

Being able to read the stats accurately is secondary. What is more useful for my case, is being able to see the number drastically change during any operation. Maybe it's unintended duplication or accidentally copying a bevel modifier with too many edges, and then quickly being able to roll back such a change. Instead of diagnosing it later.
So moving stats to the 3d view and closer to the periphery is an improvement to this usecase, but having to toggle it in the overlay options is not. For such a user it makes a lot more sense to (also) have this setting available globally. I always care about the statistics and having to enable it on every 3d view for every workspace for every file that I open is just busywork.

Or should such an ability to "always enable" an overlay option be left to an addon where Blender sticks to just the overlay options?

I just wanted to chip in as somebody who models for real time applications and pays attention to these stats constantly. Being able to read the stats accurately is secondary. What is more useful for my case, is being able to see the number drastically change during any operation. Maybe it's unintended duplication or accidentally copying a bevel modifier with too many edges, and then quickly being able to roll back such a change. Instead of diagnosing it later. So moving stats to the 3d view and closer to the periphery is an improvement to this usecase, but having to toggle it in the overlay options is not. For such a user it makes a lot more sense to (also) have this setting available globally. I always care about the statistics and having to enable it on every 3d view for every workspace for every file that I open is just busywork. Or should such an ability to "always enable" an overlay option be left to an addon where Blender sticks to just the overlay options?

Chris Kohl commented 2020-04-26 21:02:55 +02:00

Copy Link

Added subscriber: @ckohl_art

Added subscriber: @ckohl_art

Paul Kotelevets commented 2020-04-27 20:44:21 +02:00

Copy Link

So it will be hard to read them now for cases like that.

To work like that is as disctracting as watching movie like that, that makes it hard to concentrate both on a model or statistics.

Should be optional.

So it will be hard to read them now for cases like that.  To work like that is as disctracting as watching movie like that, that makes it hard to concentrate both on a model or statistics.  Should be optional.

Vyacheslav Kobozev commented 2020-05-01 19:25:00 +02:00

Copy Link

Added subscriber: @Vyach

Added subscriber: @Vyach

Vyacheslav Kobozev commented 2020-05-01 19:25:00 +02:00

Copy Link

Okay guys, you add new overlay with old problem. And new one (alredy exposed above)

Most of the time most users DO NOT interested how much face swhole scene have, they know approximate polycount and it is enough.
How much verts? It is rare, when you need such statistic. Faces? The only profit I see from it: if tris > 2*faces then object is not quad, but I don`t have stats per selected object, until I hide all the rest.
Edges? Tell me one reason to know how much edges in the scene, when I am at object mode. Did somebody ever use it?

The most important thing is amount of tris in the selected object.
If I in the local view, I still see global polycount. WHY?

Guys, PLEEEEEASE, make stats for selected objects.
Tris [selected/all] at first place (or last as most visible and noticible)
Objects selected/all
In the status bar. And I will off all other stats forever.

Okay guys, you add new overlay with old problem. And new one (alredy exposed above) Most of the time most users DO NOT interested how much face swhole scene have, they know approximate polycount and it is enough. How much verts? It is rare, when you need such statistic. Faces? The only profit I see from it: if tris > 2*faces then object is not quad, but I don`t have stats per selected object, until I hide all the rest. Edges? Tell me one reason to know how much edges in the scene, when I am at object mode. Did somebody ever use it? The most important thing is amount of tris in the selected object. If I in the local view, I still see global polycount. WHY? Guys, PLEEEEEASE, make stats for selected objects. Tris [selected/all] at first place (or last as most visible and noticible) Objects selected/all In the status bar. And I will off all other stats forever.

Paul Kotelevets commented 2020-05-01 19:57:58 +02:00

Copy Link

It should be optional to status bar statistics display, because status bar solution fits any model type, since is independent from viewport details overload.
Ability to display selected objects stats is also highly appreciated for complex assemblies and architectural modeling/optimizations.

It should be optional to status bar statistics display, because status bar solution fits any model type, since is independent from viewport details overload. Ability to display selected objects stats is also highly appreciated for complex assemblies and architectural modeling/optimizations.

Paul Kotelevets commented 2020-05-03 11:31:31 +02:00

Copy Link

To make things clear - for sure overlay statisctics is a nice feature to have, and will be useful for example, for lowpoly modeling, when the polycontrol requires real-time control, and the model does not overload the viewing area.
But there are lots of cases, when model overloads viewport, and polycount control is pretty much idle, like in combining final scene, so statistics requires to be shown independently from viewport in that cases, like in status bar example.

To make things clear - for sure overlay statisctics is a nice feature to have, and will be useful for example, for lowpoly modeling, when the polycontrol requires real-time control, and the model does not overload the viewing area. But there are lots of cases, when model overloads viewport, and polycount control is pretty much idle, like in combining final scene, so statistics requires to be shown independently from viewport in that cases, like in status bar example.

Jose commented 2020-05-04 20:05:01 +02:00

Copy Link

Added subscriber: @Dogway

Added subscriber: @Dogway

Jose commented 2020-05-04 20:05:01 +02:00

Copy Link

Overlay statistics is a very useful feature. People think whether you need poly count or such, no, overlay statistics is for everything you want to show as an overlay. We already have a few stats; framecounter, camera view, collection... this only expands the stats on an optional way.

This is good, now what's not is the implementation it has been done here. We are now chopping the status bar stats and telling what should be shown where... this is bad design. You have people that find the overlay distracting, and there are other that find the status bar not maximizing workspace full screen enough. In such terms you should be able to show the same stats on the status bar and the overlay, otherwise you end up in the middle of nowhere having to disable or enable both.

I already explained on the patch discussion why commited memory or blender version is useful. It should be customizable though, but at this point I don't know if it's worth it having so many free addons that do the job like AStats.

"Blender is known to have issues with heavy meshes, having committed memory is very useful for sculpting. Blender version, the open source nature of it makes it so many people keep at least 2 or 3 versions of Blender at the same time."

Overlay statistics is a very useful feature. People think whether you need poly count or such, no, overlay statistics is for everything you want to show as an overlay. We already have a few stats; framecounter, camera view, collection... this only expands the stats on an optional way. This is good, now what's not is the implementation it has been done here. We are now chopping the status bar stats and telling what should be shown where... this is bad design. You have people that find the overlay distracting, and there are other that find the status bar not maximizing workspace full screen enough. In such terms you should be able to show the same stats on the status bar and the overlay, otherwise you end up in the middle of nowhere having to disable or enable both. I already explained on the patch discussion why commited memory or blender version is useful. It should be customizable though, but at this point I don't know if it's worth it having so many free addons that do the job like AStats. *"Blender is known to have issues with heavy meshes, having committed memory is very useful for sculpting. Blender version, the open source nature of it makes it so many people keep at least 2 or 3 versions of Blender at the same time."* 

Vyacheslav Kobozev commented 2020-05-05 05:29:23 +02:00

Copy Link

One more thing. I see that there was problem before with instanced objects.

Both numbers (initial and total) tris are important for performance. So it looks like there should be 4 numbers for tris in object mode.
Like 16/128 (8/32) where first pair is total numbers for selected and scene and second pair do not count repeating instances.
For edit mode all can be the same, as is.

One more thing. I see that there was problem before with instanced objects. Both numbers (initial and total) tris are important for performance. So it looks like there should be 4 numbers for tris in object mode. Like *16/128 (8/32)* where first pair is total numbers for selected and scene and second pair do not count repeating instances. For edit mode all can be the same, as is.

Paul Kotelevets commented 2020-05-05 10:07:45 +02:00

Copy Link

In #75672#924386, @Vyach wrote:
One more thing. I see that there was problem before with instanced objects.

Both numbers (initial and total) tris are important for performance. So it looks like there should be 4 numbers for tris in object mode.
Like 16/128 (8/32) where first pair is total numbers for selected and scene and second pair do not count repeating instances.
For edit mode all can be the same, as is.

So we are talking about statistic modes then.

• Selection stats mode - selected object stats are shown - useful for optimizing assets/scene. Entire scene / visible collections stats for comparisons can be obtained with selecting everything.
• Editable stats mode - every editable geometry stats are shown - current default mode.
• Full stats mode - every visible geometry stats are shown, including visible links and instances and etc - useful to control overal scene viewport load when combining final scene to know how much it weights.

Those modes are needed for different types of tasks, therefore there is no need to display them together, so their appearance can be solved with proper design.

> In #75672#924386, @Vyach wrote: > One more thing. I see that there was problem before with instanced objects. > > Both numbers (initial and total) tris are important for performance. So it looks like there should be 4 numbers for tris in object mode. > Like *16/128 (8/32)* where first pair is total numbers for selected and scene and second pair do not count repeating instances. > For edit mode all can be the same, as is. So we are talking about statistic *modes* then. - Selection stats mode - **selected** object stats are shown - useful for optimizing assets/scene. Entire scene / visible collections stats for comparisons can be obtained with selecting everything. - Editable stats mode - every **editable** geometry stats are shown - current default mode. - Full stats mode - every **visible** geometry stats are shown, including visible links and instances and etc - useful to control overal scene viewport load when combining final scene to know how much it weights. Those modes are needed for different types of tasks, therefore there is no need to display them together, so their appearance can be solved with proper design.

Vyacheslav Kobozev commented 2020-05-05 15:33:31 +02:00

Copy Link

In #75672#924488, @1D_Inc wrote:
there is no need to display them together

Sometimes I need to see
a) selected/unselected for mesh or objects to understand proportions and compare.
b) as you said, I need total polycount for object to control it in lowpoly.
c) selected/visible/instanced polycount in object mode to undestand how much I can or should keep as instances

But it would be much nicer to have checkboxes, what to show and where + ability to save few presets, or, at least, to make simple text-config file for presets.
And no disputes about what better. I am not a big fan to fill workspace with unnecessary info. But sometimes I need to see it.

> In #75672#924488, @1D_Inc wrote: > there is no need to display them together Sometimes I need to see a) selected/unselected for mesh or objects to understand proportions and compare. b) as you said, I need total polycount for object to control it in lowpoly. c) selected/visible/instanced polycount in object mode to undestand how much I can or should keep as instances But it would be much nicer to have checkboxes, what to show and where + ability to save few presets, or, at least, to make simple text-config file for presets. And no disputes about what better. I am not a big fan to fill workspace with unnecessary info. But sometimes I need to see it.

Ahmad Bilal commented 2020-05-05 19:45:56 +02:00

Copy Link

Added subscriber: @SomeAB

Added subscriber: @SomeAB

Ahmad Bilal commented 2020-05-05 19:45:56 +02:00

Copy Link

I haven't had a problem with any changes made to blender since 2.8 .. and agreed with every UI change so far, as they made sense. But this one, I have to politely, yet STRONGLY disagree with. Here is my reasons & suggestions on the matter (see the image below):

I haven't had a problem with any changes made to blender since 2.8 .. and agreed with every UI change so far, as they made sense. But this one, I have to politely, yet STRONGLY disagree with. Here is my reasons & suggestions on the matter (see the image below): 

Chris Kohl commented 2020-05-05 22:02:59 +02:00

Copy Link

I'm gonna be "that guy" and say I want it like this:

3 right-aligned columns for scene (only measures objects that are not hidden), selected objects, and selected components, with numbers in fixed locations that have nice spacing in between.

• No messy slashes / or pipes | between numbers.
• Numbers are not pushed too close to each other.
• Numbers don't slide left and right when digits are added or subtracted.

It's just about the most organized and least cluttered presentation you can get.

But maybe with a better stroke, drop shadow, or translucent box to improve visibility on top of bright objects.

And the ability to choose which stats appear since that seems to be a popular request (and makes sense if we're going to add more stats like number of objects selected, multires level, etc..). For example, current collection, object name, and frame number are useless to me and I would prefer they not take up space (and I can do that by unchecking "Text Info" in the overlays, which is good). But others may want to keep that but they do not care about the entire row for UVs or the entire column for Selected Components.

I'm gonna be "that guy" and say I want it like this:   3 right-aligned columns for scene (only measures objects that are not hidden), selected objects, and selected components, with numbers in *fixed* locations that have nice spacing in between. * No messy slashes / or pipes | between numbers. * Numbers are not pushed too close to each other. * Numbers don't slide left and right when digits are added or subtracted. It's just about the most organized and least cluttered presentation you can get. But maybe with a better stroke, drop shadow, or translucent box to improve visibility on top of bright objects. And the ability to choose which stats appear since that seems to be a popular request (and makes sense if we're going to add more stats like number of objects selected, multires level, etc..). For example, current collection, object name, and frame number are useless to me and I would prefer they not take up space (and I can do that by unchecking "Text Info" in the overlays, which is good). But others may want to keep that but they do not care about the entire row for UVs or the entire column for Selected Components.

Harley Acheson commented 2020-05-05 22:39:18 +02:00

Member

Copy Link

@SomeAB = suggestions on the matter (see the image below)

Having the stats in an Editor that is separate from the 3D View means that we could only ever show global scene stats. Ideally these numbers would vary per viewport, for example if you view Local in one it would be nice to just see local stats there. They don't do that now of course, but at least that is something that could be done now.

@ckohl_art - I'm gonna be "that guy" and say I want it like this:

Ideally a mockup for this should include the text overlay as well to better illustrate how much this intrudes into the working area. Even better if it includes part of the interface so we know the scale you have used. Setting the Interface to 1X scale, setting the blender window to something that fits within our required monitor size, and with the capture including the all of the 3D View editor. Again, just to get a better sense of how this fits within the whole.

> @SomeAB = suggestions on the matter (see the image below) Having the stats in an Editor that is separate from the 3D View means that we could only ever show global scene stats. Ideally these numbers would vary per viewport, for example if you view Local in one it would be nice to just see local stats there. They don't do that now of course, but at least that is something that could be done now. > @ckohl_art - I'm gonna be "that guy" and say I want it like this: Ideally a mockup for this should include the text overlay as well to better illustrate how much this intrudes into the working area. Even better if it includes part of the interface so we know the scale you have used. Setting the Interface to 1X scale, setting the blender window to something that fits within our required monitor size, and with the capture including the all of the 3D View editor. Again, just to get a better sense of how this fits within the whole.

Chris Kohl commented 2020-05-05 22:50:41 +02:00

Copy Link

In #75672#924964, @Harley wrote:
Ideally a mockup for this should include the text overlay as well to better illustrate how much this intrudes into the working area.

That's a good point.

setting the blender window to something that fits within our required monitor size

There's a required size? I'm assuming from the context that it's a specified size to reference for testing designs? Is that listed in a doc somewhere?

> In #75672#924964, @Harley wrote: > Ideally a mockup for this should include the text overlay as well to better illustrate how much this intrudes into the working area. That's a good point. > setting the blender window to something that fits within our required monitor size There's a required size? I'm assuming from the context that it's a specified size to reference for testing designs? Is that listed in a doc somewhere?

Harley Acheson commented 2020-05-05 23:03:19 +02:00

Member

Copy Link

@ckohl_art - There's a required size?

Sorry, really not trying to make you do anything specific, and really do enjoy all mockups. I just mean it is best if you make it in a way that we gives maximum information and is a reasonable size.

Our minimum requirement is for display that can do 1280×768, but I find that a bit too small to represent proposals well. I generally start with 1X on an 1920 x 1080 monitor with the default theme and default layout. Then I scale it down slightly to give some breathing room around. In this specific case I would then capture the whole thing but clip out just the 3D View editor (including header) since the rest is superfluous to this. The result says a lot about the size and proportions of things.

That said, nothing is ever off the table in this kind of thing. So if your proposal needs a smaller font size then mention that too and perhaps give something to indicate the size difference.

Something else nice for this particular issue is to not only include that text overlay but also to include more variety in the stats display too. The problematic ones for this is the "Triangles" count as it only has a total and not a selected. And there are a few stats like that so they can't always fill a nice grid and where to put the oddballs can look funny. LOL

> @ckohl_art - There's a required size? Sorry, really not trying to make you do anything specific, and really do enjoy all mockups. I just mean it is best if you make it in a way that we gives maximum information and is a reasonable size. Our minimum requirement is for display that can do 1280×768, but I find that a bit too small to represent proposals well. I generally start with 1X on an 1920 x 1080 monitor with the default theme and default layout. Then I scale it down slightly to give some breathing room around. In this specific case I would then capture the whole thing but clip out just the 3D View editor (including header) since the rest is superfluous to this. The result says a lot about the size and proportions of things. That said, nothing is ever off the table in this kind of thing. So if your proposal needs a smaller font size then mention that too and perhaps give something to indicate the size difference. Something else nice for this particular issue is to not only include that text overlay but also to include more variety in the stats display too. The problematic ones for this is the "Triangles" count as it only has a total and not a selected. And there are a few stats like that so they can't always fill a nice grid and where to put the oddballs can look funny. LOL

CobraA commented 2020-05-05 23:35:59 +02:00

Copy Link

Added subscriber: @CobraA

Added subscriber: @CobraA

CobraA commented 2020-05-05 23:35:59 +02:00

Copy Link

The stats should be a popover, a dropdown menu with each line as an option, whatever that makes them easily toggleable instead of just one toggle in the overlays.
Blender is not just a modeling app, each workspace should have certain stats shown and their "visiblity" enabled by default.
As of now, we don't have much control over them and them being disabled by default will cause more headaches and bug reports when the 2.83 gets released...so best to avoid that and enabled the stats for all the workspaces/templates.

The stats should be a popover, a dropdown menu with each line as an option, whatever that makes them easily toggleable instead of just one toggle in the overlays. Blender is not just a modeling app, each workspace should have certain stats shown and their "visiblity" enabled by default. As of now, we don't have much control over them and them being disabled by default will cause more headaches and bug reports when the 2.83 gets released...so best to avoid that and enabled the stats for all the workspaces/templates.

Jesse Yurkovich commented 2020-05-06 00:10:43 +02:00

Member

Copy Link

Added subscriber: @deadpin

Added subscriber: @deadpin

Jesse Yurkovich commented 2020-05-06 00:10:43 +02:00

Member

Copy Link

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 ...

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 ... ```

Paul Kotelevets commented 2020-05-06 00:36:30 +02:00

Copy Link

In #75672#924755, @Vyach wrote:

But it would be much nicer to have checkboxes,

For sure, we are talking about optional checkboxes.

> In #75672#924755, @Vyach wrote: > But it would be much nicer to have checkboxes, For sure, we are talking about optional checkboxes.

Vyacheslav Kobozev commented 2020-05-06 02:59:13 +02:00

Copy Link

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.

> 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.

Harley Acheson commented 2020-05-06 03:46:52 +02:00

Member

Copy Link

@Vyach - ...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:

• ISO 31-0
• International Bureau of Weights and Measures
• International Union of Pure and Applied Chemistry
• AMA Manual of Style
• Metrication Board

> @Vyach - ...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: - [ISO 31-0 ](https://en.wikipedia.org/wiki/ISO_31-0#Numbers) - [International Bureau of Weights and Measures ](https://en.wikipedia.org/wiki/International_Bureau_of_Weights_and_Measures) - [International Union of Pure and Applied Chemistry ](https://en.wikipedia.org/wiki/International_Union_of_Pure_and_Applied_Chemistry) - [AMA Manual of Style ](https://en.wikipedia.org/wiki/AMA_Manual_of_Style) - [Metrication Board ](https://en.wikipedia.org/wiki/Metrication_Board)

Paul Kotelevets commented 2020-05-06 15:04:32 +02:00

Copy Link

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

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

Vyacheslav Kobozev commented 2020-05-06 20:22:39 +02:00

Copy Link

@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.

@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.

Harley Acheson commented 2020-05-06 20:32:01 +02:00

Member

Copy Link

@Vyach - 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

> @Vyach - 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

Vyacheslav Kobozev commented 2020-05-09 00:21:55 +02:00

Copy Link

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.

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.

Paul Kotelevets commented 2020-05-09 00:36:12 +02:00

Copy Link

In #75672#927384, @Vyach wrote:
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.

> In #75672#927384, @Vyach wrote: > 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 commented 2020-05-09 00:51:42 +02:00

Copy Link

In #75672#925010, @deadpin wrote:
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 #75672#925010, @deadpin wrote: > 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.

tintwotin commented 2020-05-09 05:24:18 +02:00

Copy Link

Added subscriber: @tintwotin

Added subscriber: @tintwotin

tintwotin commented 2020-05-09 05:24:18 +02:00

Copy Link

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).

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).

Vyacheslav Kobozev commented 2020-05-09 08:33:08 +02:00

Copy Link

In #75672#927389, @1D_Inc wrote:
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.

> In #75672#927389, @1D_Inc wrote: > 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.

Paul Kotelevets commented 2020-05-09 08:51:35 +02:00

Copy Link

In #75672#927498, @Vyach wrote:

In #75672#927389, @1D_Inc wrote:
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.

> In #75672#927498, @Vyach wrote: >> In #75672#927389, @1D_Inc wrote: >> 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.

Vyacheslav Kobozev commented 2020-05-09 22:08:53 +02:00

Copy Link

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. Another one question: should ram/version will be in the same list or separate? I propose same but with separator.

Paul Kotelevets commented 2020-05-10 11:28:18 +02:00

Copy Link

In #75672#927874, @Vyach wrote:
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.

> In #75672#927874, @Vyach wrote: > 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.

William Reynish commented 2020-05-11 13:45:03 +02:00

Author

Copy Link

No description provided.

Gilberto Rodrigues commented 2020-05-15 06:22:09 +02:00

Contributor

Copy Link

Added subscriber: @Gilberto.R

Added subscriber: @Gilberto.R

Gilberto Rodrigues commented 2020-05-15 06:22:09 +02:00

Contributor

Copy Link

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

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

tintwotin commented 2020-05-15 08:56:34 +02:00

Copy Link

Removed subscriber: @tintwotin

Removed subscriber: @tintwotin

thin soldier commented 2020-05-24 06:04:53 +02:00

Copy Link

Added subscriber: @thinsoldier

Added subscriber: @thinsoldier

thin soldier commented 2020-05-24 06:04:53 +02:00

Copy Link

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. 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.

Paul Kotelevets commented 2020-05-24 13:23:22 +02:00

Copy Link

In #75672#937574, @thinsoldier wrote:
I was not a fan of this info placement when I used Maya.

Yes, it is well known Maya issue.

In #75672#937574, @thinsoldier wrote:
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.

> In #75672#937574, @thinsoldier wrote: > I was not a fan of this info placement when I used Maya. Yes, it is well known Maya issue. > In #75672#937574, @thinsoldier wrote: > 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.

Vyacheslav Kobozev commented 2020-05-24 14:20:57 +02:00

Copy Link

@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.

@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.

Sebstian commented 2020-05-24 20:05:20 +02:00

Copy Link

Added subscriber: @bosman

Added subscriber: @bosman

Sebstian commented 2020-05-24 20:05:20 +02:00

Copy Link

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

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 

Sebstian commented 2020-05-24 20:13:00 +02:00

Copy Link

This comment was removed by @bosman

*This comment was removed by @bosman*

Atamert Ölçgen commented 2020-05-26 16:21:28 +02:00

Copy Link

Added subscriber: @muhuk

Added subscriber: @muhuk

Atamert Ölçgen commented 2020-05-26 16:21:28 +02:00

Copy Link

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

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

So3Datel commented 2020-05-27 09:37:38 +02:00

Copy Link

Added subscriber: @AxelMening-4

Added subscriber: @AxelMening-4

So3Datel commented 2020-05-27 09:37:38 +02:00

Copy Link

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

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

Chingiz Jumagulov commented 2020-06-03 08:48:10 +02:00

Copy Link

Added subscriber: @MeshVoid

Added subscriber: @MeshVoid

Chingiz Jumagulov commented 2020-06-03 08:48:10 +02:00

Copy Link

In #75672#937782, @bosman wrote:
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.

> In #75672#937782, @bosman wrote: > 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.

Gilberto Rodrigues commented 2020-06-04 22:33:19 +02:00

Contributor

Copy Link

Removed subscriber: @Gilberto.R

Removed subscriber: @Gilberto.R

Arbaz Arif commented 2020-06-18 01:36:00 +02:00

Copy Link

Added subscriber: @AcidRain0

Added subscriber: @AcidRain0

Arbaz Arif commented 2020-06-18 01:36:00 +02:00

Copy Link

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

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

Harley Acheson commented 2020-06-18 01:52:37 +02:00

Member

Copy Link

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

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

Paul Kotelevets commented 2020-06-18 09:26:08 +02:00

Copy Link

In #75672#956449, @Harley wrote:
showing the stats in the 3D viewport OR in the statusbar

Gorgeous. Thank you)

> In #75672#956449, @Harley wrote: > showing the stats in the 3D viewport OR in the statusbar Gorgeous. Thank you)

Vyacheslav Kobozev commented 2020-06-18 14:28:38 +02:00

Copy Link

In #75672#956449, @Harley wrote:
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.

> In #75672#956449, @Harley wrote: > 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.

Harley Acheson commented 2020-06-18 16:24:05 +02:00

Member

Copy Link

@Vyach - 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?

> @Vyach - 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 Kobozev commented 2020-06-18 19:38:01 +02:00

Copy Link

In #75672#957173, @Harley wrote:
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).

> In #75672#957173, @Harley wrote: > 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).

Harley Acheson commented 2020-06-18 20:22:21 +02:00

Member

Copy Link

@Vyach ...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.

> @Vyach ...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.

Vyacheslav Kobozev commented 2020-06-18 21:46:01 +02:00

Copy Link

@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.
@1D_Inc what do you think about this variant?

@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. @1D_Inc what do you think about this variant?

Paul Kotelevets commented 2020-06-19 00:46:35 +02:00

Copy Link

In #75672#957681, @Harley wrote:
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.

> In #75672#957681, @Harley wrote: > 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.

Chingiz Jumagulov commented 2020-06-23 06:38:16 +02:00

Copy Link

In #75672#956449, @Harley wrote:
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!

> In #75672#956449, @Harley wrote: > 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!

Jesse Yurkovich commented 2020-06-26 20:57:51 +02:00

Member

Copy Link

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.

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.

Julian Eisel commented 2020-06-30 11:59:41 +02:00

Member

Copy Link

Added subscriber: @JulianEisel

Added subscriber: @JulianEisel

Julian Eisel commented 2020-06-30 11:59:41 +02:00

Member

Copy Link

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.

Continuing a design discussion from [D7557](https://archive.blender.org/developer/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.

Paul Kotelevets commented 2020-06-30 15:00:42 +02:00

Copy Link

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.

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.

Vyacheslav Kobozev commented 2020-07-07 23:55:28 +02:00

Copy Link

In #75672#969758, @1D_Inc wrote:
it every time you've got some file from another person

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

In #75672#969648, @JulianEisel wrote:
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).

4. 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!

> In #75672#969758, @1D_Inc wrote: > it every time you've got some file from another person Even working with different projects, I use similar settings for similar workspaces. > In #75672#969648, @JulianEisel wrote: > 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). 4. 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!

Paul Kotelevets commented 2020-07-08 09:23:17 +02:00

Copy Link

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.

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.

Brecht Van Lommel commented 2020-07-08 11:57:47 +02:00

Owner

Copy Link

Added subscriber: @brecht

Added subscriber: @brecht

Brecht Van Lommel commented 2020-07-08 11:57:47 +02:00

Owner

Copy Link

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.

Paul Kotelevets commented 2020-07-08 12:53:06 +02:00

Copy Link

In #75672#975194, @brecht wrote:
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.

> In #75672#975194, @brecht wrote: > 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.

Brecht Van Lommel commented 2020-07-08 13:12:58 +02:00

Owner

Copy Link

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.

Paul Kotelevets commented 2020-07-08 13:22:41 +02:00

Copy Link

In #75672#975255, @brecht wrote:
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?

> In #75672#975255, @brecht wrote: > 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?

Brecht Van Lommel commented 2020-07-08 13:26:37 +02:00

Owner

Copy Link

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.

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.

Paul Kotelevets commented 2020-07-08 13:31:20 +02:00

Copy Link

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?

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?

Brecht Van Lommel commented 2020-07-08 13:46:18 +02:00

Owner

Copy Link

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.

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.

Paul Kotelevets commented 2020-07-08 14:04:48 +02:00

Copy Link

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.

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.

Paul Kotelevets commented 2020-07-08 14:15:40 +02:00

Copy Link

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.

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.

Brecht Van Lommel commented 2020-07-08 14:22:00 +02:00

Owner

Copy Link

It is a preference already.

It is a preference already.

Paul Kotelevets commented 2020-07-08 14:43:44 +02:00

Copy Link

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.

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.

Paul Kotelevets commented 2020-07-08 15:34:26 +02:00

Copy Link

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.

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.

Vyacheslav Kobozev commented 2020-07-08 20:07:39 +02:00

Copy Link

In #75672#975131, @1D_Inc wrote:
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.

@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.

> In #75672#975131, @1D_Inc wrote: > 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. @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.

Paul Kotelevets commented 2020-07-08 21:40:26 +02:00

Copy Link

In #75672#975429, @Vyach wrote:
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.

> In #75672#975429, @Vyach wrote: > 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.

Vyacheslav Kobozev commented 2020-07-08 22:08:20 +02:00

Copy Link

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.

>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.

Paul Kotelevets commented 2020-07-08 23:06:31 +02:00

Copy Link

In #75672#975533, @Vyach wrote:

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.

> In #75672#975533, @Vyach wrote: > 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.

Vyacheslav Kobozev commented 2020-07-09 03:45:12 +02:00

Copy Link

@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.

@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.

Vyacheslav Kobozev commented 2020-07-09 04:51:56 +02:00

Copy Link

@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.

@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 commented 2020-07-09 19:16:42 +02:00

Copy Link

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.

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 Kobozev commented 2020-07-10 03:02:13 +02:00

Copy Link

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. 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

Paul Kotelevets commented 2020-07-10 09:27:03 +02:00

Copy Link

In #75672#976332, @Vyach wrote:
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?

> In #75672#976332, @Vyach wrote: > 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?

Vyacheslav Kobozev commented 2020-07-10 10:19:09 +02:00

Copy Link

Guess you do not use it often, do you?

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

>Guess you do not use it often, do you? True And yes, generally not so much difference: both are UIs causing problems.

Hans Goudey commented 2020-07-18 18:34:37 +02:00

Member

Copy Link

Added subscriber: @HooglyBoogly

Added subscriber: @HooglyBoogly

Hans Goudey commented 2020-07-18 18:34:37 +02:00

Member

Copy Link

Changed status from 'Confirmed' to: 'Resolved'

Changed status from 'Confirmed' to: 'Resolved'

Hans Goudey closed this issue 2020-07-18 18:34:37 +02:00

Hans Goudey commented 2020-07-18 18:34:37 +02:00

Member

Copy Link

With Harley's commit this is resolved!

With Harley's commit this is resolved!

Harley Acheson commented 2020-07-19 02:25:11 +02:00

Member

Copy Link

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.

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.

Vyacheslav Kobozev commented 2020-07-19 16:19:02 +02:00

Copy Link

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

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

Matt commented 2020-07-26 02:37:58 +02:00

Copy Link

Added subscriber: @mattli911

Added subscriber: @mattli911

Matt commented 2020-07-26 02:37:58 +02:00

Copy Link

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.  

Paul Kotelevets commented 2020-07-26 13:21:32 +02:00

Copy Link

In #75672#985159, @mattli911 wrote:
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.

> In #75672#985159, @mattli911 wrote: > 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.

xan2622 commented 2021-01-15 00:21:44 +01:00

Copy Link

Added subscriber: @xan2622

Added subscriber: @xan2622

xan2622 commented 2021-01-15 00:21:44 +01:00

Copy Link

Would it be possible to add ngons to the Statistics ?

Would it be possible to add **ngons** to the Statistics ?

Harley Acheson commented 2021-01-15 00:33:28 +01:00

Member

Copy Link

In #75672#1093843, @xan2622 wrote:
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?

> In #75672#1093843, @xan2622 wrote: > 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?

Vyacheslav Kobozev commented 2021-01-15 01:54:05 +01:00

Copy Link

@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.

@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.

xan2622 commented 2021-01-15 07:05:07 +01:00

Copy Link

@Vyach : 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: 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).

@Vyach : 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: 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).

xan2622 commented 2022-08-28 10:43:19 +02:00

Copy Link

Added subscribers: @mano-wii, @howardt, @mont29, @ideasman42

Added subscribers: @mano-wii, @howardt, @mont29, @ideasman42

xan2622 commented 2022-08-28 10:43:19 +02:00

Copy Link

I still think that requiring users to install another add-on just to display this information (n-gons) is not optimal.
IMO, n-gons deserve to be displayed in the Scene Statistics Overlay (bellow "Triangles").
Knowing how many n-gons is important for some many 3D artists.
I hope that someday it gets added to the Statistics.

@ideasman42 @howardt @mont29 @mano-wii

I still think that requiring users to install another add-on just to display this information (n-gons) is not optimal. IMO, n-gons deserve to be displayed in the Scene Statistics Overlay (bellow "Triangles"). Knowing how many n-gons **is** important for ~~some~~ many 3D artists. I hope that someday it gets added to the Statistics. @ideasman42 @howardt @mont29 @mano-wii

Thomas Dinges added this to the 2.90 milestone 2023-02-08 16:27:21 +01:00

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

main

brush-assets-project

blender-v4.1-release

blender-v3.3-release

blender-v3.6-release

universal-scene-description

blender-v3.6-temp_wmoss_animrig_public

temp-sculpt-dyntopo

gpencil-next

anim/animation-id-113594

blender-v4.0-release

blender-projects-basics

bridge-curves

sculpt-blender

asset-browser-frontend-split

asset-shelf

tmp-usd-python-mtl

tmp-usd-3.6

blender-v3.5-release

blender-v2.93-release

realtime-clock

sculpt-dev

bevelv2

xr-dev

v4.1.1

v3.6.11

v3.3.18

v4.1.0

v3.3.17

v3.6.10

v3.6.9

v3.3.16

v3.6.8

v3.6.7

v3.3.14

v4.0.2

v4.0.1

v4.0.0

v3.6.5

v3.3.12

v3.6.4

v3.6.3

v3.3.11

v3.6.2

v3.3.10

v3.6.1

v3.3.9

v3.6.0

v3.3.8

v3.3.7

v2.93.18

v3.5.1

v3.3.6

v2.93.17

v3.5.0

v2.93.16

v3.3.5

v3.3.4

v2.93.15

v2.93.14

v3.3.3

v2.93.13

v2.93.12

v3.4.1

v3.3.2

v3.4.0

v3.3.1

v2.93.11

v3.3.0

v3.2.2

v2.93.10

v3.2.1

v3.2.0

v2.83.20

v2.93.9

v3.1.2

v3.1.1

v3.1.0

v2.83.19

v2.93.8

v3.0.1

v2.93.7

v3.0.0

v2.93.6

v2.93.5

v2.83.18

v2.93.4

v2.93.3

v2.83.17

v2.93.2

v2.93.1

v2.83.16

v2.93.0

v2.83.15

v2.83.14

v2.83.13

v2.92.0

v2.83.12

v2.91.2

v2.83.10

v2.91.0

v2.83.9

v2.83.8

v2.83.7

v2.90.1

v2.83.6.1

v2.83.6

v2.90.0

v2.83.5

v2.83.4

v2.83.3

v2.83.2

v2.83.1

v2.83

v2.82a

v2.82

v2.81a

v2.81

v2.80

v2.80-rc3

v2.80-rc2

v2.80-rc1

v2.79b

v2.79a

v2.79

v2.79-rc2

v2.79-rc1

v2.78c

v2.78b

v2.78a

v2.78

v2.78-rc2

v2.78-rc1

v2.77a

v2.77

v2.77-rc2

v2.77-rc1

v2.76b

v2.76a

v2.76

v2.76-rc3

v2.76-rc2

v2.76-rc1

v2.75a

v2.75

v2.75-rc2

v2.75-rc1

v2.74

v2.74-rc4

v2.74-rc3

v2.74-rc2

v2.74-rc1

v2.73a

v2.73

v2.73-rc1

v2.72b

2.72b

v2.72a

v2.72

v2.72-rc1

v2.71

v2.71-rc2

v2.71-rc1

v2.70a

v2.70

v2.70-rc2

v2.70-rc

v2.69

v2.68a

v2.68

v2.67b

v2.67a

v2.67

v2.66a

v2.66

v2.65a

v2.65

v2.64a

v2.64

v2.63a

v2.63

v2.61

v2.60a

v2.60

v2.59

v2.58a

v2.58

v2.57b

v2.57a

v2.57

v2.56a

v2.56

v2.55

v2.54

v2.53

v2.52

v2.51

v2.50

v2.49b

v2.49a

v2.49

v2.48a

v2.48

v2.47

v2.46

v2.45

v2.44

v2.43

v2.42a

v2.42

v2.41

v2.40

v2.37a

v2.37

v2.36

v2.35a

v2.35

v2.34

v2.33a

v2.33

v2.32

v2.31a

v2.31

v2.30

v2.28c

v2.28a

v2.28

v2.27

v2.26

v2.25

Labels

Clear labels   

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

This issue affects/is about backward or forward 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

Issues relating to Wayland windowing support.

  

Interest

Workbench

  

Interest: X11

Issues relating to Xorg/X11 support.

  

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

Issues relating to security: https://wiki.blender.org/wiki/Process/Vulnerability_Reports

  

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 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

Milestone

Clear milestone

No items

No Milestone

2.90

Projects

Clear projects

No project

Assignees

Clear assignees

No Assignees

Harley Acheson

23 Participants

Notifications

Subscribe

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#75672

No description provided.