Proposal to change loop-cut behavior #41446

New Issue

Campbell Barton · 2014-08-15T01:13:15+02:00

Campbell Barton commented

2014-08-15 01:13:15 +02:00

Currently, loopcut is done in 2 steps.

pick the loop to cut.
slide the edge loop.

In some ways this is good, you make 2 separate decisions quickly without fidgeting with the cursor to put a loop in some place which might be difficult to locate exactly.

Currently the cut is always exactly in the middle, this isn't always a bad thing - sometimes you want a cut in the middle so in that case you can simply do Ctrl+R, LMB,LMB

This design ticket proposed that it be changed so the initial pink-preview loop is aligned to the mouse cursor, this way the default behavior would be to add where you click, and if you want the loop to be exactly centered you could hold Ctrl to snap it to the center.

We can also make it so holding Ctrl while selecting a loop keeps the existing behavior. (This matches knife's midpoint snapping).

The only drawbacks I can think of are...

if you prefer old behavior as default and are adding a lot of central loop cuts.
if you want to add a loop where many edges meet or overlap, its can be hard to select the right edge and the right % in one step, In that case you can still add-and-slide, but this behavior would mean users would get into a habit of adding directly and double clicking, and in some cases there is a bit of a conflict attempting to make both decisions in one step.
Behavior with multi-cut - I would match current behavior with multi-cut and slide, but I can imagine this would feel a bit awkward from a user perspective.

Currently, loopcut is done in 2 steps. - pick the loop to cut. - slide the edge loop. In some ways this is good, you make 2 separate decisions quickly without fidgeting with the cursor to put a loop in some place which might be difficult to locate exactly. Currently the cut is always exactly in the middle, this isn't always a bad thing - sometimes you want a cut in the middle so in that case you can simply do `Ctrl+R, LMB,LMB` This design ticket proposed that it be changed so the initial pink-preview loop is aligned to the mouse cursor, this way the default behavior would be to add where you click, and if you want the loop to be exactly centered you could hold `Ctrl` to snap it to the center. We can also make it so holding `Ctrl` while selecting a loop keeps the existing behavior. (This matches knife's midpoint snapping). The only drawbacks I can think of are... - if you prefer old behavior as default and are adding a lot of central loop cuts. - if you want to add a loop where many edges meet or overlap, its can be hard to select the right edge and the right % in one step, In that case you can still *add-and-slide*, but this behavior would mean users would get into a habit of adding directly and double clicking, and in some cases there is a bit of a conflict attempting to make both decisions in one step. - Behavior with multi-cut - I would match current behavior with multi-cut and slide, but I can imagine this would feel a bit awkward from a user perspective.

❤️ 1

Campbell Barton commented

2014-08-15 01:13:15 +02:00

Changed status to: 'Open'

Campbell Barton self-assigned this 2014-08-15 01:13:15 +02:00

Campbell Barton commented

2014-08-15 01:13:15 +02:00

Added subscriber: @ideasman42

Campbell Barton commented

2014-08-15 01:17:27 +02:00

Added subscribers: @zanqdo, @JonathanWilliamson

Ray Mairlot commented

2014-08-15 11:51:43 +02:00

Added subscriber: @RayMairlot

Igor Donevski commented

2014-08-15 14:17:31 +02:00

Added subscriber: @el_diablo

Igor Donevski commented

2014-08-15 14:17:31 +02:00

About the start at the mouse cursor, I started that idea but I see that it may be against some Blender conventions (action decoupled from mouse position,like for tweak etc.). Maybe should drop that even though it may be much better for placing single cuts. It may be better suited for knife tool, for example as a mode where you click on an edge and have a parallel loop created along a ring.

ronan ducluzeau commented

2014-08-18 11:48:11 +02:00

Added subscriber: @zeauro

ronan ducluzeau commented

2014-08-18 11:48:11 +02:00

I think it is a great idea.
I disagree with el_diablo.
Knife is great for global or precise cut but it is slower because it is modal. Since Ngons, it is a fast combinaison.
But for people that continue to think there modeling process with quads addition, loop cut is still the tool for parallel loop addition.
Loopcut is used to fastly detailing model like a local subdivision. And it is a proposal to make even faster.

