7 ms·
I like FreeCAD but it has one major issue (compared to something like OnShape which I use now), it doesn't have a smart naming topology. For example, you creat
by kuon 6y ago
I like FreeCAD but it has one major issue (compared to something like OnShape which I use now), it doesn't have a smart naming topology.
For example, you create a cube, you make a hole in it (not fully through), and then you chamfer one side of the original cube. If you go back in the parametric history and change the depth of the hole for it to go through the whole cube it will change the name of the faces/edges in the history and the chamfer will then be applied to another face.
This is a very hard problem to solve, and that's where some commercial packages shines.
https://wiki.freecadweb.org/Topological_naming_problem https://wiki.freecadweb.org/Topological_naming_problem
I wish onshape was open source, but I guess it will never happen because it uses siemens parasolid under the hood (at least I think it does). I don't know if FreeCAD can come close to something like onshape with the current gerometry kernel opencascade.
- Joker_vD 6y agoHuh. 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.
- TeMPOraL 6y agoI'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.
- numpad0 6y agogive each objects with UUIDs and refer to them by-UUID?
- kuon 6y agoYeah, 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. I illustrated that here: https://imgur.com/a/XR7sO59 https://imgur.com/a/XR7sO59
- Joker_vD 6y ago> 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.
- numpad0 6y ago1. 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.
- nraynaud 6y agoyes, 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.
- ajuc 6y agoYou 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.
- zeta0134 6y agoSo, 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?
- pillefitz 6y agoI'd love to know how commercial software solve this issue. I would expect a mixture of heuristics and user inputs to resolve ambiguous assignments
- jbay808 6y agoThat 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.
- jka 6y agoHaving spent more time working on open source tools and projects recently: although yes, many codebases have limitations, there's often a rewarding escalation path towards improving the situation. * If you're unsure about the project and/or community's stance on a feature/problem, sometimes their discussion forums can help * If you have a precise problem or feature in mind -- which it sounds like you do in this case! -- finding/creating a bug for it and/or just commenting with your interest can help projects prioritize it * If you're really motivated and have the time, digging into the source and attempting an implementation; often educational even if not immediately resolvable * If you run into implementation issues (like the kernel-level concern), then GOTO 1 with the same escalation path for the design issue / dependency it relates to It can take a lot of time and effort (especially if it ends up diverging into multiple separate issues at step four), but honestly when any of this process results in an open source project fixing a bug or introducing a new feature as a result, the sense of reward is well worth it. All that said: I don't know if https://tracker.freecadweb.org/view.php?id=597 https://tracker.freecadweb.org/view.php?id=597 is the same issue, but it sounds similar and might appreciate your input :)
- jka 6y agoSelf-reply: perhaps this wasn't the most useful comment; and on reading further there is a proposed project[1] related to trying to resolve the naming issue. Hopefully the principles in the comment are reasonable, but it's definitely a tricky problem for FreeCAD to solve. [1] - https://wiki.freecadweb.org/Topological_Naming_Project https://wiki.freecadweb.org/Topological_Naming_Project
- mihaaly 6y agoI believe when one wants to use a software the incentives are not to spend time on testing or improving it but to save time on the original task at hand. Getting help from the software and not helping the software, not participating in its interest group society. For the purpose of the software - helping and carrying out tasks - lengthy digging in discussions for essential information is counter efficient.
- jka 6y ago
- thraway54321 6y agoSupposedly a lot of topology problem is fixed in realthunders fork. https://github.com/realthunder/ https://github.com/realthunder/ https://github.com/realthunder/FreeCAD_assembly3/releases https://github.com/realthunder/FreeCAD_assembly3/releases I haven't had time to look into it myself, so I can't comment how well it works, but people on other forums have suggested that it's more stable than 0.18.4 so I intend to try it out when I have some time.
- pillefitz 6y agoWhile it appeared somewhat more stable, it didn't seem to have the naming issue fixed, unfortunately.
- phkahler 6y ago>> This is a very hard problem to solve, and that's where some commercial packages shines. That is one area SolveSpace really shines too, but there is no chamfer tool - you'll have to use a boolean to subtract that chamfer.
- app4soft 6y ago> That is one area SolveSpace really shines too, but there is no chamfer tool As discussed in related SolveSpace issue thread, "chamfer" feature could be implemented in same way as "tangent arc" (aka "fillet") already implemented.[0] [0] https://github.com/solvespace/solvespace/issues/149 https://github.com/solvespace/solvespace/issues/149
- joshocar 6y agoAs someone who uses Solidworks regularly for mechanical designs this problem basically makes FreeCAD unusable in any real sense. There isn't a single model I've made that I didn't need to do something like in your example. When designing, a lot of time is spent trying to model it in such a way that one dimension change will propagate down the line so you don't have to worry about adjustments causing something like two holes to misalign. It's super easy to miss small little things that would make the whole thing not work, so you design to avoid it. Essentially, the professional programs are setup so that you make basic shapes and relations and then put in your final dimensions at the end once the conceptual design is complete.
- eggsome 6y agoI'm not a mech engineer, but it looks like SolveSpace would do this properly?