| 00:47.49 | wpwrak | whitequark: having a bit of fun with solvespace: https://github.com/wpwrak/3dstuff/tree/master/scrnsup/ |
| 00:48.55 | wpwrak | whitequark: i like the tangent arc feature. makes all these rounded corners of real-life design so much easier (even if i didn't do them perfectly) |
| 00:50.30 | wpwrak | whitequark: there's still no way to have a table with "global" variables, to use for dimensions and such, is there ? |
| 00:52.13 | wpwrak | whitequark: also, how would i do (straight-line) chamfers instead of (rounded) fillets ? it seems that i could accomplish them with "split lines", but not as nicely as tangent arcs |
| 00:55.49 | wpwrak | whitequark: just drawing a line across a corner doesn't seem to make solvespace consider it a chamfer |
| 01:29.18 | wpwrak | intersting ... chromium (resolver ?) now looks up CNAME records through /etc/hosts. and of course, i had an old name that was only used as alias "target" and that has changed in DNS but not in my local /etc/hosts ... |
| 02:33.07 | whitequark | wpwrak: nope not implemented yet |
| 02:33.31 | whitequark | wpwrak: as for chamfers can you show me a sketch tht doesn't work for you? |
| 02:55.45 | *** join/#qi-hardware sandeepkr (~Sandeepkr@103.49.155.114) |
| 05:14.19 | *** join/#qi-hardware DocScrutinizer05 (~saturn@openmoko/engineers/joerg) |
| 05:14.58 | wpwrak | whitequark: maybe i should ask what would be the best way to do chamfers. is there something like the tangent arcs ? or do i have to turn the lines leading to the corner into "construction" lines, then put together the chamfer piece by piece ? |
| 05:15.59 | wpwrak | whitequark: with the tangents (for fillets), i'm basically placing a modifier on the straight lines, without destroying them. but i don't see a comparable operation for chamfers. |
| 05:21.33 | wpwrak | hmm no, the tangent arc actually changes things, too. thought it didn't, but now i tried to delete one, and the corner it had modified was damaged |
| 09:23.54 | whitequark | wpwrak: there's an issue where the constraints do not preserve chirality |
| 09:24.11 | whitequark | so you can flip the sketch across discontiguities |
| 09:24.22 | whitequark | this is the usual cause of such 'damage' |
| 09:24.54 | whitequark | as for chamfers, no, not really, I would just sketch them by hand since you don't need as much construction geometry as for tangent arcs |
| 09:25.04 | whitequark | oh, hm |
| 09:25.12 | whitequark | you want to constrain the non-chamfered dimension, right? |
| 09:25.19 | whitequark | I see why that would call for a chamfer tool... |
| 10:30.36 | *** join/#qi-hardware erichvk (~esh@ppp118-210-206-226.lns20.adl6.internode.on.net) |
| 12:02.26 | *** join/#qi-hardware sb0 (~lekernel@201.137.253.58) |
| 12:26.54 | *** join/#qi-hardware dandon (~dandon@88.151.79.207) |
| 14:31.43 | wpwrak | whitequark: yes, i'd want to start with the basic geometry, then refine it with fillets and chamfers |
| 14:32.13 | wpwrak | like here: https://github.com/wpwrak/3dstuff/blob/master/scrnsup/scrnsup.slvs |
| 14:32.22 | wpwrak | or http://www.almesberger.net/misc/scrnsup.pdf |
| 14:33.50 | wpwrak | i first made the basic thingie without cut-out or smoothing of corners, then added the cut-out (nice and easy, since i had clearly defined edges to keep a distance from), and rounded most of the corners. |
| 14:35.47 | wpwrak | the use of the 32.0 constraint on the large diagonal at the bottom to control the width of the large vertical element is sub-optimal. i did it that way because things kept on flipping when i specified the width of that vertical element directly. but i may have been able to find a better dimension. |
| 14:37.16 | wpwrak | and yes, that problem was chirality. the left and right side of the vertical element would invert when making unrelated changes. i tried to use a negative width, but that didn't convince solvespace. |
| 14:38.59 | wpwrak | is there some way to give solvespace "hints" how to resolve such issues ? there's "show degrees of freedom", but that just gives me lots of points without too clear an idea of what to do with them. |
| 15:14.21 | whitequark | wpwrak: https://github.com/solvespace/solvespace/issues/76 |
| 15:14.36 | whitequark | this is however blocked on the new file format, as the existing one is really hostile to any kind of evolution |
| 15:14.51 | whitequark | mind filing a bug about the chamfer tool? |
| 15:18.42 | whitequark | wpwrak: also let me download your models... |
| 15:19.52 | whitequark | wpwrak: is there a reason you've assembled your entire thing totally unhinged from origin? |
| 15:20.04 | whitequark | s/assembled/drawn/ |
| 15:20.04 | qi-bot | whitequark meant: "wpwrak: is there a reason you've drawn your entire thing totally unhinged from origin?" |
| 15:20.17 | whitequark | hehe, I forgot about this feature |
| 15:20.49 | whitequark | wpwrak: this usually results in annoyance during assembly |
| 15:21.03 | whitequark | wpwrak: further. why are you using so much distance constraints? |
| 15:21.31 | wpwrak | oh, i hadn't decided on a good origin at the beginning. and when i tried to anchor it, solvespace didn't like the idea. i think it complained about conflicting constraints or such. |
| 15:21.54 | whitequark | e.g. I would use a radius equality constraint every time you have a symmetric rounded edge |
| 15:22.13 | wpwrak | ah yes, i could have used equality in a few cases |
| 15:22.25 | whitequark | you're losing out on much of the parametricity |
| 15:22.30 | wpwrak | though many radii are slightly different |
| 15:22.33 | whitequark | is this why you wanted global parameter tables? |
| 15:22.43 | wpwrak | yup :) |
| 15:22.58 | whitequark | (those are also blocked on the new file format) |
| 15:23.02 | whitequark | (basically everything interesting is) |
| 15:23.24 | whitequark | ok, about the origin: the lack of chirality preserving constraints strikes again |
| 15:23.34 | whitequark | select all, then move it about where you want it |
| 15:23.36 | whitequark | then constrain it |
| 15:23.58 | whitequark | I just put the top right circle center at origin and constrained it there, that worked |
| 15:24.06 | whitequark | the chirality issue is really troublesome. |
| 15:24.39 | whitequark | wpwrak: negative width generally flips the constraint |
| 15:24.47 | wpwrak | i just get a red screen if i try that |
| 15:24.59 | wpwrak | (that = center the center of the circle) |
| 15:25.10 | whitequark | wpwrak: how close did you move that point near the origin first? |
| 15:25.17 | whitequark | it has to be well within the circle |
| 15:25.35 | wpwrak | i selected both, then constrained them to be the same |
| 15:26.23 | wpwrak | ah, moving it close does indeed help ;-)) |
| 15:26.28 | whitequark | yes. that's not enough, because solvespace tried to move the circle way out of the rest of the sketch, inverted a few things then promptly got into a numeric instbility |
| 15:26.39 | whitequark | like I said, I know how annoying it is:) |
| 15:26.56 | whitequark | that's very high on my list of things to do |
| 15:27.06 | wpwrak | kewl :) |
| 15:27.10 | whitequark | btw I would appreciate if you went through https://github.com/solvespace/solvespace/issues and voted for the things you need |
| 15:28.46 | wpwrak | btw, with the recent requirement for gtkmm >= 3.22 (or such), you cut out even ubuntu users who update frequently. let's hope the distro moves this along soonish, too. |
| 15:29.18 | whitequark | wpwrak: yes, I understand that, and that's why it was done only in the 3.0 branch and quite late |
| 15:29.34 | whitequark | I do not expect a 3.0 stable release until the end of 2017 |
| 15:29.41 | whitequark | there's a lot of work to be done to justify it |
| 15:29.52 | wpwrak | yes, i appreciated that i could find the version to go back to fairly easily :) |
| 15:30.05 | whitequark | the benefits of gtkmm>=3.22 are rather significant as the old rendering pipeline is awful in so many ways |
| 15:30.27 | whitequark | opengl immediate mode rendered to an offscreen buffer and then flipped onto the screen using X primitives |
| 15:31.05 | whitequark | this is slow in more than one way, it has tearing, it really likes to glitch out, it doesn't play nice with compositing and doesn't work on wayland at all |
| 15:32.35 | whitequark | wpwrak: that said I *thiiink* I might be able to lower the gtkmm requirement a bit |
| 15:32.41 | whitequark | to 3.18 perhaps if that helps? |
| 15:32.55 | whitequark | I'm not sure if it's worth the effort given how buggy early gtk3 is |
| 15:33.36 | whitequark | wpwrak: hm, scratch that, gtkmm 3.22 is in stretch right now, so it will be in the next debian stable |
| 15:33.56 | whitequark | I think that qualifies as widely supported enough, and I'll stay on it for rather a while then |
| 15:35.57 | wpwrak | for chamfers: https://github.com/solvespace/solvespace/issues/149 |
| 15:36.59 | whitequark | scheduled for 3.0 |
| 15:37.08 | wpwrak | thanks ! :) |
| 15:37.21 | whitequark | that should be quite easy to do, I think it could get done in a few days once I empty my merge queue |
| 15:37.24 | wpwrak | gtkmm ... my ubuntu 16.10 now has 3.20.1 |
| 15:37.46 | whitequark | mhmm, that *is* quite recent |
| 15:38.08 | whitequark | I am certain 17.04 will include 3.22+ though |
| 15:38.16 | whitequark | grumbles |
| 15:38.52 | whitequark | gtk includes glarea for quite a while but gtkmm only exposes it since 3.18 and the function to request a GL ES context since 3.22 |
| 15:39.11 | whitequark | we use GL ES in SolveSpace exclusively because that's the least painful cross-platform solution |
| 15:39.33 | whitequark | the only sane way to get GL >1 to reliably work on Windows is to pipe it through ANGLE, which emulates GL ES 2 |
| 15:40.07 | whitequark | on Linux and macOS that involves asking for either a GL ES context or a GL core 4.0+ context due to a sequence of idiotic decisions by khronos |
| 15:40.27 | wpwrak | meh. just defenestrate :) |
| 15:40.28 | whitequark | despite the fact that we only actually use functions from the common subset of gl *2* and gl es *2* |
| 15:40.31 | whitequark | nope. |
| 15:40.37 | whitequark | most users of solvespace are on windows. |
| 15:40.45 | whitequark | if I had to leave one platform it would be windows. |
| 15:42.25 | wpwrak | sucks |
| 15:42.36 | whitequark | shrugs |
| 15:42.41 | whitequark | it's not particularly bad? |
| 15:43.00 | whitequark | actually the most frustrating platform to support was GTK without any doubt |
| 15:43.59 | wpwrak | heh :) |
| 15:45.05 | whitequark | anyway, now that the new rendering pipeline is in, you'll find that solvespace handles millions of triangles without much trouble |
| 15:45.26 | whitequark | and lots of entities too |
| 15:45.35 | wpwrak | ah, what would be nice is if the text window could be launched from a separate process. that way, one could just have it on another screen, without having to worry about how windowing system and window manager manage things. (e.g., my multihead is :0, :0.1, not one large "merged" screen) |
| 15:45.52 | whitequark | that is really not going to happen |
| 15:45.59 | wpwrak | i will find that, once ubuntu has caught up with your build requirements ;-) |
| 15:46.11 | wpwrak | too tight integration needed ? |
| 15:46.25 | whitequark | dealing with multiprocessing on multiple platforms is nasty. |
| 15:46.36 | whitequark | and I would also like to have e.g. android and webgl ports, eventually |
| 15:46.55 | wpwrak | hmm, getting tricky :) |
| 15:47.08 | whitequark | but I think this is an XY problem. |
| 15:47.16 | whitequark | why not ask for proper multi-monitor support? |
| 15:47.23 | whitequark | that's implemented on Windows. |
| 15:47.38 | wpwrak | right now, i send the text window to another virtual screen. so i can flip back and forth relatively quickly. but it would be nicer if i could have have both visible at the same time. |
| 15:47.46 | whitequark | I take it your issue is that the window position is not restored correctly? |
| 15:47.47 | wpwrak | yes, if you can do that, why not |
| 15:47.49 | whitequark | or something else? |
| 15:47.57 | wpwrak | not sure if it's not harder in the end |
| 15:48.31 | whitequark | oh, wait, I think I realize now |
| 15:48.37 | whitequark | you don't use xrandr/xinerama? |
| 15:48.38 | wpwrak | i just have 1920x1080 screens. so already the real estate is kinda tight. |
| 15:49.22 | wpwrak | i just use separate screens. without things (except for the window manager itself) moving between them. |
| 15:49.43 | whitequark | you have to use different DISPLAY variables, right? |
| 15:49.51 | wpwrak | that prevents all sort of things from misbehaving. but the downside is that i can't just drag a window to another screen. |
| 15:49.53 | wpwrak | yes |
| 15:50.14 | whitequark | well, in my opinion that kind of setup is horrifying |
| 15:50.27 | whitequark | but let me see if something can be done about it. |
| 15:50.39 | wpwrak | works pretty well for most things :) |
| 15:51.29 | whitequark | as far as I know X11 is the only relatively common platform to use this |
| 15:51.40 | whitequark | ... and in general I make no effort to accomodate the specialness of X11 |
| 15:51.44 | wpwrak | e.g., i can have my usual 4x3 array of virtual screens on each physical screen, and select them independently. also, if an application wants to go full-screen, it will never go full-all-screens |
| 15:52.15 | whitequark | that seems like purely a window manager issue |
| 15:53.09 | whitequark | wpwrak: anyway, i will accept a patch that implements this functionality |
| 15:53.17 | wpwrak | ;-)) |
| 15:53.17 | whitequark | I think you'll need to use https://developer.gnome.org/gtk3/stable/GtkWindow.html#gtk-window-set-screen and... |
| 15:53.35 | wpwrak | this one looks interesting: https://github.com/solvespace/solvespace/issues/85 |
| 15:53.48 | wpwrak | there is no comparable "list of items" anywhere now, right ? |
| 15:53.49 | whitequark | https://developer.gnome.org/gdk3/stable/GdkDisplay.html#gdk-display-open with your "DISPLAY2" env variable and... |
| 15:53.53 | whitequark | then https://developer.gnome.org/gdk3/stable/GdkDisplay.html#gdk-display-get-screen |
| 15:54.15 | whitequark | I have no idea whether this will work and I won't have a setup where I can verify that it works even any time soon, I don't think |
| 15:54.29 | whitequark | since in my laptop the nvidia card isn't connected to any actual outputs |
| 15:55.28 | whitequark | wpwrak: indeed |
| 15:55.36 | whitequark | that *also* has to wait until the new file format :) |
| 15:55.59 | whitequark | the existing file format doesn't really have any hierarchy in the assembly tree |
| 15:56.15 | whitequark | wpwrak: overall, do you feel solvespace is saving your time? or is it not there yet? |
| 15:56.29 | wpwrak | is there any non-hierarchical list of items ? |
| 15:56.49 | whitequark | well, there's the list of imported groups |
| 15:57.49 | wpwrak | this "hook" was the first design where i thought my very basic understanding of solvespace would be sufficient to get the thing done, and i wasn't disappointed. |
| 15:58.47 | wpwrak | and i especially liked how easy it was to add those pesky fillets. with my usual workflow (python-script freecad) that sort of thing is a nightmare |
| 16:00.11 | wpwrak | my biggest problem are the chirality surprises (and perhaps some other effects of under-defined sketches). especially when you don't have a clear idea from the beginning, it can get pretty messy to do a partial cleanup and try something else. |
| 16:02.36 | wpwrak | for the ui, perhaps the best would be a unified window as suggested in https://github.com/solvespace/solvespace/issues/39 |
| 16:02.53 | wpwrak | but with the possibility of having multiple viewports (in separate windows) |
| 16:03.14 | wpwrak | kinda pitaish to implement, i'd guess, though |
| 16:05.40 | wpwrak | oh, and it the dialog that tells me that deleting this will also delete a bunch of other things (usually constraints) meant to be anything more than to instill a vague feeling of fear and uncertainty ? :) i.e., at that point, some sort of way to explore what exactly if being deleted may be useful. that it, unless one is expected to accept whatever the outcome on good faith |
| 16:07.17 | wpwrak | (imported groups) yeah, i still have to wrap my head around these. once i leave the 2D plane, my understanding of solvespace gets increasingly cargo-cultish :) |
| 16:19.25 | wpwrak | my hope is that some day i'll be able to do things like the anelok case with solvespace. with freecad, i manage, but every little quirk and wrinkle i add makes the design more obscure. i.e., that scripted design process doesn't scale nicely. |
| 16:24.16 | whitequark | wpwrak: the unified window is in my queue, in fact there is a partial implementation |
| 16:24.29 | whitequark | the good news is the gtk3 migration made that much easier in some ways |
| 16:25.22 | whitequark | but I'll have to rework quite a bit of the platform code to make that elegant |
| 16:26.05 | whitequark | wpwrak: (dialog) well uh... you could say "no" :) |
| 16:26.24 | whitequark | there isn't really anything better that can be done at that point because leaving the entities in the sketch would cause a crash |
| 16:26.47 | whitequark | it could give you the names of the entities that are removed but those aren't super informative |
| 16:27.07 | whitequark | in general its purpose is to tell you that there were 'some' dependent entities or constraints |
| 16:27.30 | *** join/#qi-hardware pcercuei (~pcercuei@92.177.36.45) |
| 16:27.36 | whitequark | (imported groups) those are conceptually very simple. when you import a group you get a 'snapshot' of the geometry in that file, as a single 'thing' |
| 16:27.37 | wpwrak | a list of them, with the option to highlighting them would be neat |
| 16:27.48 | wpwrak | of course, wildly incompatible with a modal dialog ;-) |
| 16:28.06 | whitequark | nothing in that snapshot can be modified anymore. the mesh won't get regenerated, the entities won't budge |
| 16:28.14 | whitequark | you can rotate it though |
| 16:28.36 | whitequark | also, when you update the file you've imported and reload, the imported geometry automatically updates. |
| 16:28.44 | whitequark | (highlighting) how? they're dead. |
| 16:29.19 | wpwrak | i mean before deletion, while you're still trying to make up you mind about whether to say yes or no |
| 16:29.49 | whitequark | that's not really how the UI is structured, solvespace never asks you if you really want to do something |
| 16:29.56 | whitequark | instead it implements reliable undo |
| 16:30.08 | whitequark | mhm |
| 16:30.12 | whitequark | I have an idea |
| 16:30.37 | wpwrak | yes, reliable undo is very good to have |
| 16:37.31 | whitequark | ok, so the idea |
| 16:37.43 | whitequark | the 1st time you delete something you get a screen in a text window showing dependents |
| 16:37.46 | whitequark | that will highlight them as usual |
| 16:37.54 | whitequark | the 2nd time you hit delete after that does the deletion |
| 16:38.06 | whitequark | can you file a bug requesting for this improvement? |
| 16:38.24 | whitequark | it will likely dpeend on https://github.com/solvespace/solvespace/issues/90 |
| 16:48.53 | wpwrak | suggested a non-modal way to do this: https://github.com/solvespace/solvespace/issues/150 |
| 17:07.47 | *** join/#qi-hardware sb0 (~lekernel@201.137.253.58) |
| 17:12.12 | *** join/#qi-hardware _whitelogger (~whitelogg@uruz.whitequark.org) |
| 17:12.12 | *** mode/#qi-hardware [+v _whitelogger] by ChanServ |
| 17:22.14 | whitequark | alright |
| 18:55.49 | *** join/#qi-hardware planasb (~planasb@78-61-86-243.static.zebra.lt) |
| 18:55.49 | *** join/#qi-hardware planasb (~planasb@unaffiliated/planasb) |
| 19:07.57 | *** join/#qi-hardware sb0 (~lekernel@200.57.254.31) |
| 19:53.49 | *** join/#qi-hardware wildlander (~wildlande@unaffiliated/wildlander) |
| 22:04.22 | *** join/#qi-hardware infobot (ibot@rikers.org) |
| 22:04.22 | *** topic/#qi-hardware is Copyleft hardware - http://qi-hardware.com | hardware hackers join here to discuss Ben NanoNote, atben/atusb 802.15.4 wireless, anelok and other community driven hw projects | public logging at http://en.qi-hardware.com/irclogs and http://irclog.whitequark.org/qi-hardware |
| 22:04.22 | *** mode/#qi-hardware [+v infobot] by ChanServ |
| 23:52.08 | *** join/#qi-hardware wildlander (~wildlande@unaffiliated/wildlander) |