IMHO, drawbacks mentioned by Campbell are not real ones.

Pressing Ctrl is to have a old behavior is not an awfull change and users can easily become used to it.
Users already have to arrange their viewports in a way selection can be correclty done.Blender have tools to occlude confusing geometry, zoom in/zoom out.
Users are expecting an auto-adjustement of spacing between cuts for multicut. And its default spacing is based on ring width to cut. So, it is not weird.

What multicut drawback idea is revealing that in fact, loopcut is missing an option to control spacing between cuts.
I suggest to add one.
I like OOGhz idea of an additionnal symmetry option for multicut.
In my mind, it would not be same thing that spacing because it could be working for any number of cuts.
Imagine :
multicut is about 2 cuts with symmetry on, one cut would be under mouse and the other one at the opposite side of the ring (no need to precise a spacing).
For multicut = 3 cuts with symmetry on, one cut would be under mouse and the other one at the opposite side of the ring and the third one stay centered (no need to precise a spacing).
For multicut = 4 cuts with symmetry on, middle between 2 cuts would be under mouse according to spacing values and the 2 other ones would be at the opposite side of the ring.
For multicut = 5 cuts with symmetry on, same thing that for 4 but with a loop cut centered.

And with symmetry off, center of cuts are under mouse according to spacing value.

But actually, nobody really use multicuts with slide because of lack of spacing value.
We are doing several loopcuts or constrained to select ring edges and do individual scale.

I also think that shift R or F3 behaviour should take into account ring under mouse for loopcut instead of redoing it on previously cutted ring.

I think it is a great idea. I disagree with el_diablo. Knife is great for global or precise cut but it is slower because it is modal. Since Ngons, it is a fast combinaison. But for people that continue to think there modeling process with quads addition, loop cut is still the tool for parallel loop addition. Loopcut is used to fastly detailing model like a local subdivision. And it is a proposal to make even faster. IMHO, drawbacks mentioned by Campbell are not real ones. - Pressing Ctrl is to have a old behavior is not an awfull change and users can easily become used to it. - Users already have to arrange their viewports in a way selection can be correclty done.Blender have tools to occlude confusing geometry, zoom in/zoom out. - Users are expecting an auto-adjustement of spacing between cuts for multicut. And its default spacing is based on ring width to cut. So, it is not weird. What multicut drawback idea is revealing that in fact, loopcut is missing an option to control spacing between cuts. I suggest to add one. I like OOGhz idea of an additionnal symmetry option for multicut. In my mind, it would not be same thing that spacing because it could be working for any number of cuts. Imagine : multicut is about 2 cuts with symmetry on, one cut would be under mouse and the other one at the opposite side of the ring (no need to precise a spacing). For multicut = 3 cuts with symmetry on, one cut would be under mouse and the other one at the opposite side of the ring and the third one stay centered (no need to precise a spacing). For multicut = 4 cuts with symmetry on, middle between 2 cuts would be under mouse according to spacing values and the 2 other ones would be at the opposite side of the ring. For multicut = 5 cuts with symmetry on, same thing that for 4 but with a loop cut centered. And with symmetry off, center of cuts are under mouse according to spacing value. But actually, nobody really use multicuts with slide because of lack of spacing value. We are doing several loopcuts or constrained to select ring edges and do individual scale. I also think that shift R or F3 behaviour should take into account ring under mouse for loopcut instead of redoing it on previously cutted ring.

Igor Donevski commented

2014-08-18 11:59:00 +02:00

Its nice to have someone disagreeing with me disagreeing with myself :). As I said I suggested the start at the mouse cursor, but I can see how its in some way against some of the Blender conventions. But then again, maybe conventions could be changed for the better sometimes. About the multi-cut spacing, I agree the control of the spacing is desirable. I do have a presumably good suggestion on this, however I didn't want to overload the refactor.

The suggestion is to upgrade the ramp control (from nodes) for general interface control so it could be used for loop spacing. It already has all the controls needed. And also it would offer the same (or better) functionality to the Bandsaw from lightwave for example:

