I always love to see these projects attempting to create an Open-source parametric CAD tool, but I think they will never get the the level of functionality and stability required. The fundamental issue for all of them is the lack of a robust open source "parametric CAD kernel", these the the central core that understands BREP and implements the geometric operations.
The most widely used kernel is OpenCascade, the kernel used by FreeCad. However it is outdated, unstable and limited in significant ways with no realistic future prospects. It is unfortunately the limiting factor of FreeCads functionality and prevents any serious use of it.
The most widely used commercial kernel is Parasolid, used in many packages including SolidWorks, OnSpace, and NX.
What I would love to see is Siemens adopting a model similar to some of the game engines (Unreal and Unity) where it's free up until a revenue limit. Opening up Parasolid for "free" open source and small commercial operations would be both brilliant for society but also for Siemens, it would only result in a growth in the use of Parasolid and increased revenue.
Nick Kallen has been working on an BREP based CAD tool with the sort of ease of modeling that things like Blender has. Originally it was based on C3D, but he switched halfway through to Parasolid.[0] It’s amazing the amount of features he has built considering it’s a one person project. It’s worth going through his progress report videos.[1]
>these the the central core that understands BREP and implements the geometric operations.
I've seen people quote a good modern CAD kernal as a 100 man year project. It's probably not going to happen, maybe there's some avenue for government funding?
Alternatively Signed-Distance-Functions are pretty nice. They're not BREP, but they're a lot easier to implement, and it might be possible to shove them into a BREP-shaped hole.
Here's a signed-distance-function based CAD kernal written in a few thousand lines of python+numpy, that seems to be about as fast as openscad. Maybe faster. https://github.com/fogleman/sdf
Why is BREP so challenging? I hear these sort of statements a lot. But often they turn out complicated as much because it’s a crusty code base built on hacks of hacks. What am I missing?
SDF do seem like a cool option. They’re computationally expensive but I’d bet the ray tracing features coming out in GPUs would help with that.
I do think 100 man years is an exaggeration, or maybe they're talking about fully reverse engineering an existing CAD kernel and all the weird proprietary extensions it supports.
In my uninformed opinion working with meshes is hard. In the interest of comparing apples to apples I'll compare a CSG-based approach (joining two mesh objects together) with an SDF-based approach (joining to SDF objects together).
If you want to merge two mesh spheres together you need to do a lot of work. First you need some way of telling whether a point is inside or outside of another mesh. This is because you need to be able to delete all the vertexes/points/faces that are inside the other mesh. So you do that, and you delete all the points/vertexes/faces that are colliding with the insides of another object. Then you need to stitch the two meshes together. This is a whole thing, you need to find the boundary where the two meshes would have collided, create a bunch of new edges along that path while also taking into account where the existing faces on both objects are going to be.
There's a lot that can go wrong during this as well, it's possible for your geometry to be "non-manifold" which means it has no clear inside or outside, and it's really easy to accidentally make an object non-manifold when you're stitching it together with another object. There are issues where sometimes meshes look alright but in reality there are two edges on top of each other, or a face with zero area, or all kinds of crazy stuff. Making a tool that can reliably stitch two meshes together is a pretty big challenge. Than you start talking about adding fillets to vertexes, and how that affects the mesh geometry of other attached faces, and you're having to write some really complicated error prone code for N different combinations of situations. Like what if the chamfer abuts another chamfer? What if it abuts a spheroid? A bunch of edge cases (heh) depending on the faces that your edge butts up against.
With SDFs you just check if the point is inside one object or the other, and than re-generate the mesh from scratch. You write one not-too-difficult mesh algorithm and everything else is basically just OR/XOR/AND-ing things together. It makes defining geometry geometry about as simple as possible, just write a function that can say whether a point is inside your geometry or not. Something you need to be able to do for mesh based CSG anyway, but with a bunch more complications.
This is also why tools like openscad can't do fillet/chamfer joins after 10 years and the tool I threw together in a few weeks can.
The "Parabola Segment - exact" and "Polygon - exact" examples in particular. Probably requires some combination of the two for your use case. Basically turn your lines into 2D SDF objects that define the outside of your object.
I think most of those objects actually could be chained together, like the actual quadratic bezier example has a real interior and exterior when you look at it more closely: https://www.shadertoy.com/view/MlKcDD
So yeah, the intersection of a bunch of line segment SDFs like that could do it. A bit more completed than that but that's the basic principle. Not sure about the performance... There is probably a more efficient way to do it, but I don't have the math skills to figure it out.
My personal idea for how I’d engineer for that is to reframe the problem as “the geometry is a program in a programming language”, and have ways to calculate surface Normals, derivatives, etc.
But you are absolutely correct that choice of representation / data structure makes a huge difference in what’s easy to calculate. And perhaps the best approach would be to internally have tools that can map between different data structure representations based on the calculations on the calculation at hand
I would contest they are generally necessary.
Applications of parametric CAD are many. Can a jeweller designing a parametric ring do without them? Probably.
That said, you can e.g. calculate derivatives of the SDF and, simply speaking, when they 'flip' you know you found an edge or corner.
You can project onto the SDF along a plane or line and 'record' the intersection, use it as input in your model etc.
Similarly, you can treat an area bounded by such edges as a face etc.
Just because there is nothing out there yet doesn't mean it can't be done.
I also predict a great future for SDF based CAD for the simple reason that manufacturing methods mostly used for prototyping now (3D printing) will become more common for final pieces.
And there is no need for an explicit representation (higher order surfaces or polygon meshes) of the shape to get tool paths (often derived from 2D bitmap slices) for these methods.
One thing that probably won't change is the need for things which we design to be made of multiple parts which must be assembled together. For any serious application this requires specifying geometric dimensioning and tolerancing information, which ideally should be tied to the topological entities in question.
I'd argue that this information is becoming even more important with the rise of 3d printing and other digital manufacturing tools. If this information can be included in the CAD data, the manufacturing tool might automatically determine how best to manufacture the part to meet the required tolerances.
Topological information is also useful for analysis. We may wish to apply a load or boundary condition only on a face.
At the moment you don't. What I'm suggesting is that you could build up a conventional BREP-based datastructure, and than use SDF to "render" it. This gives you a very clear separation between your data structure and your meshing algorithm, and as I understand it a big chunk of those "100 man years" would be in dealing with the meshing algorithm and edge cases in it.
I suspect that having a generic meshing algorithm that will always mesh your datastructure with no edge cases would significantly reduce the time needed to implement a CAD kernel. You just need an algorithm that can tell you if a given point is inside or outside of your BREP. All you really need for that is a surface that points at a given direction, and the ability to tell whether a point is under the surface or not. Define your surfaces as BREP, render them using SDF, only have to write one meshing algorithm.
That being said I disagree with your definition for parametric CAD. Mostly the name, I get that you're talking about BREP based CAD. That is one way to do parametric CAD, but CSG can also work, especially if you can do more advanced operations like a filleted difference or union, or blends between two shapes, or other advanced CSG operations. I don't think that CSG-based CAD is inherently worse as long as you've got the ability to do things like fillet/chamfer CSG operations.
You probably don't need to do a fillet along an edge if you can do a fillet where you subtract one object from another, something that SDFs can do easily: https://github.com/fogleman/sdf#smooth_difference
>>these the the central core that understands BREP and implements the geometric operations.
> I've seen people quote a good modern CAD kernal as a 100 man year project. It's probably not going to happen, maybe there's some avenue for government funding?
Perhaps the leverage of AI coding assistants will bring it down to a few man years over the next 5.
I think some interesting developments are made in that sector in the form of https://github.com/hannobraun/Fornjot and https://github.com/ricosjp/truck. Let's see whether one of those will actually get anywhere near a usable level. Fornjot in particular is shaping up really well.
The purpose is "CAD-like" -- that is, parametric surface modeling operations on polygonal geometry.
Blender has its purposes, but I think surface or solid CAD must be pretty far down the roadmap. But there are often times where BREP or NURBS type workflows would be quite useful, and also some modeling operations such as "extend geometry from object A based on object B's coordinates and normals" can be very useful.
If you need operations like variable radius fillets on tapered multiple intersections with G3 continuity—this is probably not for that. But selecting the midpoint edge of some other object and offsetting a plane by some radius? This makes that sooooo much easier.
> Opening up Parasolid for "free" open source and small commercial operations
I've used Parasolid in a previous job. OpenCascade may be unstable and limited, but Parasolid can be too depending on your use case. Its not a silver bullet.
A agree with this 100%, I have used OpenCascade and Parasolid in the past. With the recent OCCT development trajectory, I'd hesitate to recommend one over the other on the geometry kernel alone. Also people often forget OpenCascade includes an entire visualisation module that FreeCAD doesn't even make use of...
Why? I've gotten far enough with FreeCAD despite its annoyances that I would be tempted to look into solving the problems with the kernel, and here you are discouraging people like me from getting involved by saying it's hopeless.
The culture of constantly losing interest and starting over in many areas of software is one of the things I dislike the most.
I don't even think that the biggest problems have anything to do with the geometry kernel. The entire UI in general could be overhauled without touching the kernel and it would make the difference between highly usable and productive CAD program with some limitations vs incomprehensible mess.
Not OP, but that sounds unnecessarily harsh. FreeCAD is much more approachable now than it was few years ago. It's definitely far from perfect, but it's getting substantially better and we should collectively encourage that.
I also realized during that time that my distro was doing a poor job at packaging it to make it work as designed (and I can't fault the packagers for that, it's a highly specialized/niche application after all). The flatpak version seem much more cohesive.
If one thing, I'm amazed by how much one can accomplish with FreeCAD given a little patience and perseverance: it brings parametric CAD, drawing projections FEM… to the masses, which, when I was learning that stuff as part of my curriculum, was completely out of reach of most universities, let alone the hobbyist scene.
It's an under-appreciated, fundamental, piece of software if you ask me.
FreeCAD, for me, has been extremely frustrating, but it has convinced me, coming from OpenSCAD and not a regular CAD background, that a constraint solver and features like fillets or the curves workbench are really things I was missing and didn't know it.
FEA is tantalizing, but I haven't been able to accomplish much yet.
A significant part of the "incomprehensible mess" seems to be that errors from the kernel have no context. If you ask in a forum, people just kind of shrug. It's not clear on which side the bug really is in such a situation.
Is there anything that can be done with GPUs being so fast to trade computer time for developer time? Like, would a point cloud or some other approximation be easier to work with?
Yes! You've pretty much hit the nail on the head with your point cloud description, that's what the signed-distance-functions I was talking about basically are. You build a mathematical function that says whether a given point is inside or outside of your object and then you sample it a bunch of times and build a mesh based on that.
Works quite well on modern CPUs, works very well on modern GPUs. The library I linked to uses numpy and numpy is fast on CPU, but a newer tool like jax would let you run pretty similar code on the GPU even faster. All this machine learning stuff actually makes python a very good choice for complicated numerical stuff like CAD.
When I say "works quite well on GPUs" I mean "runs in real-time on a shader in a web browser" https://www.shadertoy.com/playlist/43cXRl . Note that none of those objects are meshes, it's a shader rendering the objects directly based on a signed-distance-function, every single frame.
You still need to turn your SDF/point-cloud into a mesh, but that means you only need to implement one algorithm, something like marching cubes is good enough and dual contouring is a bit more complicated but also more precise.
To clarify, can this method be used as a fully functional replacement to BREP for a mechanical (machine design) CAD system?
I am a robotics engineer and 100% of my work is open source (see my profile). I understand that without fully open source CAD it is hard to make fully open source machines.
If we were somehow able to rally support around a single project to create an open source CAD kernel and associated interface (perhaps built in to blender or FreeCAD to avoid building a new UI), what approach would you recommend? How long would you estimate it would take for three full time senior developers to get a useful system out?
Any thoughts are appreciated. I am at the extremely early stages in my career where I hope to learn to raise money for open source non profit hardware projects. Open source CAD is a sort of linchpin and without it we cannot succeed in quite the way we would like.
> To clarify, can this method be used as a fully functional replacement to BREP for a mechanical (machine design) CAD system?
I think so, but there are some open problems. Also it depends on the senior people. Inigo Quilez is a world class expert in this domain, and for the most part we're copying his work, get him on board and you'll be golden.
Fundamentally it makes sense, BREP is about representing boundaries and you can definitely use SDFs to represent the area under a boundary (infinite SDFs are possible, although obviously you can't turn them in to a mesh). Enclose a volume with boundaries and you can mesh that out just fine. A bit different from CSG-based SDFs, but entirely plausible.
>what approach would you recommend?
If I was to do this I'd take the constraint solver from solvespace (same one used in this post) and start using it to generate SDFs. At that point you're already 80% of the way to your end goal.
I mean if I was personally to do this I'd start by making a system that implements everything openscad can do, try to get some funding going, and than add in a solvespace based workbench for doing 2D cad that you can import into an openscad-ish language. You can see my efforts here: https://github.com/traverseda/PySdfScad
That's tackling it from a different angle than BREP though. I think that openscad but better is a surprisingly viable thing though, especially if you use it to do things like generate the gears/screws/whatever you import into your BREP based CAD project. Use scriptable CAD as the underpinning for more advances CAD.
> How long would you estimate it would take for three full time senior developers to get a useful system out?
Well define "useful"? Honestly I think you can get 80% done in under a month. I built the first pysdfscad in a week or two and replicated 80% of openscad's features. Fogleman built the library I used for pysdfscad in under a month.
I'd expect something pretty good in under a year at that kind of rate. There would be some outstanding problems, like it would be a challenge to figure out how to apply a fillet/chamfer to an edge, but not an insurmountable challenge. Geometry import is another place where you're going to spend a lot of time/money but is very important.
So let's say two or three years with three very competent seniors working on it to get a pretty good CAD program, with a GUI.
Thank you for this. It is encouraging that something like this could be done for under $1 million. I’m just dreaming right now but I think open source mechanical CAD is one of the low level pieces that could touch billions of lives.
It would be cool to put together some kind of foundation, with a working group and some kind of RFC process, to build a concrete plan which could then be used for fundraising.
It definitely would, yeah. I think the SDF stuff will come to fruit eventually. There's also Matt Keeter's libfive-studio available and I saw a solvespace maintainer in this thread asking about it. I think the open source community is getting skilled up for it.
That’s a good point. I am planning on following up with them soon about another project I am working on. I will see if there is any room to ask about this.
When I tried marching cubes and dual contouring against SDFs I ended up with a ton of performance issues that I was unable to resolve in the time I had allotted for experimenting. To get the resolution I needed I ended up with way too many triangles which used a lot of memory. I could later simplify the meshes but given the high number of initial triangles that process was quite slow. What I would like to explore (and hope that someone else does before me) would be a SDF optimized meshing algorithm that would make use of the extra distance and normal information.
I did not, I'm away from my notes at the moment so I don't remember which libraries I used. I used a couple of different ones but not OpenVDB. Next time I try this task I'll try OpenVDB and see how far I get. Thanks for the recommendation.
To have access to something commercial for free may be nice.
The ideals of free software though call to produce free and open code because it remains free, open, and available. Siemens, were it to graciously offer some free tier access, would be also in a position to limit or withdraw such access at any moment. (This even applies to the paid licenses.)
However limited OpenCascade is, it's here, and it's usable, up to a point. I hope that a successor to it will emerge, if there's a need.
>> SolveSpace's kernel seems rock solid to me. It just doesn't support fillets or bevels.
Sorry, I work on Solvespace and can confirm it has some serious NURBS bugs. There are several open issues on github relating to NURBS boolean failures. The problems seem to fall into 4 or 5 categories, and we can probably fix some of the common ones. It's going to take time and some deep dives into the code though.
There are two Rust projects working on parametric kernels I'm aware of.
The first one, Truck[1] seems to have a company behind it, Ricos Ltd, that look like they to know what they're doing[2]. The tweet shows their product using functionality from Truck (the frontend is not OSS AFAIK).
Fornjot is an ambitious project IMHO. Their kernel is in a separate crate[3].
As for OSS code that could be a good base to either use (or port to something like Rust) for someone to write their own kernel is Ayam [4], the oldest OSS 3D NURBS modeler that is still being developed.
Siemens is trying to make the Parasolid file format into an ISO standard. I have input into how my country votes on this.
I suggested that I might support this if Parasolid was made open source, dual licence it as commercial and AGPL, got nowhere with the project leader who is being paid by Siemens.
I spent the past 2 years working in AutoCAD and was surprised to find that it really hasn't changed much in the past 20+ years, other than some simple UI changes. I ported over 100,000+ lines of Lisp from the mid 90s and it worked almost without modification though I did rewrite it for other reasons.
That project has come to an end prematurely. Is there a real future in CAD programming? I feel like I've wasted a good chunk of my life on a dead language in a dead product. Is any of this knowledge portable?
I'm super glad this exists, this space definitely needs compelling open source alternatives to bring back the hobbyists scene from proprietary offerings (mostly fusion360), and every effort should be encouraged since this is a very difficult nut to crack.
I known my way around CAD software and so I gave this a shot around 4 months ago, but it looked frankly alien and relied a lot on blender idiosyncrasies and baggage that most people with a CAD background would likely be missing. Basic things were hard to find and simple things were hard to do. I also had doubts that the foundations are sound (whatever engine props this up seems to be using floating point numbers instead of parametric equations, so things like pockets on top of coincident lines would incorrectly leave infinitesimal volumes of material).
I should give it a new look but the road ahead will likely be very long.
Autodesk has gone out of their way to destroy free F360. I finally quit when you had to reload the free version with a new account every 30 days. Forcing Eagle into F360 was just evil. Trying to use either is the hobbits being shown Frodo's clothes levels of anguish and despair.
This may make me look at Blender again (too hard to learn at the time). Designspark Mechanical isn't too bad if you have become an F360 refugee.
F360 makes me so sad. I'd gladly pay for it, but I make like 2 or 3 models as a hobbyist per year and their cheapest plan is hundreds of dollars per year. I wish there was something in between that unlocked the full functionality. Or at least multi-page-PDF support.
While it definitely has missing features, I've found that their free tier works pretty well for most stuff that I run into for 3D printers or in my wood shop. I have about 80 models in my F360 account right now and I've never paid for it. Never needed to print multiple pages, though. (Occasionally a cut list for plywood, but there are plugins for that.)
Your Term Has Expired
You can still administer your teams, but you now have 'basic' access to Fusion. If you would like to restore full access, click Subscribe Now.
With basic access you can still:
View projects
Comment on and mark up files
Download files
It used to be you had to switch every year. But the ts and cs are buried on the web site if they are public at all. You have have it installed to see your license details, which I no longer do.
OK, so you were using non-free-tier features, and they were pulled when you were no longer in the non-free trial? That's a different thing.
F360 locks teams and some features (stress/strength modeling, for example) behind a paywall but for the actual free tier--useful for 3D printing, woodworking, etc.--is effectively unlimited for single-user use. (You have a limit of ten "editable" documents at once, which is silly but not of much consequence.)
I don't have a ton of experience with CAD software so maybe it's par for the course, but one of the things I dislike about F360 is how it runs like a dog regardless of your hardware.
I started using blender again recently and the UI has major improvements, but mostly learning the shortcuts pays off big time (i.e. rx for rotate x, sy for scale y, gx for move x : in global space, gxx will move x in local space and so on).
Changing space key in the settings to pop up a search toolbar, etc.
My point being, each software has its own mechanics and takes a while to become productive at it. Blender has a lot of content online from users, with tips and tutorials, so it’s currently a good space to be, learning wise.
CAD support is lacking though. Glad linking CAD Sketcher here found more users willing to try it out. Hopefully it gets feedback/support, helping to its development.
Not disagreeing with any of that, I was just thinking that very little of what's generally useful in blender for making art transposes well into something useful or convenient for CAD. The whole mindset is different: you generally don't scale anything when designing a mechanical part, you specify or parametrize dimensions (because catalogue items like fasteners won't care that it looks awesome at 123.6%), and similarly, you don't move things by arbitrary offsets in arbitrary directions, you add assembly constraints so the kinematics make sense.
I'm sure CAD Sketcher will grow a ton of convenient shortcuts too, I don't think they'll have much in common with the rest of blender.
I've been using Blender a few times for 3D printing. Functional parts with playful/artistic touch. I can recommend it for that. I tried FreeCAD recently but it feels, well, constrained.
FreeCAD is like entering values into a form, while Blender is like playing around with the model interactively. You can drag anything around, tear it apart, fix it again. It's possible to keep things editable, almost parametric, but this requires more planning and knowledge.
For getting started you definitely want to follow tutorials. One for basic mesh modelling, and one with focus on CAD. (How on earth are you supposed to figure out that you want a "subdivision surface" modifier. It's the first thing I add in every project.) But I'm thinking now FreeCAD may be just as hard to learn as Blender (unless you already know CAD).
(But now that I know the basics of CAD workflows, CAD Sketcher looks interesting. Before that, I wouldn't have seen the point.)
I would recommend trying out SolveSpace first, which is what CAD Sketcher is based on. It has a delightfully simple UI, and the basic sketching workflow is the same, so you can learn the concepts first in SolveSpace, then get familiar moving around in Blender and transfer your SolveSpace knowledge over.
This is awesome, I have been struggling with FreeCAD after switching from Fusion 360. However I find blender a joy to work with for 3d art so I have to give this a try.
Blender has nice UX (the new versions, used to be horrible) but sadly what is holding opensource CAD back for me is the poor constraints and parametric modeling backend.
Anything beyond simple polyhedra and booleans runs into a problem. Fillets, chamfers, sweeps and lofts don't work well. It's a shame.
Things have improved quite a bit in the latest freecad versions, and I remember reading somewhere that the next one promises to solve whatever's left over.
My biggest gripe with freecad isn't necessarily that (it's easy enough to work around), but that going back few steps to edit things and apply it forward is very fragile. There are ideas floating around to better handle this workflow but we'll have to see how well that goes (it's probably a very difficult problem to solve with no general solution). In the meantime this gives me a lot of frustration and rework, but, running on Linux, there's no real alternative as far as I can see.
You make a base sketch and pad it up to create a square part with a single hole in the centre. You chamfer the hole. You change the base sketch so that it is now a rectangular part with 2 holes, 1 at the left and 1 at the right.
Should the chamfer apply to the left hole, the right hole, or both holes?
Obviously there are special cases that FreeCAD doesn't currently handle optimally, but a general solution is impossible without FreeCAD reading your mind.
(You could also asy "any of those 3 options is better than trying to apply the chamfer to a random bit of un-chamferable geometry". But a general solution is still impossible.).
Agreed. I have no problem with this looking and feeling like a rebase operation in a version control system: fix the "conflict" to continue re-applying the sequence of changes linearly, drop steps along the way that are irrelevant or edit those needing to.
I'm not even sure FreeCAD's editing model is anything like that (on the surface it seems that it understands geometries but disregards the process to obtain them).
It is, and in a lot of cases you will get exactly that: an error at a certain point in the list of operations that you need to fix up so that the rest of them can be done on top of it. The entire reason that the topological naming problem is such a problem is because it breaks FreeCAD's understanding of the sequence of operations.
The first thing I would expect is a visualization of the failure.
When you move things around and break stuff, let's say by creating two disconnected solids, then I would expect a preview to show that.
Also, one problem with FreeCAD is that you need to open a sketch to modify it but often the model you are modifying is then hidden. So now you have to roughly guess the optimal value, close the sketch and inspect the model and repeat this process until you have something usable. If you need to use clipping planes to see inside the model then enjoy setting those up every iteration.
From the user's perspective, the circle that was originally drawn, which wasn't touched when adding a second circle to the sketch. If the original was deleted, then it's unclear (possibly assume the first replacement).
IIRC (not testing now) FreeCAD already handles this example sensibly. You can add circles to the sketch and the chamfer stays put. If you delete the circle and add a new one, it appears on the new hole. But if you add a square instead, it moves to a random edge of the rectangular hole.
The 'edge' of the rectangular hole is actually a loop of four edges, so this is understandable. Commercial software can fix some of these cases - I don't think the Freecad link branch can, but it does at least detect that the original geometry was deleted and raises an error asking you to reselect instead of allowing things to move around. And unrelated features downstream don't break. Not dissimilar UX to when I mess with something that Fusion can't handle, I say.
>a general solution is impossible without FreeCAD reading your mind.
The goal of a well-written program is to give the user the opportunity to express what is in their mind at an appropriate time, and to change their mind after seeing some output. And to be told explicitly or implicitly why their inputs don't work.
FreeCAD tends to get wedged so you can't back up, very unpredictably (for a newbie). This makes all its other issues worse because it inhibits experimentation.
You actually can back up, but it is time-consuming and not easy to discover. You need to manually step through the project tree until you find the first feature that is incorrect (this is not necessarily the first feature that fails to compute!), then either fix the sketch itself, or fix the sketch attachment, or the fillet/chamfer edges in the case of fillets/chamfers, and then proceed down the tree until it's all correct.
It's a lot of work, but often less work than starting from scratch.
Just moving the hole won't break anything, either in mainline or the realthunder branch. Not only that, but adding a second hole won't break anything either.
Changing the hole from a circle to a square on mainline will completely screw things up though.
It should remain on the hole it was applied to and new hole should not have the feature. Solvespace works this way although it doesn't do fillets or chamfers. The changes getting merged in the next version of freecad should help a lot with this.
so after a few minutes of trial, I have to admit I did finally have a proper way to CAD on windows. Constraint sketching on open source, well, did try all options, at least now I can do it. Also the last version of blender did improve accessibility
Blender is great when you get used to it... specially if you have a 3D printer... CAD is what is/was missing. You can even do similar to parametric editing aka non destructive editing workflow.
I'm glad that Blender is getting some CAD-like workflows, they allow to create types of models which are very hard otherwise.
I had to disburse some cash, but I've been complementing Blender with Rhino 3D for a few months now and it's a good mix. Blender is amazing for meshes and renders and animations, Rhino 3D is an amazing BRep modeller and both Grasshopper and Kangaroo 2 help in "getting just the right look".
The same for me. I love Rhino, and Rhino8 will have RhinoCode that I can use with F# instead of C# or Python. I was one of about 50 to 100 people who gave money back in early 2000s to take Blender opensource, and I used it to create wood carvings from photos using a shape-from-shading algorithm originally developed by NASA(?) to extract more information from single-lens, greyscale satelite imagery. I also used it to create other useful tools for myself. I am glad to see this CAD Sketcher developed, but as a long-time CAD user, I don't think it will reach critical mass or technical ability to compete with things like Fusion 360 ($400/year) but it includes so much - simulation, FEA, rendering, and a bunch of other goodies in a focused, minimal gui.
The most widely used kernel is OpenCascade, the kernel used by FreeCad. However it is outdated, unstable and limited in significant ways with no realistic future prospects. It is unfortunately the limiting factor of FreeCads functionality and prevents any serious use of it.
The most widely used commercial kernel is Parasolid, used in many packages including SolidWorks, OnSpace, and NX.
What I would love to see is Siemens adopting a model similar to some of the game engines (Unreal and Unity) where it's free up until a revenue limit. Opening up Parasolid for "free" open source and small commercial operations would be both brilliant for society but also for Siemens, it would only result in a growth in the use of Parasolid and increased revenue.