Inset thickness/depth history regression #54918

New Issue

Andy Davies · 2018-05-01T21:39:06+02:00

Andy Davies commented

2018-05-01 21:39:06 +02:00

System Information
Win10 Pro 64bit v1709
64GB DDR4 RAM
NVIDIA GTX 1080 with driver 397.31
NVIDIA GTX 680 with driver 397.31

Blender Version
Broken: (2.79a 8928d99270, 2.79b f4dc9f9d68)
Worked: (2.79 5bd8ac9)

Hey all,

Blender used to remember the last thickness values used for inset, which is desirable as when modelling you generally want a consistent width for inset when used on the same mesh with subd. Inset is an invaluable tool for quickly generating support loops that retain the flow of curvature on a surface as manually adding such loops can cause creases in the mesh. This ability has been reduced as the user is forced to input the same value manually each time the tool is used. It should be noted that all other settings apart from depth are recalled correctly when re-running inset (depth should also be remembered but isnt.).

If you use 2.79 (5bd8ac9), the inset values are remembered each time you use the tool.

Generate a cube
Select a face loop
Press I to run Inset
Enter a thickness value of 0.05
Select another face loop
Press I to run Inset
The thickness value of 0.05 is remembered
Repeat infinitum

If you use 2.79a (8928d99270) or 2.79b (f4dc9f9d68 ), the inset values are reset to the default value of 0.01 each time you use the tool.

Generate a cube
Select a face loop
Press I to run Inset
Enter a thickness value of 0.05
Select another face loop (if not already selected)
Press I to run Inset
The thickness value is now 0.01

F3 can of course be used, but is generally unworkable as it breaks the flow of modelling and is limited in the number of actions which can be stored. In addition, pressing F3 might as well be replaced by simply entering the inset value manually as it takes around the same time to preform both actions.

Thanks for looking :)

**System Information** Win10 Pro 64bit v1709 64GB DDR4 RAM NVIDIA GTX 1080 with driver 397.31 NVIDIA GTX 680 with driver 397.31 **Blender Version** Broken: (2.79a 8928d99270f, 2.79b f4dc9f9d68b) Worked: (2.79 5bd8ac9) Hey all, Blender used to remember the last thickness values used for inset, which is desirable as when modelling you generally want a consistent width for inset when used on the same mesh with subd. Inset is an invaluable tool for quickly generating support loops that retain the flow of curvature on a surface as manually adding such loops can cause creases in the mesh. This ability has been reduced as the user is forced to input the same value manually each time the tool is used. It should be noted that all other settings apart from depth are recalled correctly when re-running inset (depth should also be remembered but isnt.). If you use 2.79 (5bd8ac9), the inset values are remembered each time you use the tool. 1) Generate a cube 2) Select a face loop 3) Press I to run Inset 4) Enter a thickness value of 0.05 5) Select another face loop 6) Press I to run Inset 7) The thickness value of 0.05 is remembered 8) Repeat infinitum If you use 2.79a (8928d99270f) or 2.79b (f4dc9f9d68b ), the inset values are reset to the default value of 0.01 each time you use the tool. 1) Generate a cube 2) Select a face loop 3) Press I to run Inset 4) Enter a thickness value of 0.05 5) Select another face loop (if not already selected) 6) Press I to run Inset 7) The thickness value is now 0.01 F3 can of course be used, but is generally unworkable as it breaks the flow of modelling and is limited in the number of actions which can be stored. In addition, pressing F3 might as well be replaced by simply entering the inset value manually as it takes around the same time to preform both actions. Thanks for looking :)

Andy Davies commented

2018-05-01 21:39:06 +02:00

Added subscriber: @AndyDavies-3

Philipp Oeser commented

2018-05-02 10:54:16 +02:00

Added subscribers: @ideasman42, @brecht, @lichtwerk

Philipp Oeser commented

2018-05-02 10:54:16 +02:00

To my knowledge, this was an intentional change (though there seems to be some discussion about it)

see reports #53441, #54206 (this one has a more in depth analysis)
see commits e6404274a1, 596f33f801

It seems to me this was concluded with:

Shift+R and F3 remember the setting
invoking modal with hotkey Iwill always start at near zero

If that is the case, then this report can be closed?

But before closing this, I would like to raise attention to @brecht and @ideasman42 just to make sure...

To my knowledge, this was an intentional change (though there seems to be some discussion about it) - see reports #53441, #54206 (this one has a more in depth analysis) - see commits e6404274a1, 596f33f801 It seems to me this was concluded with: - Shift+R and F3 remember the setting - invoking modal with hotkey `I`will always start at near zero If that is the case, then this report can be closed? But before closing this, I would like to raise attention to @brecht and @ideasman42 just to make sure...

