<J24k63>
teepee probably wouldn't happen without the jst
<teepee>
I don't think there's a general spec or recommendation for simple 2 pin connectors. There's not even one for barrel connectors where center and shell is pretty distinctive.
<teepee>
that's what I mean, there's even center positive and center negative power jacks even though center positive is clearly the one used more often
<teepee>
on the good note, the usb hub has cut power quick enough to prevent the magic smoke coming out of any of the components, esp32, touch controllers and ws2812 leds
<teepee>
both displays are working :)
Guest49 has joined #openscad
Guest49 has quit [Write error: Connection reset by peer]
L29Ah has left #openscad [#openscad]
L29Ah has joined #openscad
teepee_ has joined #openscad
teepee has quit [Ping timeout: 264 seconds]
teepee_ is now known as teepee
<InPhase>
teepee: Heh. I spent part of Christmas, and part of New Years, fixing up the LED lights under my parents' kitchen cabinets, which were electrician installed in such a way that only some of the units were replaceable by using the connectors. But then made worse because the manufacturer arbitrarily changed the connectors, meaning the parts couldn't even be swapped out. So I was there guessing at
<InPhase>
polarities while trying to rig up custom connections for these replacements, because the new replacement units can't even be opened up anymore non-destructively and have been factory sealed.
<InPhase>
teepee: It really raised my consciousness of how absolutely stupid it is that we have no standardized connectors for LED lighting. It's becoming an epidemic level problem that manufacturers treat LED lights like they will last forever, and then make them so poorly that a lot go out within 1-2 years. And then they're installed in such a way that it takes non-consumer-level skills to replace the units.
<InPhase>
For close to a century we had standardized bulb sockets trivial to replace. Now changing a bulb is morphing into a "call an electrician" problem if you aren't super careful about what lights you get installed.
<teepee>
yeah, I think quite a number of the closed lighting stuff is totally overdriven causing it to fail in short time
<InPhase>
teepee: Fortunately I discovered the empirical way that at least you can plug the LED units I was working with in with opposite polarity and they do not break.
<teepee>
24V lighting ftw
<teepee>
unlikely to happen though
<teepee>
but it's a more general problem, like kitchen built-in microwave - same - no standards
<InPhase>
I see merit to a household DC wiring standard. But please standardized connectors that are suitable for use in low profile enclosures.
<teepee>
the one in my mothers home broke some time ago, replacement 500€
<InPhase>
Well microwaves tend to last 10-20 years typically, at least.
<teepee>
now she has a 90€ one sitting on the table wasting the place with the broken one still there just taped shut
<InPhase>
But over half of these under cabinet LED units had to be replaced within 2 years, and under reasonably light use.
<InPhase>
And it was $200 when they called in an electrician to replace the first two that went out.
<InPhase>
That's like $100 each to change a lightbulb!
<teepee>
at least it was not AI lighting that was only licensed so you did not pay monthly fee regardless of use ;)
<InPhase>
I went and replaced 3 more. One more was out but I couldn't replace it as I didn't have the right crimp connector replacements to handle the part the electrician did extra custom.
<InPhase>
So the last one was postponed.
<InPhase>
Well yes, that would be worse. :)
<teepee>
baby step with usb-c in EU now, lets see if that works
J24k32 has joined #openscad
<InPhase>
I think USB-C would probably be overkill for a DC standard, but maybe that's prevalent enough and low enough in component cost that it's the way to go. The need for the negotiation circuitry seems excessive though.
<InPhase>
Had the under counter lights been USB-C connector type power delivery, this would have been light work.
<teepee>
if you'd have a low voltage bus everywhere in the house it might not be that bad of a compromise
J24k63 has quit [Ping timeout: 240 seconds]
<InPhase>
The existing setup had wires running from the light switch to a cable running from the wall udner the cabinet to a custom connector that the manufacturer arbitrarily changed as the starting point. Running the light switch to a USB-C plug under the cabinet would decouple the electrician work from the user level stuff really well.
<teepee>
yep, I mean, we can drive and charge notebooks with usb-c easily. that does not leave all that much stuff for the high voltage connections
mmu_man has quit [Ping timeout: 252 seconds]
<InPhase>
The 450 lumen LED units I was working with were spec'd at 3W, so a non-PD usb-C connector would be able to run 5, which would be plenty for under a normal stretch of cabinets like I was dealing with. One USB-C unit per cabinet, all connected to the same light switch by runs through the wall, would be perfect.
<InPhase>
Although nothing prevents using PD and getting 100W or 240W for larger installation needs.
<InPhase>
A USB-C PD brick is like $15 now. This sort of expense would add nothing to the cost of the associated electrical work.
<InPhase>
Skipping even a single revisit by an electrician would pay for it several times over.
<phryk>
openscad in freebsd is now apparently new enough to have measurement tools and switching to the new manifold renderer worked fine. pleasantly surprised that it honors colors, even alpha – tho not true transparency.
<InPhase>
phryk: Sounds like they're following nightly builds.
<phryk>
InPhase: Ah, I got openscad-devel installed, that's probably it. :)
<InPhase>
phryk: Which is honestly a fair choice. We're definitely due for a new stable with all these impressive changes.
<phryk>
alpha has some weird effect with the triangulation tho.
<phryk>
this doesn't break technically things for me, just seems like something you might want to know.
<phryk>
technically break*
<InPhase>
Is anything actually wrong there?
<InPhase>
Depending on how those components are actually connected up to that baseline, that might be the only correct tessellation.
<phryk>
oh, no, the tesselation isn't the problem. just the color of the grey box should be uniform.
<InPhase>
Is that preview or render?
<phryk>
render.
<InPhase>
Does it look uniform in the stable release?
guerd has joined #openscad
<phryk>
huh, i'm actually getting a similar effect in preview if i disable "Show Edges", but if this shows up along triangulation edges, then the preview uses a different one than the full render.
<phryk>
let me test, hopefully the normal openscad package is the stable release. :P
<phryk>
huh. i assume "2024.12.30" is not the stable release?
<InPhase>
If it's a behavioral regression, the next question would be if you can comment out like 95% of that design and have something with like three cubes, maybe a blue, a black, and a transparent grey left, and still get the issue.
<InPhase>
Stable is 2021.01
<InPhase>
2024.12.30 is a nightly build. :)
<InPhase>
And not very many nights ago, even if it is from last year.
<phryk>
aye. manual build didn't work for me last i checked (which was after 2021)
<phryk>
yeah, it doesn't find some of the dependencies (cgal, bison), even tho they are there.
<phryk>
both with a major version upgrade tho – cgal >= 4.9 required, have 5.5, bison >= 2.4 required, have 3.8.
<phryk>
qscintilla also failed to be recognized, but there's a '#' in front of the line, so I'm not sure whether that matters. also two "eval: -query: not found".
<phryk>
(talking check-dependencies.sh)
<phryk>
i'
<phryk>
ll hopefully write a minimal example demonstrating the issue tomorrow (or rather, later today, given that it's 5am). sharing that is probably simpler than figuring out random build issues and possible dependencies on library versions not available through packages anymore.
Virindi has quit [Ping timeout: 265 seconds]
<InPhase>
Building is typically not hard, but the number of people testing building regularly on freebsd is probably not large. Some interested freebsd user contributing to the build scripts a variant that works for freebsd would probably fix that gap up real quick.
<InPhase>
That check-dependencies has some platform specific stuff in it, which might just slip into not working on a platform nobody has been testing regularly on.
<InPhase>
phryk: Well that looks like something that could be upstreamed with a conditional platform check.
<InPhase>
Although it is not the proper structure for cmake file contents. Hard-coded absolute paths are contrary to the expected way of writing cmake files.
<InPhase>
The platform should be providing a way to access this information with the portable tools.
<phryk>
I'm pretty clueless about binary build systems. You mean something like pkg-config metadata?
<InPhase>
Yeah. Or system cmake files.
<phryk>
I have no idea what those are and where they would be coming from. ^^;
* InPhase
nods.
<InPhase>
Then probably a role for someone else later, unless you want to do some digging.
Non-ICE has quit [Read error: Connection reset by peer]
Guest35 has joined #openscad
Guest35 has quit [Client Quit]
guerd has quit [Read error: Connection reset by peer]
<phryk>
InPhase: I think I want to do some sleeping, it's 9am and I'm still awake 😂😭
lcdk has joined #openscad
Virindi has joined #openscad
<J24k32>
teepee can't believe after color 3mf exports works nicely - printables has deactivated colors for in 3d viewer ..
mmu_man has joined #openscad
Guest1 has joined #openscad
Guest1 has quit [Client Quit]
Smeef has quit [Read error: Connection reset by peer]
Smeef has joined #openscad
ccox_ has joined #openscad
ccox has quit [Ping timeout: 244 seconds]
mtm has quit [Ping timeout: 252 seconds]
mtm has joined #openscad
<InPhase>
J24k32: I guess Prusa would need better multicolor printer options for sale for that to make sense for them?
greenbigfrog has quit [Ping timeout: 276 seconds]
<J24k32>
they do have the MMU and even have the XL with 5 nozzles
<J24k32>
hm seems to be only discarding colors on some models .. some still have them and others only have the colored preview
<InPhase>
Does it correspond to how prusa slicer expects multicolor input to be structured?
<InPhase>
And yeah, I've seen before that they have some multicolored options, but if you roam around their shop looking for multicolor printer options, it doesn't seem to be prominently featured and is not easy to find. Either they're bad at marketing this, or they don't want to push these options, perhaps because they are not ones with high customer satisfaction. (I don't know what else to think when a
<InPhase>
company obscures their most "advanced" options being for sale.)
<J24k32>
this may be interesting ( teepee ) I recolored only one color (with 3d builder) and this give a colored preview but not in 3D view
<J24k32>
then i recolored all colors which give a colored view in 3D too
<J24k32>
and when using materials not colors it doesn't give a colored preview
<guso78k>
it appears, that build123d can also display as openscad in windows now ...
<J24k32>
InPhase while others printer (not just bambu) have these filament spool changer .. Prusa only changes filaments without spool rewinding or management
<guso78k>
Inphase, this has clear advantages! Printing Wax-Like filament becomes possible without spool management(lost-wax-casting)
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
snaked has quit [Quit: Leaving]
Non-ICE has joined #openscad
<InPhase>
kintel: If the triangles are in random order, and we're getting randomized color streaks, maybe there's an off-by-one error in whatever goes to associate normals with faces? Sliding that by one could trivially cause that result.
<InPhase>
Basically, there has to be some sort of misattribution of lighting to faces. A misalignment of the normals in a list feels like the most probable way that could arise.
lcdk has quit [Ping timeout: 240 seconds]
guso78k has quit [Quit: Client closed]
kintel has joined #openscad
<kintel>
InPhase It's not a normal-related issue, it's related to rendering order; transparent faces should be rendering in back-to-front order to get the correct blending effect
<kintel>
We had the same issue with CGAL too, but it was only visible when rotating 90 degrees or more, since triangles were more or less sorted
<kintel>
alternatively, we could turn off backface rendering. I tried, but it didn't look too good
KAOS30 has joined #openscad
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
KAOS30 has quit [Quit: Client closed]
guso78k has joined #openscad
<InPhase>
kintel: Oh, I see. Yeah, that makes sense.