Looptools [Design Proposal]

[dfelinto]

This proposal is now an official design task.

---

Design proposal for the future of Looptools from Dalai and Pablo.

Because of its popularity, the Looptools should be integrated as a core feature in Blender. This was also reiterated by the modeling module a few months ago (with a follow-up proposal for the Circle operator).

More recently, in preparation to this design task, Pablo asked on Blender Today about the audience usage of the Looptools.

Operator	Quantity	Equivalent	Community Notes
Circle	12	None	“I find the result unpredicteable”
Space	10	None?	Suggestion to call it “Even Distribution”
Relax	8	Smooth
Flatten	4
Curve	3		This needs more tooltip instructions. I see people use this to create smooth S-pline alike for Verts, and then use Loft/Grid Fill to create a smooth wave mesh.
Gstretch	2		Suggestion to name it “Straight Line Toward”
Loft	1
Bridge	0	Bridge Edge Loops

Other suggestions: Set Flow

Design suggestions

Migrate as is - UI tweaks

Looptools have been used for several years and is stable enough. The most important part is to unify the UI with the rest of Blender and make it available out of the box.

Porting the tools to C++ may not be needed at all. And it should definitely not get on the way of having the port initiated.

Bring one-by-one

The idea from the modeling team to port the tools into one by one is fine. The caveat is that the add-on will have to be updated to keep only the un-ported tools.

For that we need to make sure the blender_version_min is set for new versions accordingly.

This is the same principle applied to the Storypencil add-on (which is yet to be updated with the features ported to Blender 5.0).

Port them by popularity

1. To Circle [Circle]
2. Space [Space Evenly, Evenly Distribution]
3. Relax
4. Flatten
5. Curve
6. Straight Line Toward [Gstretch]
7. Loft
8. Bridge

Circle

Rename to To Circle. Add to Mesh/Transform menu below To Sphere and to the context menu in all selection modes, below Subdivide.

The naming diverges from what was proposed on #144080. The point of not using a noun directly is valid, however Blender already use “To Sphere”, as a way to use a noun in the operator name, so it should be fine. Circularize (the proposed name on #144080) is a mouthful and would get on the way of people quickly searching for Circle.

Looptools v4.7.7	Proposed

Space

Rename to Space Evenly. Add to Mesh/Transform and to the context menu in all selection modes.

Looptools v4.7.7	Proposed

Relax

Add to Mesh/Transform and to the context menu in all selection modes.

This tool is similar to “Smooth Vertices”, but there are too many differences in functionality to justify unifying them. For the time being leave it be, until the unification becomes a must.

Looptools v4.7.7	Proposed

Flatten

Add to Mesh/Transform and to the context menu in all selection modes.

Looptools v4.7.7	Proposed

Curve

Rename to To Curve. Add to Mesh/Transform and to the context menu in all selection modes.

The Restriction behaviour is not super clear, but for now it could be ported as it is. Its items need to follow Blender’s capitalizaton rules though.

The “Boundaries” option could be renamed to “Extend”. It works opposite of boundaries. It may be better as off by default (which is a different behaviour than what we have now).

Looptools v4.7.7	Proposed

Gstretch

Gstretch has been broken since 4.3 (Nov 2024). bug report 1, 2

Rename to To Annotation. Add to Mesh/Transform and to the context menu in Vertex select mode.

The option to use Grease Pencil as guides should be removed. It is way too hacky. This means the entire “Use guides:” option should go away. This is only visible at the moment on the Viewport Edit > LoopTools panel (which won’t be ported to Blender).

Options that don’t seem to do anything and should be removed:

• None guides option should be removed.
• Conversion should be removed.

ToDo’s:

• Needs adjusting of all tooltips to remove mentioning Grease Pencil when it doesn’t apply (Annotations instead)

Looptools v4.7.7	Proposed

Loft / Bridge

Leave it out of Blender (for now). Blender already has a bridge tool.

Menu Entry

The main way to access the tools is via the context menu:

Additionally the Loop Tools submenu should also be inside the Mesh menu.

[nickberckley]

In general the proposal matches how we wanted to go (modeling module), one by one is the correct approach. There are small things I don’t agree with, like names and placements, but those can be discussed in PRs when the time comes.

However, the main disagreement I have is with keeping it as a Python code, and I’ll explain why. This was initially what I wanted as well, it would allow me to do it myself and not rely on others, but I found lots of things that didn’t work as well. If we keep the Python code it would still need lot of work and maintenance, and we’ll also have to keep some hacks around.

1. There are some issues with the code.

Proposal mentions that Loop Tools has been stable, but it’s not exactly that simple. There are bugs popping up, and some long standing issues need to be fixed. There’s also a question of maintenance. Loop Tools is very _mathemetical_, meaning there’s not much to maintain it in terms of API, but the algorithm is something else, and will need people who are familiar with it.

