teepee changed the topic of #openscad to: OpenSCAD - The Programmers Solid 3D CAD Modeller | This channel is logged! | Website: http://www.openscad.org/ | FAQ: https://goo.gl/pcT7y3 | Request features / report bugs: https://goo.gl/lj0JRI | Tutorial: https://bit.ly/37P6z0B | Books: https://bit.ly/3xlLcQq | FOSDEM 2020: https://bit.ly/35xZGy6 | Logs: https://bit.ly/32MfbH5
aiyion1 has quit [Ping timeout: 255 seconds]
aiyion1 has joined #openscad
aiyion1 has quit [Remote host closed the connection]
aiyion1 has joined #openscad
aiyion1 has quit [Remote host closed the connection]
aiyion1 has joined #openscad
ur5us has joined #openscad
teepee_ has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
snaked has joined #openscad
snaked has quit [Remote host closed the connection]
snaked has joined #openscad
snaked has quit [Client Quit]
snaked has joined #openscad
LordOfBikes_ has quit [Ping timeout: 255 seconds]
Av8r has joined #openscad
Av8r has quit [Quit: Connection closed]
LordOfBikes_ has joined #openscad
ur5us has quit [Ping timeout: 260 seconds]
ur5us has joined #openscad
drfff has joined #openscad
ur5us has quit [Ping timeout: 255 seconds]
ur5us has joined #openscad
ur5us has quit [Ping timeout: 248 seconds]
J238375533 has joined #openscad
qeed has quit [Ping timeout: 255 seconds]
J2383755 has quit [Ping timeout: 260 seconds]
Lagopus has joined #openscad
TheAssassin has quit [Remote host closed the connection]
qeed has joined #openscad
TheAssassin has joined #openscad
teepee_ has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
guso7835 has joined #openscad
guso7835 has quit [Client Quit]
guso7835 has joined #openscad
guso7835 has quit [Client Quit]
TheAssassin has quit [Quit: No Ping reply in 180 seconds.]
ur5us has joined #openscad
TheAssassin has joined #openscad
ur5us has quit [Read error: Connection reset by peer]
Guest41 has joined #openscad
L29Ah has quit [Ping timeout: 255 seconds]
Guest41 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
jonasbits has joined #openscad
Guest41 has joined #openscad
Guest41 has quit [Quit: Client closed]
use-value has joined #openscad
marcus has quit [Remote host closed the connection]
marcus has joined #openscad
teepee has quit [Remote host closed the connection]
teepee has joined #openscad
califax has quit [Remote host closed the connection]
califax has joined #openscad
teepee_ has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
guso78 has quit [Quit: Client closed]
L29Ah has joined #openscad
califax has quit [Ping timeout: 255 seconds]
califax has joined #openscad
use-value has quit [Remote host closed the connection]
use-value has joined #openscad
milza has quit [Quit: milza]
Guest89 has joined #openscad
Guest89 has quit [Client Quit]
guso78 has joined #openscad
guso78 has quit [Client Quit]
teepee_ has joined #openscad
teepee_ has quit [Remote host closed the connection]
teepee_ has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
tcurdt has quit [Ping timeout: 255 seconds]
Lagopus has quit [Ping timeout: 246 seconds]
guso78 has joined #openscad
SenFache has quit [Read error: Connection reset by peer]
Sauvin has joined #openscad
GNUmoon has quit [Ping timeout: 255 seconds]
GNUmoon has joined #openscad
Shivam67 has joined #openscad
Shivam67 has quit [Client Quit]
Shivam6 has joined #openscad
Shivam57 has joined #openscad
Shivam6 has quit [Client Quit]
ur5us has joined #openscad
Shivam57 has quit [Quit: Client closed]
guso78 has quit [Ping timeout: 260 seconds]
qeed_ has joined #openscad
qeed has quit [Ping timeout: 252 seconds]
<linext> dates from 01 to 31 can be displayed using 12 sides on two cubes
<teepee> neat
<teepee> that may want to get a customized version :)
<Scopeuk> those (not printed) are very common in the uk
<Scopeuk> my grand parents and parents have them
<linext> i have a question
<linext> i did a presentation on advanced 3d printing
<linext> someone asked what would happen to an STL file if the normals were incorrect
<linext> so i took a tetrahedron and put junk into the normal of the first polygon
<linext> kisslicer didn't even notice
<linext> so what are those normal vectors for?
<InPhase> HimeHaieto: Well, I think Firefox is really good at wasting RAM, probably in large part being the fault of various site designs, and occasionally the fault of memory leaks. But OpenSCAD seems to be really good at actually making use of RAM for things that kind of make sense when used at scale.
<InPhase> I'll be fair and note we DID have that one memory leak, from that nefarious function literals issue. But we fixed it.
<InPhase> And that leak was rarely significant in real designs and usage. I constructed a kind of silly testcase to highlight that issue.
teepee_ has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
<HimeHaieto> I find myself more concerned with accuracy/correctness issues when working with openscad than memory consumption or render time
<HimeHaieto> I actually earlier came across my first critical precision error - for "spacing = length / 4", length - spacing was deemed to be larger than length * 3 / 4 and thus caused an object in a loop to get skipped
<HimeHaieto> also I've seen a number of cases where the rendered mesh had clear issues with cutouts not showing cleanly (instead getting weird chaotic garbledy-goop in the hole that scrambles around almost like an old tv without reception when moving the camera around)
<HimeHaieto> most recently encountered with two cutouts in the same translation block of a for loop..."fixed" by...making an exact copy of the translation for each cutout instead of sharing the same statement line...because that makes sense...
<HimeHaieto> I think much of the precision related stuff may potentially be more in the realm of cgal though, but iono
<HimeHaieto> and yes, firefox is indeed really good about wasting ram, and it doesn't help that they've almost sort of prided themselves on it in actual statements/commentary on the matter - apparently in their mindset unused memory is what's really wasted memory/potential, and they clearly don't like to think of their software as being anything other than the primary or even sole software/focus when running
<HimeHaieto> concepts like multitasking, shared resources/contention, system-level memory management, or just in general the notion that anything else may exist on the system (or need to run concurrently with firefox) that could need or make better use of memory than their precious application
<HimeHaieto> just a classical single-user, mostly-single-application kind of mindset
<teepee> wait, *other* aplication than a webbrowser? ;-)
<HimeHaieto> I still clearly remember the days when by necessity we had to close most or all other software before launching a new one (particularly for bigger things), but while those days ought to have long since passed by now, I'm not convinced a number of firefox developers ever truly left that era or grew beyond that
<HimeHaieto> sorry, have a bit of a history/beef with firefox devs...
* teepee assumes they will progress to invent all the things the operating system is doing
<HimeHaieto> and my point exactly, teepee :p
<teepee> so at some point we just drop the kernel and call it gnu/firefox :)
<HimeHaieto> gotta prepare for web 7.0, when your browser is expected to handle all aspects of the system from bootstrapping onward, and you'll be fiiine, because no way a web site might break your usb devices or virtualisation with some bad or even nefarious javascript
<HimeHaieto> teepee: well, there was that whole "firefox os" thing...
<teepee> I remember the name, but no details at all... must... resist... clicking... the... link...
<HimeHaieto> "the applications use open standards and approaches such as JavaScript and HTML5...and open web APIs that can communicate directly with hardware"
<HimeHaieto> see, the "jokes" I made weren't necessarily even as far-fetched as you might like to think, should firefox devs get their run of things
<HimeHaieto> sometimes they seriously do seem to think they own or ought to own the place
<InPhase> HimeHaieto: That "accuracy / correctness" issue sounds like standard floating point comparison issues. It's worth doing such things as integers and then applying a scaling factor to get the actual dimensions, to avoid these. That's common to all programming languages.
<InPhase> As for cutouts not showing properly, this requires following "the overlap rule" that you will see under "Note:" in the manual for union and difference.
<InPhase> This is again a fundamental issue about floating points.
<InPhase> (And not a bug.)
<InPhase> HimeHaieto: This has always been an issue, but I wrote out those "Note:" sections of the manual myself to try to make it extra clear, because nearly all initiates to the language seem to make this mistake and then want it to be fixed. But it's not broken, it's just a requirement of following the overlap rule to make the math involved valid.
<HimeHaieto> again, for the cutout part, it was like: "translate([1, 2, 3]) {foo(); bar;}", which didn't work right, versus "translate([1, 2, 3]) foo(); translate([1, 2, 3]) bar();", which did...that doesn't seem like it has anything to do with overlap to me
<InPhase> It can be.
<InPhase> There's an example showing why in the manual. :)
<InPhase> It can trigger if foo and bar have additional non-integer offsets inside.
<JordanBrown[m]> I understand the math problems, but practically it seems like, especially if we have a grid snap concept, we could snap anything thinner than 10^-10 to being nonexistent.
<JordanBrown[m]> Of course, I am totally handwaving away the difficulty of *implementing* such a thing.
<InPhase> JordanBrown[m]: It's certainly a lot trickier when it's in the middle of a geometry calculation.
<HimeHaieto> inphase: foo was a cylinder, bar was a square, and they both used the same value for diameter/length...it was so incredibly straightforward it didn't seem like there should ever be a problem with it
<JordanBrown[m]> Yeah, but do you need to do it in the middle, or do you only need to do it when displaying the result or exporting?
<HimeHaieto> also, it was the cylinder specifically that got the problem, which also happened to be the first child of the combined translation
<InPhase> JordanBrown[m]: In the middle, because you can get CGAL exceptions from invalid geometries mid-calculation from this problem, and the whole rendered piece disappears.
<InPhase> HimeHaieto: I'd have to see a complete testcase to know specifically what the issue was.
<InPhase> HimeHaieto: But I can certainly note that many of the failure cases are unintuitive.
<JordanBrown[m]> Ah, I was thinking only of z-fighting.
<InPhase> JordanBrown[m]: Yeah. That's the best-case outcome. :)
<HimeHaieto> inphase: my file is like 1k lines long, not sure if you'd want to see it lol
<InPhase> JordanBrown[m]: And maybe the worst teacher, because it makes people think it's just a display problem.
<JordanBrown[m]> I keep wondering how much of this is caused by grid snap, and whether we'd be better off with either no grid snap or a much finer grid. I need to find the implementation and build an experimental with a much finer grid and see whether I start running into other problems.
<InPhase> JordanBrown[m]: "grep -r GRID". It's pretty easy to do a finer grid.
<teepee> the remeshing stuff from fast-csg is likely a better option
<teepee> or who knows, maybe not even needed at all with Manifold
<teepee> question is if anyone will ever find enough time to find out :)
<InPhase> JordanBrown[m]: It's GRID_COARSE and GRID_FINE in Grid.h. I have confirmed there are some fine structure issues that sometimes go away with a finer grid, when doing very small features. So I'd love to be rid of it. But I don't think it solves the fundamentals of the overlap rule.
<JordanBrown[m]> I expect that it's easy. It just hasn't percolated to the top of my stack.
<InPhase> HimeHaieto: I'm not afraid of a large file if you can point to a relative point in it to focus on.
<InPhase> HimeHaieto: Although I note that is uncommonly long for a scad file. :) My longest one appears to be 632 lines.
<InPhase> Of scad files I've downloaded and saved, only 7% are longer than this, and less than 1% are over 1000 lines.
Av8r has joined #openscad
<InPhase> I like to break things apart if they get too big. Libraries are good.
<InPhase> Why solve one problem when you can solve an entire set of them?
<HimeHaieto> haven't regenerated it in a bit, but zoomed out as far as that it wouldn't look all that different now from how it did then
<HimeHaieto> either way, I think that gives a good visual idea of what I'm working on
<InPhase> I see the visual relics of the outdated release. :) I think we cleaned up that green there between 2019 and 2021.
<teepee> hi Av8r - was that you working on the PDF stuff? (sorry if not, my brain is overloaded with spaghetti C code ;-)
<Av8r> (Yes, Export PDF dialog, with some new features).   I'm wrapping up coding/testing an ExportPdf Dialog box.   All the new features test out okay, but there are two odd observations.   First, when I run the new Openscad build from the command line (but with GUI, to test the code), messages show up for "no  matching signal for
<Av8r> on_okButton()_clicked" and for "...on_cancelButton()_clicked".   The buttons work as expected in the new dialog box, and the signals are mapped  (accept() to accepted()) in the ui header file for my new code.   Is this a spurious message, or am I missing something?  The dialog box is executed with exec().
<InPhase> Av8r: Is there a pdf up for it?
<InPhase> I mean.
<teepee> sounds like some auto-connect fails, if you additionally attach the signals in code it would work
<InPhase> Is there a PR up for it?
<Av8r> Other observation:  LOG messages no longer are showing up in the Error console, instead are showing up in stderr when I run from the command line.  The app also shows the current date in the status bar. I know the LOG messages used to be display in the window.
<Av8r> No PR yet.  I want to sort out these issues.
<teepee> right no PR, but lots of details in the issue ^
<Av8r> Also, selection persistence is only within the app (during a single run), default values on start-up.  Seems like I should integrate it with Preferences/Settings, at least for the paper size.
<InPhase> Av8r: Ok. I was going to glance at the connect code and see if anything jumped out at me. There are a few gotchas in that system.
<teepee> I think if you call it on_<name>_clicked it tries to auto-connect that
<Av8r> I also might play a little bit more with the opacity/line width of the grid feature to improved discernability of the geometry on-screen in the PDF.
<teepee> not sure where the () in that message come from, those might be the reason for the warning
<Av8r> Okay, so if I rename the signals it might remove that message.
<InPhase> Av8r: See src/gui/PrintInitDialog.h and .cc maybe
<teepee> worth a try, I have not touched Qt code for maybe a year or so, so I might start to misremember things
<Av8r> Probably need to update my notes in 4143.  I went back to embedding the options (indirectly) in the exportInfo structure.  Added a pointer, which points to the options structure, rather than passing a separate reference.  Cleaner since it passes through several intermediary methods on the way to the ExportPdf code.
<Av8r> Yes, I used PrintInitDialog as my guide.
<Av8r> Thx,
<InPhase> Ok.
<Av8r> I've not yet pushed the code to my github fork.  Since it seems to be functional, I guess I could do that and others could throw darts at it.
<teepee> please! it does look very cool from both description and screenshots already
<Av8r> I think it touches three existing files (mainwindow.cc, export.h, exportPdf.cc), and adds three (the exportPdfDialog.h, .cc, and .ui).
<Av8r> I will put it on githhub.  It's been several years since I've done so, so it may take me a few minutes...   :)
<teepee> no rush, already past midnight here and I'm fighting with a > 3400 lines of code C file which includes inline Oracle SQL
<teepee> so assuming I win, I'd love to have a look :)
<Av8r> There is still some cruft commented out in the exportPdfDialog files.  I first tried to use maps to manage the interface between the dialog and the main code, but I could not get them to compile.  So I reverted to switch statements and one set of if/elseifs.
<teepee> as for the logging code, that needs fixing. it currently uses some static pointers to switch where the output goes, which is horrible
<teepee> so either you ignore the problem to be fixed along with the other places
<teepee> or you need to call some "log-to-console-now" before running the dialog
<teepee> setCurrentOutput();