kyak changed the topic of #qi-hardware to: 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
<wpwrak> whitequark: having a bit of fun with solvespace: https://github.com/wpwrak/3dstuff/tree/master/scrnsup/
<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)
<wpwrak> whitequark: there's still no way to have a table with "global" variables, to use for dimensions and such, is there ?
<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
<wpwrak> whitequark: just drawing a line across a corner doesn't seem to make solvespace consider it a chamfer
<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 ...
wildlander has quit [Quit: Saliendo]
<whitequark> wpwrak: nope not implemented yet
<whitequark> wpwrak: as for chamfers can you show me a sketch tht doesn't work for you?
sandeepkr has joined #qi-hardware
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined #qi-hardware
<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 ?
<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.
<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
<whitequark> wpwrak: there's an issue where the constraints do not preserve chirality
<whitequark> so you can flip the sketch across discontiguities
<whitequark> this is the usual cause of such 'damage'
<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
<whitequark> oh, hm
<whitequark> you want to constrain the non-chamfered dimension, right?
<whitequark> I see why that would call for a chamfer tool...
erichvk has joined #qi-hardware
sb0 has joined #qi-hardware
dandon has joined #qi-hardware
<wpwrak> whitequark: yes, i'd want to start with the basic geometry, then refine it with fillets and chamfers
<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.
<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.
<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.
<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.
erichvk has quit [Ping timeout: 258 seconds]
sb0 has quit [Quit: Leaving]
<whitequark> this is however blocked on the new file format, as the existing one is really hostile to any kind of evolution
<whitequark> mind filing a bug about the chamfer tool?
<whitequark> wpwrak: also let me download your models...
<whitequark> wpwrak: is there a reason you've assembled your entire thing totally unhinged from origin?
<whitequark> s/assembled/drawn/
<qi-bot> whitequark meant: "wpwrak: is there a reason you've drawn your entire thing totally unhinged from origin?"
<whitequark> hehe, I forgot about this feature
<whitequark> wpwrak: this usually results in annoyance during assembly
<whitequark> wpwrak: further. why are you using so much distance constraints?
<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.
<whitequark> e.g. I would use a radius equality constraint every time you have a symmetric rounded edge
<wpwrak> ah yes, i could have used equality in a few cases
<whitequark> you're losing out on much of the parametricity
<wpwrak> though many radii are slightly different
<whitequark> is this why you wanted global parameter tables?
<wpwrak> yup :)
<whitequark> (those are also blocked on the new file format)
<whitequark> (basically everything interesting is)
<whitequark> ok, about the origin: the lack of chirality preserving constraints strikes again
<whitequark> select all, then move it about where you want it
<whitequark> then constrain it
<whitequark> I just put the top right circle center at origin and constrained it there, that worked
<whitequark> the chirality issue is really troublesome.
<whitequark> wpwrak: negative width generally flips the constraint
<wpwrak> i just get a red screen if i try that
<wpwrak> (that = center the center of the circle)
<whitequark> wpwrak: how close did you move that point near the origin first?
<whitequark> it has to be well within the circle
<wpwrak> i selected both, then constrained them to be the same
<wpwrak> ah, moving it close does indeed help ;-))
<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
<whitequark> like I said, I know how annoying it is:)
<whitequark> that's very high on my list of things to do
<wpwrak> kewl :)
<whitequark> btw I would appreciate if you went through https://github.com/solvespace/solvespace/issues and voted for the things you need
<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.
<whitequark> wpwrak: yes, I understand that, and that's why it was done only in the 3.0 branch and quite late
<whitequark> I do not expect a 3.0 stable release until the end of 2017
<whitequark> there's a lot of work to be done to justify it
<wpwrak> yes, i appreciated that i could find the version to go back to fairly easily :)
<whitequark> the benefits of gtkmm>=3.22 are rather significant as the old rendering pipeline is awful in so many ways
<whitequark> opengl immediate mode rendered to an offscreen buffer and then flipped onto the screen using X primitives
<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
<whitequark> wpwrak: that said I *thiiink* I might be able to lower the gtkmm requirement a bit
<whitequark> to 3.18 perhaps if that helps?
<whitequark> I'm not sure if it's worth the effort given how buggy early gtk3 is
<whitequark> wpwrak: hm, scratch that, gtkmm 3.22 is in stretch right now, so it will be in the next debian stable
<whitequark> I think that qualifies as widely supported enough, and I'll stay on it for rather a while then
<whitequark> scheduled for 3.0
<wpwrak> thanks ! :)
<whitequark> that should be quite easy to do, I think it could get done in a few days once I empty my merge queue
<wpwrak> gtkmm ... my ubuntu 16.10 now has 3.20.1
<whitequark> mhmm, that *is* quite recent
<whitequark> I am certain 17.04 will include 3.22+ though
* whitequark grumbles
<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
<whitequark> we use GL ES in SolveSpace exclusively because that's the least painful cross-platform solution
<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
<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
<wpwrak> meh. just defenestrate :)
<whitequark> despite the fact that we only actually use functions from the common subset of gl *2* and gl es *2*
<whitequark> nope.
<whitequark> most users of solvespace are on windows.
<whitequark> if I had to leave one platform it would be windows.
<wpwrak> sucks
* whitequark shrugs
<whitequark> it's not particularly bad?
<whitequark> actually the most frustrating platform to support was GTK without any doubt
<wpwrak> heh :)
<whitequark> anyway, now that the new rendering pipeline is in, you'll find that solvespace handles millions of triangles without much trouble
<whitequark> and lots of entities too
<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)
<whitequark> that is really not going to happen
<wpwrak> i will find that, once ubuntu has caught up with your build requirements ;-)
<wpwrak> too tight integration needed ?
<whitequark> dealing with multiprocessing on multiple platforms is nasty.
<whitequark> and I would also like to have e.g. android and webgl ports, eventually
<wpwrak> hmm, getting tricky :)
<whitequark> but I think this is an XY problem.
<whitequark> why not ask for proper multi-monitor support?
<whitequark> that's implemented on Windows.
<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.
<whitequark> I take it your issue is that the window position is not restored correctly?
<wpwrak> yes, if you can do that, why not
<whitequark> or something else?
<wpwrak> not sure if it's not harder in the end
<whitequark> oh, wait, I think I realize now
<whitequark> you don't use xrandr/xinerama?
<wpwrak> i just have 1920x1080 screens. so already the real estate is kinda tight.
<wpwrak> i just use separate screens. without things (except for the window manager itself) moving between them.
<whitequark> you have to use different DISPLAY variables, right?
<wpwrak> that prevents all sort of things from misbehaving. but the downside is that i can't just drag a window to another screen.
<wpwrak> yes
<whitequark> well, in my opinion that kind of setup is horrifying
<whitequark> but let me see if something can be done about it.
<wpwrak> works pretty well for most things :)
<whitequark> as far as I know X11 is the only relatively common platform to use this
<whitequark> ... and in general I make no effort to accomodate the specialness of X11
<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
<whitequark> that seems like purely a window manager issue
<whitequark> wpwrak: anyway, i will accept a patch that implements this functionality
<wpwrak> ;-))
<wpwrak> this one looks interesting: https://github.com/solvespace/solvespace/issues/85
<wpwrak> there is no comparable "list of items" anywhere now, right ?
<whitequark> https://developer.gnome.org/gdk3/stable/GdkDisplay.html#gdk-display-open with your "DISPLAY2" env variable and...
<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
<whitequark> since in my laptop the nvidia card isn't connected to any actual outputs
<whitequark> wpwrak: indeed
<whitequark> that *also* has to wait until the new file format :)
<whitequark> the existing file format doesn't really have any hierarchy in the assembly tree
<whitequark> wpwrak: overall, do you feel solvespace is saving your time? or is it not there yet?
<wpwrak> is there any non-hierarchical list of items ?
<whitequark> well, there's the list of imported groups
<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.
<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
<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.
<wpwrak> for the ui, perhaps the best would be a unified window as suggested in https://github.com/solvespace/solvespace/issues/39
<wpwrak> but with the possibility of having multiple viewports (in separate windows)
<wpwrak> kinda pitaish to implement, i'd guess, though
<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
<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 :)
<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.
<whitequark> wpwrak: the unified window is in my queue, in fact there is a partial implementation
<whitequark> the good news is the gtk3 migration made that much easier in some ways
<whitequark> but I'll have to rework quite a bit of the platform code to make that elegant
<whitequark> wpwrak: (dialog) well uh... you could say "no" :)
<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
<whitequark> it could give you the names of the entities that are removed but those aren't super informative
<whitequark> in general its purpose is to tell you that there were 'some' dependent entities or constraints
pcercuei has joined #qi-hardware
<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'
<wpwrak> a list of them, with the option to highlighting them would be neat
<wpwrak> of course, wildly incompatible with a modal dialog ;-)
<whitequark> nothing in that snapshot can be modified anymore. the mesh won't get regenerated, the entities won't budge
<whitequark> you can rotate it though
<whitequark> also, when you update the file you've imported and reload, the imported geometry automatically updates.
<whitequark> (highlighting) how? they're dead.
<wpwrak> i mean before deletion, while you're still trying to make up you mind about whether to say yes or no
<whitequark> that's not really how the UI is structured, solvespace never asks you if you really want to do something
<whitequark> instead it implements reliable undo
<whitequark> mhm
<whitequark> I have an idea
<wpwrak> yes, reliable undo is very good to have
<whitequark> ok, so the idea
<whitequark> the 1st time you delete something you get a screen in a text window showing dependents
<whitequark> that will highlight them as usual
<whitequark> the 2nd time you hit delete after that does the deletion
<whitequark> can you file a bug requesting for this improvement?
<whitequark> it will likely dpeend on https://github.com/solvespace/solvespace/issues/90
<wpwrak> suggested a non-modal way to do this: https://github.com/solvespace/solvespace/issues/150
sb0 has joined #qi-hardware
_whitelogger has joined #qi-hardware
<whitequark> alright
sb0 has quit [Quit: Leaving]
eintopf has quit [Quit: Lost terminal]
planasb has quit [Ping timeout: 258 seconds]
planasb has joined #qi-hardware
planasb has joined #qi-hardware
planasb has quit [Changing host]
sb0 has joined #qi-hardware
wildlander has joined #qi-hardware
infobot has quit [Ping timeout: 246 seconds]
infobot has joined #qi-hardware
pcercuei has quit [Quit: dodo]
wildlander has quit [Ping timeout: 245 seconds]
sb0 has quit [Quit: Leaving]
wildlander has joined #qi-hardware