2. Add-on uses scene properties, which need to go.

One thing that it seems escaped you two is the unfortunate sidebar panel that Loop Tools has in 3D viewport. Now, removing this will be controversial, but it should be done, it breaks our UI guidelines not only in terms of look, but also in behavior.

Operators in Blender expose their settings once they are executed, and they can be modified from there. Loop Tools has those, but it also keeps duplicates of those properties on Scene ID as well, because add-on wanted to provide a way to set those properties before the operator is run as well. This is as unimportant as it gets, there are only 4-5 props per operator that you rarely touch, no need to maintain this feature at all, and should be removed. Currently it’s sending data back-and-forth between those two sets of properties.

3. Python code keeps cache

Currently, Loop Tools has a cache system. Each operator stores and read them before execution. This cache keeps the information about the topology, and it can get pretty big if the topology is large and complex. Without this, though, operator can be slow on large meshes. This method is little hacky. As a comparison, C++ version of the To Circle operator that @Tariq [implemented in PR](https://projects.blender.org/blender/blender/pulls/151642) is considerably faster than Python, even with cache being kept.

4. To Annotations operator is nightmare to design.

This is the operator that initially I thought we would just not import at all, alongside Bridge. Even if we drop GP support, this is still very complex. Problem is, annotations have layers, they are per-frame, they have weird projections. The operator as it is barely works unless you set everything up perfectly. Maintaining this, especially with Python code would be a nightmare. I think this is a feature best left for add-ons.

---

TL:DR - Existing Python code is complex, little buggy, and quite hacky. I don’t think keeping it is worth it. Even if it takes some time, I would prefer if they were rewritten in C++, polished in the process, and also found the maintainer as well.

[dfelinto]

@nickberckley

…

By the way, I just updated the post to fix the images. You may want to look again, it may influence your impression from the proposal.

[1D_Inc]

Gstretch

The original goal behind Gstretch was to modify Bsurfaces addon functionality from creating to editing loops. It is expected to shape selected loop with Gpencil strokes, straighten them when no Gpencil strokes detected, and convert Gpencil strokes into wiremesh loops when no selection.
Later this functionality was forked to Cstretch (Mira tools) for besier shaping to curve and Spread loop (1D_Scripts) to straighten/align loop (could be seen in TOPOLOGY WORKS 1080p video). Later Spread loop evolved to more engineering tool (with precise slopes control in permilles/degrees) to design general plan slopes.

Circle

Circle realization has limitation - it shifts the center depending on uneven loop density, was enhanced by Arc support functionality which shapes loop in form of 3-point arc (based on end loop and active vertex) and also allow to set 3d cursor to the center of arc (which appeared to be critical missing functionality).

Relax

looptools Relax is good for loops, bad for faces, Blender Smooth is good for faces bad for loops.
Ended up with separate contextual Relax, which runs Looptools_Relax in vetrices/edges mode and Blender_Smooth in Faces mode.

[nickberckley]

One more thing that @HooglyBoogly and I discussed in the past was making those operators into Node Tools and shipping them as essential assets. This is the path that I would want the most. Initially I moved away from this idea because of some reasons (mentioned in the design doc I created), but after some more thinking and playing I want to give this another go. This will be much better option in my opinion, as it would provide not only operators, but also an example of node tools for users, and probably useful node groups as well in the process that they can repurpose, and build more complex tools using this presets.

Last week I looked into this again, and found that translating such complex math into nodes was little beyond me. There might also be some things that GN doesn’t do quite well yet (but might be good targets for nodes module). However I made barebones version with just math of the Circle operator, and I want to get the help of the community into implementing it as node tools, even if it’s just for the experimentation.

I would love it if some time is given to me for that, I think it can be a very good exploration.

[1D_Inc]

@nickberckley

Loop Tools is very mathemetical, meaning there’s not much to maintain it in terms of API, but the algorithm is something else, and will need people who are familiar with it.

It was quite challenging at the time, I used to actively building contacts with such kind of peolpe.
To this time I’ve lost almost all of them. Some of those people has gone to Sverchok, so GN implementation was expected to evolve a more math-related part of community.

[dfelinto]

@nickberckley

One thing that it seems escaped you two is the unfortunate sidebar panel that Loop Tools has in 3D viewport. Now, removing this will be controversial, but it should be done, it breaks our UI guidelines not only in terms of look, but also in behavior.

I’m aware of it (and its hack code) and agree that it shouldn’t be ported over at all.

It is actually mentioned on this post, but indeed more as a matter of fact than with the importance it could have: This is only visible at the moment on the Viewport Edit > LoopTools panel (which won’t be ported to Blender).

@nickberckley

Problem is, annotations have layers, they are per-frame, they have weird projections.

I may be missing out on something here, but I don’t see the layer/per-frame as an issue. Specially because I would expect this to be used with a quick use-and-discard workflow. You do your annotation, and run the operation.

@nickberckley

Even if it takes some time, I would prefer if they were rewritten in C++, polished in the process, …

The way I see it, we can always port it to C++ after it is in Blender. Even if it changes the original behaviour. But anyways, I think this is beyond the core of the proposal here and it depends indeed on the people who will be able to implement this.

[costavojik]

Love it!
I have a small suggestion for GStrech and Space. In theory they are very similar one is distribute points along current shape/path and the other is between A and B. So I think they could be “united” into one operator.

And the second major idea. Some of them can be recreated with geometry node tools. I think it’s the way to go? It’s much better if Blender modeling operators would become “nodified” and customized into niche tools when there’s need. This one just falls as a bigger project where there needs to be shortcuts and all kind of gizmos control in GN

[Mifth]

Hi, I’m Pavel. I was working on Mira Tools and Sculpt Layers addons. If you want it in Python I potentially can do it as a part time dev. But it would be great to get paid for such kind of a job.)

