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
fling has joined #openscad
<peepsalot> germ: all of openscad internals basically operate on mesh data. so yeah NURBs would mean rewriting a lot. also i'm not sure how one would do boolean ops union/difference/intersection on nurbs data
<germ> Yeah exactly!. But you follow my thinking peepsalot:, cheers !.. Yeah, some things I would have no idea how to go about
<InPhase> peepsalot: What's generating our code coverage report, and does it rely on python2?
<peepsalot> "gcov" i think?
<linext> germ, pymesh might be what you're looking for if there's something not in openscad
<InPhase> peepsalot: I see "gcovr" is used which is a separate install. Might that be missing from our 20.04 and 22.04 setups?
<peepsalot> yeah
<InPhase> I'm testing the github-ci.sh on my 22.04, after installing gcovr
<peepsalot> i have gcovr and gcov executables, and gcov-10, gcov-11, etc for every version of gcc I have
<InPhase> This seems to be a locally runnable script.
<peepsalot> the r is for report generation i think. i don't see gcov being called explicitly, but maybe it gets called when those compile flags are used?
fling has quit [Ping timeout: 255 seconds]
<InPhase> I think it might be a site setting to run that script to do build, test, and coverage.
<peepsalot> gcov - coverage testing tool vs gcovr - generate simple coverage reports
<peepsalot> ^ summary from each man page
<InPhase> This is a slow build... PARALLEL=2 by default. :)
<InPhase> I've gotten used to 8 now.
<peepsalot> i doubt the parallelism has any effect on it
<peepsalot> if you wanted to bump it up locally
<InPhase> It only has an effect on the amount of thumb twiddling I need to do. :)
<InPhase> Although that gives me time to finish my pasta I guess.
fling has joined #openscad
<InPhase> Oh, I probably will need to run "build test coverage" instead of just shortcutting it with "build coverage". That looks dependent. :)
<InPhase> I will let it fail after this build and then do "test coverage".
fling has quit [Remote host closed the connection]
fling has joined #openscad
fling has quit [Remote host closed the connection]
<InPhase> peepsalot: Oh. Do our tests run on 20.04 and 22.04? Because it didn't fail, it just reported 0 coverage when I skipped running the tests. (Trying again with tests.)
fling has joined #openscad
<InPhase> If we're only running tests on one, maybe we migrate that to 22.04
<peepsalot> yep, tests on all 3 Ubuntu LTS
<InPhase> Ok.
fling has quit [Ping timeout: 255 seconds]
<linext> one step closer to getting unit lines and the little cube on the bottom left: https://www.3dcustomizer.net/create/customization/58
<InPhase> peepsalot: Well, that run didn't work, because 20 tests failed...
teepee has quit [Quit: bye...]
<peepsalot> lib3mf?
<InPhase> Oh, I in fact do not have that installed.
teepee has joined #openscad
<InPhase> Maybe I never ran tests since that last hard drive failure.
<InPhase> Thanks for the timely pointer.
<peepsalot> InPhase: also, issue1165 needs updating. i had fixed that in a PR but not merged yet https://github.com/openscad/openscad/pull/4067/files#diff-82ce92289b5ae4894112eed658b839b503c2788567c8b565e71c4c33ce5fa4ab
<peepsalot> InPhase: i'm not sure about the example024 fails though. you could also exclude them with a regex using ctest -E
<peepsalot> i also fixed it so that 3mf tests won't run if the exe wasn't built with 3mf support, in that PR
<peepsalot> InPhase: did you do a fresh pull from master?
<peepsalot> looking at it again, i think the lib3mf thing was actually fixed in an already merged PR
juri_ has quit [Ping timeout: 268 seconds]
juri_ has joined #openscad
<germ> Thank you so much, linext:! I did come across pymesh during my search
<linext> also, meshmixer is pretty good for GUI operations that are somewhat complex
<InPhase> peepsalot: Yeah, apparently it wasn't lib3mf. It still failed on all 20 in the rerun that I just came back to the results of.
<InPhase> peepsalot: Well, I don't know quite how to get to a coverage run if the tests don't pass.
<InPhase> peepsalot: And yes, I appear to be up-to-date.
<InPhase> I had pulled recently.
<InPhase> Well, I fudged running the tar command right after the test failure, and then ran coverage, but it still has 0% coverage.
<InPhase> There might in fact be an issue here locally as well.
<germ> linext: Cheerios! Let me try each
<JordanBrown[m]> peepsalot: Happy to review, whether or not the tool will let you list me as a reviewer.
<germ> Actually Idk whether pymesh is exactly what I'm looking for. Just the name itself and now browsing the doc...
<InPhase> germ: I don't think nurbs and computational geometry are compatible, except as nurbs being a method of producing an input component for later computational geometry.
LordOfBikes has quit [Ping timeout: 268 seconds]
<InPhase> germ: Now I have given a lot of thought to writing a nurbs library for OpenSCAD.
<germ> <3
<InPhase> (Although someone else might have done so already. I haven't searched for it in a while.)
<germ> I think you are right: I remember reading in a book about curves that it was just imposible to solve intersection
<InPhase> germ: A method that is compatible with computational geometry and also preserves curves perfectly is the SDF approach. It's just not particularly suitable for combining with meshes while keeping the SDF. One needs to go all SDF, or convert to mesh for any sort of sensible combination.
<germ> SDF ?
<InPhase> In theory you should be able to write down an SDF for any mesh in a systematic way, except that the results seem to be quite insane.
<InPhase> germ: Signed-Distance Function, where you define all 3D models as a function where 0 is the surface, and other values represent the distance outside or inside of the surface.
<InPhase> Combinations of those SDFs are then done by mathematical operations for things like unions, intersections, chamfering, and so on.
<InPhase> It does some things very elegantly that meshes do poorly. But it has some downsides in comparison, such as inferior representation of crisp edges and poor control over tesselation.
<germ> What keeps me thinking about it is that in my case I think I'd know how to go about the opreations.. But it is a simple case, I wonder about all the other operations. Now... that cheat-sheet isn't very long :p
<germ> I can open a feature request, get the ball rolling. I'm happy to start looking too
<InPhase> If you're simply worried about keeping curves smooth, however, just drop $fa=1; $fs=0.4; at the top of your OpenSCAD script, and everything will come out beautifully for a standard printer.
LordOfBikes has joined #openscad
<germ> It's for video games :p
<InPhase> Well that can work too.
fling has joined #openscad
<germ> And in general, it feels more efficient, if it is at all possible !
<InPhase> I'm fairly confident no one will implement a nurbs output for OpenSCAD any time soon. I've been wrong before about some of those guesses, but that would be some spectacular effort that would require abandoning all the core libraries in use to do most of the geometry calculation, and would probably require a few doctoral theses worth of clever math work.
<germ> I think you are right, InPhase:.
<germ> I'm curious what this guys have: https://smlib.com/
<InPhase> Probably 20 decently paid full-time programmers on staff. :)
fling has quit [Ping timeout: 255 seconds]
<germ> XP. I found this also fishing randomly https://math.stackexchange.com/questions/468958/how-do-i-find-the-outline-resulting-from-the-intersection-of-a-nurbs-surface-and But it is the `simple' case (yet it's alrdy complicated.)
fling has joined #openscad
<InPhase> peepsalot: Okay, I made a copy of the github-ci.sh script (45 minutes ago) set to skip all the failing tests, and reran. It completed now, and produced a coverage report, but they are all still 0% coverage. So I confirm this is not due to a run error, nor due to a problem with the CI server, but is actually something broken.
<InPhase> peepsalot: I don't know this gcda file format that is apparently the input for coverage reports, but it looks like it has a lot of small positive and negative 32-bit ints in it, and they are non-zero. So I'm going to heuristically guess the problem is happening at the point of the gcovr run.
<InPhase> peepsalot: I kind of thought trying it this way would give actionable information. But it really just looks like success.
<InPhase> One bit of info I see, under the premise of blame gcovr, is that 4.2 (the one in 20.04) introduced dropping support for an older syntax.
fling has quit [Ping timeout: 255 seconds]
<InPhase> peepsalot: Well, I went through a few options in gcovr issues, but I don't see anything actionable here to fix it. I also tried verbose running. And I tried disabling the parallel run of gcovr (since that's not enabled for the 18.04 version), but no help there either. There's just no information to indicate any direction of a problem. *shrug*
J222899 has joined #openscad
fling has joined #openscad
J2228 has quit [Ping timeout: 260 seconds]
ur5us has quit [Ping timeout: 252 seconds]
<peepsalot> InPhase: is there any info in this dir? -fprofile-dir=.gcov
<InPhase> Yeah, that's where all the *.gcda files ended up.
use-value has quit [Remote host closed the connection]
<InPhase> But it's a binary format that I don't know how to parse.
use-value has joined #openscad
<InPhase> Those are the files that I mentioned appearing to have a bunch of non-zero 32-bit signed integers, plus some other stuff in a structure.
ABSHK has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
ABSHK has joined #openscad
little_blossom has quit [Ping timeout: 268 seconds]
<peepsalot> "The .gcno files are placed in the same directory as the object file. By default, the .gcda files are also stored in the same directory as the object file, but the GCC -fprofile-dir option may be used to store the .gcda files in a separate directory."
<peepsalot> i wonder if that profile-dir is actually messing things up. or we need to move files around, post testing
<gbruno> [github] glechapelain opened issue #4436 (Output curved surfaces) https://github.com/openscad/openscad/issues/4436
<peepsalot> InPhase: "It is not recommended to access the coverage files directly. Consumers should use the intermediate format that is provided by gcov tool via --json-format option."
<peepsalot> hmm, maybe the json comment doesn't apply to gcovr though
<peepsalot> I saw in gcvor man page this option which might help? --object-directory OBJDIR Override normal working directory detection. Gcovr needs to identify the path between gcda files and the directory where the compiler was originally run. Normally, gcovr can guess correctly. This option specifies either the path from gcc to the gcda file (i.e. gcc's '-o' option), or the path from the gcda file to gcc's working directory.
<peepsalot> JordanBrown[m]: re: code review, I was referring to this PR: https://github.com/openscad/openscad/pull/4433
<peepsalot> JordanBrown[m]: mainly curious what others thought about the changes to warnings, which can be seen in the expected test output files
<peepsalot> i will also accept "thumbs up" reactions to the PR as shorthand for "I looked over the changes and approve" :D
hrberg has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
hrberg has joined #openscad
<JordanBrown[m]> peepsalot: looks good to me. I suggested some wording simplifications - your choice.
<InPhase> peepsalot: Well, I tried to ignorantly hammer away at doing things there, without any comprehension of what is actually needed. The closest to working was this one: https://stackoverflow.com/a/43586279
<InPhase> peepsalot: I ran that *.gcno command inside of each directory that has a gcno file in it. Then I ran the second command, and I got 0% coverage on everything except the lexer .l and .y files, which are now 100% coverage.
<peepsalot> 100%, noice!
<peepsalot> :P
<InPhase> But it also says 0 out of 0 on that one. It just decided this is 100%. ;)
<peepsalot> lol
<InPhase> So it changed something, but I suspect that's not the issue.
<InPhase> Time for bed.
ur5us has joined #openscad
peepsalot2 has joined #openscad
peeps[win] has quit [Ping timeout: 256 seconds]
fling has quit [Ping timeout: 255 seconds]
fling has joined #openscad
ur5us has quit [Ping timeout: 260 seconds]
little_blossom has joined #openscad
Guest61 has joined #openscad
Guest61 has quit [Quit: Client closed]
ur5us has joined #openscad
Guest79 has joined #openscad
Guest79 has quit [Client Quit]
fling has quit [Ping timeout: 255 seconds]
fling has joined #openscad
fling has quit [Ping timeout: 255 seconds]
ur5us has quit [Ping timeout: 256 seconds]
teepee has quit [Ping timeout: 255 seconds]
teepee has joined #openscad
teepee has quit [Excess Flood]
teepee has joined #openscad
teepee has quit [Remote host closed the connection]
teepee has joined #openscad
ToAruShiroiNeko has quit [Ping timeout: 246 seconds]
ToAruShiroiNeko has joined #openscad
<gbruno> [github] dannypike synchronize pull request #4126 (Support building under Visual Studio on Windows) https://github.com/openscad/openscad/pull/4126
ToAruShiroiNeko has quit [Ping timeout: 252 seconds]
ToAruShiroiNeko has joined #openscad
juri_ has quit [Ping timeout: 255 seconds]
juri_ has joined #openscad
rustyaxe has left #openscad [#openscad]
guerd87 has quit [Quit: Leaving]
la1yv has quit [Remote host closed the connection]
la1yv has joined #openscad
guerd87 has joined #openscad
snaked has quit [Quit: Leaving]
teepee_ has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
aiyion has quit [Ping timeout: 255 seconds]
aiyion has joined #openscad
aiyion has quit [Remote host closed the connection]
aiyion has joined #openscad
use-value has quit [Remote host closed the connection]
use-value has joined #openscad
J222899 has quit [Quit: Client closed]
J222899 has joined #openscad
J222899 has quit [Quit: Client closed]
J222899 has joined #openscad
use-value1 has joined #openscad
use-value has quit [Ping timeout: 264 seconds]
use-value1 is now known as use-value
<gbruno> [github] jordanbrown0 opened issue #4437 (Add support for sets) https://github.com/openscad/openscad/issues/4437
<gbruno> [github] thehans synchronize pull request #4433 (Fix for issue #4432) https://github.com/openscad/openscad/pull/4433
<gbruno> [github] thehans pushed 5 additions 6 modifications (Merge pull request #4433 from thehans/issue4432 Fix for issue #4432) https://github.com/openscad/openscad/commit/40aae29c3b71bc333bc1d013801b51ede99465ee
<gbruno> [github] thehans closed pull request #4433 (Fix for issue #4432) https://github.com/openscad/openscad/pull/4433
<gbruno> [github] thehans closed issue #4432 (linear_extrude regression for `slices=0`) https://github.com/openscad/openscad/issues/4432
Guest17 has joined #openscad
Guest17 has quit [Client Quit]
JakLareo has joined #openscad
JakLareo has left #openscad [#openscad]
<linext> something about include <text_on.scad> is not working for the WASM file system
<linext> possibly because it ends with \n
<linext> i appended the file onto my code, and it worked
Guest61 has joined #openscad
<JordanBrown[m]> I believe that OpenSCAD is pretty good about dealing with both \r\n and \n line endings.
<linext> correct, removing the \n from the included file didn't have an effect
<linext> i suppose i could chop out parts of the imported file and see if it starts working
Guest61 has quit [Quit: Client closed]
<linext> what's strange is that the WASM file system claims that it can't find the file
<linext> however, this example works: https://www.3dcustomizer.net/create/customization/79
<JordanBrown[m]> teepee, InPhase: for Life, I was kind of thinking of the animation having several parts: a few flips of a blinker, then maybe a glider crossing the screen, then maybe as many generations of the R pentonimo as will fit in 50x50, then a glider gun running for a while. I could make that be a single animation, but it would be easier to make N animations and concatenate them. What do you think?
<linext> maybe i can get some feedback on what's making this code slow to load: https://www.3dcustomizer.net/create/customization/118
<linext> on the PC it's only a few seconds
ur5us has joined #openscad
<gbruno> [github] thehans synchronize pull request #4067 (Use cmake for install and packaging with Windows) https://github.com/openscad/openscad/pull/4067
teepee_ has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
<gbruno> [github] thehans opened pull request #4438 (Fix additional close parenthesis causing compile errors.) https://github.com/openscad/openscad/pull/4438
<JordanBrown[m]> Trivia: a glider gun on a wraparound 50x50 board self-destructs around 200 generations.
<peepsalot> that just means the wraparound is broken
<peepsalot> oh, glider *gun*, nevermind
ur5us has quit [Ping timeout: 260 seconds]
ur5us has joined #openscad
<InPhase> JordanBrown[m]: Normally I keep animations very short to keep file size down, but because your animation there is discrete, you can go much longer. So sure, boost it up with a few varieties.
<InPhase> JordanBrown[m]: If you have 3 frame transitions per second, you could probably go as long as 5 minutes!
<InPhase> Maybe check file size as you're going, so you don't waste time on things you can't use.
<InPhase> JordanBrown[m]: The grass is 30MB, which is probably a good max target. If you get to 100MB, you won't even be able to push it to github.
<Scopeuk> is this as a gif?
<Scopeuk> perhaps this is a use case for webm?
<gbruno> [github] thehans closed pull request #4438 (Fix additional close parenthesis causing compile errors.) https://github.com/openscad/openscad/pull/4438
<gbruno> [github] thehans pushed 1 modifications (Merge pull request #4438 from thehans/issue4432 Fix additional close parenthesis causing compile errors.) https://github.com/openscad/openscad/commit/972d1846400bfce71e20cfe94683daeeed25ba1d
<InPhase> Scopeuk: I used webp
<InPhase> But we can also use gif. I'm not sure which will work better for the Life case with such slow frame rates.
<InPhase> I never tried making such a slow webp, but maybe that works fine.
<Scopeuk> true my understanding is at low frame rate and simple block colours gif is quite effective
<InPhase> This is my webp generation method, after apt install webp: img2webp -v -loop 0 -d 33 -lossy -q 97 -m 4 frames/frame*.png -o happy_grass.webp
<InPhase> -d is image duration in milliseconds.
<InPhase> So this is my approximately 30fps approach.
<peepsalot> animated gif is limited to 256 palette colors which can make for annoying banding
<peepsalot> apng would be nice. https://caniuse.com/?search=apng that even does partial transparency, whereas gif is basically 1bit alpha channel
<peepsalot> looks like supported by all recent browsers except for android browser unfortunately
<peepsalot> or opera mini, which apparently has a user base 2x that of android browser
<peepsalot> oh, those are also 8 or 9 years old... the current android browser is branded "chrome for android" now
<peepsalot> but it looks like webp has about at the same browser support too. i don't know much about capabilities of that format. probably no need for multiple formats anyways
<InPhase> I picked webp last year because it made the stuff I was doing prettier, and seemed to google as having widespread support.
<InPhase> But we can also always assume gif is supported, it's just usually bulkier.
<InPhase> So this year I just copy/pasted my webp making script. But if it's hard or inconvenient for anyone, or doesn't fit a particular design well, I think we can use anything that's widely supported.
<InPhase> If somebody can't see one video on one ancient device, that's life. They're probably used to problems.
teepee has quit [Remote host closed the connection]
<InPhase> Looks like J222899 used gif last year, and nobody filed any protests. But if we're keeping them in the repository, we want to generally be mindful of size.
<InPhase> gif might do better on Life though. It'd be worth comparing both and seeing.
<J222899> mp4 is much smaller though
<InPhase> It is, but I think there was a noticeable quality reduction on my design last year with that.
<InPhase> I vaguely remember gradients getting disrupted.
teepee has joined #openscad
<J222899> gif  is terrible for color with light and transparency
<J222899> you can see this on the penrose star where strange color artifacts apear
<J222899> isn't that jpeg animation thing the best choice?
<gbruno> [github] thehans synchronize pull request #4067 (Use cmake for install and packaging with Windows) https://github.com/openscad/openscad/pull/4067
<teepee> except google decided to rip it out of chrome, so there's that
aiyion has quit [Ping timeout: 255 seconds]
<J222899> i think firefox you also need to enable it iirc
aiyion has joined #openscad
<J222899> https://jpegxl.io/tutorials/firefox/     "download the nightly" ↦
J22289998 has joined #openscad
J222899 has quit [Ping timeout: 260 seconds]
<peepsalot> it looks like its competitor AVIF has wider support across browsers
<peepsalot> seems like both are too bleeding edge for now though
aiyion has quit [Remote host closed the connection]
aiyion has joined #openscad
<teepee> readme updated in order of the doors (plus script to generate)
<teepee> I tried updating the track.png and it still does not show on github, probably a size issue or something
snaked has joined #openscad
<gbruno> [github] thehans synchronize pull request #4067 (Use cmake for install and packaging with Windows) https://github.com/openscad/openscad/pull/4067
<teepee> yeah, the image seems fine, but it does not work in the readme
<teepee> wait, you get it with that exact url?
<teepee> hmm, let me try with chrome
<teepee> hmm, works with chromium
<teepee> strange
<teepee> oh, content-security-policy something something
<J22289998> oh julia looks nice
ur5us has quit [Ping timeout: 260 seconds]
<teepee> animation would be cool, but I'll probably not have the time to do that
J22289998 is now known as J22
<J22> color animation?
<J22> or  to change the julia set
<teepee> change the set, moving the c constant around basically
<J22> looks like only small changes are nice .. there is  a lot  "nothing" between
<teepee> oh, interesting, maybe doing a couple of linear interpolations would work
<othx> J22 linked to YouTube video "Julia Set Fractal Animation" => 1 IRC mentions
<J22> sec 18 - 25  .. is the sweetspot
<teepee> so in the overview image that is just starting at the circle and goes straight up way out of that picture
<teepee> which does not seem to be the most interesting path :)
J22 has quit [Quit: Client closed]
J22 has joined #openscad
<teepee> second 22 is about top middle I suppose