<JakeSays>
i have an instance of openscad that is consuming 32GB of memory
<peepsalot>
teepee: maybe... I'm still trying to decide what mesh classes would be beneficial for us. I think current Polyset is not conducive to editing such as merging vertices etc, because the data structure has no connectedness. a half-edge structure seems to make a lot more sense
snakedGT has joined #openscad
<peepsalot>
magnum has its own Mesh class but that seems specialized for GL/visualization, and is more like a convenient interface for VBOs, not necessarily for editing manifold geometry.
snaked has quit [Ping timeout: 252 seconds]
<peepsalot>
there's CGAL's Surface_mesh too, which I'm guessing is similar in structure to OpenMesh, but I don't know the full differences or list of features, pros/cons
Guest35 has joined #openscad
Guest35 has quit [Client Quit]
<peepsalot>
i know that ochafik's PR made some usage of Surface_mesh, but also kept Polyset. I guess the big question is how many different Geometry/mesh representations do we actually need, and what are their purposes. maybe it would be enough to convert CGAL Nef and Polyhedron_3 straight to Magnum::Mesh for visualization
<peepsalot>
and eventually Surface_mesh, assuming eventual inclusion of ochafik's PR
aiyion has quit [Remote host closed the connection]
aiyion has joined #openscad
drew has joined #openscad
ur5us has joined #openscad
<InPhase>
Something must be in the github issue water lately.
oldlaptop has quit [Quit: No Ping reply in 180 seconds.]
oldlaptop has joined #openscad
oldlaptop has quit [Client Quit]
oldlaptop has joined #openscad
<ccox>
ye gods Qt likes to put it's hooks all over the system. Trying to get multiple versions to live side by side seems near impossible.
drew has quit [Quit: Quit]
<InPhase>
It is a beast.
drew has joined #openscad
<ccox>
too bad we can't kill that beast... yet.
<InPhase>
ccox: Were you around for my long-winded rant against Qt the other day?
<InPhase>
My dismay with it as a gui system grows with time.
<ccox>
nope, just joined the channel. Been trying to get the MacOS build to.. well.. build. And failing repeatedly.
<InPhase>
Have you tried the homebrew approach?
<ccox>
Right now the biggest problems are that Qt doesn't play well with multiple versions of Qt, and that the latest available Qt (5.15) seems to require C++17, while OpenSCAD wants C++14.
<ccox>
yep, that's what I'm working on now, after nuking all other Qt installs.
<ccox>
I started with the dependencies script, got it 99% working, then ran into Qt version nightmares.
<InPhase>
If that's your only issue, go into CMakeLists.txt and change set(CMAKE_CXX_STANDARD 14)
<InPhase>
17 should work fine, we are simply keeping it at 14 for now for the sake of older systems.
<InPhase>
I can run a build test on 17. Give me 3 minutes.
<ccox>
It doesn't work - part of the OpenSCAD codebase still trigger errors under C++17. (at least with clang and g++)
<ccox>
So now I'm trying to figure out what the least disruptive path forward might be.
<InPhase>
Yeah, the C++17 build went fine, and the program seems to work. There are no new issues in the codebase going from 14 to 17.
<ccox>
which compiler, which platform, which Qt version?
<InPhase>
Although for some reason it took 30 seconds longer to build. I guess g++ has some extra inefficiencies that kick in for C++17.
<InPhase>
g++, Ubuntu 20.04, Qt 5.12.8
<InPhase>
I'm just using the Qt from the repository.
<ccox>
let's just say they have some work remaining on their C++17 implementation, but are spending their time on their C++20 implementation.
<InPhase>
I haven't had any C++17 issues with g++ yet. I use it for my work stuff.
<ccox>
ok, I've got 5.12.2
<InPhase>
The only issue I actually had with C++17 was attempting to port one of my work projects to a mac, at which point libc++ kicked up some absurd errors with constexpr in the stdlib.
<InPhase>
But I was able to work around them.
<ccox>
I write C++ benchmarks, and find LOTs of problems in everyone's compilers (then get to file lots of bugs, then wait years for them to fix the bugs)
<ccox>
unfortunately homebrew only wants to serve up 5.15.2 (sorry for the earlier typo).
<InPhase>
5.15.2 should go fine.
<InPhase>
The Linux nightlies are using 5.15.2 to build.
<InPhase>
I'm not certain if the mac nightlies are as well, but at least the code is compatible with 5.15.2
<ccox>
Mac builds are still apparently on 5.9.9 (cached)
<InPhase>
Yes, the mac nightly appears to be that. But I don't think there's any specific reason it shouldn't work on 5.15.2 from homebrew, because the codebases are already compatible. If you're having some other issue, maybe pastebin some error messages. https://bpa.st is useful for this.
<ccox>
they should be compatible, but don't build.
<InPhase>
I for the first time learned how to unpack a mac dmg file on Linux. Apparently 7z can do it, and inside I found the Qt version hiding.
<ccox>
and 5.9.9 won't work because it conflicts with any other qt version installed.
<InPhase>
Well, pastebin your errors. There might be information hiding in the exact messages hinting at a solution path.
<ccox>
yep, from the dependencies download script - unfortunately homebrew doesn't seem to have any version other than 5.15.2
lastrodamo has quit [Quit: Leaving]
<InPhase>
I would say try to fix the 5.15.2.
<InPhase>
This should be the path of least resistance.
<InPhase>
Then you have a known-good Qt, you just need to get past whatever build error you're getting.
drew` has joined #openscad
drew has quit [Ping timeout: 252 seconds]
drew` is now known as drew
<ccox>
I think that's the case, but still got a bunch of issues to figure out.
<InPhase>
Ok. Well, if you provide some details, maybe I or someone can advise.
<ccox>
and, of course, clang is giving me bogus line numbers in a huge header.
<InPhase>
I don't use macs much, but I've debugged more C++ builds than I can count.
<ccox>
<insert many cursewords here> homebrew kept around a copy of the Qt 6.13 headers after I told it to uninstall
<ccox>
and the compile is getting the versions confused.
<ccox>
that explains much.
<InPhase>
Well that could break everything.
<ccox>
<old man shakes fist at pathetically incompetent excuse for an app framework>
arebil has joined #openscad
<ccox>
yay! the build is progressing!
<InPhase>
Progress. :)
<ccox>
The C++17 issues were in the Qt 6 headers that got mixed with the Qt5 headers. So back to C++14, remove a bunch of error checking from my cmake file, and fingers crossed.
<InPhase>
Qt6 requiring C++17 makes more sense. I was pretty sure Qt 5.15.2 did not require this.
<ccox>
yeah, it confused me as well - but the error message and the header it opened showed C++17 features used. I didn't think to check every symlinks in the path.
<InPhase>
Although we are not setup for Qt6, as there are allegedly breaking changes that no one has looked into.
<InPhase>
And some breaking changes that are very frustrating to deal with relating to exception handling.
<ccox>
there are also licensing issues, open source purity issues, and a lot of ill will from the owners of Qt issues.
<InPhase>
Yes.
<InPhase>
The important parts of Qt remain LGPL, but they try hard to pretend otherwise.
<ccox>
I sooo want to see a better framework emerge. But the sets of people with good framework experience, and the set of people working on open source, don't intersect much.
<ccox>
and done. Got a couple of errors in translation-update.sh (assumes linux commands), but the build appears to work.
ur5us has quit [Remote host closed the connection]
ur5us has joined #openscad
<InPhase>
ccox: Glad you got it sorted out.
<ccox>
InPhase: thank you for your help and encouragement
arebil has quit [Quit: My keyboard has gone to sleep. ZZZzzz…]
<gbruno>
[github] ChrisCoxArt opened issue #3927 (script translation-update.sh creates "command not found" error on MacOS (and probably Windows)). https://github.com/openscad/openscad/issues/3927
drew has quit [Ping timeout: 252 seconds]
drew has joined #openscad
drew has quit [Quit: Quit]
drew has joined #openscad
ccox has quit [Remote host closed the connection]
ur5us has quit [Ping timeout: 252 seconds]
drew has quit [Ping timeout: 245 seconds]
arebil has joined #openscad
ferdna has joined #openscad
ccox has joined #openscad
ccox has quit [Ping timeout: 245 seconds]
ccox has joined #openscad
<ccox>
Starting to get some useful results from profiling - F6 renders are spending 60% or more of their time allocating and freeing small blocks of memory inside CGAL and gmp
<ccox>
(and because of that, profiling memory allocations is S L O W )
ferdna has quit [Quit: Leaving]
arebil has quit [Quit: My keyboard has gone to sleep. ZZZzzz…]
<knielsen>
cbmuser: We talked earlier about getting my key into debian-maintainers-keyring and getting upload rights to openscad. For this I need an advocacy, I've sent you mail with details
Guest25 has joined #openscad
Guest25 has quit [Client Quit]
gunnbr has joined #openscad
<teepee>
gunnbr: \o/
othx has joined #openscad
<gunnbr>
status?
<othx>
Gthx.NET version 2.08 2021-08-14: OK; Up for 35 seconds; mood: pretty good.
<gunnbr>
botsnack!
<othx>
YUM! This is why I love #openscad.
<teepee>
did it run on facebook? :D
<gunnbr>
:D
<gunnbr>
I finally fixed the one problem I was having with othx last night so I can upgrade it to the same version as gthx.
<teepee>
cool
<gunnbr>
And then I can work on this problem where they both keep dying without restarting for no apparent reason.
<teepee>
botsnack!
<othx>
YUM! This is why I love #openscad.
arebil has quit [Quit: My keyboard has gone to sleep. ZZZzzz…]
qeed has quit [Read error: Connection reset by peer]
qeed has joined #openscad
<InPhase>
teepee: Re: #3927 on translation-update.sh, the only reason I didn't PR that is because I have never run that, and I'm not sure if it's auto-run anywhere important such that my python suggestion would break things.
<teepee>
it normally runs after each build, it's not super critical for dev though
<teepee>
no wait, translation-make.sh is run
<teepee>
ah, right and that internally runs the -update
<InPhase>
Ah, I see that path now.
<InPhase>
I guess then I did run it implicitly, but didn't notice. :)
<InPhase>
I assume all of our CI platforms have properly working Python in place?
<teepee>
at least those doing release builds should have it, yes
<InPhase>
Ok.
<teepee>
I think we can try the python solution, I don't think it could make things worse
<InPhase>
Is it cross-compiling and that's how the realpath worked on the CI?
<teepee>
if it currently only works on linux, I would assume that certainly has python
<InPhase>
All computers everywhere should come with Python. It's just unfortunate that they currently don't.
<teepee>
yes, windows build is just on a linux machine so that would use the native realpath
<InPhase>
But I feel like all developers should have Python.
<teepee>
well, not the MacOS machine unfortunately
<teepee>
the poppler build now fails with missing python, so I'm trying to install that via macports
<teepee>
so we'll have it in that case too
arebil has joined #openscad
<InPhase>
I thought current mac was bundling Python3 by default.
<InPhase>
Perhaps it's an older MacOS version?
<teepee>
could be a path issue with macports
<teepee>
not sure, it's not giving a mac version it's giving Xcode 12.2
<InPhase>
Brilliant, mac, make life more difficult in the future.
<buZz>
yes, punish the users
<InPhase>
Python is not "legacy".
<buZz>
or they wont ever upgrade to linux
<teepee>
well, I see the point of keeping those decoupled
<teepee>
but then macos has no nice way to update as linux :)
<teepee>
in the end, it's more likely they just don't want to care, classic Apple strategy
<teepee>
I assume they could have found a nice user friendly solution via the mac store with auto-updates
<InPhase>
Python gets reliably bundled with Linux because it's central to how core system components work. Which in turn is for a good reason, because it's one of the top system tool programming languages right now. Not sure what mac is doing with its unixness instead of all that good stuff.
<teepee>
that's what I mean, bundle with the user level stuff
<teepee>
don't bundle with the kernel :)
<teepee>
the old mac behaviour would be more like it's included in kernel upgrades
<InPhase>
Well that sounds weird.
<teepee>
yep, but that's what it sort-of is, by bundling with the OS release
<InPhase>
Although there should generally be three layers, kernel, system layer, user layer.
<teepee>
yeah, it's not a perfect analogy
<InPhase>
Python belongs reliably in that system layer.
<teepee>
but with macos it seems there's no system layer as such
<teepee>
macos is like kernel+system = releases / apps = appstore
<teepee>
linux has everything upgradable in the distros from one place
<buZz>
macos is like a car that cant drive on all roads
<buZz>
windows is a car that can use many roads
<buZz>
linux is a car that can make anything a road
<teepee>
but it looks nice when parked :)
<buZz>
lol yeah 'as long as you dont touch it'
<buZz>
:)
<teepee>
I like that comparison
peeps[zen] has quit [Ping timeout: 245 seconds]
peepsalot has joined #openscad
<InPhase>
Then android is an electric bicycle and the iphone a hoverboard?
<buZz>
android is more like a rollator
<buZz>
iphone like a rollator with rearview mirrors
<teepee>
iphone = sight seeing bus
<teepee>
android = clown car
<teepee>
;-)
<buZz>
lol yeah
<buZz>
both horrible iPaq clones
hisacro has quit [Ping timeout: 245 seconds]
mhroncok has quit [Quit: Leaving.]
paddymahoney has quit [Remote host closed the connection]
arebil has quit [Quit: My keyboard has gone to sleep. ZZZzzz…]
peeps[zen] has joined #openscad
peepsalot has quit [Ping timeout: 252 seconds]
peepsalot has joined #openscad
peeps[zen] has quit [Ping timeout: 245 seconds]
arebil has joined #openscad
arebil has quit [Client Quit]
hisacro has quit [Ping timeout: 268 seconds]
hisacro has joined #openscad
Jack21 has joined #openscad
<Jack21>
Hi, seems some rounding has changed when getting [[0,0]] in the old version i now get [[-8.88178e-16, -8.88178e-16]] which is an issue for rotate_extrude
<Jack21>
with v 21.3 this was 0 while 21.9.25 giving this "slightly below 0" (the calculation is doing sqrt and sin and as the echo is only 5 digits i can not find out where this error come from)
<Jack21>
maybe it is in the rotate_extrude as the error has wrong numbers so "rotate_extrude()circle(r=1,$fn=6);" give "(range is -0.50 -> 1.00)" and also when hitting F5 several times the error just vanish (but didn't get geometry)
<Jack21>
a circle(r=1,$fn=4); gives correct range error - so there is y calculated but given as x in the error msg or the shape is rotated later
<peepsalot>
Jack21: can you pastebin the scad to reproduce?
<Jack21>
from the "echo" it should be fine : issue = [[2.5, 3.7081], [-1.11022e-15, -4.44089e-16]], original = [[4, 0], [1.5, -3.7081]], adjustment = [-1.5, 3.7081]
<Jack21>
so i am adding 3.7081 to -3.7081 but it is not 0
ur5us_ has joined #openscad
hisacro has quit [Ping timeout: 250 seconds]
<Jack21>
peepsalot: so i can not find out which 3.7081 is different - but when i add them i get [-1.11022e-15, -4.44089e-16]
<Jack21>
as one is calculated (phytagoras) with sqrt(x²-y²) this might be the different value
<Jack21>
when i add 1.5 to the 1.5 i get 3 but when substracting i get -1.11022e-15
<Jack21>
Ok i now compared the values within the working and not working scad versions - and they seem to be the same, so i would assume that the rotate_extrude module changed how this numbers are used
hisacro has joined #openscad
<Jack21>
so found it rotate_extrude()
<Jack21>
polygon([[-0.000000000000001,+0],[2,8],[1,5]]); is working on older but not newer versions
<Jack21>
the old version allowed negatives till rotate_extrude()
<Jack21>
polygon([[-0.00001,+0],[2,8],[1,5]]);
<Jack21>
rotate_extrude()translate([+0.9999995,0]) circle(1,$fn=4); this is working too which is weird
<Jack21>
so there is a difference in the translation module - which rounds after the 6 decimal
<Jack21>
probably the problem would also go away if other calculations like sinus work with higher precision
<peepsalot>
rotate_extrude()translate([+0.9999995,0]) circle(1,$fn=4); does not work for me
<peepsalot>
Jack21: newer versions have more accuracy in general for 2D
<peepsalot>
which is likely why it worked before, because it got rounded to 0, but with increased accuracy, it now keeps the very small negative value
<Jack21>
so how should i solve this if the proper math is not giving the result
<Jack21>
and maybe the should be a way to see the actual value and not a rounded one
<peepsalot>
i don't know, your sample script is 7k lines, can you actually single out the part of the code which has the problem?
<peepsalot>
"actual value" is not possible with floating point representation
<Jack21>
the "echo" is obviously only giving 6 decimals while the calculation is using 16 (or something like this)
<peepsalot>
oh, in the echo, yes there is limited precision there
<Jack21>
if i add a rounding operation for all vectors it would be terrible for the performance
<Jack21>
wouldn't it make sense that rotate_extrude is setting everything under 1 e-14 to 0?
<peepsalot>
outputting maximum precision in echo would also likely slow things down and increase memory footprint (due to how CSG caching works, referencing subtrees by string), but might be worth trying given how often it is brought up
<Jack21>
having a higher accuracy than the translate is also not helping
<peepsalot>
Jack21: what is the "proper math" which results in inaccurate value?
<Jack21>
i calculate the points of a part circle and move them so they are at 0 but as the sin() and sqrt() produce values that are rounded at some point - the -e15 value is generated instead of 0
<peepsalot>
if you can guarantee $fn a multiple of 4, then the cardinal points of a circle should be precise
<Jack21>
this is not true for very h multiples - as i am calculating the intersecting point of two circles the resulting arc point is calculated precise
<peepsalot>
can you show demonstrate your circle calculations in 100 lines or less?
<Jack21>
inPhase: what does "UB" mean? and why wouldn't it be ok if a point is [-1e-15,5] to put it to the next raster = [0,5]
<InPhase>
Jack21: Undefined Behavior, meaning you cannot guarantee a correct outcome, and if you get one once, you cannot guarantee it will keep working as you change things, or across versions, or across platforms.
<InPhase>
Jack21: I thought you knew the term as you named your file that. ;)
<Jack21>
inPhase -- UB are my initials - Ü
<InPhase>
Hahah. Convenient or inconvenient, I'll let you decide. :)
<Jack21>
that example file is giving lots of warning and errors btw
<ccox>
UB - the compiler writer's excuse whenever the compiler doesn't do what the customer wants.
<InPhase>
Jack21: So if we bump up -1e-15 should we bump up -1e-14? Or -1e-13? An arbitrary threshold in the engine itself moves the problem but doesn't solve it.
<InPhase>
ccox: Except in OpenSCAD we have many cases where it's fundamentals of math causing the problem.
<Jack21>
if we use a raster of -e10 this point would snap at 0
<InPhase>
Jack21: Yeah, it solves your case. But then not the person with a point -1.1e-10 off.
<Jack21>
and every geometry below 1nm (nanometer) is not possible to machine
<InPhase>
Jack21: If you know your points are derived and not exact, you can put them back on the axis with the method I showed. But you need to be careful that at least two points have the exact same x=0.
<dalias>
jack21, someone could be making their model with units of km O_o
<InPhase>
Jack21: If your points near the y-axis are for example are x=-1e-15 and x=+1e-15, and we snap only the left-most one, it's still invalid.
<Jack21>
no that will not happen as the calculation accuracy is higher so if someone is -1.1e-10 off he didn't use proper math to get there or he wants that value
<dalias>
(or worse yet, yards! :)
<dalias>
kidding here but i don't think openscad has any hard assumptions about how the units correspond to physical world units
<InPhase>
Jack21: We could solve that by snapping left AND right. But then someone whose leftmost point is x=+1e-15 has a valid design, unless we snap it to x=0 and then it's invalid?
<dalias>
anyway solving numerical instability by snapping is a very error-prone idea
<dalias>
it just makes it so you randomly hit much worse issues when you happen to be midway between snap points
<InPhase>
Yeah. It's generally introducing a problem on a different design for every problem it solves on the first design.
<Jack21>
when i create a cube (1); and export this - it will measure 1mm
<dalias>
jack21, it will measure 1 "stl unit"
<Jack21>
3mf
<InPhase>
Jack21: That's a matter of your slicer settings.
<dalias>
i've seen plenty of stl's with inches or other awful units :/
<Jack21>
which is why we don't use stl anymore - Ü
<dalias>
ah, maybe 3mf stores an intended unit in the file. never used it myself
<InPhase>
Millimeters is by far the most common unit, and everybody should conform and use it. But officially we don't require it.
<Jack21>
however even with km we are good with e-12
<dalias>
inphase, i could see reasonable uses producing models for game world or something where you might want 'game unit' instead of mm
<InPhase>
Jack21: If you want to snap, it's actually easy to write a snap function with a list comprehension. Just pass your points through it.
<dalias>
or you could use units of um just so the default $fs is sane ;-)
<InPhase>
dalias: I favor changing default $fs and $fa... But other people are more change-phobic than me.
<InPhase>
I think "better default quality" is not a breaking change. :)
<ccox>
it is when file sizes balloon.
<InPhase>
If your design breaks when default resolution increases, question some life choices. *chuckle*
<Jack21>
if you save an file with an object smaller 1.e-6 it will have 0 in the file
<InPhase>
Jack21: Not with binary mode.
<InPhase>
Jack21: Which is now default.
<Jack21>
in 3mf only 6 decimals are stored
<Jack21>
but the name says it is for manufacturing
<Jack21>
and the high precision seems not be consistent as the translate module has lower accuracy then the rotate_extrude
lastrodamo has quit [Quit: Leaving]
<InPhase>
Jack21: Okay. I made a 1e-6 cube, and 3mf saved it. I learned two things: One, 3mf definitely stores values of 1e-6. Two, cura does NOT handle this scale of design elegantly. :) https://i.imgur.com/5ZfhgwT.png
<dalias>
cura works in integer microns
ur5us_ has quit [Ping timeout: 250 seconds]
<Jack21>
yes 1e-6 is the minimum (nanometer) but 1e-7 results in <vertex x="0" y="0" z="0" />
<Jack21>
<vertex x="0" y="0" z="0" />
<Jack21>
<vertex x="0" y="0" z="0" />
<Jack21>
<vertex x="0" y="0" z="0" />
<Jack21>
<vertex x="0" y="0" z="0" />
<Jack21>
<vertex x="0" y="0" z="0" />
<Jack21>
<vertex x="0" y="0" z="0" />
<Jack21>
<vertex x="0" y="0" z="0" />
<InPhase>
Ok, yes, 1e-7 disappears. It works fine for binary stl though.
<InPhase>
So ultimately it's processed correctly, just not output with 3mf.
<InPhase>
Is there a specification limit for it though, or do we just have an unnecessary limit in the export_3mf.cc file?
<Jack21>
The decimal values representing the coordinates can be recorded to arbitrary precision. Producers SHOULD NOT use more precision than the error generated in their calculations, or the anticipated resolution of their consumer.
<Jack21>
(from the specs) and that is what i mean - if a calculation in oscad is only precise to 1e-15 the rotate_extrude should calculate above that error
<InPhase>
Solve one problem, make another. It has to be on the scad implementer doing calculations to make floating point values that comply with requirements, because there are many varieties of ways this can go wrong, different for different types of designs.
<InPhase>
I get that it's tricky to be aware of, but floating point math is intrinsically tricky, because finite representation of arbitrary values is fundamentally tricky. There are no generalized ways around it when transcendental functions are involved..
<InPhase>
Say we clamped it for rotate_extrude... Should we clamp unions or differences? Should every polygon clamp? If you have a series of rotation operations should you clamp after each one?
<InPhase>
unions and differences also pose issues, as one set of values could be overlapped, and another not overlapped. You might think "Yes!" But this fails on its face the moment we union or difference at a 17 degree angle instead of at a 0 or 90 degree angle. So suddenly the union and difference clamping becomes unstable, working only at certain orientations, and introducing additional problems at other
<InPhase>
angles.
<Jack21>
is there a reason why i have so many microsoft links within the 3mf (and they are not working)?
<InPhase>
This is not purely theoretical. We do have a form of clamping during the 3D render step because of the way the CGAL library uses rationals inside, such that a grid snap increases efficiency before a render (allegedly). However, this actually breaks some designs. I've had perfectly valid scad code turn non-manifold just because of 3D grid snapping, which I demonstrated by altering the grid snapping
<InPhase>
value in OpenSCAD and the code suddenly worked fine. Here it was done for performance, and it already caused problems.
<InPhase>
I am actually hopeful that after corefinements we can do some benchmarking without 3D grid snapping and purge this.