https://www.youtube.com/watch?v=ggjWlPm7L0k

Its nice to have someone disagreeing with me disagreeing with myself :). As I said I suggested the start at the mouse cursor, but I can see how its in some way against some of the Blender conventions. But then again, maybe conventions could be changed for the better sometimes. About the multi-cut spacing, I agree the control of the spacing is desirable. I do have a presumably good suggestion on this, however I didn't want to overload the refactor. The suggestion is to upgrade the ramp control (from nodes) for general interface control so it could be used for loop spacing. It already has all the controls needed. And also it would offer the same (or better) functionality to the Bandsaw from lightwave for example: https://www.youtube.com/watch?v=ggjWlPm7L0k

ronan ducluzeau commented

2014-08-18 22:14:24 +02:00

I think this ramp control thing from a 2008 video is awfull for quick modelling. It may have its place in procedural modelling with other nodes.
But to add loops on the face of a character, using this instead of several direct clicks on mesh : it is illness.

When I am thinking of loop spacing, it is one value to obtain an equal spacing between loops. Maybe we could think of different falloff.
But the idea of a highly customizable loop spacing, it seems overcomplicated from my point of view.

Adding stops in this ramp to reuse this distribution, several times, is probably interesting in architecture or CAD modelling.
Adding several single loop cuts and registering them in a macro is probably as fast and as efficient.
But we need a way to run macro without mouse hovering text editor but hovering things in 3Dview.

I think this ramp control thing from a 2008 video is awfull for quick modelling. It may have its place in procedural modelling with other nodes. But to add loops on the face of a character, using this instead of several direct clicks on mesh : it is illness. When I am thinking of loop spacing, it is one value to obtain an equal spacing between loops. Maybe we could think of different falloff. But the idea of a highly customizable loop spacing, it seems overcomplicated from my point of view. Adding stops in this ramp to reuse this distribution, several times, is probably interesting in architecture or CAD modelling. Adding several single loop cuts and registering them in a macro is probably as fast and as efficient. But we need a way to run macro without mouse hovering text editor but hovering things in 3Dview.

Campbell Barton commented

2014-08-19 07:25:08 +02:00

The initial proposal can be added opt-in or opt-out (so we don't even need to agree on whats better just now, also possible to make a preference, but that seems unnecessary)

If we agree its useful & worth spending time on, it can be added and we can postpone choosing the default until it can be tested.

@zeauro, don't think loop-cut falloff is related to this proposal.

The initial proposal can be added opt-in or opt-out (so we don't even need to agree on whats better just now, *also possible to make a preference, but that seems unnecessary*) If we agree its useful & worth spending time on, it can be added and we can postpone choosing the default until it can be tested. @zeauro, don't think loop-cut falloff is related to this proposal.

Ignatz commented

2014-08-19 08:10:52 +02:00

Added subscriber: @ignatz

Ignatz commented

2014-08-19 08:10:52 +02:00

Just off the top of my head...

Another way to approach this proposed change is to leave the functionality of the loop cut more or less as it is currently,...

but to also offer some shortcut which if pressed would bring up an option box (prior to the cuts being made) which would allow for numerically setting number of cuts, spacing of cuts, location of cuts, and so forth.

Conceivably, one could also have a save and restore system within this option box for reuse of preferred loop-cut arrangements.

Just off the top of my head... Another way to approach this proposed change is to leave the functionality of the loop cut more or less as it is currently,... but to also offer some shortcut which if pressed would bring up an option box (prior to the cuts being made) which would allow for numerically setting number of cuts, spacing of cuts, location of cuts, and so forth. Conceivably, one could also have a save and restore system within this option box for reuse of preferred loop-cut arrangements.

Andy Davies commented

2014-08-27 13:56:23 +02:00

Added subscriber: @AndyDavies-3

Andy Davies commented

2014-08-27 13:56:23 +02:00

Crosspost from the mailing list as I didn't get a reply there.

I made a script a few years ago to do something similar to this :)
http://www.metalliandy.com/downloads/scripts/fastloop_016.py

The main issue I see with this is that there is a need to be precise and I use the default behaviour more than I would the modified behaviour. It's still a very useful too though so I'm not complaining that you want to add it :)

