<HimeHaieto>
ok...odd issue here...with the source being merely "cylinder(r = 1, h = 1); translate([0, 0, 1]) scale([10, 0, 0]) cylinder(r = 1, h = 1);", I get...a segmentation fault when rendering via `openscad --render ...`, but not when omitting the render option (obviously not possible for all output types)
<HimeHaieto>
erm...what?
<InPhase>
Hmm.
<InPhase>
Well it's a completely invalid design. But it sure shouldn't segfault.
<InPhase>
HimeHaieto: It's possible that the bug is actually a regression in CGAL, and not in our code. It would require some exploration to be sure.
<InPhase>
CGAL has a tendency to not handle precondition violations gracefully.
ur5us has quit [Ping timeout: 255 seconds]
<HimeHaieto>
inphase: does that mean you were able to replicate it yourself, or is it maybe only happening for me?
use-value has quit [Ping timeout: 248 seconds]
<HimeHaieto>
I also see that the issue changes and minimises it even further than I did
<HimeHaieto>
and sure enough, I see the same behaviour when I adopt said change
<HimeHaieto>
actually, oddly enough, I got it for cylinders like I originally showed, but not cubes as exactly done in the issue you opened
<HimeHaieto>
no idea what's going on here...also I'm running it on 2019.01-rc2 atm
<HimeHaieto>
funny little thing I accidentally found here anyway...also, I hate it in general when I figure out my expressions evaluate to 0 instead of what I'm expecting...often because I typed the wrong name and uninstantiated names evaluate to 0 instead of giving an error or something
qeed_ has joined #openscad
qeed has quit [Ping timeout: 255 seconds]
J2395 has joined #openscad
J23 has quit [Ping timeout: 260 seconds]
<InPhase>
HimeHaieto: Yeah, I replicated it and simplified it down. The scale([1,0,0]) is the critical component. scale([1,1,0]) does not crash, but any scale with two zeroed dimensions does.
<HimeHaieto>
interesting, but at least in my case, it also needed that first non-scaled cylinder as well, otherwise no segfault
<HimeHaieto>
so...that's odd too
<InPhase>
Well, I have two cubes.
<HimeHaieto>
I'm with you that it might be an issue with cgal though, hard to say without knowing more
<InPhase>
I don't have an old 2019.01-RC2 around to test with, but that release candidate isn't too critical anyway, as it's 4 years old.
<HimeHaieto>
yes, cubes for you, cylinders for me - as mentioned, it *also* doesn't segfault for me if the primitives are cubes instead of cylinders
<InPhase>
You can try with one of the nightly builds, to have something more up-to-date.
<HimeHaieto>
all things considered, it's very strange and erratic
<InPhase>
2019.01-RC2 is way too old to be running or worrying about. It's missing a lot, and wasn't even a final release. :)
<HimeHaieto>
I've just been using what was packaged in the debian distro I'm still using for things despite being a little old now (buster)
<InPhase>
The app image releases don't require installing.
<InPhase>
What I do is drop .AppImage files in /usr/local/bin, and then do a symlink of /usr/local/bin/openscad to the release I want to run as primary.
<HimeHaieto>
I did find it *very* odd that the package maintainers would choose a release candidate, but I certainly had no control over that
<InPhase>
Since /usr/local/bin is earlier in the path, that will have precedence over the package installed versions.
<HimeHaieto>
that sounds...hacky?
<InPhase>
That's pretty standard. It's exactly what AppImage releases are designed for. :)
<HimeHaieto>
if you want to do something like that and move between multiple versions, I'd consider environment modules to be a far stronger/better/safer option
<InPhase>
It's the one I keep /usr/local/bin/openscad pointed at.
<HimeHaieto>
and no weird custom/nonstandard tinkering and system-wide symlinks and whatnot
<InPhase>
Running the nightly has huge advantages from all the truly massive speed boosts that can be turned on with the fastcsg features.
<InPhase>
Renders are about 5-10 times faster.
<HimeHaieto>
environment modules are what are used in like every supercomputing cluster ever, though in my experience they unfortunately don't seem to be well known about outside of those environments despite not being specific to them
<InPhase>
Yes, I use them on my work cluster.
<HimeHaieto>
ah, cool
<InPhase>
Although in this case, everything other than the current release of OpenSCAD is too out of date. :)
<HimeHaieto>
I don't use appimage, but among other things I don't think I'd expect them to handle things like dependencies between multiple applications/libraries nearly as well, if at all
<InPhase>
So there's no point having anything on the system run older ones, environment setting or not.
<InPhase>
For the master branch I typically launch with a helper script that co-launches openscad and vim, and increases the stack size to improve OpenSCAD's recursion depth.
<InPhase>
Also my launcher script tracks maximum memory usage for each run of OpenSCAD in a log file, so that I can monitor for memory consumption regressions.
<InPhase>
HimeHaieto: Actually, managing dependencies is the one job of AppImages. All dependencies needed are bundled. I don't think I've ever seen an issue running an AppImage. They just... work.
<HimeHaieto>
and how would that work for shared libraries, or applications dependent upon other applications?
<InPhase>
Plus it's very consistent computer to computer, so I know that if I'm testing things with an AppImage, I'm running almost the same thing as everyone else using the AppImage on the same platform. There are only subtle differences like video drivers and such.
stevegenoud has joined #openscad
<InPhase>
HimeHaieto: All shared libraries needed are bundled into the AppImage file.
<HimeHaieto>
I'm guessing given the name "appimage", the former is simply not something you can do with them, and I'd also guess the latter is shaky at best, but iono
<InPhase>
It has all dependencies bundled, but otherwise runs exactly like a regular program. There is zero issue interacting with other programs. It's not like snaps with their sandboxes. AppImages are just a bundled executable that removes dependencies as a problem.
<InPhase>
There's always a tradeoff, but in this case the tradeoff is that openscad the executable is 20MB, and the OpenSCAD AppImage files are 40MB, because the dependencies are bundled. But... 40MB is nothing.
stevegenoud has quit [Ping timeout: 260 seconds]
<InPhase>
It's worth giving a try if you haven't. They're a wonderful little bit of technology, and have solved the Linux executable distribution problem very well.
<HimeHaieto>
I don't think we're on the same page
<HimeHaieto>
I can `module load libblas/2.3` and build/run some code with it, then `module swap libblas libblas/3.4` and instantly get everything from the 3.4 version instead, etc
<InPhase>
If you mean swapping out dependencies of an AppImage by a module load, then yeah, you definitely can't do that without building one yourself. They have no external dependencies to alter. That's the whole point.
<HimeHaieto>
I'm talking about the likes of modules that upon loading affect *other* software or environments outside of themselves
<HimeHaieto>
and that didn't seem like something solved by the "here's something that packages everything up inside of it" kind of notion
<HimeHaieto>
similarly, it's not just libraries that can create that interdependency issue, but also applications or even data too, so that's what I was wondering/getting at
<InPhase>
But why would you want to do that? The AppImage for releases contain a set of library versions well tested as working with that bit of code.
<InPhase>
Thought goes into that. Swapping it out is unlikely to work better.
<HimeHaieto>
I thought you said you do this stuff and have worked in such environments before, but maybe I misjudged
<InPhase>
I do. And it often leads to a big pile of bugs and hunting down of complex dependency issues. lol. Not sure why you'd want to interject that into a system that works well. :)
<HimeHaieto>
if there was no value in or need for that sort of thing, it wouldn't be how nearly all packages are maintained in, e.g., scientific computing centres
<HimeHaieto>
this prolly isn't the channel to have an extended discussion on the merits of appimages vs environment modules anyway
<InPhase>
"module load" I use mostly just to fix issues with old release servers having outdated base installs of things. conda is another one I use, but there's a reason "I'm trapped in conda hell today" is a well-understood phrase.
teepee_ has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
<HimeHaieto>
suffice it to say, there's lots of people that find themselves in need of managing multiple versions of not just applications but also libraries or data, and doing it in a more dynamic or particularly user specific/defined manner, all the time
<HimeHaieto>
I find myself personally in that camp all the time, and nothing I've ever seen yet can provide greater power/flexibility to address such situations, so that's what I use myself
<InPhase>
I think you'd have a hard time finding many use cases for that with OpenSCAD releases.
<HimeHaieto>
btw, modules allow for you to specify dependencies on specific versions of everything it depends on, if you wanted to go just as strict as an appimage would be for a give binary you're trying to run like that
<HimeHaieto>
I'm not saying you're doing anything "wrong" or that you should change though
<InPhase>
Although this could be how you managed to get 2019-01.RC2 to segfault. I tested RC3 of that (the one I had around as an AppImage), and it did not segfault. So probably it had to do with one of the libraries you fed it, which mismatched what we released with.
<HimeHaieto>
I will say that the biggest thing about your appimage solution I did find...iono, maybe a bit odd or something I suppose, was less about appimage or environment modules or whatever else, but that you'd put unstable/indev versions of software in /usr/local for the whole system to see and use
* HimeHaieto
shrugs
<HimeHaieto>
I'm not too concerned about the segfault though, I only even came across it in the first place because of an error leading those scale values to be 0, but it was an interesting discovery nonetheless
<InPhase>
Anything running "openscad" runs the stable version I want to be run. Anything running one of those OpenSCAD*.AppImage files is pretty explicitly running it. That'd be no accident.
<InPhase>
OpenSCAD-2021.01-x86_64.AppImage is a more stable release than 2019-01.RC2 was by a wide margin.
<HimeHaieto>
all I really want right now is just to get my design finished, which simultaneously is starting to feel so close while still feeling so far
<HimeHaieto>
the amount of time I've lost even just struggling trying to figure out where the pcie expansion slot cutouts go...you don't want to know >_>
<HimeHaieto>
at times I've almost felt like I've been trying to reverse engineer things from limited specification documentation
guso78 has joined #openscad
vanknee has joined #openscad
vanknee has quit [Client Quit]
Guest23 has joined #openscad
Guest23 has quit [Client Quit]
<JordanBrown[m]>
The reason that you need two cylinders to demonstrate the problem is that CGAL doesn't get involved if there's only one object.
<JordanBrown[m]>
HimeHaieto: ^
<JordanBrown[m]>
InPhase: I don't directly know anything about AppImages but based on what you say above, it sounds like they have the same problem as static linking: the distribution problem if there is a serious bug in a library is awful.
<JordanBrown[m]>
Heck, if you're going to statically bundle the files together, why not statically link and reduce the startup costs of dynamic linking?
<guso78>
only 3d operation which must continue with only one object is offset :)
<guso78>
and of course multmatrix
<JordanBrown[m]>
I don't believe that CGAL is involved in a multmatrix of a single object.
<guso78>
no, its not
<JordanBrown[m]>
There are lots of CGAL-related failures that only appear if you have two objects. It's kind of annoying, because error reports are often of the form "I don't understand why this fails when I add a cube, it works by itself".
<JordanBrown[m]>
I think it would be better if CGAL was *always* used when you F6.
<JordanBrown[m]>
But I have never looked at the logic to see what's really going on.
<guso78>
JordanBrown[m], this would definitely a performance decrease. if cgal converts to internal database in order to find out, that its nothing todo, still the effort and time is spent for nothing
<JordanBrown[m]>
Oh, there would definitely be a performance cost. How much of one, I don't know, but I suspect not much. After all, we wouldn't be asking CGAL to do any boolean operations, just to validate the polyhedron it had been given.
<JordanBrown[m]>
And of course there are relatively few real models that are only a single CSG object.
<JordanBrown[m]>
Eh, well, wait a minute. A single polyhedron() is entirely plausible,
<JordanBrown[m]>
But still, the cost would be less than the cost associated with unioning that object with a cube.
<guso78>
only valid reason for using cgal on a single object would be self-repair self-intersecting objects
<JordanBrown[m]>
Detecting self-intersecting objects. Detecting non-closed objects. Detecting non-manifold objects. All of those "detecting..." cases that get done as soon as you do any real Boolean operation with the object.
<guso78>
JordanBrown[m], how much would you rate the ability to repair objects with cgal ?
<JordanBrown[m]>
It confuses people that their polyhedron or their imported STL is OK by itself, but causes problems as soon as you try to do anything with it. Most of the time it would be better if it had a problem all by itself.
<JordanBrown[m]>
Zero.
<guso78>
haha
<JordanBrown[m]>
AFAIK it does not do repair.
<JordanBrown[m]>
Not that I am an expert.
<JordanBrown[m]>
But it seems to be very very picky.
<guso78>
can cgal repair objects repair 2 coplanar faces with just opposite normal vector ?
<JordanBrown[m]>
I did just say "zero" and "AFAIK it does not do repair", didn't I? :-)
<JordanBrown[m]>
I believe that reversed faces are one of the cases that it does not handle.
<guso78>
ok, "charged" no further questions
<guso78>
i am asking because of offset. my results always have "closed" faces and they are not manifold, because they might have double, negative room or coplanar faces which need to resolve
<JordanBrown[m]>
I just made a polyhedron with a couple of flipped faces, and CGAL rejected it.
<JordanBrown[m]>
ERROR: The given mesh is not closed! Unable to convert to CGAL_Nef_Polyhedron.
<JordanBrown[m]>
Or at least our CGAL-related processing rejected it.
fury999io has joined #openscad
guso78 has quit [Quit: Client closed]
guso78 has joined #openscad
<guso78>
JordanBrown[m], I dont relate to flipped faces.
<guso78>
just use a manifold polygon and move some vertices so that it is self-intersecting (which means it has areas where volume overlap is 2.
<guso78>
when faces are not flipped here, question is if cgal can repair it with an union
<guso78>
polygon -> polyhedron
<JordanBrown[m]>
I doubt it.
<JordanBrown[m]>
But you can try it: just put together whatever construct you like with polyhedron(), and try to union it with a cube.
<JordanBrown[m]>
But I need to go to bed, sorry.
<guso78>
different timezone haha, have a nice one
<JordanBrown[m]>
US/Pacific
<JordanBrown[m]>
Los Angeles
<JordanBrown[m]>
Good night.
fury999io has quit [Quit: Konversation terminated!]
castaway has joined #openscad
teepee_ has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
fury999io has joined #openscad
Guest21 has joined #openscad
fury999io has quit [Quit: Konversation terminated!]
<guso78>
you can best see it in wireframe mode(and again there is this mysterious yellow small rectangle at the cube)
<guso78>
in the model shown, a 4 sided pyramid intersects a cube in the same object
stevegenoud has quit [Quit: Client closed]
J2395 has quit [Quit: Client closed]
stevegenoud has joined #openscad
J2395 has joined #openscad
stevegenoud has quit [Ping timeout: 260 seconds]
<InPhase>
JordanBrown[m]: Some (many) libraries are very static-linking unfriendly. Qt is one of them. So AppImage solves that problem.
<InPhase>
JordanBrown[m]: And yes, it does couple an executable to a fixed library version, but that simplifies problems because those library versions match what has been tested, and thus one hunts for fixes in different versions of releases rather than sampling the space of dependencies. Very few people are out there hunting for fixes by combinations of libraries, and those people are typically developers
<InPhase>
anyway who can build it themselves.
<InPhase>
JordanBrown[m]: As for CGAL and stl imports, the proper solution to that will be to add in a run of the CGAL validation call at stl import. This is a known option, but hasn't been implemented.
J2395 has quit [Quit: Client closed]
J23 has joined #openscad
stevegenoud has joined #openscad
J23 has quit [Quit: Client closed]
J23 has joined #openscad
stevegenoud has quit [Ping timeout: 260 seconds]
guso78 has quit [Quit: Client closed]
stevegenoud has joined #openscad
stevegenoud has quit [Quit: Client closed]
stevegenoud has joined #openscad
guso78 has joined #openscad
stevegenoud has quit [Ping timeout: 260 seconds]
stevegenoud has joined #openscad
stevegenoud has quit [Ping timeout: 260 seconds]
stevegenoud has joined #openscad
stevegenoud has quit [Ping timeout: 260 seconds]
stevegenoud has joined #openscad
stevegenoud has quit [Client Quit]
stevegenoud has joined #openscad
stevegenoud has quit [Client Quit]
stevegenoud has joined #openscad
stevegenoud has quit [Ping timeout: 260 seconds]
stevegenoud has joined #openscad
fling has quit [Remote host closed the connection]
stevegenoud has quit [Ping timeout: 260 seconds]
fling has joined #openscad
stevegenoud has joined #openscad
stevegenoud has quit [Ping timeout: 260 seconds]
stevegenoud has joined #openscad
stevegenoud has quit [Ping timeout: 260 seconds]
lf94 has joined #openscad
<lf94>
we need a csg vs brep competition
teepee_ has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
stevegenoud has joined #openscad
stevegenoud has quit [Ping timeout: 260 seconds]
teepee has quit [Quit: bye...]
teepee has joined #openscad
stevegenoud has joined #openscad
<JordanBrown[m]>
InPhase: static linking and library bundling are great, until one of those libraries has a security bug, and then it's nearly impossible to eradicate because you have to track down and update every application that bundled or statically linked with that library. And those libraries *do* have security bugs.
<JordanBrown[m]>
CGAL and malformed polyhedra (from whatever source) - yes, the same validation / conversion logic that's used when you start actually doing Boolean operations.
ToAruShiroiNeko has quit []
stevegenoud has quit [Ping timeout: 260 seconds]
ToAruShiroiNeko has joined #openscad
guso78 has quit [Quit: Client closed]
<lf94>
Given 4 cubes connected to make a corner shape, how would you fillet the inner corner point
<guso78>
Are these the same changes which were the result of the new image compare ?
<J23>
is there a reason why "!" below another "!" is not working iirc in earlier versions you could "refine" that view only selection
guso78 has quit [Ping timeout: 260 seconds]
guso78 has joined #openscad
guso78 has quit [Client Quit]
<JordanBrown[m]>
lf94: WRT CSG vs BREP: from what I understand, and I'm not an expert, I don't think the two can even be compared. CSG is an abstract way to describe a shape, constructing it out of primitives, transformations, and operations. BREP is a concrete way to represent a shape.
<JordanBrown[m]>
You could do CSG with any number of underlying representations - mathemetical boundaries, mesh boundaries, voxels, et cetera. You could generate your BREP shape using any number of techniques - CSG, drawing, sculpting, et cetera.
ur5us has joined #openscad
<JordanBrown[m]>
J23: if I understood what I was reading correctly in the source, ! sets the one and only root node of the CSG tree. It is not clear to me what happens if that particular line is executed multiple times and so yields multiple CSG nodes - I think it picks the first one.
<J23>
Yes and it would be convenient if i could "!" the instance and then further down parts of that instance
<J23>
like here https://bpa.st/5APQC it is not possible to view only the sphere (5) because !sphere(s); will use the first instance
<J23>
So i need to * the first one ..
<J23>
at the moment a make a ! at the top .. then checking in line 1234 .. making another ! .. going back to top to remove that .. going back down (F2) .. Also would be nice to activate multiple .. like you have 10 objects and only want to view 2 .. you can't "!" the two .. you need to "*" the other 8 .. or create groups ..
teepee has quit [Remote host closed the connection]
<InPhase>
guerd87: Correct, those images were actually different from JordanBrown[m]'s font work, but JordanBrown[m] logically only updated the tests that failed at that time, and not the tests that should have failed but weren't caught. So I caught them when I improved the image comparison last month, and pushed the updates, which are now merged into your python-support branch.
<InPhase>
guerd87: Well, the bottommost one. A few of the others were changed from other work.
<InPhase>
guerd87: I also manually went through visual comparison of every image replacement at least twice, several of them many more times, so I'm pretty confident they were all correctly replaced (except for the one that was disabled and migrated out to a separate issue.)
teepee has joined #openscad
<JordanBrown[m]>
J23: it seems like coming up with sensible semantics for multiple ! might be tricky. Draw a CSG tree. Mark some number of nodes with !. Now figure out what the effective CSG tree looks like. Explain why. Draw another CSG tree, and mark it. Apply your rules. Is the result what you expect? Lather, rinse, repeat. Remember to maintain compatibility with the existing single-! case.
<InPhase>
JordanBrown[m]: I would interpret multiple "!" as top level union of everything marked !.
<InPhase>
JordanBrown[m]: Unless they are nested... Then the top-most one is the only one with effect.
<J23>
and sequential "!" shouldn't be a problem at least theoretically
<InPhase>
Well, one could argue that maybe nested should ALSO be top level union of both.
<JordanBrown[m]>
I don’t believe those rules let you isolate the sphere(5).
<InPhase>
Although multiple ! is probably most often a stupid thing to do, as it's going to be hard to make useful. But maybe in some rare cases it's useful.
ali1234 has quit [Remote host closed the connection]
<JordanBrown[m]>
AFK now
ali1234 has joined #openscad
<J23>
i mean the ! will not change the evaluation .. you can make a design show faster by them .. only with *
<J23>
s/can /can't
<J23>
InPhase .. if you have a Car with all components .. now you will see only the motor and gear .. sure you probably have some conditionals implemented for this .. but multiple "!" is something i would use quite often and had to use workarounds