Huh. Let me try with a programming analogue: so you have that statement earlier in the program where a bunch of named variables are introduced (with values assigned to them). You change this statement, so it now computes differently named variables. Of course, all the later statements keep using the names they're using, and things become weird. Is this roughly correct?
If so, then, uh, that's the problem of renaming the bound variables, it's an annoying one, but it has been around since the inception of λ-calculus and has several well-known solutions.
You need to know which autogenerated names from the last generation correspond to which autogenerated names in the current generation.
The problem with CAD is - you don't know.
Previously you had:
[OK] create sketch_1 (a rectangle)
[OK] pad the sketch_1 into a cuboid_1 (face_1, face_2, ..., face_6)
[OK] create sketch_2 (a round circle) in the middle of face_2 (which is on the right side of the cuboid)
[OK] pocket the sketch_2 creating a round hole in the cuboid_1
Then you change the sketch_1 making it a pentagon instead of a rectangle. The tree becomes:
[OK] create sketch_1b (a pentagon)
[OK] pad the sketch_1b into a cuboid_1b (face_1b, face_2b, ..., face_7b)
[X] create sketch_2b (a round circle) in the middle of face_?
[X] pocket the sketch_2b creating a round hole in the cuboid_1b but where exactly ?
There's no face_2 anymore - new side faces of the cuboid_1b are each in different places and at different angles than side faces of the old cuboid_1. You can decide basing on some heuristics, but that heuristics sucks in FreeCad and is almost never right.
I only every used Free Cad so I don't know how other CAD solves this problem, I can see using a better heuristic (like the least change of the plane and distance of the sketch ? ) or forcing the user to specify which edge corresponds to which when editing a sketch that isn't the final one in the dependency chain.
You could also force the user to mark and name objects in the sketch on which other sketches can depend - and when you edit the sketch you'd have to set them up correctly after the edit.
So, could you potentially store more metadata than just the face name, like it's normal for example, or the location and approximate surface area, and try to use that to reduce the problem space for an educated guess?
That will fail when, instead of turning the rectangle into a pentagon, you rotate it 45 degrees into a rotated rectangle.
I suspect that SolidWorks solves this by naming each face after, for example, the sketch line segment or arc that it was extruded from. But I'm not sure.
I'm also not sure if I understand the problem description correctly, but based on my little experience with 3DSMax, Blender and SolveSpace, I'd use this programming analogy:
You have a code that creates an array A, and then later on code that does something to elements A[2], A[3] and A[5] - elements which you semantically understand as "frobnicators of A", and whose number and indices depend on the contents of the array.
You then apply changes to the first part of the code, and now the correct frobnicators of A to modify are A[6] and A[14]. But the tool used to auto-update the array accessing part has no obvious way to know that by mentioning A[2], A[3] and A[5] you meant the frobnicators of A, and not say the barbulators of A. So it cannot auto-infer that you now want elements A[6] and A[14].
Or back to 3D land, what I assume is happening is that when you cut a hole through a solid, what you mean is to cut a hole (in a particular spatial relation to the solid's origin), and what happens is properties of some faces of that solid get modified. Then you apply further modification to these (and other) faces. After that, when you start reparametrizing the hole you cut in the past, the latter modification has no clue what your intent was, and blindly applies itself to the same faces it used before.
I imagine the problem is not theoretically solvable without extra "intent-related data", and existing solutions are just a bunch of heuristics guessing what the person doing the modelling meant by any given step. Topology being one thing you can use to inform these heuristics.
Yeah, but that's hard, because imagine you have an edge with UUID 1, then you edit the history which lead into that edge being cut in half. Which one of the two edges has UUID 1?
The answer is complicated because if you have a chamfer on that edge, depending on how you split it, you want to have the chamfer on both resulting edges. So they both get a new UUID, but you have to modify the next operation to apply to what "was" the edge 1.
1. sketch a rectangle, extrude up. edge_1 in question created.
2. chamfer edge_1. chamfered edge_2 and _3 are created.
3. sketch a rectangle on far side, extrude toward camera for 1/2 full length. edge_4 is created at middle of box.
4. do other stuff. lots of things come and go.
5. you changed mind. extrusion distance is changed so edge_4 goes past chamfered surface.
On Fusion 360 with History enabled, this will result in a progress bar and backend goes back to step 2. to re-do and re-compute all subsequent ops up to step 5. As the result there will be probably edges 2, 3, 4, 5 that now represent near and far side chamfered edges. If you've done something that presently don't make sense at step 4., Fusion 360 throws an error and leave half done objects.
Okay, now I understand the problem. It needs the History feature to be done right, and UUID.
> So they both get a new UUID, but you have to modify the next operation to apply to what "was" the edge 1.
Of course, that's exactly how I personally would expect the things to be done? You obviously have to propagate changes through all the operations further down the line.
But how? Let's take a cube, of which I modify one face. Then I change the cube to be a pentagon (let's assume it's a parametrized object). What face of the cube corresponds to which face of the pentagon?
yes, it's correct.
That why editing the model history of an object is actually way harder than re-running a program after an edit. I feels superficially the same but after you've spent a few hours on the CAD thing, you realize that it's doing things way smarter than what it seems.
If so, then, uh, that's the problem of renaming the bound variables, it's an annoying one, but it has been around since the inception of λ-calculus and has several well-known solutions.