glen/dyna3
1
0
Fork 0
Code Issues 8 Pull Requests 2 Actions Projects Releases 2 Wiki Activity

Update User Stories

Glen Whitney 2024-07-12 23:53:37 +00:00
parent e4164945de
commit c1dc99e90e
1 changed files with 16 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
User-Stories.md

@ -26,4 +26,19 @@ the following constraints are incompatible
c00c-points-coincident
c00d-angle
```
This was just kind of astonishing, since (a) without the c00d-angle constraint, SolveSpace reported that the copy box had three degrees of freedom, which seems like they must correspond to the orientation of that box as a whole, so it's unclear why it can't just use one of those degrees of freedom to ensure the angle I specified; and (b) if I just make two line segments and make each the same length and then make two endpoints coincide and then constrain their angle to 108°, SolveSpace has no problem. So maybe there is something just superficially wrong with the boxes; but (i) I am not sure nor have the time how we might debug that, and (ii) if not, then clearly the tactic of "just skin SolveSpace" seems totally dead, in that at the point where things went awry, it still seemed like just a "toy" problem. Kind of a pity because I do really need to know the answers here, and I was hoping SolveSpace was going to find them for me!
This was just kind of astonishing, since (a) without the c00d-angle constraint, SolveSpace reported that the copy box had three degrees of freedom, which seems like they must correspond to the orientation of that box as a whole, so it's unclear why it can't just use one of those degrees of freedom to ensure the angle I specified; and (b) if I just make two line segments and make each the same length and then make two endpoints coincide and then constrain their angle to 108°, SolveSpace has no problem. So maybe there is something just superficially wrong with the boxes; but (i) I am not sure nor have the time how we might debug that, and (ii) if not, then clearly the tactic of "just skin SolveSpace" seems totally dead, in that at the point where things went awry, it still seemed like just a "toy" problem. Kind of a pity because I do really need to know the answers here, and I was hoping SolveSpace was going to find them for me!
- But I did get a nice response from a SolveSpace maintainer pointing me to the "Link/Assembly" method of combining copies of objects, so I switched to that. Unfortunately, it reported unsolvable constraints in exactly the same place. I think there is a lot of clue about what is going on in the [following SolveSpace forum entry](https://solvespace.com/forum.pl?action=viewthread&parent=1238&tt=1638401711) in which a user was simply trying to construct a truncated icosahedron from hexagon and pentagon units (very similar to this use case!) and was running into very similar problems. The following passage is particularly alarming:
> For example, two point-on-point constraints will always overconstrain, because they're either redundant (if the distances between the point pairs are equal) or inconsistent (otherwise). Take a look at the assembly tutorial for examples of sets of constraints that exactly constrain a part in an assembly.
> whitequark et al. have a development version in which you can permit overconstraints if they're redundant but not inconsistent. If you don't want to think about how many degrees of freedom you're constraining, that might help.
> Also note that groups are solved in order, with geometry in earlier groups locked down by the time a later group is solved. In your step 6, it looks like you're constraining in a way that would require two parts to move, which won't work.
I think it will be hopeless to assemble the aaaD without a step in which multiple boxes need to move in concert. And it has some warning and maybe some hope for Dyna3:
* Warning: the authors of SolveSpace seemed to feel the need to solve in pretty bite-size chunks at a time. Is that because doing more global constraint satisfaction was impractical?
* Hope: maybe it's not a limitation of the underlying engine but more of the way that the current SolveSpace UI is using that engine, chopping it up into small pieces that are successively locked down. Perhaps if we fed the same data into SolveSpace in a different way, chunking it a bit less fine (i.e., merging elements from different boxes in a single solver call), we would get a global solution.
- Ok, so at this point I backed off to making the smallest construction I could think of that would have enough in it that it would simultaneously solve into a non-planar configuration that should be tightly constrained enough to produce elements that will assemble rigidly into the full solution, placing each additional copy one at a time. I hit on six rectangles, surrounding two equilateral triangle faces, with two adjacent far sides of rectangles that will form regular pentagons constrained to be at 108°. That seems to curl up properly and I think it is fully constrained and will assemble into the desired unit. I should mention, though, that the first time that I built it, it folded "incorrectly" (like bad protein folding!) in that one part was convex one way and the other part was convex the other way, so overall it was not a portion of a convex solid. The only way I could find to get out of this rut was to delete some of the line segments, sort of push around the remaining elements to be closer to what I knew the solution should look like, and then put back in and re-constrain those deleted line segments. This second time I got lucky that it snapped into the desired configuration.
- The next step is to extrude the boxes from the six rectangular faces of the assembly, but so far I have not found a way to get solvespace to realize that they are extrudable rectangles. I can create a new workplane from two adjacent edges and a vertex, but then if I select all of the edges and vertices and hit extrude, only that one original vertex extrudes to make a line, not the whole rectangle to make a solid. Not sure if this is due to numerical issues leading solvespace not to think that the whole rectangle really lies in the workplane, or if there's just something I don't know about bringing elements into a workplane or something.