Perhaps it would be best to keep the current defaults and have the new functionality assigned to a hot key along with some sort of feature that detects the curvature of the surface that you are adding the loop to so that it doesn't break CC subd? The current ALT smooth isnt automatic so is hard to get perfect results.

Something like this would work I think.

CTRL+R enters loopcut/slide as normal
When in loopcut mode hitting CTRL would toggle the cut edge to be moved to the mouse pointer
Holding shift would add the cut based on surface curvature

See swift loop
http:*docs.autodesk.com/3DSMAX/15/ENU/3ds-Max-Help/index.html?url=files/GUID-D07B4F5B-33AE-4544-A905-A52A678C7D64.htm,topicNumber=d30e125039
Also if you fancy adding something really useful to Loopcut something like the pinch command in Max would be amazing.
http:*docs.autodesk.com/3DSMAX/15/ENU/3ds-Max-Help/index.html?url=files/GUID-57E3DDC9-50D2-4467-93E9-B1B103CEA30D.htm,topicNumber=d30e140493

Cheers,

Andy

Crosspost from the mailing list as I didn't get a reply there. I made a script a few years ago to do something similar to this :) http://www.metalliandy.com/downloads/scripts/fastloop_016.py The main issue I see with this is that there is a need to be precise and I use the default behaviour more than I would the modified behaviour. It's still a very useful too though so I'm not complaining that you want to add it :) Perhaps it would be best to keep the current defaults and have the new functionality assigned to a hot key along with some sort of feature that detects the curvature of the surface that you are adding the loop to so that it doesn't break CC subd? The current ALT smooth isnt automatic so is hard to get perfect results. Something like this would work I think. - CTRL+R enters loopcut/slide as normal - When in loopcut mode hitting CTRL would toggle the cut edge to be moved to the mouse pointer - Holding shift would add the cut based on surface curvature See swift loop [http:*docs.autodesk.com/3DSMAX/15/ENU/3ds-Max-Help/index.html?url=files/GUID-D07B4F5B-33AE-4544-A905-A52A678C7D64.htm,topicNumber=d30e125039 ](http:*docs.autodesk.com/3DSMAX/15/ENU/3ds-Max-Help/index.html?url=files/GUID-D07B4F5B-33AE-4544-A905-A52A678C7D64.htm,topicNumber=d30e125039) Also if you fancy adding something really useful to Loopcut something like the pinch command in Max would be amazing. [http:*docs.autodesk.com/3DSMAX/15/ENU/3ds-Max-Help/index.html?url=files/GUID-57E3DDC9-50D2-4467-93E9-B1B103CEA30D.htm,topicNumber=d30e140493 ](http:*docs.autodesk.com/3DSMAX/15/ENU/3ds-Max-Help/index.html?url=files/GUID-57E3DDC9-50D2-4467-93E9-B1B103CEA30D.htm,topicNumber=d30e140493) Cheers, - Andy

ronan ducluzeau commented

2014-08-27 17:25:44 +02:00

In #41446#26, @AndyDavies-3 wrote:
Crosspost from the mailing list as I didn't get a reply there.

I made a script a few years ago to do something similar to this :)
http://www.metalliandy.com/downloads/scripts/fastloop_016.py

The main issue I see with this is that there is a need to be precise and I use the default behaviour more than I would the modified behaviour. It's still a very useful too though so I'm not complaining that you want to add it :)

But since this script, edge slide has been given a super fast GG shortcut. So precision is no more a big problem.

> In #41446#26, @AndyDavies-3 wrote: > Crosspost from the mailing list as I didn't get a reply there. > > I made a script a few years ago to do something similar to this :) > http://www.metalliandy.com/downloads/scripts/fastloop_016.py > > The main issue I see with this is that there is a need to be precise and I use the default behaviour more than I would the modified behaviour. It's still a very useful too though so I'm not complaining that you want to add it :) > But since this script, edge slide has been given a super fast GG shortcut. So precision is no more a big problem.