Andy Davies commented

2018-05-02 12:51:50 +02:00

Thanks for the reply @lichtwerk

If this is the new default then that's rather unfortunate. #53441 was not a valid bug report as the tool has remembered the value since 2.64.

F3 and Shift+R cannot be used as a direct replacement for I as it only has a limited number of history states, which means that after only a few minutes modelling you have to re-enter the required value (assuming you can remember it if it is set to something irregular). This unfortunately breaks the functionality of the tool significantly and it seems the lesser of two evils would be that people reset the tool to zero is they want that state, rather than forcing people to re-enter a specific value if they require a set amount. Also, the tool remembers all the other checbox states/values (apart from Depth, which should also be recalled when the tool used again) so if If the intention was to reset Inset to default each time it was used then everything would need to be reset wouldnt it?

Could we please revert the functionality back to the original state or at least get some kind of over-ride checkbox or setting somewhere that is a fix for this?

Thanks for the reply @lichtwerk If this is the new default then that's rather unfortunate. #53441 was not a valid bug report as the tool has remembered the value since 2.64. F3 and Shift+R cannot be used as a direct replacement for I as it only has a limited number of history states, which means that after only a few minutes modelling you have to re-enter the required value (assuming you can remember it if it is set to something irregular). This unfortunately breaks the functionality of the tool significantly and it seems the lesser of two evils would be that people reset the tool to zero is they want that state, rather than forcing people to re-enter a specific value if they require a set amount. Also, the tool remembers all the other checbox states/values (apart from Depth, which should also be recalled when the tool used again) so if If the intention was to reset Inset to default each time it was used then everything would need to be reset wouldnt it? Could we please revert the functionality back to the original state or at least get some kind of over-ride checkbox or setting somewhere that is a fix for this?

Brecht Van Lommel was assigned by Philipp Oeser

2018-05-02 13:08:10 +02:00

Philipp Oeser commented

2018-05-02 13:08:10 +02:00

Added subscriber: @WilliamReynish

Philipp Oeser commented

2018-05-02 13:08:10 +02:00

Personally I can live with the current behaviour, but I can also see advantages of the way it was before.

Dont want to disturb the guys doing their CodeQuest magic, but as I am no UX designer, I will pass this on to @brecht then.
As this also touches Tool design in a more general way, maybe @WilliamReynish can share his view on this topic?

Personally I can live with the current behaviour, but I can also see advantages of the way it was before. Dont want to disturb the guys doing their CodeQuest magic, but as I am no UX designer, I will pass this on to @brecht then. As this also touches Tool design in a more general way, maybe @WilliamReynish can share his view on this topic?

Andy Davies commented

2018-05-02 13:27:16 +02:00

Thanks, @lichtwerk

Generally I think it is desirable to recall any values that have to be entered manually into a tool from the last use (including bevel), as consistency in such things is essential to solid modelling. Hopefully we can get this sorted out to mutual benefit for all users.

Cheers

Thanks, @lichtwerk Generally I think it is desirable to recall any values that have to be entered manually into a tool from the last use (including bevel), as consistency in such things is essential to solid modelling. Hopefully we can get this sorted out to mutual benefit for all users. Cheers

daniel commented

2018-11-22 22:43:55 +01:00

Added subscriber: @midan-3

daniel commented

2018-11-22 22:43:55 +01:00

andy davies, I am with you and also very please devs to do inset/bevel userfriendly as it was earlier.

William Reynish commented

2018-11-22 22:56:29 +01:00

The trouble is that these are interactive. If the interactive interaction should stay consistent, then it can't 'remember' the amount. The same is true for move or rotate - it would be very weird if, when you move something, it would start off by moving however much your last move was - in fact that would feel very buggy.

If Bevel or Inset were not interactive, then it definitely could work the way you suggest, but not when it depends of interactive input.

So I see a few ways to solve this.

1: Use the Info area to re-execute your commands again with the same settings applied (already possible)
2: We could have a way to execute these commands without going to the interactive stage (though how would users find this?)
3: This kind of thing is well suited to a macro recording type system where you can record performing certain actions in certain ways, and then quickly replay them.

The trouble is that these are interactive. If the interactive interaction should stay consistent, then it can't 'remember' the amount. The same is true for move or rotate - it would be very weird if, when you move something, it would start off by moving however much your last move was - in fact that would feel very buggy. If Bevel or Inset were not interactive, then it definitely could work the way you suggest, but not when it depends of interactive input. So I see a few ways to solve this. 1: Use the Info area to re-execute your commands again with the same settings applied (already possible) 2: We could have a way to execute these commands without going to the interactive stage (though how would users find this?) 3: This kind of thing is well suited to a macro recording type system where you can record performing certain actions in certain ways, and then quickly replay them.

