teepee changed the topic of #openscad to: OpenSCAD - The Programmers Solid 3D CAD Modeller | This channel is logged! | Website: http://www.openscad.org/ | FAQ: https://goo.gl/pcT7y3 | Request features / report bugs: https://goo.gl/lj0JRI | Tutorial: https://bit.ly/37P6z0B | Books: https://bit.ly/3xlLcQq | FOSDEM 2020: https://bit.ly/35xZGy6 | Logs: https://bit.ly/32MfbH5
califax has quit [Remote host closed the connection]
califax has joined #openscad
J23k84 has joined #openscad
J23k has quit [Ping timeout: 245 seconds]
snaked has quit [Ping timeout: 240 seconds]
snaked has joined #openscad
LordOfBikes_ has joined #openscad
LordOfBikes has quit [Ping timeout: 255 seconds]
kintel has joined #openscad
mmu_man has quit [Ping timeout: 240 seconds]
use-value has quit [Remote host closed the connection]
use-value has joined #openscad
gunnbr has quit [Read error: Connection reset by peer]
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
derkork has joined #openscad
<derkork> Hi, I have built a node based editor for OpenSCAD which can also work with text based OpenSCAD libraries. One thing that really helps with integration is proper documentation on the various library modules and functions. So far I have not been able to find a common agreed-upon documentation format for OpenSCAD modules/functions. In other languages
<derkork> the documentation format is standardized so tools can parse and display documentation to the user (e.g. in generated documentation html or in autocomplete inside the editor). For my editor I have come up with a standardized, machine readable format that helps the editor to infer data types (when not otherwise possible)  and show documentation to
<derkork> the end user. I have documented it here: https://github.com/derkork/openscad-graph-editor/blob/master/manual/manual.md#documentation-comment-format  . My question would be if we could have this or something similar as proper "official" documentation style so that over time libraries can adopt it and tooling built around OpenSCAD can make use of
<derkork> this. I think this would also simplify the life of library developers as there could be a standardized documentation generator (right now everyone seems to use their own format and tools).
derkork has quit [Ping timeout: 245 seconds]
derkork has joined #openscad
derkork has quit [Quit: Client closed]
<Virindi> gahh. my model breaks only when I render it, with "ERROR: The given mesh is not closed! Unable to convert to CGAL_Nef_Polyhedron." The problem seems to be a 2D minkowski, there isn't even anything strange going on
<Virindi> no zfighting faces
<Virindi> I wish there was a better way to know which part of the model was causing the problem
<Virindi> rather than it just dying with a generic error
mmu_man has joined #openscad
<Virindi> it is not even easy to bisect because openscad does so much caching.
use-value has quit [Remote host closed the connection]
use-value has joined #openscad
mmu_man has quit [Ping timeout: 240 seconds]
califax has quit [Remote host closed the connection]
teepee_ has joined #openscad
tjmurphy[m] has quit [Remote host closed the connection]
teepee has quit [Ping timeout: 240 seconds]
teepee_ is now known as teepee
mmu_man has joined #openscad
<J23k84> Virindi are you using experimental features?
<J23k84> also there is an option to "flush cache"
mmu_man has quit [Ping timeout: 240 seconds]
mmu_man has joined #openscad
use-value1 has joined #openscad
use-value has quit [Ping timeout: 246 seconds]
use-value1 is now known as use-value
use-value has quit [Quit: use-value]
<pa> i think i found it, but apparently no M3.. starts from M4 :(
J23k84 has quit [Quit: Client closed]
J23k84 has joined #openscad
mmu_man has quit [Ping timeout: 246 seconds]
e2k has joined #openscad
<J23k84> pa that sounds like a bad library
J23k84 has quit [Quit: Client closed]
<pa> lol no i meant the physical nuts
J23k84 has joined #openscad
snaked has quit [Quit: Leaving]
mmu_man has joined #openscad
mmu_man has quit [Ping timeout: 240 seconds]
mmu_man has joined #openscad
califax has joined #openscad
sauce has quit [Server closed connection]
sauce has joined #openscad
mmu_man has quit [Ping timeout: 265 seconds]
<Virindi> ah, "flush caches", of course
<Virindi> the problem is that I can't get this to work no matter how I tweak it. I am not using anything experimental other than VBOs as far as I know, I tried turning on manifold and it said the part was not manifold, as I'd expect
<Virindi> ah, finally found a tweak that fixes it
<Virindi> I am doing a 2D minkowski of an object outline and a circle to add clearance to a part for 3dp, so the circle r=0.08. It seems this is too small somehow. r=0.1 doesn't work, r=0.15 does work
<Virindi> I never use minkowski, I figured I would try it this time. Guess that was a mistake.
dTal has quit [Server closed connection]
dTal has joined #openscad
<Virindi> (yes I checked, the outline polygon is a proper polygon, no overlapping lines or anything)
<Virindi> since 0.15mm is way too much, I guess I have to rewrite it to move the polygon points outwards rather than using minkowski
<lf94> Neat little thing I noticed. On smaller prints, some features "blend" into larger ones, creating very shallow bumps / lumps / curves. It's essentially the exact same effect as if I'd do a smooth blend operation.
<Virindi> rounding is a function of nozzle size, you can use a smaller nozzle :)
<lf94> Not sure why I've never noticed this before, but it's very noticeable on this print I've done - it looks *exactly* like how it did when I smooth blended the features in earlier iterations, looking at the renderings
<lf94> Virindi: no, this is a bump appearing on the opposite side of the feature
<lf94> imagine you have a cylinder, and then a thin box on top
<lf94> you'd see a bump created by the cylinder
<lf94> I think it's just gravity at work
<Virindi> with vertical features you have infill layers causing differences in the top
J23k84 has quit [Quit: Client closed]
J23k84 has joined #openscad
<lf94> ah yeah, that too
<lf94> I say gravity too though because this has no support underneath (I'm actually printing a half cylinder)
<lf94> It'd be so nice to get a bot to render some code and share the render B)
<J23k84> virindi try using offset(.1)  also  small fs or high fn can cause problems
<lf94> scadbot> difference() { cylinder(...); cube(...); }
<lf94> <scadbot> link-to-render.png
<Virindi> ah, I've never heard of offset. "requires 2015.03", wow that is too recent for me :)
<Virindi> I switched it to offset and it seems to work
<Virindi> I "learned" openscad before that version so I never even knew it existed
<InPhase> Virindi: The program has gotten sooo much better since the 2015 era.
J23k84 has quit [Quit: Client closed]
J23k84 has joined #openscad
sauce has quit []
sauce has joined #openscad
califax has quit [Remote host closed the connection]
califax has joined #openscad
<lf94> God dammit. 2mm off to get this thing to close.
<lf94> I thought cone-like pegs inside would be good too. But I need more like elongated cylinder pegs
<lf94> take up less space but still good for layer adhesion
L29Ah has left #openscad [#openscad]
<lf94> Is a cylinder with "flatter sides" just a really rounded box?
<lf94> I got like 5 hours of sleep last night and cant think straight
<lf94> I think rounded cubes and elongated cones can be really nice primitives to build strong pieces
L29Ah has joined #openscad
<InPhase> lf94: For less thinking required: https://github.com/rcolyer/smooth-prim
J23k84 has quit [Quit: Client closed]
<InPhase> lf94: I typically like to round or chamfer the ends of a part to be inserted into another for that initial insertion ease. This is usually sufficient by itself to achieve most of what a cone would have provided.
J23k84 has joined #openscad
J23k84 has quit [Client Quit]
J23k84 has joined #openscad
<InPhase> lf94: But then you still have the opportunity for a snug fit, whereas a cone will always have a tendency to separate.
<lf94> For me I'm thinking layer adhesion strength
<lf94> fat bottom / thinner top
<lf94> also: always try to avoid non-circular slices
<lf94> I dunno what Im going on about
<lf94> Im so tired
<dTal> <lf94> Is a cylinder with "flatter sides" just a really rounded box?
<dTal> that seems philosophical
<dTal> polygon([for(a =[0:128])[(2+0.1*cos(4*360*a/128))*cos(a*360/128),(2+0.1*cos(4*360*a/128))*sin(a*360/128)]]);
<lf94> Is an ellipsoid also just a variant of a really rounded box
<lf94> I guess a more robust operation would be
<gbruno> [github] t-paul closed issue #1593 (Export colors to .amf files.) https://github.com/openscad/openscad/issues/1593
<lf94> blend.intersect(cylinder(), box())
<lf94> This way you get a nice transition from the roundness of the cylinder, to the box
<lf94> er
<lf94> flat top
<lf94> which is better for 3d printing
<lf94> FDM hates curves
<lf94> rather: printing spheres
<InPhase> lf94: A nice shape approach I used before when I wanted something to not snap off, keep snug, and insert smoothly: https://bpa.st/36AI6
<lf94> supports created by 1*mm nozzle are impossible to remove
<InPhase> I hate supports. It's always an unpredictable scenario of whether they will snap off or turn a printing project into a whittling project.
<InPhase> I go to great lengths to design items and prints that won't need any supports.
<InPhase> If there's a choice to alter the item but still preserve its core functionality while removing supports, I do the alteration, pretty much every single time.
<lf94> Yes, completely agree
<lf94> maybe you can help me
<lf94> eh
<lf94> you probably dont have the time
<lf94> Im basically printing a half cylinder
<lf94> If you're actually going to clone it tell me; I'll push the latest variation of this
<lf94> (I removed a peg; the peg is supposed to stop the enclosure from moving along the wire it's on)
<lf94> (But only one is needed; two take up too much space when wrapping around)
<InPhase> I don't even know what to do with that sort of code. Do you have a rendered image?
<lf94> (pushed)
<lf94> do you have libfive installed
<lf94> if yes: you can run it easily with $ node examples/wire-enclosure.js
<lf94> i'll share the stl
<InPhase> Installed, no, although I have a copy of the repository. I also currently don't have node. :)
<lf94> I should probably commit artifacts like this
<lf94> My node-libfive bindings are slowly turning into an actual useful system
<lf94> It's just too bad I touch it once every few months
<InPhase> Okay, I have the stl up.
<lf94> The goal is to be easily able to swap out libfive for fidget (Matt's other SDF renderer)
<lf94> So I print two halves
<lf94> And combine it
<lf94> Adhesion of the two halves: solder iron along the seam
<InPhase> This is your wire bundle enclosure?
<lf94> Yeah
<lf94> "bundle"?
<lf94> It's to hide a repair job
<InPhase> Yeah, you mentioned several wires soldered.
<lf94> Ah yeah. 5 wires in 1 sheath
<InPhase> By the time you clamp them in something like this it's a "bundle". :)
<InPhase> So what's that random cone supposed to be doing?
<lf94> So wrapping the sheath around the peg takes a bunch of space
<lf94> It's to stop the enclosure from moving
<peepsalot> a capsule module is very easy to make in native openscad. dunno why you need libfive for that. you translate two spheres by the separation and hull them
<lf94> I dont need libfive for that
<lf94> I prefer js-based code cad environments
<lf94> js-based *and* desktop native.
<lf94> But I dont wanna have this conversation right now
<lf94> I really gotta figure out this enclosure - I've got just tonight to put it all together and deliver the fixed thing x)
<InPhase> So what is the design question about it, now that I see it?
<lf94> I had it done, until putting it together: it was 2mm off from closing.
<lf94> Well
<lf94> Without supports I think the middle just falls in on itself
<lf94> when printing larger
<lf94> (I increased the size from 10mm diameter to 12mm)
<lf94> Maybe I need to print faster
<lf94> 50mm/s 1mm nozzle 0.2mm height
<InPhase> Rather than a cylinder, externally rounded internally pointy hexagon, pointy end up?
<lf94> you're a geometric genius
<lf94> I think that'll work perfectly...
<lf94> well, might not leave enough room inside actually
<lf94> The stacked sheath (from being wound around the peg) is ~6mm in height
<InPhase> Well the room you design should be the actual room you get. Are there actual external constraints?
<lf94> No but it's gonna look u-g-l-y
<lf94> if it's too big
<lf94> eh, I'll try it no supports again
<lf94> i only tried this bigger variant with supports
<InPhase> Print it in black. That makes everything less ugly.
<lf94> my pla+ is only white :')
<lf94> I was gonna spray paint it after sanding
<lf94> It's such a small piece to sand, I dont mind
<lf94> 40mm in length
<lf94> It actually looks really good
<lf94> Hiding the solder job makes it look very professional
<lf94> rather than just slapping shrink tubing on it
J23k84 has quit [Quit: Client closed]
J23k84 has joined #openscad
<lf94> I also thought about just using adhesive to prevent it from moving
<lf94> But I want this to last
<lf94> The winding around the peg will 100% stop it from moving forever
<lf94> Also: I'm genuinely surprised this doesn't exist in the makerspace. I've asked around several places and seems no one has made this
mmu_man has joined #openscad
<InPhase> I think most often people just make little enclosure boxes.
<lf94> yeah but this is a headphone wire
<lf94> also I just tried it: the enclosure doesnt move at all when closed
<lf94> Maybe it's all so tight anyway
<InPhase> Well you don't need a peg in the middle to do this anyway. You could achieve it with a zig-zagged opening on both ends. You'd just want to avoid having a sharp corner there.
<lf94> you mean for it to "clamp" down on the wire right
<lf94> to me that's too precision specific
<lf94> the peg is guaranteed
<InPhase> Nope, just instead of a small cylindrical opening, an opening more like a short winding river.
<lf94> I'll improve the design another day when this becomes a problem again lol
<lf94> ah!
<lf94> I could do that internally too...
<lf94> just need enough space for the curving
<lf94> yeah I remember seeing this in a few electronics
<lf94> I could just use 2 pegs inside too right
<lf94> well placed
<InPhase> Yeah, it's the same principle really. The pegs are just a bit bulkier and probably make assembling it a tad more awkward.
<lf94> yeah but the pegs dont alter the external appearence
kintel has joined #openscad
<lf94> I'm definitely going to improve this design because I've had to fix cables way too often
<lf94> and then get some aliexpress cloner to copy it
<lf94> and create millions for cents
ali1234 has quit [Server closed connection]
ali1234 has joined #openscad
mmu_man has quit [Ping timeout: 240 seconds]
mmu_man has joined #openscad
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Guest71 has joined #openscad
Guest71 has quit [Quit: Client closed]
guso78 has joined #openscad
L29Ah has quit [Ping timeout: 240 seconds]
RoyK has quit [Server closed connection]
RoyK has joined #openscad
L29Ah has joined #openscad
J23k84 has quit [Quit: Client closed]
J23k84 has joined #openscad
J23k84 has quit [Client Quit]
guso78 has quit [Quit: Client closed]
J23k84 has joined #openscad
guso78 has joined #openscad
guso78 has quit [*.net *.split]
J23k84 has quit [*.net *.split]
guso78 has joined #openscad
snaked has joined #openscad
J23k has joined #openscad