Andy Davies commented

2014-08-28 00:57:58 +02:00

In #41446#28, @zeauro wrote:

In #41446#26, @AndyDavies-3 wrote:
Crosspost from the mailing list as I didn't get a reply there.

I made a script a few years ago to do something similar to this :)
http://www.metalliandy.com/downloads/scripts/fastloop_016.py

The main issue I see with this is that there is a need to be precise and I use the default behaviour more than I would the modified behaviour. It's still a very useful too though so I'm not complaining that you want to add it :)

But since this script, edge slide has been given a super fast GG shortcut. So precision is no more a big problem.

The GG edgeslide and my fast loop script are two totally different modelling tools :)
The fastloop script allows for fast placement of loops without having to keep hitting CTRL+R (add loop, slide, add loop, slide vs CTRL+R add loop, slide, CTRL+R add loop, slide etc.).
The issue I mentioned with accuracy is that fastloop (and similar tools) are not accurate because you cant specify the distance from the neighbouring edge as you can with loopcut slide due to the speed of the intended workflow. It's meant to be a quick and dirty way to add loops, but with that speed you get a lower level of precision.

> In #41446#28, @zeauro wrote: >> In #41446#26, @AndyDavies-3 wrote: >> Crosspost from the mailing list as I didn't get a reply there. >> >> I made a script a few years ago to do something similar to this :) >> http://www.metalliandy.com/downloads/scripts/fastloop_016.py >> >> The main issue I see with this is that there is a need to be precise and I use the default behaviour more than I would the modified behaviour. It's still a very useful too though so I'm not complaining that you want to add it :) >> > > But since this script, edge slide has been given a super fast GG shortcut. So precision is no more a big problem. The GG edgeslide and my fast loop script are two totally different modelling tools :) The fastloop script allows for fast placement of loops without having to keep hitting CTRL+R (add loop, slide, add loop, slide vs CTRL+R add loop, slide, CTRL+R add loop, slide etc.). The issue I mentioned with accuracy is that fastloop (and similar tools) are not accurate because you cant specify the distance from the neighbouring edge as you can with loopcut slide due to the speed of the intended workflow. It's meant to be a quick and dirty way to add loops, but with that speed you get a lower level of precision.

ronan ducluzeau commented

2014-08-28 11:49:12 +02:00

In #41446#29, @AndyDavies-3 wrote:

The issue I mentioned with accuracy is that fastloop (and similar tools) are not accurate because you cant specify the distance from the neighbouring edge as you can with loopcut slide due to the speed of the intended workflow.

But after a fastloop, you can specify the distance from the neighbouring edge with an edge slide. In fact, you have to type GGE more than just GG.
Edge Slide is the same tool that the Slide of Loop Cut and Slide.

I just mean than before edge slide was unknown, less used because it did not have any shortcut and was only accessible from specials menus.

> In #41446#29, @AndyDavies-3 wrote: > The issue I mentioned with accuracy is that fastloop (and similar tools) are not accurate because you cant specify the distance from the neighbouring edge as you can with loopcut slide due to the speed of the intended workflow. But after a fastloop, you can specify the distance from the neighbouring edge with an edge slide. In fact, you have to type GGE more than just GG. Edge Slide is the same tool that the Slide of Loop Cut and Slide. I just mean than before edge slide was unknown, less used because it did not have any shortcut and was only accessible from specials menus.

Andy Davies commented

2014-08-28 17:50:15 +02:00

In #41446#30, @zeauro wrote:

In #41446#29, @AndyDavies-3 wrote:

The issue I mentioned with accuracy is that fastloop (and similar tools) are not accurate because you cant specify the distance from the neighbouring edge as you can with loopcut slide due to the speed of the intended workflow.

But after a fastloop, you can specify the distance from the neighbouring edge with an edge slide. In fact, you have to type GGE more than just GG.
Edge Slide is the same tool that the Slide of Loop Cut and Slide.

I just mean than before edge slide was unknown, less used because it did not have any shortcut and was only accessible from specials menus.