Andy Davies commented

2018-12-30 06:37:17 +01:00

Sorry for the late reply. I've only just noticed that this thread had replies.

@WilliamReynish
Thanks for the input. :)

Fwiw, the inset tool has always been interactive and it has also stored the last used value since 2.64, which is why I initially reported this as a regression vs a complaint/bug. As you said it just started at previous value and then moved from there if the user required it and doesn't feel buggy other than a slight jump in the inset width if the user moves the mouse, which isn't offensive (I suppose this is why the storing of values has been around for 5 or 6 years without much complaint).

If the previous functionality isnt going to be restored fully could we perhaps reach a compromise where inset only remembers the value if the user entered it manually or some kind of override checkbox to force storing of values and restoring the previous functionality that the user has to check when first entering a value to be remembered?

Inset has been a very useful and robust, but the removal of the stored values has seriously broken its functionality for me which unfortunately means I'm stuck on 2.79 until we can find a solution.

Cheers :)

Sorry for the late reply. I've only just noticed that this thread had replies. @WilliamReynish Thanks for the input. :) Fwiw, the inset tool has always been interactive and it has also stored the last used value since 2.64, which is why I initially reported this as a regression vs a complaint/bug. As you said it just started at previous value and then moved from there if the user required it and doesn't feel buggy other than a slight jump in the inset width if the user moves the mouse, which isn't offensive (I suppose this is why the storing of values has been around for 5 or 6 years without much complaint). If the previous functionality isnt going to be restored fully could we perhaps reach a compromise where inset only remembers the value if the user entered it manually or some kind of override checkbox to force storing of values and restoring the previous functionality that the user has to check when first entering a value to be remembered? Inset has been a very useful and robust, but the removal of the stored values has seriously broken its functionality for me which unfortunately means I'm stuck on 2.79 until we can find a solution. Cheers :)

Andy Davies commented

2019-01-26 12:58:19 +01:00

Any more thoughts on this @WilliamReynish
It would be great to get a solution ready for 2.8 :)

Any more thoughts on this @WilliamReynish It would be great to get a solution ready for 2.8 :)

Sebastian Parborg commented

2019-02-06 16:52:57 +01:00

Added subscriber: @ZedDB

Sebastian Parborg commented

2019-02-06 16:52:57 +01:00

Changed status from 'Open' to: 'Archived'

Sebastian Parborg closed this issue

2019-02-06 16:52:57 +01:00

Sebastian Parborg commented

2019-02-06 16:52:57 +01:00

This is a feature request.
In 2.8 we now have tools so perhaps the inset tool could be coded to work in the way you want.

I agree that this would be a useful feature. But all feature requests should go to https://rightclickselect.com/ so a solid proposal can be made and voted on.

This is a feature request. In 2.8 we now have tools so perhaps the inset tool could be coded to work in the way you want. I agree that this would be a useful feature. But all feature requests should go to https://rightclickselect.com/ so a solid proposal can be made and voted on.

Andy Davies commented

2019-02-06 18:33:14 +01:00

@ZedDB with respect, this is absolutely not a feature request. My initial report was due to a regression in functionality due to other users erroneous bug reporting.

https://developer.blender.org/T53441
https://developer.blender.org/T53145

I am asking that the previous functionally be restored to its previous state as it was from 2.64-2.7.

Please reopon this report.

Thanks!

@ZedDB with respect, this is absolutely not a feature request. My initial report was due to a regression in functionality due to other users erroneous bug reporting. https://developer.blender.org/T53441 https://developer.blender.org/T53145 I am asking that the previous functionally be restored to its previous state as it was from 2.64-2.7. Please reopon this report. Thanks!

Sebastian Parborg commented

2019-02-06 19:08:47 +01:00

As you pointed out, this was an intended change.
So to solve this I suggest you do a proposal over at rightclickselect and drum up support for it over there.

Perhaps you want this functionality on other operators as well. So if you prepare a nice proposal on how to tackle this issue in an elegant way, it will be a popular requested feature and will eventually make it into blender.

Otherwise we could revert and and then someone else want to revert it to the way it is now and we will repeat this forever.

