00:27 <GitHub> [solvespace] wpwrak opened issue #186: slightly shifting an assembly causes excessive computation https://github.com/solvespace/solvespace/issues/186

03:10 <GitHub> [solvespace] Evil-Spirit commented on issue #178: @kellpossible, Yes, this is how this problem solved in other CADs - compute approximation numerically and try to interpolate it using bezier curves. https://github.com/solvespace/solvespace/issues/178#issuecomment-277153514

03:30 <wpwrak> 285 minutes ... i guess the result will be 42 :)

08:48 <GitHub> [solvespace] Evil-Spirit commented on issue #186: @wpwrak, Can you try with this: https://github.com/Evil-Spirit/solvespace-master/commit/a5ffd9d182360e1be904aa35e2f9eb331783b211 https://github.com/Evil-Spirit/solvespace-master/commit/9cf1a09bcdaa5a2bc99400d368dc1a8f43996e1d https://github.com/solvespace/solvespace/issues/186#issuecomment-277194816

08:51 <GitHub> [solvespace] Evil-Spirit commented on issue #186: @wpwrak, oh, sorry, you already try it... https://github.com/solvespace/solvespace/issues/186#issuecomment-277195507

08:53 <GitHub> [solvespace] Evil-Spirit commented on issue #186: @wpwrak, you can also try to switch off edges completely. This can improve performance. https://github.com/solvespace/solvespace/issues/186#issuecomment-277195768

08:59 <GitHub> [solvespace] whitequark commented on issue #186: @Evil-Spirit this is nonsense, edges should not get generated for 285 minutes. https://github.com/solvespace/solvespace/issues/186#issuecomment-277196916

10:57 <GitHub> [solvespace] wpwrak commented on issue #186: I stopped it at 704 CPU-minutes. Virtual size has been growing at about 12 kB/s over the last nine hours.... https://github.com/solvespace/solvespace/issues/186#issuecomment-277220327

10:59 <GitHub> [solvespace] whitequark commented on issue #186: @wpwrak please never post bare backtraces like this bare in github. Either surround them with ``` ``` or add a hastebin link. When you post a comment containing #1, #2, ..., GitHub back-links these issues to the current one, which is just annoying noise.... https://github.com/solvespace/solvespace/issues/186#issuecomment-277220677

10:59 <GitHub> [solvespace] whitequark commented on issue #186: I stopped it at 704 CPU-minutes. Virtual size has been growing at about 12 kB/s over the last nine hours.... https://github.com/solvespace/solvespace/issues/186#issuecomment-277220327

10:59 <Guest3233> [solvespace] whitequark commented on issue #186: @wpwrak please never post bare backtraces like this bare in github. Either surround them with ``` ``` or add a hastebin link. When you post a comment containing #1, #2, ..., GitHub back-links these issues to the current one, which is just annoying noise.... https://github.com/solvespace/solvespace/issues/186#issuecomment-277220677

14:02 <GitHub> [solvespace] Evil-Spirit commented on issue #186: @whitequark, this is because of SnapToMesh. This function performs edges splitting by vetices (this is probably for correct working of MakeCertainEdgesInto and so on). So, this function somehow perform extra subdivision and probably goes into infinite loop or just getting some big number of triangles and just calculate it very long time. Each group increases the triangles count.... https://githu

14:05 <GitHub> [solvespace] Evil-Spirit commented on issue #186: @whitequark, this is because of SnapToMesh. This function performs edges splitting by vetices (this is probably for correct working of MakeCertainEdgesInto and so on). So, this function somehow perform extra subdivision and probably goes into infinite loop or just getting some big number of triangles and just calculate it very long time. Each group increases the triangles count.... https://githu

14:07 <GitHub> [solvespace] whitequark commented on issue #186: @evil-spirit thanks. What is the root cause of that? https://github.com/solvespace/solvespace/issues/186#issuecomment-277254358

14:09 <GitHub> [solvespace] Evil-Spirit commented on issue #186: @whitequark, I don't know at the moment, but I am going to export mesh for each group and look at this in some 3d editor to figure out what's went wrong way. https://github.com/solvespace/solvespace/issues/186#issuecomment-277254844

15:01 <GitHub> [solvespace] wpwrak commented on issue #186: @whitequark: I see what you mean (stack trace). Sorry about that.... https://github.com/solvespace/solvespace/issues/186#issuecomment-277268647

15:13 <wpwrak> hmm. "regenerate all" before the change, change (1.50 -> 1.25), "regenerate all" after, works, but then activating a "late" group still goes busy :(

15:59 <whitequark> wpwrak: what?

16:08 <wpwrak> i tried to see if i could "help" solvespace by manually asking for "regenerate all", i.e., immediately before and after the distance change that then triggers the endless computation. but that didn't work.

16:08 <whitequark> naw, of course not

16:08 <whitequark> you need to recompute the mesh

16:08 <wpwrak> so "regenerate all" doesn't do that ?

16:09 <whitequark> not for inactive groups

16:09 <wpwrak> and yes, "rebuilding the mesh from basics" was what i was looking for

22:42 <wpwrak> hmm, if i print "g" in SolveSpace::SolveSpaceUI::GenerateAll, i get the same group name ("tr-boss") for different values of "g". normal/irrelevant ?

22:44 <wpwrak> (different values of "g") that is, with a difference of ~8 hours between the reading of "g"

23:46 <wpwrak> tried to delete the tr-* groups first. in these, i had used translating, for the first time. but that didn't help either.