The point I'm trying to make is that specifying the distance between neighbouring edges is out of the scope of the workflow of fastloop that's all. It's not meant to be accurate, only fast :)

There is no point having a way to add edgeloops quickly if you have to manually type in the distance between the neighbouring edge which slows down the adding of those edge loops and makes the script redundant.
Currently with fastloop you just click once and slide the edge then the tool automatically goes back into loopcut mode allowing you to create a new edge. It's fast because you dont have to keep hitting CTRL+R and worry about accurate placement of the edges. It's meant to be a quick and dirty way of adding geometry.

> In #41446#30, @zeauro wrote: >> In #41446#29, @AndyDavies-3 wrote: > >> The issue I mentioned with accuracy is that fastloop (and similar tools) are not accurate because you cant specify the distance from the neighbouring edge as you can with loopcut slide due to the speed of the intended workflow. > > But after a fastloop, you can specify the distance from the neighbouring edge with an edge slide. In fact, you have to type GGE more than just GG. > Edge Slide is the same tool that the Slide of Loop Cut and Slide. > > I just mean than before edge slide was unknown, less used because it did not have any shortcut and was only accessible from specials menus. The point I'm trying to make is that specifying the distance between neighbouring edges is out of the scope of the workflow of fastloop that's all. It's not meant to be accurate, only fast :) There is no point having a way to add edgeloops quickly if you have to manually type in the distance between the neighbouring edge which slows down the adding of those edge loops and makes the script redundant. Currently with fastloop you just click once and slide the edge then the tool automatically goes back into loopcut mode allowing you to create a new edge. It's fast because you dont have to keep hitting CTRL+R and worry about accurate placement of the edges. It's meant to be a quick and dirty way of adding geometry.

Takanu commented

2014-11-26 08:51:27 +01:00

Added subscriber: @Takanu

Takanu commented

2014-11-26 08:51:27 +01:00

I see the issues associated with the suggested changes, but if those can be figured out this proposal makes more sense. In regards to @zeauro's initial comment, accuracy is definitely an issue, and something I have issue with using the current Edge Slide tool, let alone the proposal for the new one. Zooming and repositioning the camera every time you want to quickly add in some edge loops for detail adds additional time to both zoom in and back out to view the entire model.

Maybe a solution to this would be to add a temporary zoom feature that relies on cursor proximity rather than geometry selection, so a more precise selection could be made quickly, and this could have the benefit of helping other tools for precision. Regardless though, so long as the old behaviour can be accessed for precision this is a good proposal :D

I see the issues associated with the suggested changes, but if those can be figured out this proposal makes more sense. In regards to @zeauro's initial comment, accuracy is definitely an issue, and something I have issue with using the current Edge Slide tool, let alone the proposal for the new one. Zooming and repositioning the camera every time you want to quickly add in some edge loops for detail adds additional time to both zoom in and back out to view the entire model. Maybe a solution to this would be to add a temporary zoom feature that relies on cursor proximity rather than geometry selection, so a more precise selection could be made quickly, and this could have the benefit of helping other tools for precision. Regardless though, so long as the old behaviour can be accessed for precision this is a good proposal :D

Daniel Salazar commented

2014-11-26 18:00:49 +01:00

Before 2.5 there was a very useful thing in loopcut that I used all the time. If you accepted the loopcut with MMB it went always to the middle! Can we have this back? if so I don't see the problem with this behavior change. So:

LMB: Loop cut in position
MMB: Loop cut in middle

Before 2.5 there was a very useful thing in loopcut that I used all the time. If you accepted the loopcut with MMB it went always to the middle! Can we have this back? if so I don't see the problem with this behavior change. So: LMB: Loop cut in position MMB: Loop cut in middle

daniel commented

2014-12-17 12:29:25 +01:00

Added subscriber: @midan-3

daniel commented

2014-12-17 12:29:25 +01:00

I would like to suggest another functionality to loopcut - loopcut on selected.
Now if we have mesh like on image screen1 {F132449}it is not possible to make loop cut in selected egdes at once. We have to subdivide them and then select and move/slide.
If we had an option "on selected" we could do it very fast and better .