[Mikhail_Rachinskiy]

@dfelinto

The way I see it, we can always port it to C++ after it is in Blender.

It will never be ported to C++, Py version is good enough for everyone, there won’t be an incentive to work on C++ port.

I like the idea @nickberckley proposed to get community help with GN port: implement To Circle and see how it compares to Py version.

[SpookyDoom]

Is it really a good idea to port everything into a geonodes pack, now?

LopTools has become a pretty integral part of modeling. Why splitting it off into GeoNodes and why will it never be ported to C++? I get that modifiers are a good idea for GeoNodes since they have a wide range of functionality with a justification to stay modal. But LoopTools does not need that. Why split a rework off into yet another functionality status?

(edit) even @nickberckley said earlier that he would prefer it to be rewritten in C++.

[dfelinto]

@nickberckley have you talked with @Tariq about any of this by the way?

At the end of the day I don’t care if the port happens in C++, Node Tools or even a cleaner Python. I just hope an ideal solution doesn’t get on the way of having this ported at all.

Talking to Sergey, he highlighted that it would be good to understand what is that makes porting to C++ an issue. From what I could find Tariq’s concerns were more about the code solutions and less about Python vs C++.

[Tariq]

Hi, porting to c++ isn’t an issue. The major thing left for me to do was to properly implement the best fit option(It’s a non linear least squares approach). I was mostly occupied with winter of quality stuff, bug fixes etc but I’m in my c++ port branch, working on it now.

[Mikhail_Rachinskiy]

@SpookyDoom

even @nickberckley said earlier that he would prefer it to be rewritten in C++

I’m also in favor of C++ port.

@SpookyDoom

why will it never be ported to C++?

For the reasons stated in my reply.

@SpookyDoom

Why splitting it off into GeoNodes

For the reasons stated in nickberckley reply.

[Wevon_AAS]

Hello everyone.

LoopTools Relax is very useful. Although it might seem like Smooth Vertices, it’s quite different. It relaxes each loop independently and preserves the position of the vertices at the final edge of the selection, making it ideal for edges. It allows you to maintain tension in one direction.
It could be improved by having the option to consider the tangent of the edges before the selection, to better preserve continuity with the mesh outside the selection.

As 1D_Inc says, support for creating or distributing arcs, with control over the center or endpoints, would be fantastic.

[Xorrito]

I like the idea of using Node Tools. Here’s my attempt:

It simply projects a circle on the selection and snaps the selection border to the circle by proximity (big caveat: more than one vertex can snap to the same vertex on the circle).

Haven’t figured it out how to do it by index.

LoopToolCircle.blend (146.3 KB)

[Xorrito]

Space, same problem as above.

Space.blend (127.1 KB)

[Tariq]

Awesome work. I’m not sure if this is the right place to give feedback on your approach but I presume it should be fine given the overall goal here is porting looptools to blender so it will be good to see how far node tools can also go with regards to this. I tested your file and there’s still quite a handful of problems apart from the caveat you mentioned.
Apart from the missing options like fit inside, factor, lock xyz, etc
It does not work properly with the mirror modifier

It should be able to create multiple circles from different selections in one go

More of the multiple circles in one go issue

Expected outcome(result from my c++ port)

It does not create a good circle if selection ends at the boundary of a mesh

The circle is quite jagged along curved surfaces like a sphere

More of the jagged circle along curved surfaces

It’s not working on whole plane selections. I should be able to convert this to a circle.

It should be able to circularize the edges surrounding a single vertex(looptools addon does this)

[Xorrito]

Yes it’s very basic, node tools can’t be aware of modifiers and many other things but I think that we need to know the limitations to see where it lacks and what can be improved.

It is amazing what can be done with them for people that can’t code like me.

[Xorrito]

Fixed whole plane selection and circle near mesh borders. Thanks @Tariq.

LoopToolCircle.blend (149.1 KB)