<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?
<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.
<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>
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.
<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.
<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
<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.
<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]
<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?
<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.
<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?