3 ms·
Sorry but no. Well maybe you managed to put a new/old name to the problem but SDFs don't solve selecting an edge or a face or a point out of 5000.
by injidup 5y ago
Sorry but no. Well maybe you managed to put a new/old name to the problem but SDFs don't solve selecting an edge or a face or a point out of 5000.
- regularfry 5y agoNothing does. That's what I'm getting at. SDFs give you a different way of thinking about the problem to avoid having to make the selection explicitly which, when you can get away with it, solves for an interesting subset of the problem space, but there is no general solution to the problem you're describing, visual CAD or CAD-as-code. What we do have are mountains of hacks that more or less work to hide that fact. Any CAD package, code or visual, has only two ways to identify topological entities. Either you identify them from their underlying topology ("this edge is the 5th created by the intersection of objects A and B"), or you define some sort of query function over the final shape as it ends up in space, divorced from how it was created ("give me the edge that includes an arc in the XY plane radius r about point B"). Freecad does the former, from what I can see Onshape does something like the latter, but in both cases it's possible to generate a pathological feature tree which breaks under a change you want to make. How easy it is to make that breakage happen (or, conversely, how likely you are to accidentally trip over it in your day-to-day work) is controlled by how high the mountain of hacks is. It's reasonable to say that no current CAD-as-code package solves the problem today but it's not true to say that it couldn't be done. The most obvious approach you could see is where the user clicks to select an element in a rendered preview and some selector string or other gets copied to to the clipboard that they then paste into the code to use directly, just like you can get a usable selector for a DOM element in the same format as you'd write by hand out of Chrome's Dev tools. That would work with either approach, and the fact that you're using a selector string in the same format as you'd write by hand means you can edit it as code when you need to.
- injidup 5y agoThis is exactly what OnShape does. When. You click they generate two things, an id for that which is selected based on a feature path as well as the region that was clicked along with the type of object. The first works as long as the feature tree remains stable. This is only possible with a GUI selection mechanism which you acknowledge. As OnShape provides a powerful scripting system called feature script the future you imagine is already here. I wrote my own feature components for surfboard design using it.
- regularfry 5y agoIt's not only possible with a GUI selection mechanism, that's just one way to get at them. If you've got a human-readable selector, it should be human-writable as well, and there will be cases where you would want to do that. The property of only working "as long as the feature tree remains stable" is a big part of the Topological Naming Problem, and it applies to both GUI and non-GUI environments.
- injidup 5y agoI think we both agree that stability is an issue. I'm only taking issue with the 'code only' crowd who are claiming that it's just as easy to SELECT an object via code as with a mouse. It is not. In fact depending on the contextual information the GUI is able to obtain when the user clicks it is probably possible in many cases to ensure better stability than code only. Again look at how OnShape records user selection via mouse click. It not only tries to record path information but also the 3D location of the click. Thus if the path lookup fails there is a fallback. The actual recorded data is quite unwieldy but as it is computer generated this is fine. As you point out the "topological naming problem" is not guaranteed to be solvable under feature tree changes. However it can be often solved with heuristics that can be collected by an agent from analysing what the user clicked on and trying to figure out what makes that click unique. It's not 100% reliable but it is hard to do better or faster if you are hand coding a more than trivial part.
- injidup 5y agoI think we both agree that stability is an issue. I'm only taking issue with the 'code only' crowd who are claiming that it's just as easy to SELECT an object via code as with a mouse. It is not. In fact depending on the contextual information the GUI is able to obtain when the user clicks it is probably possible in many cases to ensure better stability than code only. Again look at how OnShape records user selection via mouse click. It not only tries to record path information but also the 3D location of the click. Thus if the path lookup fails there is a fallback. The actual recorded data is quite unwieldy but as it is computer generated this is fine. As you point out the "topological naming problem" is not guaranteed to be solvable under feature tree changes. However it can be often solved with heuristics that can be collected by an agent from analysing what the user clicked on and trying to figure out what makes that click unique. It's not 100% reliable but it is hard to do better or faster if you are hand coding a more than trivial part. Again I recommend you look an actual production system. https://www.onshape.com/en/resource-center/tech-tips/tech-tip-how-to-use-query-explorer-in-featurescript https://www.onshape.com/en/resource-center/tech-tips/tech-ti...