califax has quit [Remote host closed the connection]
califax has joined #openscad
marcus has quit [Remote host closed the connection]
<JordanBrown[m]>
I'm going to try to put together a very-much-draft object PR in the days after Christmas, after Christmas insanity has quieted down and during the company shutdown between Christmas and New Years.
<InPhase>
teepee: Is there any part of your home that is not already full of colorful LEDs from all these LED projects?
J233695 has joined #openscad
<teepee>
yep
<teepee>
also all 3 are gifts, so not going to take up any room here :)
J2336 has quit [Ping timeout: 260 seconds]
<teepee>
that sparkly blue filament is nice, but I guess I need to give in getting a new Prusa printer so I can use the marmor filament too which seems to be available in 1.75mm only
_whitelogger has joined #openscad
<JakeSays>
hello scad'ers!
ur5us has quit [Ping timeout: 246 seconds]
aiyion has quit [Remote host closed the connection]
aiyion has joined #openscad
ur5us has joined #openscad
J233695 is now known as J23
<J23>
teepee .. we have the same china vice Ü
<J23>
but why do you need a new printer for that filament?
ur5us has quit [Ping timeout: 255 seconds]
fancsali[m] has quit [Quit: You have been kicked for being idle]
L29Ah has left #openscad [#openscad]
castaway has joined #openscad
Junxter has joined #openscad
SamantazFox has joined #openscad
<Scopeuk>
J23 at a guess the key bit is "1.75 mm only", are you still running 2.75/3mm teepee?
<J23>
oh ah hm well makes sense
<teepee>
yep original prusa v1 with the prusa 3mm nozzle
<teepee>
it's ok, but a bit old, loud and maybe was never perfectly assembled :)
<J23>
3mm nozzle .. that must be super fast prints .. Ü
<J23>
so cura v5 removed the wall overlap setting .. now my string art is not working that nice anymore
gknux has quit [Ping timeout: 268 seconds]
gknux has joined #openscad
aiyion has quit [Remote host closed the connection]
<linext>
your else on line 391 should do something, but doesn't
<InPhase>
linext: That seems to be doing a type check for a floating point type, and if the type check fails to match, it looks for rounding up existing.
<InPhase>
Although I don't know any floating point types that do rounding up.
<InPhase>
That would be a pretty rare choice.
<InPhase>
linext: Does this roof error depend on whether or not fast-csg is enabled?
<linext>
if you change it to roof(method="voroni") it works
<InPhase>
Well that narrows it somewhat I suppose.
<InPhase>
Ultimately that's a precondition check failing in CGAL, so it's their code not handling wasm well. But if voronoi works and straight doesn't, then there might be a subtle call difference that could be identified.
<InPhase>
linext: It looks like there is no OpenSCAD flaw. You cannot build a straight skeleton with CGAL, as used in the straight version of roof, without it passing along to that assertion.
<InPhase>
linext: voronoi looks like it is implemented within OpenSCAD instead of using CGAL.
<InPhase>
linext: So if you want to fix it and support roof with straight, you'll need to figure out why wasm fails that call within CGAL.
<InPhase>
And then that will require either changing the wasm environment, or getting a bug fix into CGAL if there is even a bug, or someone needs to boldly try to reimplement straight skeleton without using CGAL, like was done for voronoi.
<linext>
yes
<linext>
"I dug deeper into CGAL, found the assertion that was failing and removed it to see if the issue was surface level. After upgrading some of the build files, unfortunately it still does not work. This will need to be brought higher to the maintainers of CGAL. "
<InPhase>
Sounds about right. Most of those CGAL assertions follow the Chesterton's fence principle.
<peepsalot>
didnt the WASM build require loosening FPU strictness or something?
<InPhase>
peepsalot: This one is under CGAL_NO_PRECONDITIONS, which is probably not so safe to turn off.
<InPhase>
Although it does appear to my not-100%-effort inspection to be a rounding check.
<InPhase>
Now I don't know how float rounding manages to be a precondition of an algorithm... But that's CGAL. ;)
<InPhase>
Generally that's on the "don't do this with floats" list.
jimusmallard has quit [Remote host closed the connection]
<teepee>
IIRC it's safe in WASM, there's some dedicated interval logic
milza has quit [Quit: milza]
Busata has joined #openscad
<Busata>
hello, was reading the openscad tutorial and the rotation bit got me a bit confused as it doesn't seem to be mentioned. Are the transformations on the object applied on reverse order as written? the tutorial says the wheel should be rotated first & then translated but the statement starts with translate
<linext>
start with translate
<linext>
then your x,y,z directions will be as you expect
<linext>
if you rotate before you translate, your x could be z, z could be y, y could be x
<linext>
then you have to guess and check
<Busata>
oh ok, that makes sense, misread that bit then. thanks
<JordanBrown[m]>
Work your way out from the inside.
<JordanBrown[m]>
Thus for
<JordanBrown[m]>
Translate(…) rotate(…) cube(…)
<JordanBrown[m]>
You take a cube, then rotate it, then translate that.
<JordanBrown[m]>
From the perspective of a conventional language you might think of the thing following as an additional argument.
<JordanBrown[m]>
Thus the argument to the translate is a rotated cube.