04:02 <GitHub> [solvespace] Evil-Spirit commented on issue #199: @jwesthues, Then it is ok, because pt-on-line work using:... https://github.com/solvespace/solvespace/issues/199#issuecomment-279601986

04:29 <GitHub> [solvespace] jwesthues commented on issue #199: Seems complicated. You can just use the same one equation as projected point-line-distance, with distance of zero. https://github.com/solvespace/solvespace/issues/199#issuecomment-279605111

04:55 <GitHub> [solvespace] Evil-Spirit commented on issue #199: @jwesthues, Then we will loose the direct parameter t and we can't do some ability to fix it (0.5=midpoint, any other cases also can be useful). This can be very useful when we are implement inequality (ranged constraints e.g. https://www.youtube.com/watch?v=u4dQ-eBAXx0). https://github.com/solvespace/solvespace/issues/199#issuecomment-279608238

05:16 <GitHub> [solvespace] jwesthues commented on issue #199: If you need t later, then you can calculate it from the point and line's endpoints. You need the extra parameter to write continuous equations for "parallel" or "point-on-line" in 3d, but not in 2d. https://github.com/solvespace/solvespace/issues/199#issuecomment-279610574

05:58 <wpwrak> hmm.. i'm getting good at producing naked edges :( so far, it seems that none of them are actually for real. maybe slvs could just feed the whole 3d stuff to opencascade for clean meshes :) oce seems to be pretty good at figuring out when coincident things are really the same and when not

06:08 <whitequark> we've considered and disregarded oce long ago

06:10 <wpwrak> guess it's a bit on the heavy side

06:10 <wpwrak> but the math seems to be pretty solid. never had issues with oce-based critters.

06:11 <wpwrak> well, let's hope this things can be fixed in slvs, too ...

06:11 <whitequark> among other things there's the license difficulties

06:11 <whitequark> and the code quality is atrocious.

06:12 <whitequark> it does work, but at what cost?

06:12 <whitequark> anyway. I certainly hope our backend can be improved

06:15 <wpwrak> the universal solution seems to be to force a mesh. that has so far solved all issues. or at least hid them well enough.

06:16 <whitequark> yes. but meshes suck.

06:16 <wpwrak> but each time i force a mesh, i'm one step farther away from being able to batch-generate my prints. i now have a lot of parts, and it would be really useful if i could say "make" and get first the stls, and then the gcode, without manual intervention.

06:18 <whitequark> yes.

06:20 <GitHub> [solvespace] whitequark opened issue #203: undefined behavior in solvespace-cli https://github.com/solvespace/solvespace/issues/203

06:34 <GitHub> [solvespace] Evil-Spirit commented on issue #199: Now this is already introduced, so there is no any reasonable argument to remove it and then back again. Complicated equations is not problem. Equations can look like complicated and can work good because they produce perfect derivatives(but ugly equations), but also it can be simple and produce simple and fast derivatives but can cause serious issues when trying to converge (increase number of newt

06:45 <GitHub> [solvespace] Evil-Spirit commented on issue #199: @jwesthues, I also have some theroy about "transformation of dof": when we are constraining some of the dof, we have to express it directly by defining the new parameter. So, every time we take off some dof, we should introduce new parameters which directly express the resulting dofs and link them by equations with involved old parameters. https://github.com/solvespace/solvespace/issues/199#iss

06:46 <GitHub> [solvespace] Evil-Spirit commented on issue #199: @jwesthues, I also have some theroy about "transformation of dof": when we are constraining some of the dof, we have to express it directly by defining the new parameter. So, every time we take off some dof, we should introduce new parameters which directly express the resulting dofs and link them by equations with involved old parameters. https://github.com/solvespace/solvespace/issues/199#iss

07:15 <GitHub> [solvespace] whitequark commented on issue #199: > Now this is already introduced, so there is no any reasonable argument to remove it and then back again.... https://github.com/solvespace/solvespace/issues/199#issuecomment-279626482

08:06 <GitHub> [solvespace] Evil-Spirit commented on issue #199: @whitequark, We haven't break anything when equations was rewritten to use parameter, isn't it? For one more checkbox inside textwindow for pt-on-line we can allow showing value label and fixing param to specified value. https://github.com/solvespace/solvespace/issues/199#issuecomment-279634779

08:07 <Guest39041> [solvespace] Evil-Spirit commented on issue #199: @whitequark, We haven't break anything when equations was rewritten to use parameter, isn't it? For one more checkbox inside textwindow for pt-on-line we can allow showing value label and fixing param to specified value. https://github.com/solvespace/solvespace/issues/199#issuecomment-279634779

15:22 <GitHub> [solvespace] jwesthues commented on issue #199: This shouldn't affect backwards compatibility either way. It's a question of speed and stability.... https://github.com/solvespace/solvespace/issues/199#issuecomment-279736925