UV Sync select been going steadily, reasonably happy with progress. Did box select / circle select thing. Have to carefully check all the scenarios, and bug fix what’s there. Not at the point where ready to take feedback yet.
Found an interesting bug where merging vertices could cause a hole in the mesh. Fixed it.
Howard:
Worked more on bevel node. Redid the data structures to have less bundling of attributes of things into structures, and use parallel arrays similar to how Mesh was refactored. Figured out a non-redundant indexing of the usual corner pattern to make it easier to build the new Mesh that results from the bevel. A bit iffy whether this is going to be done by the early June 4.5 beta deadline, but still trying for that.
Discussion Topics
Nika:
Bugs are accumulating in Loop Tools, and do not seem to be getting attention of the developer of that addon. Nika has been looking at fixing it. There’s a large amount of math in them, so they are hard to understand and therefore fix. Wondering: could it be a good first issue to slowly rewrite those algorithms in C++ and have them in Blender?
Campbell: yes, but maybe not a “good first issue”. We don’t know how difficult these are.
Nika: will try to make up from a UI/UX point of view how things should look to fit into Blender’s design. E.g., currently, properties are stored with scene, so that next time you run them, you get the same properties. So some design choices need to be made, and Nika will try to make a design. Current file is one giant 6000 line Python file. Huge number of downloads of this (seems like every other Blender user?)
Campbell: would be good to have the couple critical tools identified so that we know how to prioritize.
Jonathan: use Circle a lot, and Loft. Nika: also has a good Flatten. Jonathan: goes along with “set flow” for usefulness.
Campbell: a little policy question: how to transition people off of Blender if they have the later version of Blender that now has it built in. Nika: can work on that.
Nika: also a question of whether they should be in geometry nodes too. Howard: probably can be built with more built-in nodes, but do who will build those out of primitives instead of calling the edit tool code. Campbell: let’s get the tool working first, and then have that discussion later.
Jonathan:
Curious about GSOC: the person who wanted to work on surfaces didn’t get in but really wanted to work on it. Is there a way that people who want to work on larger projects to do that? Can they apply for a grant?
Campbell: usually we want to see evidence from smaller things that the person could do such a big project before thinking about a grant.
Howard:
Welcome to Tariq, who will be doing a GSOC project on mirror improvements!
There are a few more addons that add ease of use like booltools, but the two mentioned above add functionality that blender doesn’t have so are a basic tools for modeling that every modeler have to enable at some point.
Interesting and the very fear I had when it was first announced that Rigify, Node Wrangler, Image as Planes and Loop Tools was going to be kicked out of Core Blender and on to the Extensions Platform.
Of those, all where ‘saved’ apart from Loop Tools.
As to the question of what should be first to be converted to C++ inside Blender, that’s easy, Circle.
It was the same before extensions. There was no official maintainer for those back then either and very few changes were occurring for them outside of trying to keep them working as things changed. For example the last real change done for loop tools happened in August 2021 (well before extensions etc).
This was brought up and @nickberckley mentioned in the meeting that Loop Tools has some special features that would not be possible with node tools, like the ability to detect a mirror modifier and create half circles on its axis of symmetry such that the mirrored result is a perfect circle.
I absolutely want to improve node tools performance and I have plans for how to do it. It’s a bit involved though (basically making BMesh in edit mode optional).
In this it’s also a bit of a missing feature though. The builtin extrude operator is much faster because it’s a modal operator, so it’s not executing from scratch every time. First it does the topology change, then it’s just doing a deformation. So implementing modal node tools can also improve the performance.
But that’s the important bit. Even if nothing was really added or improved, the fact that it was core Blender means everyone was at least assured the existing features would still be there and continue to work with each new version.
The moment anything was kicked out to the Extensions platform, that was no longer the case.
Loop tools being a big example, I mean over 800K pretty much screams ‘core feature’ and that’s largely just single user download, given that it hasn’t had any updates since moving to the Extensions platform.
If something isn’t done soon, I would be a little surprised if Blender 5.0 didn’t totally break it.
Bugs still happen where the “core” addons break. It’s not like many addons have test code either - core or not (I think only glTF has them and those are on the upstream github repo). The only thing gained from being “core” is that there’s sometimes a group of nearby developers who are often guilt-tripped into “fixing” them even though none of us were the ones who created the original code There really is no assurance.
I do agree that many items of loop tools should be something more native though.
Setflow and Looptools are essentials for any modeler who does a lot of subdivision modeling. If these can be in the Blender core deployment that would be great. Circle, flatten and relax from Looptools is used very often, and Edgeflow (Setflow) is so important from people migrating from other 3D tools to Blender. For example, if setflow was not available in Blender, I would probably still be forced to use commercial 3D tools.
The only issue that I experienced is that circle tool is sometimes not as robust as in other 3d apps. It tends to rotate circle in certain situations and doesn’t keep it aligned to the mesh as it should be.
Also people migrating from other apps usually do a quick test of Blender without any addons. So I feel if these additional tools were available by default it would make a better impression on them.
I will chime in and give a little +1 to ‘Space’ as one of my most used critically used features of Loop Tools, along with Circle.
Weirdly, despite it being built into blender, my most used feature might be its Bridge tool because Blender’s Bridge Edge Loops tool doesn’t appear in the right-click menu when in vertex mode - it only appears in edge selection mode - whereas Loop Tools is always there.
(I know Bridge Edge Loops is the Ctrl+E Edge menu, but I seem to always get caught out by expecting it to be in the right-click one and when I see it’s not there, I just use Loop Tools.)
Bugs are accumulating in Loop Tools, and do not seem to be getting attention of the developer of that addon.
Wow, the last time Bartius Crouch and I touched Loop Tools was probably in 2012, when we made F2.
The latest tool I funded in Looptools was Gstretch (the idea was to provide the functionality similar to Bsurfaces, but for editing loops instead of creating)
2013 was probably the last time I contacted with Bartius - since then I decided to change the development strategy - to discover critical Blender modeling demands and prototype possible solutions to them and test those solutions in quite heavy production conditions in order to make sure that they are bulletproof, so I worked with dozens of python devs which resulted in several toolsets. The idea was to discuss possible solutions with core devs later, having working tested prototypes and approaches, also avoiding implementing raw solutions at the core level to not to force anyone to maintain them.
The strategy didn’t worked as expected - several years spent developing and testing tools and approaches offline resulted in the core developers being unaware of the problems that had been solved all this time.
So there is a decade-long gap between us that we can’t do anything about, different cube-tested implementations and now we discuss slowly degrading Looptools in 2025.
Well, at least we has got experience how to not to do things, right?)
I still think that instead of changes to Sync mode there should be a new “Flushing mode” , since semantically ongoing development results in a mixture of a Sync and Unsync modes…
Are there concrete things you would like to address our attention to now? One way to do so would be to come to a Modeling Module meeting and explain them. Or if there are addons or RCS proposals that you think need bumped attention from us, feel free to message me (say, in chat.blender.org). I can’t promise they will get immediate attention, as our bandwidth is fully taken up right now, but it could give us ideas for what to work on next.
There really is no assurance.