As you pointed out, this was an intended change. So to solve this I suggest you do a proposal over at rightclickselect and drum up support for it over there. Perhaps you want this functionality on other operators as well. So if you prepare a nice proposal on how to tackle this issue in an elegant way, it will be a popular requested feature and will eventually make it into blender. Otherwise we could revert and and then someone else want to revert it to the way it is now and we will repeat this forever.

Andy Davies commented

2019-02-06 22:17:14 +01:00

@ZedDB @brecht @ideasman42

Yes, it was an intended change, but it was still a change based on false information. A user shouldn't be able to simply report anything as a bug because they don't understand how a tool works and because someone already changed the code force everyone else to live with the error.

The inset tool stored the values for 5-6 years without complaint and the bug report that was the catalyst for the change should have been initially rejected because it wasn't a bug in the first place.

It's not really fair that you want me to drum up support for a feature that has been removed based on error that has lived in Blender since 2.64. I just want the tool restored back to its previous state.

@ZedDB @brecht @ideasman42 Yes, it was an intended change, but it was still a change based on false information. A user shouldn't be able to simply report anything as a bug because they don't understand how a tool works and because someone already changed the code force everyone else to live with the error. The inset tool stored the values for 5-6 years without complaint and the bug report that was the catalyst for the change should have been initially rejected because it wasn't a bug in the first place. It's not really fair that you want me to drum up support for a feature that has been removed based on error that has lived in Blender since 2.64. I just want the tool restored back to its previous state.

William Reynish commented

2019-02-06 22:41:41 +01:00

The general idea of being able to repeat an action again on a different part of the mesh has obvious useful utility. To me it's not about getting support or not, it's about how we can design the best system for this, which works in a generic way for all tools, not just specifically Inset.

The old way this worked with this tool was poor, because the interactive dragging had a conflict with the starting inset offset. This caused the inset operation to be inconsistent, because it might start out non-zero, and so the relationship with the dragged distance was not consistent.

The old way was basically a hack/mistake for this specific tool that had a useful side-effect. but made the tool inconsistent.

What I think we should try and do, is to find a way to make it easy to to do this kind of thing with any tool and any operator. It is a generic capability that isn't specific to the Inset tool.

Ideas:

We could add a better way to play back macros using the Info Editor (or some other way)
There could be a different way to execute all operators to make them use the same options as last time it was used. Say by Ctrl-clicking on a menu item, for example.

So this is why it is considered a feature request. To support this kind of thing in a generic way, it requires some work to do it. But the concept of repeating actions is of course valid and useful, we just need to support it in a generic, general and consistent way.

The general idea of being able to repeat an action again on a different part of the mesh has obvious useful utility. To me it's not about getting support or not, it's about how we can design the best system for this, which works in a generic way for *all* tools, not just specifically Inset. The old way this worked with this tool was poor, because the interactive dragging had a conflict with the starting inset offset. This caused the inset operation to be inconsistent, because it might start out non-zero, and so the relationship with the dragged distance was not consistent. The old way was basically a hack/mistake for this specific tool that had a useful side-effect. but made the tool inconsistent. What I think we should try and do, is to find a way to make it easy to to do this kind of thing with any tool and any operator. It is a generic capability that isn't specific to the Inset tool. Ideas: - We could add a better way to play back macros using the Info Editor (or some other way) - There could be a different way to execute all operators to make them use the same options as last time it was used. Say by Ctrl-clicking on a menu item, for example. So this is why it is considered a feature request. To support this kind of thing in a generic way, it requires some work to do it. But the concept of repeating actions is of course valid and useful, we just need to support it in a generic, general and consistent way.

William Reynish commented

2019-02-06 22:46:40 +01:00

Speaking of which, is there a reason you can't use Repeat History to solve this? If you want to repeat your inset operation with the same settings again, either Repeat Last or Repeat History aught to work for you.

Andy Davies commented

2019-02-06 23:19:45 +01:00

@WilliamReynish Thanks for the reply.

I agree that there is probably a more elegant solution for this, but until one is found users have just lost the ability entirely. A better solution would have probably been keeping the functionality until it could have been improved upon and then implemented the a new version of Blender. It might take months to get something put in place to restore the previous functionality, which sucks because I'm stuck on 2.7 until I can get a replacement.

History is generally unworkable as it breaks the flow of modelling and is limited in the number of states which can be stored. This means that after only a few minutes modelling you have to re-enter the required value (assuming you can remember it if it is set to something irregular) and/or search through a huge list of text, while reading each entry, in order to find the state you need. This is a huge work-flow breaker that is exacerbated by the loss of muscle memory for the action and your eyes having to adjust from a looking at meshes for an extended period to reading text. History might as well be replaced by simply entering the inset value manually as it probably takes around the same time to perform both actions. It just isn't as efficient as hitting "I" and having the tool remember the setting for you.

