<InPhase>
teepee: So the bug was actually in Manifold instead of the OpenSCAD usage of it?
<linext>
is there a tutorial for using gradients to create beveled edges?
<linext>
someone showed me how to do a long time ago and i don't remember
J23 has quit [Quit: Client closed]
<linext>
basically you use a graphics editing program to put a gradient around the edge of the 2d shape, then it becomes a rounded 3d edge
J23 has joined #openscad
<InPhase>
All of our graphics imports are 2D.
<InPhase>
Although rotate_extrude is a real gem for getting beveled edges and such on round things.
<linext>
maybe there's a step in the middle
<linext>
such as converting the grayscale image into a height map
snaked has quit [Ping timeout: 248 seconds]
<InPhase>
That is in fact a thing, although the result is almost always completely terrible.
<InPhase>
To do that you would probably want to do something like a blur and then save it again.
<InPhase>
I do vaguely remember showing someone how to do that quite a few years back. And it will work, but it's not going to be as pretty of a result as constructing a geometry the normal way.
<linext>
i'm making thumb bars for various leatherman tools, starting with the most best selling
<linext>
so the wave, charge, surge, etc.
<linext>
they don't have clearance to fit a screw, so those have to be press fit and super glued
<InPhase>
Do you like the ridge there?
<InPhase>
(At the top.)
<InPhase>
Normally I'd work to remove that, but maybe for the purpose of a thumb bar, which is already so tiny that gives some favorable small amount of grip.
<InPhase>
The aesthetic is favorable enough with that functional form I think.
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<linext>
yes, i need a flat surface to print from
<linext>
it prints upside down
<InPhase>
Ah.
<linext>
also, i found a way to chamfer the leatherman free thumb tab
epony has quit [Remote host closed the connection]
<InPhase>
linext: Well... I'd still like to see some sort of more strenuous tests of metal fatigue and such compared to regular machined parts, but those are already some very impressive results. I can see enough to see it is certainly at least within a small factor of machined steel parts.
<InPhase>
So if there's a difference, it's small.
LordOfBikes has joined #openscad
<linext>
i wonder if i clamp a piece of printed plastic against a metal file, if it will get a knurl
J237 has joined #openscad
<linext>
i tried it, it worked somewhat
<linext>
if the metal file was more rough it might do better
<InPhase>
linext: And if you put your printed plastic in some hot water just under the threshold of too hot, you might get a better result from that clamping.
<InPhase>
linext: The right temperature could require some failures to sort out...
<InPhase>
I guess you'd have to do it fast though. The metal will cool it down quickly. Or you'd need to put the files in the water too.
<linext>
i bet i could get a nice knurl made on jlcpcb.com in stainless steel and use that to put a texture on plastic surfaces
<InPhase>
Please call it "the waffle iron".
<lf94>
32 hour day. I could get behind that.
fling has joined #openscad
srk has quit [Remote host closed the connection]
srk has joined #openscad
kintel has joined #openscad
epony has joined #openscad
epony has quit [Remote host closed the connection]
epony has joined #openscad
epony has quit [Remote host closed the connection]
johnstein has quit [Quit: Leaving]
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
fedorafan has quit [Ping timeout: 248 seconds]
fedorafan has joined #openscad
ur5us has quit [Ping timeout: 250 seconds]
ur5us has joined #openscad
drkow has joined #openscad
drfff has quit [Ping timeout: 248 seconds]
drkow has quit [Ping timeout: 252 seconds]
ur5us has quit [Ping timeout: 250 seconds]
Bocaneri has joined #openscad
Bocaneri is now known as Guest2353
ur5us has joined #openscad
Sauvin has quit [Ping timeout: 246 seconds]
teepee_ has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
guerd87 has quit [Read error: Connection reset by peer]
ur5us has quit [Ping timeout: 252 seconds]
guest29057 is now known as KimK
teepee has quit [Remote host closed the connection]
teepee has joined #openscad
ur5us has joined #openscad
castaway has joined #openscad
ur5us has quit [Ping timeout: 248 seconds]
use-value has quit [Ping timeout: 240 seconds]
linext has quit [Ping timeout: 265 seconds]
ccox has joined #openscad
ccox_ has quit [Ping timeout: 248 seconds]
J237 has quit [Quit: Client closed]
J237 has joined #openscad
<JakeSays>
so i'm making a hose adapter for my air conditioner. the adapter needs to connect a 150mm tube to a 90mm rounded rectangle tube. how would i go about defining a shape that 'morphs' from a cylinder to a rectangle?
<Scopeuk>
the easiest is probably to position a thin cylinder and a thin rectangle a distance apart and doing a hull
<J237>
you can even have chamfers if you need ↦ (chamfer=[.5,.5])
guso78 has joined #openscad
<InPhase>
Still waiting on the release of the spellbook of UB.scad incantations.
<JakeSays>
InPhase: LOL
<J237>
InPhase there are doxygen comments with some info .. and you have the "help=true" in each module - and there are examples
<J237>
i really try but open for comments and critics
J237 has quit [Quit: Client closed]
J23 has joined #openscad
<J23>
but more important is that i try to keep my modules working even if you don't know .. like chamfer is working with just a number .. or [bottom,top] or [[bottom in,out],[top in,out]]
<InPhase>
J23: Yeah. I see a sincere effort has been made. :) They still at the end of the day work like some numerical magic. :)
<J23>
same magic you use (with less math)
<InPhase>
Perhaps... But I understand my own magic...
* InPhase
starts preparing his own spellbook.
<J23>
last time i stumbled over your SDF code with functions within functions .. still not sure how that works
<InPhase>
Well, to be fair, I only understand some of my own magic.
J23 has quit [Quit: Client closed]
J23 has joined #openscad
<InPhase>
J23: I actually went back and looked at the bubble trap source code the other day. Without looking at the origin code from which I constructed it, I cannot discern how that works by inspection. It's just a mystical soup of equations that magically produce the animation result.
<J23>
lets be honest .. we write comments and docu for us self to not be clueless if we need to touch it a year later
<InPhase>
Although I was aiming for compactness rather than clarity with that bit, and it sort of evolved by a "hey, that looks neat if I tweak it like this" iterative process.
<J23>
i mean "what where you thinking" is quite a common first one when looking at old code
<InPhase>
With the closepoints related stuff I try to comply more with standardized equations in the structures, and then I can come back and figure it out again, since I have familiarity with those mathematical forms.
<InPhase>
The sdf stuff is also aligned with a standardized form, but we're going to need to write up a guide to how to think about that before other people who don't know this formulation are going to be able to make use of it.
<J23>
yeah i think every library uses some own logic and syntax of how you use it
<J23>
so you have some similar modules but they working different
<InPhase>
I must head off to work.
<J23>
ok ..
<J23>
have a nice day
kintel has joined #openscad
guerd87 has joined #openscad
fedorafan has quit [Ping timeout: 246 seconds]
fedorafan has joined #openscad
Virindi has quit [Ping timeout: 252 seconds]
<JakeSays>
J23: so i updated your lib. my old version had ~7k lines. latest has ~13k lines.
<JakeSays>
one suggestion though - git provides excellent changelog tracking.
<J23>
always growing .. what do you suggest?
<JakeSays>
J23: getting rid of the embedded changelog.
<JakeSays>
that's what git is for
<JakeSays>
other than that i dont have a problem with the size
<JakeSays>
my point was more along the lines of "wow you've been busy!" :)
<J23>
i need the changelog to see what changed (sure older can be purged) and i don't want to open git to get the info
<J23>
but i started to make new "products" in a separate lib
fedorafan has quit [Ping timeout: 240 seconds]
<JakeSays>
J23: well, it's totally not a big deal. i can handle the change log.
<J23>
and to use git i would need to commit every change - but some changes are just testing or "alpha" .. so i try to ensure the uploaded version is at least tested a little bit
fedorafan has joined #openscad
<J23>
but i should remove the old stuff at the bottom Ü
<JakeSays>
J23: lol i will say you definitely know your shit.
<J23>
thanks .. some older modules are bit crappy and creepy
<lf94>
InPhase: teepee: what would be a blocker for getting Python in
<lf94>
I think this makes it further accessible
<lf94>
Maybe lock it behind a setting if there's concern about malicious scripts?
<lf94>
[ ] Enable Python support
<lf94>
or, erm, suppert -> interpreter
<guso78>
lf94 we have 4 different locks in series if i remember correctly ...
<lf94>
guso78: would it be difficult to get a nodejs interpreter working?
<guso78>
lf94 i dont think so, the infrastructure is almost layed down.
<lf94>
I like this idea of being able to turn on / off different interpreters
<guso78>
biggest task is to link in the interpreter and create all the bindings, and its many ...
<lf94>
I've done 100+ bindings by hand, I'm used to it now
<lf94>
(for libfive :D)
<guso78>
in python each function was about 5-10 lines of code
fedorafan has quit [Ping timeout: 260 seconds]
fedorafan has joined #openscad
<Scopeuk>
the only issue with "bolt on another" with interpreters is that they need maintenance and every new path through the system adds yet another set of cracks and bugs. the project isn't exactly over flowing with resource to chase every avenue. I do ratehr like the simplicity and cleanlines of open scad designs but I fully accept otehrs find it
<Scopeuk>
limiting
<guso78>
Scopeuk, true. but in case of python the only "real" change was in between python2 and python3 and overall all, they are at most meant to be extensions for the always stable/working openscad language
<guso78>
if we find out real changes in usage between the version we can detect the versions and act correctly depending on them. I believe the benefit of having additional languages is greater than the impact of have to add another version check here and then ..
guso7870 has joined #openscad
guso787 has joined #openscad
guso78 has quit [Ping timeout: 260 seconds]
castaway has quit [Ping timeout: 240 seconds]
guso7870 has quit [Quit: Client closed]
<InPhase>
lf94: I don't consider it sufficient to lock it behind a setting given the existing expected behavior of OpenSCAD. The significant risk I am concerned about is Python files hidden inside libraries or designs which do malicious things, and where people have no realization that they are Python files and not just normal scad files. Remember the most vulnerable OS out there also has all the file
<InPhase>
extensions hidden by default. I therefore think Python files should require explicit approval the first time each one is run, or for each set in a run (i.e., approve all).
<InPhase>
lf94: We cannot just put a checkbox, because people will just follow some instruction for "enable this to use my design!" and then suddenly be completely vulnerable, with no conceptualization of what they have done to themselves.
<InPhase>
lf94: An explicit approval for the first run of each thing forces the question, "Do I trust where I got this?"
<InPhase>
For the command line, an enable python flag would be sufficient.
<guso787>
InPhase, this enable-python command line option is also required when "wanting" to run python code in gui mode.
<InPhase>
guso787: That would go away with a suitable warning system.
<InPhase>
guso787: We traditionally have zero command line flags affecting gui mode.
<guso787>
Sorry, we dont have this yet, this is why its still there. do you have any template code for displaying such warning window in the gui ?
<InPhase>
Must be something similar. Let's see.
<guso787>
i think such thing was not required before, so there is no template code.
<guso787>
but overall its qt
<InPhase>
It'd probably fit trivially into one of the standard Qt message boxes. Just looking for a good example.
<guso787>
i did qt in the past. i could look into it and could add this "Feature" in an extra PR
<guso787>
InPhase latest PR brings Python into openscad. just none of the functionalities would be available yet
<guso787>
InPhase are you an authorized openscad member ?
<InPhase>
guso787: Or maybe QMessageBox::warning would be better. The difference is mostly just the default icon.
<InPhase>
It looks like there are three examples of calling QMessageBox::warning in MainWindow.cc
<guso787>
Inphase, would you like to raise this messagebox once for each new appearance of openscad instance/python script ?
<InPhase>
guso787: And yeah, I'm a project member on github, if that's what you mean.
<guso787>
Inphase, somehow i also managed to be an member of "openscad organization" . question is if you are an authorized member ?
<InPhase>
guso787: You'll have to define what you mean by "authorized member".
<InPhase>
guso787: As for "each", I think there are two behaviors required for it to be a pleasant experience. One is that the options on the box should be QMessageBox::YesAll, QMessageBox::Yes, QMessageBox::No, defaulting with cursor over No. The YesAll will make it auto-approve all of the python files for that preview or render.
<guso787>
InPhase of course, my bad ..... is it also your daily duty to approve PR's in github or rather others ....
<InPhase>
guso787: The second behavior is that each approved python file should have its hash saved, so that it isn't asked about a second time.
<InPhase>
I do at times approve PRs, but it is not a daily activity for me.
<guso787>
InPhase, I like the concept . lets implement it ASAP
<InPhase>
But at the very least the approve button works, and I'm allowed to do it. :)
buZz has quit [Ping timeout: 276 seconds]
teepee_ has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
<guso787>
maybe i get time during the weekend to look into the QMessageBox topic
<InPhase>
guso787: The Qt website says QMessageBox::warning and the YesAll and such are all deprecated, but just go ahead and use them. We have that all over the codebase.
<InPhase>
guso787: They break too much stuff, and at some point it will require a large scale effort to upgrade Qt past a certain point.
buZz has joined #openscad
buZz is now known as Guest4105
Guest4105 is now known as buZz
<joseph_>
I often need to add my own "epsilon" of 0.01mm to dimensions in order to prevent z-fighting when there's a cut. (I've sometimes seen others call it "tolerance" instead, but that can get confusing if I'm printing parts that fit together.) Anyway, has there ever been discussion of a feature to do this automatically?
<InPhase>
It has been discussed frequently, but it's mathematically impossible.
<InPhase>
It feels possible because it's obvious in the simple cases. But it is in the general case impossible.
<InPhase>
Hence it is not a tolerance, but labeled in the manual as "the overlap rule".
<InPhase>
(I made up the name, in an effort to get people to stop thinking it could be automated away.)
<InPhase>
I can tell you how the conversation goes. Eventually after hearing why it is "hard" due to the fundamental nature of floating points and irrational numbers, someone cleverly proposes that there should just be a threshold of very small size below which features are removed reliably. And then they learn in response that all this does is migrate the problem to a different distance scale, at which point
<InPhase>
it is the same issue.
<InPhase>
And then there is some back and forth about how to address the balance of issues most commonly faced. But ultimately what it does if you shift it like that, is make it MUCH less obvious where it is actually going to be a problem.
<InPhase>
And then at the end of it all, we end up back at the overlap rule. :)
<InPhase>
And the reason this problem cannot be made less obvious, is because it's not a matter of z-fighting in the display. The core problem is that failing to satisfy the overlap rule will often result in rendered objects which are not actually manifold.
<InPhase>
The z-fighting in the display is more of a convenient early warning sign that you're setting yourself up for non-manifold problems. It would be even better if we could guarantee z-fighting happened all the time, or make it like bright pink or something. :)
linext has joined #openscad
<linext>
this might make a good tutorial on how to make rounded edges on 2d shapes