<HimeHaieto>
any devs here or those who otherwise might know more about how openscad/cgal works internally?
<HimeHaieto>
I've been wondering/uneasy about how much it might treat curves as actual curves instead of approximated polygonal meshes of arbitrary/variable resolution, and/or for which operations if it varies by case (primitives, boolean ops, hull/minkowski, etc)
<JordanBrown[m]>
Not at all curves, all straight lines.
<HimeHaieto>
I'm wondering among other things about if, say, stuff like precision errors or similar could potentially cause unexpected results for compound objects like in intersections involving lots of curvatures
ur5us_ has quit [Remote host closed the connection]
ur5us_ has joined #openscad
<HimeHaieto>
or a difference that leaves slivers of extraneous volume on the sides due to where a polygonal approximation got cut off compared to that of another node
<HimeHaieto>
worried that there may not be a 100% guarantee of correctness, basically - not just about the fragment resolution/mesh quality of the final output
LordOfBikes_ has quit [Ping timeout: 252 seconds]
LordOfBikes_ has joined #openscad
<JordanBrown[m]>
Well, yeah, kind of. Trying to do a really thin shell, for instance, might have problems. Then again, assuming that you are talking about 3d printing, a shell less than about 0.4 thick would be problematic anyway, and even that is iffy. Your can control the number of segments used, so if you need more you can set it for more.
<JordanBrown[m]>
Of course, performance suffers.
<HimeHaieto>
well that assumption wouldn't especially hold for me - I'm working/thinking more along the lines of sending schematics to a manufacturer for production
<HimeHaieto>
so, not really concerned about 3d printing, let alone as a home user
<HimeHaieto>
one of my first problems is already that obviously no manufacturer will accept or work with openscad or any format openscad natively produces, so part of my flow here is already trying to rely on freecad to convert my designs to the step format
<HimeHaieto>
among other things I discovered that things like hulls are handled with a particular lack of grace, which made me rather sad
Guest5 has joined #openscad
<Guest5>
Hello, has anybody had issues using version 2021.01 on a MacBook Air M1 running macOS Ventura 13.2?
ur5us_ has quit [Ping timeout: 255 seconds]
Guest5 has quit [Quit: Client closed]
teepee has quit [Ping timeout: 255 seconds]
teepee has joined #openscad
teepee has quit [Remote host closed the connection]
teepee has joined #openscad
J2351 has joined #openscad
<JordanBrown[m]>
HimeHaieto: I am not sure, but I believe that hull does exactly what it mathematically must do.
J23 has quit [Ping timeout: 260 seconds]
<JordanBrown[m]>
I believe there is only one convex hull of a set of points, and that is what it produces.
<HimeHaieto>
"of a set of points" is a key phrase here though, no?
<JordanBrown[m]>
Sure, like I said, everything is a straight line.
<HimeHaieto>
pretty sure that at least for hulls specifically, it always ("must", I think, because cgal) converts any circles/curves to a series of points approximating them to some resolution, and performs the hull based on that
<JordanBrown[m]>
No, hull does not do that.
<HimeHaieto>
and I don't think afaik that it ever returns to a more rounded representation afterward
<JordanBrown[m]>
There are not true circles.
<JordanBrown[m]>
The circle primitive, like the cylinder and sphere primitives, makes a figure composed of straight lines.
<JordanBrown[m]>
Everything in OpenSCAD is composed of straight lines.
<JordanBrown[m]>
It is well defined exactly what polygon the circle primitive will produce in any given case.
<HimeHaieto>
I mean, what I had originally thought was that it was more about rendering than internal mathematical calculations
<HimeHaieto>
that's part of why I was asking
<HimeHaieto>
as in, it's *possible* to be more precise for doing things like unions of spheres, but then convert them to points and meshes for rendering output
<JordanBrown[m]>
It is possible, but OpenSCAD does not do it.
<HimeHaieto>
I didn't know to what extent, if any, openscad itself operates on any such structures based on their semantic or mathematical meaning, versus said fragmented forms
<HimeHaieto>
it does seem like you're right though and that it doesn't ever do any such thing
<JordanBrown[m]>
Everything is straight lines. At all levels except the very highest where you say “circle”.
<JordanBrown[m]>
But the name “circle” is a convenient fiction. The circle primitive generates regular polygons.
<InPhase>
HimeHaieto: The way to think about it is to find the resolution limit of the manufacturing process, and design your curves to have that resolution.
<JordanBrown[m]>
It will make them with as many sides as you like, but they are always regular polygons.
<HimeHaieto>
I think I had been misled a bit by the fact that I've been using freecad and its openscad python compat module, since to at least *some* extent, *it* will actually recognise, bring in, and operated upon such shapes based on said semantics/mathematical definitions
<InPhase>
HimeHaieto: For 0.4mm nozzle FDM printing I go with $fa=1; $fs=0.4; And then I get features that are the size of what I can print.
<InPhase>
There is then no physical difference between what I produce and what a curve would produce.
<JordanBrown[m]>
I don’t know anything about freecad’s behavior, but if its circle primitive does not generate regular polygons then it is not compatible with OpenSCAD.
<HimeHaieto>
inphase: for one, it's important to consider that the cad files get passed around and actually manipulated by multiple engineers, so it can matter if complex geometries are preserved in their original form vs converted to largely inoperable meshes
<HimeHaieto>
it's not the end of the road for the files after they leave my hands to get passed to some tech or machine ready to consume it as is like might be the case for 3d printing
<JordanBrown[m]>
Meshes are outputs, not appropriate for further operations.
<InPhase>
HimeHaieto: Yeah, what you need to do depends on the process.
<JordanBrown[m]>
Hypothetically one could take a CSG dump and consume that, but you would have already lost most of what you would want to edit.
<HimeHaieto>
similarly, they may also need to go back and forth with me a bit on some things, passing modifications along the way, which can be hard if information is lost like that
<InPhase>
HimeHaieto: I've worked with machine shops. (And have done work in machine shops.) Generally it helps to have a conversation with the machine shop or the manufacturer about what sort of specification they actually need for their procedures and for their systems. It won't always be the same thing.
<JordanBrown[m]>
Information is lost the moment you go from OpenSCAD language to any other form.
<JordanBrown[m]>
Going the other direction does not work.
<HimeHaieto>
jordanbrown: as for what freecad does, it apparently scans the csg to recreate much of the semantic structure itself, such that a sphere declaration in the scad file remains an actual sphere in freecad and/or any resulting step file, including through various transformations
<InPhase>
HimeHaieto: But it's certainly the case that OpenSCAD's internal structure is currently far from what it would take to represent true mathematically pure curves in any sort of output. Parts of the language could support it, but parts of the language would not. However no part of the engine is setup for this sort of stuff.
<HimeHaieto>
thus, if they were to modify some of those objects, in theory I should still be able to clearly relate the results back to my original work just fine...but it's easy to see reasons for why I've become a bit uneasy about the prospective process
<JordanBrown[m]>
HimeHaieto: the list of primitive shapes, transformations, and operations is the boring part of the picture. What is interesting is *why* that sphere is that particular size, and in that particular position, and that can be reconstructed from the CSG only in the most trivial of cases..
eponym has joined #openscad
epony has quit [Remote host closed the connection]
eponym has quit [Remote host closed the connection]
<HimeHaieto>
the manufacturers and cam engineers should largely to entirely not care about such why questions afaik, they should just be concerned with other things like this piece is out of spec or we can't meet those tolerances
<JordanBrown[m]>
But if they are pushing back changes, those changes have to be properly integrated into the design, not blindly applied with no knowledge of how they affect the rest of the design.
<JordanBrown[m]>
In nontrivial cases, that is.
<InPhase>
HimeHaieto: There is, interestingly and fundamentally, no way to represent mathematically pure 3D surfaces in the general case. That's part of the problem. You can only represent a subset of them. Like, cylinders are easy. Spheres we could figure out. But when you start talking about other more deformed and arbitrary surfaces of 3D shapes, it ventures quickly into the land of the impossibility of a
<InPhase>
single representation capturing it.
<JordanBrown[m]>
But it seems that the reason that he is interested is that he thinks that he can take those shapes, edit them, and push them back upstream… which only works in the trivial cases.
<InPhase>
Other 3D CAD programs handle this by constraining what can be edited to what they are willing to represent, e.g., having some NURBS features for editing shapes, and then passing those all the way to the output format. But at that point you have a 1 to 1 coupling between the shape editing/design techniques and the processing of the system that manufactures shapes, so that it can pass all the way down
<InPhase>
the stack.
<HimeHaieto>
*if* (eek!) I do my job well enough, any changes they may need made should be fairly small/trivial, and easy to reintegrate with my source...that's what I've been thinking/hoping at least ._.
<HimeHaieto>
so...maybe I just need to try as hard as I can to do it well before even getting to that point, lest I'd have to throw out everything I've done already and restart with what originally pushed me to openscad with the frustration of working with it...iono, this is why I've been feeling a bit uneasy
<HimeHaieto>
kinda feels like what I'd ideally really want openscad to be doesn't really exist anywhere at all :(
<JordanBrown[m]>
Maybe, though it doesn’t seem like the curve representation that you were discussing is the real issue.
<HimeHaieto>
also, I'm a girl (he -> she) :p
<JordanBrown[m]>
Oops, sorry.
<InPhase>
HimeHaieto: There might be a bit of an xy problem in what you're attempting, as you haven't clarified what exactly you're ultimately trying to do. So maybe you can clarify that a bit.
<JordanBrown[m]>
If the downstream people say “this sphere need to be smaller”, then you need to edit the OpenSCAD source to make it smaller. Expecting them to edit something that is not OpenSCAD source, if it works, means that you are not using OpenSCAD to anything like it’s full potential.
<InPhase>
HimeHaieto: It's also might be that what you're looking for is impossible, or would require some radically different approaches. I can't really assess that without the description of the core goal.
<JordanBrown[m]>
For instance, my primary model is a model of my house, to approximately 25mm accuracy.
<JordanBrown[m]>
A window is broken up into multiple panes.
<JordanBrown[m]>
If the dividers between the panes are too thin for the downstream process, fixing one of them is not the answer, because there are probably a hundred or so of them. What needs to happen is changing the OpenSCAD program so that window pane dividers are thicker.
<JordanBrown[m]>
They are rectangular prisms, but if you think of them that way then you are operating at entirely the wrong level.
<HimeHaieto>
well the actual project I'm working on is creating a new niche "power user" desktop computer tower
<HimeHaieto>
so there's at least a benefit that compared to many potential models, a whole lot of what I'm doing can be represented by more basic shapes, but I still ran into the hull problem (freecad doesn't support/reimplement its own hull op, so apparently makes openscad make a mesh for each one and uses those), and still have lingering concerns over things like boolean ops
<JordanBrown[m]>
In effect, hull takes a list of vertices as input, and produces the convex hull of those vertices.
L29Ah has quit [Read error: Connection reset by peer]
<JordanBrown[m]>
It does not make meshes or convert curves.
<JordanBrown[m]>
Or, rather, it does not convert its input into a mesh, at least not exactly. Its input already is a mesh.
<HimeHaieto>
in the case of hull, we're talking about an external tool making use of openscad to hull, meaning it only gets what openscad is capable of outputting
<HimeHaieto>
I'm already expecting to do everything I can to remove/avoid hulls to prevent issues importing the design into freecad/exporting to step
<JordanBrown[m]>
More importantly, it is limited by what OpenSCAD is capable of taking as input.
<lf94>
question
<lf94>
why cant we just have a smooth polygon union
<JordanBrown[m]>
Answer
<JordanBrown[m]>
What does that mean?
<lf94>
given two rectangular prisms
<lf94>
unioned at the middle
<lf94>
why cant their intersections be smoothed out
<JordanBrown[m]>
I am not a strong 3D geometry person, but I believe that the answer is that that is easy to do in most special cases, and difficult to do in the general case.
<JordanBrown[m]>
Perhaps the key distinction is that Blender is a tool for editing 3d figures, while OpenSCAD is a tool for generating 3d figures.
<JordanBrown[m]>
OpenSCAD does not really have mechanisms for editing anything.
<HimeHaieto>
don't feel bad about blender, I made an animated short film in blender many years ago and yet still can't remember how to actually use much of its interface
<lf94>
catmull-clark seems very applicable to openscad
<lf94>
you dont need to select any faces
<lf94>
we could use some sort of bounding volume to limit things
<JordanBrown[m]>
Alas I am on my iPad and do not have any STL viewing tools.
<JordanBrown[m]>
Like I said I think there are libraries that make shapes like that.
<HimeHaieto>
I know of $fn, but don't think I quite understand any of the other crap
<InPhase>
HimeHaieto: That is perhaps why you are struggling with polygonal issues.
<lf94>
I think I'm going to give up on non-polygon based code cad
<InPhase>
HimeHaieto: Near the top of your scad file, write: $fa=1; $fs=0.4;
<lf94>
I dunno, I feel damn lost
<lf94>
Why is there not one universal thing that just works
<lf94>
Why cant there be
<HimeHaieto>
maybe because if there was one universal thing that simply worked, there'd be no room left for anyone to sell you stuff? -.^
<JordanBrown[m]>
Because “just works” means different things to different people.
<HimeHaieto>
mmm, cynicality
<InPhase>
HimeHaieto: $fa says that large curves will not have more than 1 degree from one segment to the next, while $fs=0.4 says that small curves will keep approximately 0.4mm segments.
<lf94>
just works -> can generate organic shapes, can generate specific surfaces, all while not requiring years of expertise to understand to build the system in the first place
<InPhase>
HimeHaieto: That combination of $fa and $fs is a pretty good starting point for most people.
<lf94>
I'm tired of this divide between brep/frep/csg, it really sucks
<JordanBrown[m]>
Describing an organic shape is hard. That’s why not everybody is a sculptor.
<lf94>
With smooth union, you basically get organic shapes
<InPhase>
HimeHaieto: The default values for $fa and $fs are from the very early days of OpenSCAD, and I really think we should update them for modern hardware.
<lf94>
With fractal code, you get organic shapes
<lf94>
are we doomed forever to be imprisoned by the complexity of cadware?
<JordanBrown[m]>
Well, sure, it’s relatively easy to get an organic shape. But getting the one that you want is much harder.
<JordanBrown[m]>
There is a reason that CGI houses spend huge amounts of effort trying to come up with models of real-world objects.
<JordanBrown[m]>
It’s because the real world objects are very hard to describe precisely.
<lf94>
How many people maintain openscad you think?
<JordanBrown[m]>
Hard to say, but my guess would be in the neighborhood of a dozen who are more than trivially active.
<JordanBrown[m]>
And of course they are all volunteers doing it in their spare time.
<JordanBrown[m]>
If you totaled it up, my guess would be one or two full time equivalents.
<InPhase>
JordanBrown[m]: Subjectively I think there is more developer activity now than I've seen at any point since I started watching it in 2016 or so.
<InPhase>
I think it might be on a steady rise.
<JordanBrown[m]>
Might be.
<InPhase>
And we should really be looking for a release point. There are a lot of experimental features in the pipeline, so there won't be a clean breaking point. But we should just pick one at some point, because releases are good for progress.
<JordanBrown[m]>
We need enough funding to put teepee on salary :-)
<InPhase>
Google Salary of Code.
<lf94>
Isn't it concerning though that even a project like OpenSCAD is massively complex?
<lf94>
CGAL is nuts
<HimeHaieto>
you do realise what all openscad/cgal still have to do, right?
<lf94>
yes
<lf94>
it's crazy
<lf94>
is it really impossible for there to be nothing simpler?
<HimeHaieto>
"math is haaard" (in distraught high school girl voice)
<JordanBrown[m]>
OpenSCAD isn’t massively complex. It’s just not simple.
<lf94>
If it's not simple it's complex.
<HimeHaieto>
it's like 50k lines of code for everything combined I believe...there's so much out there that's far worse if that's your metric
<HimeHaieto>
I just spent entirely too much time the last couple days or so looking at all kinds of math crap related to hulls (with actual curves!)
<HimeHaieto>
advanced math is not generally what most people call simple, so I don't know what you're expecting there
<HimeHaieto>
also blender is both bigger/more complex, and totally insufficient for actual cad work, lest you ever consider actually spending a bunch of time trying to use it instead before realising it yourself
<HimeHaieto>
just throwing that one out there for good measure
<JordanBrown[m]>
Our main repo at work is, I think, about 12MLOC.
<JordanBrown[m]>
OpenSCAD is small enough that individuals can do real work on it in their spare time.
<HimeHaieto>
size really doesn't matter much as far as development is concerned
<JordanBrown[m]>
It does, and it doesn't. It's more a matter of lines per engineer, and of how intrinsically hard those lines are to write.
<HimeHaieto>
there can be projects with 100 mloc that are super approachable and easy to develop on, and horrifying nightmares of projects with very few lines
<lf94>
size doesnt matter...
<JordanBrown[m]>
Yes, source quality matters a lot.
<lf94>
it 100% matters for the longevity of a project
<JordanBrown[m]>
OpenSCAD is not the best source I've seen, but it's also not the worst.
<JordanBrown[m]>
But mostly the hard parts of OpenSCAD are delegated to CGAL, FreeType, and some other underlying libraries.
<JordanBrown[m]>
I'm sure there are some isolated hard parts that I don't know about. I don't know who does offset or minkowski, for instance.
<JordanBrown[m]>
But the language parts are relatively straightforward, as is the overall structure of the geometry processing.
<JordanBrown[m]>
It's only slightly multithreaded, and has almost no security attack surface, and those are probably the two most intrinsically difficult things at work.
<JordanBrown[m]>
But the low-level geometry stuff, the stuff that's mostly delegated to CGAL... that's hard stuff.
<HimeHaieto>
wait, slightly multithreaded?
<HimeHaieto>
since when?
<JordanBrown[m]>
Long time. But only slightly.
<HimeHaieto>
I thought everything in openscad and cgal was frustratingly 100% single threaded
<JordanBrown[m]>
I believe the UI and F6 render are in different threads.
<HimeHaieto>
oh, right, the things all those other people use, almost forgot again...
<JordanBrown[m]>
Windows task manager says it's something like 10 threads, though I don't know what they are all doing.
<JordanBrown[m]>
But CGAL is single-threaded, and I believe the preview processing is in the same thread as the UI.
<HimeHaieto>
yeah, cgal being single threaded is what had really surprised me...
<JordanBrown[m]>
I am surprised that it's not MT for sibling branches of the tree. But my understanding (and observation agrees) is that the most expensive part is the last union, and that's ST.
<JordanBrown[m]>
Though actually that's in how OpenSCAD calls CGAL, not CGAL itself.
<JordanBrown[m]>
(I'm assuming here that CGAL is not actively MT-hostile, that it doesn't have global variables or similar evils that make even doing parallel computations that are unrelated difficult or impossible.)
<JordanBrown[m]>
Could CGAL itself be MT, so that it could do one union using multiple processors? Probably. But at the same time, it's probably one of those projects where you need somebody who needs a PhD thesis.
fury999io has joined #openscad
<JordanBrown[m]>
And I suspect that going from PhD thesis to production-ready is non-trivial too.
<JordanBrown[m]>
MT is hard.
<HimeHaieto>
you're talking to someone who pursued their phd in mt et al
<HimeHaieto>
I know a thing or two about parallelism ;p
<JordanBrown[m]>
The fact that "pursued their PhD in MT" is a thing says that it's hard :-)
<JordanBrown[m]>
I am surprised that (it seems) nobody has made CGAL run at least partially on a GPU. It seems like there should be large parts that would be applicable.
<HimeHaieto>
well, to be fair, there are also those who get phds in puppetry or "humanities"
<JordanBrown[m]>
It's probably best that we don't try to compare the two.
<HimeHaieto>
just because you can go deeper doesn't mean the surface level need be unapproachable
<HimeHaieto>
I may be a bit biased here though
<JordanBrown[m]>
Well, yeah, if you have a PhD-level understanding of concurrency then you are way, way ahead of the majority of programmers.
<HimeHaieto>
also technically the key term is more "hpc" (high-performance computing) than something specific like mt
<HimeHaieto>
mmm, supercomputers
<JordanBrown[m]>
Sure, though usually when people talk about that near me they mean massive scale.
<JordanBrown[m]>
Exactly, supercomputers.
<JordanBrown[m]>
And of course that's not what we're talking about here.
<HimeHaieto>
I mean more like hpc encompasses more than just mt
<HimeHaieto>
but anyway, math ought to be more parallelisable than what cgal seems to make it appear, but it's...old?
<JordanBrown[m]>
I haven't looked into the development history and practices of CGAL. There does seem to be active development, but I haven't tried to understand what they are doing.
<HimeHaieto>
I know that "legacy code" tends to be one of the biggest enemies of hpc/mt
<JordanBrown[m]>
And there may be better geometry engines than CGAL... now if only somebody would spend the time to make OpenSCAD run on top of one of them.
<JordanBrown[m]>
Legacy code is one of the biggest enemies of any established project.
<HimeHaieto>
occt?
<JordanBrown[m]>
When I said that MT and security were two of the hardest things at work, I didn't mention what is arguably the hardest of all: don't break anything.
<HimeHaieto>
"job security is what breaking things is for" - me
<JordanBrown[m]>
For a lot of the stuff at work, if something breaks at a customer site thousands of people start twiddling their thumbs, so we try really hard not to do that.
<HimeHaieto>
excuses...embrace the irresponsibility and the better off your life will be
<JordanBrown[m]>
My understanding at the time was that the real problem was that they were behind on applying patches, and had put way too many eggs in one basket, but...
<JordanBrown[m]>
Avoiding having our systems cause outages that are discussed on CNN is important to us.
<HimeHaieto>
I thought any press was good press :p
<HimeHaieto>
ok I'll stop now lol
<JordanBrown[m]>
Um... no. :-)
<JordanBrown[m]>
Anyhow, if you want to put OpenSCAD atop some better geometry engine, or parallelize CGAL, that would be great. Right now there doesn't seem to be anybody with the right expertise, interest, and energy to do that.
<HimeHaieto>
time is definitely always a fun one
<JordanBrown[m]>
yep
<HimeHaieto>
I'd have to confess the thought crossed my mind wondering if there may be any feasibility to a simple dumb implement-openscad-on-top-of-cadquery kind of thing
<HimeHaieto>
don't know much about it but saw it recently and wondered a bit about it
<JordanBrown[m]>
I don't know anything about it. What's needed is mesh arithmetic - unions, intersections, et cetera of meshes.
<JordanBrown[m]>
But I haven't looked at that part of the program.
<HimeHaieto>
"AndSelector", "SumSelector", and "SubtractSelector" seem potentially promising toward that end
<JordanBrown[m]>
Entirely possible, though since CadQuery seems to be basically a Python library on top of OpenCascade, one wonders why you would write OpenSCAD-language instead of just writing Python.
<HimeHaieto>
because python, for one
<HimeHaieto>
and the model...and code/style - have you seen some of their basic examples?
<JordanBrown[m]>
No, hadn't heard of them until you mentioned them.
<JordanBrown[m]>
Describing that kind of shape wouldn't be any prettier in OpenSCAD. It would just be a linear extrusion of a polygon, with an equally ugly series of coordinates.
<JordanBrown[m]>
And a "current pen position" model is helpful when you want to do things like "arc to".
<HimeHaieto>
I don't think I'd do that as a pure polygon of points in openscad
<HimeHaieto>
I might argue whether one ought to want to "arc to" like that...not so sure about that one
<HimeHaieto>
also think I was totally wrong about the selectors upon inspection, but the 3d workplane methods might be the ticket...union, cut, intersect
<JordanBrown[m]>
There are a couple of different techniques that could be used, but I think I'd probably go with extruding a polygon.
<JordanBrown[m]>
And yes, they seem to have the right sorts of operators available. Unsurprising, since they think they are a direct competitor to OpenSCAD.
<HimeHaieto>
I think part of my problem is that I'm not so sure if I can become a fan of brep
<HimeHaieto>
the mathematician in me squirms a bit at the inelegance
<HimeHaieto>
also, they have no 3d hull, only 2d, so there's that coming up again
<HimeHaieto>
also no minkowski, but that's not surprising in the least
teepee has quit [Remote host closed the connection]
teepee has joined #openscad
guso787 has quit [Quit: Client closed]
guso78 has joined #openscad
<JordanBrown[m]>
Somebody should write test programs that measure how long it takes various geometry libraries to do fundamental tasks - e.g., union two 100k-face objects.
<JordanBrown[m]>
Though of course if they can operate directly on curves that's taking things to a new level.
<JordanBrown[m]>
anyhow, it's bedtime.
<HimeHaieto>
curves would require us to have a whole different discussion we don't have time for right now, but you could do a thing or two
fury999io has quit [Quit: Konversation terminated!]
GNUmoon has joined #openscad
<guso78>
teepee, how can i find out that i am running in linux workflow and how can i disable the test then ?
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #openscad
fury999io has joined #openscad
fury999io has quit [Quit: Konversation terminated!]
fury999io has joined #openscad
castaway has joined #openscad
Tallak has joined #openscad
<Tallak>
Hi. I made a library called `bladegen` at gihub/thingiverse that some people here and there seem to be using. It would have been so nice to have some kind of package management for OpenSCAD, because many of these users seem to be unable to extract things in the `libraries` folder. Even just a menu option to install some of the more common libraries
<Tallak>
would have been very helpful.
Tallak has quit [Quit: Client closed]
Tallak has joined #openscad
Tallak has quit [Client Quit]
L29Ah has joined #openscad
fury999io has quit [Quit: Konversation terminated!]
<Scopeuk>
My understanding is cgal is very achedemically pure maths focused on the geometry domain, the computational problem domain is not a project concern so multithreading etc is not something they are interested in
L29Ah has quit [Read error: Connection reset by peer]
<guso78>
after 3 attempts, all checks are clean :)
guso78 has quit [Client Quit]
<J2351>
hm regarding that library thing - until there is a better solution, I wonder if it would help people to have just a menu item "install library" that let you select a (downloaded - or maybe also url if possible) library - and just copy into the users library folder. With a message "library xyz.scad is now available with <include>xyz.scad or
<J2351>
<use>xyz.scad
epony has quit [K-Lined]
ur5us_ has joined #openscad
<HimeHaieto>
tbh I think what would be far more useful before worrying about libraries and full on package management would be proper namespacing
<HimeHaieto>
all you need is for two of your libraries to define do_something and you have a problem
<teepee>
there's a chance the object proposal will cover the namespace topic
<teepee>
also, oops, someone got k-lined ;-)
<Friithian>
klines are always fun
<teepee>
J2351: maybe that would be a first step to get started
<J2351>
at least it shouldn't cost too many dev resources to get this implemented
L29Ah has quit [Ping timeout: 252 seconds]
<J2351>
and oSCAD already knows the path .. I mean you could also have the library also just in the same folder as the saved file (afaik) But if this is in place a missing library (file) could instead of a popup just open the file dialog to select the library
gknux has quit [Ping timeout: 260 seconds]
gknux has joined #openscad
<InPhase>
HimeHaieto: CGAL appears to have been largely constructed by mathematicians rather than software engineers, or at least by people who chose to focus on mathematician type approaches to solving the problems the library handles.
<InPhase>
HimeHaieto: So while there have been rumbling of multithreaded updates to CGAL coming, I have yet to see the fruits of that labor. It might take a while to hit the ideal.
L29Ah has joined #openscad
guso78 has joined #openscad
<guso78>
teepee, i managed to get the ctest running in python-support. python is only enabled in linux and the python test is only performed in linux.
ur5us_ has quit [Ping timeout: 255 seconds]
<teepee>
nice!
<teepee>
aha, I see cgalpngtest_python_primitives
<guso78>
yes, i plan to add more tests
<guso78>
basically exersizing all commands all operators once
<guso78>
primitives already has quite some transformations included
<guso78>
which tasks do you see left on your/my side ?
L29Ah has quit [Read error: Connection reset by peer]
<teepee>
I guess the main topic is to get things packaged for the builds, I'm open for any ideas or help
<teepee>
I'll try to find some time to get this sorted
<guso78>
teepee, i believe i dont understand. Package for linux is a zip or gzip compressed binary. isn't it?
<teepee>
it should be trivial for the OBS package builds
L29Ah has joined #openscad
<teepee>
but AppImage and Snap, I don't know how that will work
<teepee>
there's no nightly build for Flatpak so that will be a topic for later
<InPhase>
guso78: Have you merged back in the changes to master from a few weeks ago to your python branch that started right before that.
<InPhase>
guso78: It will be helpful to grab those before making additional changes to the tests.
<InPhase>
Best to take the easy path and avoid merge conflicts.
<InPhase>
It popped into my head as I recalled resolving a bunch of cgalpngtest issues. :)
<teepee>
merged the latest changes to python-support
<guso78>
InPhase. today i made sure to have minimal differences to "python-support" instead of "minimal differences to master". I did this because i had compilation issues on windows with venv
<teepee>
we also have an issue with the current master builds, the windows installer grabs the venv folder
<guso78>
teepee, great, i was missing that some time.
<guso78>
my next task is to sync your changes to my workspace
<InPhase>
teepee: Oh. I guess there's an exclusion list somewhere?
<teepee>
I thought it's an include list so it's a bit surprising
<InPhase>
teepee: It's located under tests, right?
<InPhase>
I'm pretty sure I set that to tests/venv, unless I messed that up on Windows only somehow.
<teepee>
not sure, I just saw it yesterday when a friend did some streaming with openscad
<InPhase>
lol, ok.
<InPhase>
Then I guess it still works.
<InPhase>
set(VENV_DIR "${CCBD}/venv")
<teepee>
yes, just the unzip did give some errors, I think it grabbed some symbolic link
<InPhase>
Should be tests/venv
<teepee>
yep, that makes sense
<InPhase>
The windows specific cmake stuff was simplified down to just: set(IMAGE_COMPARE_EXE "${VENV_DIR}/Scripts/python.exe")
<InPhase>
Rather than: set(IMAGE_COMPARE_EXE "${VENV_DIR}/bin/python")
<InPhase>
The only other differences are in the msys2 scripts.
<teepee>
release builds are MXE, so it's just grabbing the python stuff in cmake but never runs it
<InPhase>
Working directories for venv creation are CCBD, which is tests/
<guso78>
Can anybody explain in brief, what is that venv ?
<InPhase>
guso78: Python virtual environment for installing packages used for testing.
<guso78>
Thx
<InPhase>
guso78: Specifically, numpy and pillow are presently used.
<guso78>
teepee, thank you for merging
<InPhase>
This replaces the usage of imagemagick.
Bocaneri has joined #openscad
ur5us_ has joined #openscad
<guso78>
ahh, python also has a rich graphics lib!
Bocaneri is now known as Guest6558
<InPhase>
guso78: The updated algorithm I wrote in Python is better customized to our exact testing needs, and thus catches issues with fewer false negatives and fewer false positives.
Guest6558 is now known as SenFache
<InPhase>
Whereas with imagemagick if we had reduced the false negatives by adjusting the threshold, we would have gotten too many false positives. So to avoid the false positives we were just missing testing failures that were happening.
<teepee>
hmm, the zip includes OpenSCAD_Test_Console.py and also tests and tests-build folders
<guso78>
in imagemagic you just can use the "Existing" but in python you can code what you need
<InPhase>
teepee: That issue might predate my change, but might just be more noticeable now that there's a whole venv coming along for the ride.
Sauvin has quit [Ping timeout: 252 seconds]
<teepee>
yeah, could be some of the earlier cmake changes
<InPhase>
guso78: Yeah, I think of the version I did as just a base layer that happens to work well for all of our current tests. But now we can toss in customized tests for different situations.
<teepee>
specifically we need to check how to exclude that stuff from cpack
<InPhase>
Also I'm optimistic that we could use python for stl tests and things like that.
<InPhase>
It's low burden to add a few more libraries, once the venv is in place.
<InPhase>
And we're decoupled from the reduced maintenance of imagemagick. Pillow seems to get more attention.
<guso78>
i got some working python functions to read/write stl's (binary and ascii), not sure it this can help
<teepee>
is there a simple way to move the vevn population to later, right now it's already running at cmake time
<teepee>
which might be the "normal" way, I don't know
<guso78>
it loads/saves to a proprietray database and alll of that would have to be changed
<InPhase>
I saw there were a bunch of good looking stl libraries out there, but I was not motivated to initiate such testing. But I think it would be a good idea for someone to do, and would be stronger testing than relying purely on images. We should also be testing rendering output more.
<InPhase>
There should probably be tests for every single file export type we support. Which Python can do.
<guso78>
InPhase, you would compare STL's by xoring with a reference ?
<InPhase>
There is a validatestl.py that kintel adapted from someone else's code, and that I added binary stl support to. But it only checks for very basic problems in the stl.
<InPhase>
guso78: I think not. You would want a slightly fuzzy test that does not trip up on floating point issues.
<InPhase>
guso78: Which requires some smarter code, like you could do with a Python script.
<guso78>
in that case you probably just want to compare two unorderes sets of vertices, points, faces and finally stl volume :)
<InPhase>
teepee: Well, this happens because top level cmake runs the tests cmake.
guso7856 has joined #openscad
<InPhase>
teepee: There are probably some other options we could choose there, although it would require some thought probably to break that out.
<InPhase>
teepee: Minimally it could be a compile time option so that it's only run when someone wants to later do testing, and not for non-testing builds.
<InPhase>
teepee: That would probably require no thought. :)
<InPhase>
teepee: But then we just need to update the testing docs accordingly, and each of the action scripts that does testing.
<InPhase>
And I would need to update my personal build script, but I could live with that.
<InPhase>
Oh...
<InPhase>
We DO have this option already. It just defaults to ON.
<InPhase>
teepee: Maybe the minimal change is ENABLE_TESTS=OFF on the packaging builds?
<InPhase>
That would be very sensible, as this is a waste of build time.
guso78 has quit [Ping timeout: 260 seconds]
<teepee>
ah, good idea, that should be pleny enough. it's not really an issue anyway, I just noticed when building last time
<InPhase>
This is probably for the best. Most devs doing their own builds should build testing anyway, and get notification if that's not setup, so that we keep contributers encouraged to actually include tests. :)
<teepee>
:)
<peepsalot>
my libstdc++ just completely broke a few days ago. no idea what is going on.
<peepsalot>
CMakeFiles/OpenSCAD.dir/src/openscad.cc.o: undefined reference to symbol '_ZNSt15basic_streambufIcSt11char_traitsIcEE8overflowEi@@GLIBCXX_3.4'
<InPhase>
peepsalot: Clean build?
<peepsalot>
yep
<InPhase>
:(
<peepsalot>
/usr/bin/ld: /lib/x86_64-linux-gnu/libstdc++.so.6: error adding symbols: DSO missing from command line
<peepsalot>
InPhase: why are you checking the i386 version though
<InPhase>
Hmm. I grepped for it and that came up.
<InPhase>
Let me look again.
<InPhase>
Yeah, that was just the first hit.
<InPhase>
I guess try again with the x86_64-linux-gnu directory.
<InPhase>
Should be an identical result.
<InPhase>
Unless of course it is broken...
<InPhase>
It is a common symbol used in other libraries that use libstdc++, so the right one got buried in noise.
guso78 has joined #openscad
<guso78>
teepee, can you elaborate again, which ideas/help is missing for packaging ?
guso78 has quit [Quit: Client closed]
guso7856 has quit [Ping timeout: 260 seconds]
ToAruShiroiNeko has quit [Ping timeout: 260 seconds]
Fleck has quit [Remote host closed the connection]
lkcl has quit [Quit: BNC by #bnc4you]
ToAruShiroiNeko has joined #openscad
Fleck has joined #openscad
SenFache has quit [Remote host closed the connection]
SenFache has joined #openscad
teepee_ has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
<HimeHaieto>
inphase: no kidding, I actually took a quick look at cgal's top-level union code since jordanbrown suggested it was one of the more costly operations, and even that has plenty of (no phd required) opportunity for parallel improvement
<HimeHaieto>
it appears to largely happen by creating a union object, adding polyhedrons to it one at a time, then calling a function to request the polyhedron representing the union of all that had been added up to that time
SenFache has quit [Remote host closed the connection]
<HimeHaieto>
however, that get_union function is effectively pretty much just an accessor, since it performs a union every time you add a single polyhedron, unioning it to the previous ones
castaway has quit [Ping timeout: 255 seconds]
<HimeHaieto>
would probably make a lot more sense, and be a dead simple change to implement, to just simply maintain the n polyhedrons in a list, then have t threads each union n / t of the polyhedrons, then union the remaining t polyhedrons (for which you could also just as easily multithread with decreasingly fewer threads)
SenFache has joined #openscad
<HimeHaieto>
I mean, since you only have to perform the actual union upon the get_union call
SenFache has quit [Remote host closed the connection]
<HimeHaieto>
granted, that all could also just as easily be done by the code calling into cgal, but there's the question of where the responsibility for parallelising such operations should lie (ofc I'd argue toward cgal), and if cgal could do ultimately do a better job of it than any code using it could (likely true)
SenFache has joined #openscad
SenFache has quit [Remote host closed the connection]
SenFache has joined #openscad
L29Ah has quit [Read error: Connection reset by peer]
SenFache has quit [Ping timeout: 255 seconds]
L29Ah has joined #openscad
<InPhase>
HimeHaieto: Well, if you could figure out how to get that sort of functionality into CGAL it would be huge in impact.
<InPhase>
HimeHaieto: Especially if it is compatible with the path through CGAL that the fast-csg feature of OpenSCAD is using.
<InPhase>
fast-csg already got us up to 5-10 times performance boost on a lot of things. Another factor of 10 or so from threading would put us at 100 times the capacity of what we could render just a couple years ago.
<InPhase>
The way I think about these performance questions is that it's not about the speed. It's about the capability. There is a certain amount of time to render a model beyond which it stops being worth doing, because it would take prohibitively long for all the feedback cycles to iteratively fix your mistakes.
<InPhase>
So when we go up in performance, we're really saying that we can do models that are X amount more complex.