I would like to suggest another functionality to loopcut - loopcut on selected. Now if we have mesh like on image screen1 {[F132449](https://archive.blender.org/developer/F132449/screen1.png)}it is not possible to make loop cut in selected egdes at once. We have to subdivide them and then select and move/slide. If we had an option "on selected" we could do it very fast and better .

Campbell Barton removed their assignment 2016-08-11 06:36:01 +02:00

Campbell Barton commented

2016-08-11 06:36:01 +02:00

Removed subscriber: @ideasman42

daniel commented

2017-04-21 10:39:00 +02:00

I would be good to add snapping to loopcut i.e. when you slide egde after hitting CTRL +R and left/right mouse button to accept it could be good to have an option to snap to

Robin Bonhoure commented

2020-10-10 04:52:50 +02:00

Added subscriber: @Ziboo

Robin Bonhoure commented

2020-10-10 04:52:50 +02:00

If you do revive this task, please could you add pinch like on 3dsmax (http://docs.autodesk.com/3DSMAX/15/ENU/3ds-Max-Help/index.html?url=files/GUID-57E3DDC9-50D2-4467-93E9-B1B103CEA30D.htm,topicNumber=d30e140493)
This might be the biggest feature I'm missing in Blender so far

Thanks a lot !

If you do revive this task, please could you add pinch like on 3dsmax (http://docs.autodesk.com/3DSMAX/15/ENU/3ds-Max-Help/index.html?url=files/GUID-57E3DDC9-50D2-4467-93E9-B1B103CEA30D.htm,topicNumber=d30e140493) This might be the biggest feature I'm missing in Blender so far Thanks a lot !

Pratik Borhade commented

2021-03-29 15:59:10 +02:00

Added subscriber: @PratikPB2123

Hologram commented

2021-04-20 20:06:21 +02:00

Added subscriber: @Hologram

Hologram commented

2021-04-20 20:06:21 +02:00

Loop cut could well benefit from being modal in terms of setting smoothness, number of cuts, and pinching. I would also love to see "set flow" (which is a highly useful addon) being used to inserted loops while maintaining mesh curvature as part of such modals. It is to be preferred over the smoothness factor in cases curvature was already established and it does not require any user adjustments as it works as is. While these complicate the design task somewhat, considering the high demand for these improvements on Rightclick select it deserves to be mentioned here as well.

Loop cut could well benefit from being modal in terms of setting smoothness, number of cuts, and pinching. I would also love to see "set flow" (which is a highly useful addon) being used to inserted loops while maintaining mesh curvature as part of such modals. ![afbeelding.png](https://archive.blender.org/developer/F10030197/afbeelding.png) It is to be preferred over the smoothness factor in cases curvature was already established and it does not require any user adjustments as it works as is. While these complicate the design task somewhat, considering the high demand for these improvements on Rightclick select it deserves to be mentioned here as well.

Daniel Salazar commented

2021-04-20 23:54:11 +02:00

Removed subscriber: @zanqdo

Bin Li commented

2021-09-29 06:23:53 +02:00

Added subscriber: @hexaylon

Bin Li commented

2021-09-29 06:23:53 +02:00

agree, the loop cut start at mouse position makes sense.
Would increase speed and fluidity.
adding extra loops at the tip of model to hold shapes when subdividing is commonly performed.

it could be realized by holding ctrl for example, and does not have to impact any other usage.
bumping this up for further attention

agree, the loop cut start at mouse position makes sense. Would increase speed and fluidity. adding extra loops at the tip of model to hold shapes when subdividing is commonly performed. it could be realized by holding ctrl for example, and does not have to impact any other usage. bumping this up for further attention

Hologram commented

2021-09-29 16:52:46 +02:00

For reference, the Fast Loop addon does this and more, it is the most complete Loop Cut tool in any DCC and should therefore be used as reference!
See: https://blenderartists.org/t/fast-loop/1302008

For reference, the Fast Loop addon does this and more, it is the most complete Loop Cut tool in any DCC and should therefore be used as reference! See: https://blenderartists.org/t/fast-loop/1302008

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Proposal to change loop-cut behavior #41446