As I mentioned above, I would be more than happy to have to check a box (unchecked by default) that forces Blender to remember the stored value (essentially the old functionality) or setting it up as to where inset only remembers the value if the user entered it manually. This could then be replaced when a more elegant solution is found.
Cheers,

@WilliamReynish Thanks for the reply. I agree that there is probably a more elegant solution for this, but until one is found users have just lost the ability entirely. A better solution would have probably been keeping the functionality until it could have been improved upon and then implemented the a new version of Blender. It might take months to get something put in place to restore the previous functionality, which sucks because I'm stuck on 2.7 until I can get a replacement. History is generally unworkable as it breaks the flow of modelling and is limited in the number of states which can be stored. This means that after only a few minutes modelling you have to re-enter the required value (assuming you can remember it if it is set to something irregular) and/or search through a huge list of text, while reading each entry, in order to find the state you need. This is a huge work-flow breaker that is exacerbated by the loss of muscle memory for the action and your eyes having to adjust from a looking at meshes for an extended period to reading text. History might as well be replaced by simply entering the inset value manually as it probably takes around the same time to perform both actions. It just isn't as efficient as hitting "I" and having the tool remember the setting for you. As I mentioned above, I would be more than happy to have to check a box (unchecked by default) that forces Blender to remember the stored value (essentially the old functionality) or setting it up as to where inset only remembers the value if the user entered it manually. This could then be replaced when a more elegant solution is found. Cheers,

William Reynish commented

2019-02-06 23:37:33 +01:00

A currently supported way to do this, is to do an Inset (or anything else) and set your settings for the operator. Then, select a different mesh element and use Repeat History and select the previous Inset command. This will re-perform an inset on the new selection with the same settings as the previous inset.

Another thing that works currently, but is more work, is to use the Info Editor to copy a previous command and re-apply it using the Python console.
This area could be made smarter. Users should be able to record little macros here, or at the very least be able to double-click on a command here to re-execute without using the Python console.

This last thing would probably be really quite easy to add in fact.

A currently supported way to do this, is to do an Inset (or anything else) and set your settings for the operator. Then, select a different mesh element and use Repeat History and select the previous Inset command. This will re-perform an inset on the new selection with the same settings as the previous inset. Another thing that works currently, but is more work, is to use the Info Editor to copy a previous command and re-apply it using the Python console. This area could be made smarter. Users should be able to record little macros here, or at the very least be able to double-click on a command here to re-execute without using the Python console. This last thing would probably be really quite easy to add in fact.

Andy Davies commented

2019-02-07 00:10:43 +01:00

Thanks for the thought you are putting into this @WilliamReynish

Assuming you do all your insets at the same time I agree the first option will work, but unfortunately this isn't very often the case. I generally inset as and when the tool is needed rather than in quick succession so I may use the tool 10 times in 2 mins or 10 times in 20 mins depending on the model, so it's limited by the number of history states and has the same pitfalls as I mentioned above.

The macro stuff does sound fun though :)

Thanks for the thought you are putting into this @WilliamReynish Assuming you do all your insets at the same time I agree the first option will work, but unfortunately this isn't very often the case. I generally inset as and when the tool is needed rather than in quick succession so I may use the tool 10 times in 2 mins or 10 times in 20 mins depending on the model, so it's limited by the number of history states and has the same pitfalls as I mentioned above. The macro stuff does sound fun though :)

daniel commented

2019-02-10 13:27:13 +01:00

@WilliamReynish, , as Andy Davies said, maybe it is inconsistent with interactive tool, but it is a very big regression and worse to not have it and have interactive tool than vice versa.
I tried for a very long time to deal with it , but can not. It is a straggle with history repeat, when it was earlier it was good.
@brecht, @ideasman42 could you give us a line of code and where to put it to bring back (change to) "old" good functionality of bevel, inset tool?
those who want it back apply code to have it, for the rest it stay as it is. I dont want to wait until perhaps it will be in 2.80

@WilliamReynish, , as Andy Davies said, maybe it is inconsistent with interactive tool, but it is a very big regression and worse to not have it and have interactive tool than vice versa. I tried for a very long time to deal with it , but can not. It is a straggle with history repeat, when it was earlier it was good. @brecht, @ideasman42 could you give us a line of code and where to put it to bring back (change to) "old" good functionality of bevel, inset tool? those who want it back apply code to have it, for the rest it stay as it is. I dont want to wait until perhaps it will be in 2.80

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Inset thickness/depth history regression #54918