<InPhase>
kintel: It should be pretty easy to setup. The only annoying part will be trying to wedge it into the cmake file.
L29Ah has quit [Read error: Connection reset by peer]
<InPhase>
As we all know, CMakeLists.txt spells are part of an arcane dark art, for which the scrolls containing the proper spells are hard to find and in obscure language.
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
kintel has joined #openscad
<kintel>
InPhase: heh, very true. It's also important to keep CMakeList.txt as clean as possible to avoid accumulating tons of cruft which we don't dare clean up
<InPhase>
kintel: I think I actually got it, with a pretty reasonable CMakeLists.txt set of content.
<InPhase>
It sets up and validates the environment, and cleans it up on make clean now.
<InPhase>
And I "think" it's done in a cross-platform manner, but the CI will be the test of that.
<InPhase>
Now I need to make sure it actually runs all the tests properly. :)
L29Ah has joined #openscad
<InPhase>
Do we have any other usage of ImageMagick other than this image comparison?
<peepsalot>
kintel: btw do you have any settings to update circleci's configuration regarding IRC? failing circle-ci jobs give a message "Attempt to post message to channel #openscad on irc server chat.freenode.net:6667 failed"
<InPhase>
I left it in as a configurable option to fall back to the old ways, but if it's not used anywhere else this would remove a dependency on that as a requirement.
<kintel>
InPhase I believe the image compare is the only ImageMagick usage
<kintel>
I don't know about the IRC integration
<JordanBrown[m]>
A while back somebody (InPhase? kintel?) said something about a version of ImageMagick that didn't include "compare". I'm not sure, but I think that older versions had a bunch of independent executables while newer versions just have "magick" with a bunch of subcommands.
<kintel>
compare is just a symlink to magick on my installation
<InPhase>
JordanBrown[m]: Yeah, it was missing for me on graphicsmagick.
<InPhase>
Which is supposed to be the more maintained version of imagemagick.
<InPhase>
So I interpret this as we're relying on kind of deprecated things.
<InPhase>
So I backported to old imagemagick to do this comparison. I would like to switch back to graphicsmagick though. :)
<InPhase>
imagemagick has, believe it or not, had security holes unearthed in its usage a few years back.
<InPhase>
Although you have to have a special sort of setup for that to matter, it still indicates that you want something maintained, even for image manipulation.
<InPhase>
But, if it works well enough for the problem, I think there's a huge benefit to a Pillow/Python based image comparison solution. It opens the door to the possibility of custom comparisons if the standard one does not capture what we're trying to test on a particular test.
<InPhase>
Once you have infrastructure with pillow and numpy, and the test name is being passed in as the file basename, you can add in triggering off of that to custom tests.
<JordanBrown[m]>
I have no real opinion, other than that I think our time is not well-spent trying to figure out how to do image comparisons.
<InPhase>
The basics of that part I solved in like 30 minutes. But I do that sort of analysis for a living.
<InPhase>
The rest is just setting it up to actually integrate. :)
<InPhase>
Now if I could figure out what's eating the standard error outputs of what ctest is running, I could maybe figure out why cmake is not switching over to the newly configured setup.
<InPhase>
These are the tricky parts...
Bocaneri has joined #openscad
Bocaneri is now known as Guest9402
Sauvin has quit [Ping timeout: 252 seconds]
Guest9402 is now known as Sauvin
Guest9189 has joined #openscad
Guest9189 has quit [Client Quit]
J2356 has joined #openscad
J23 has quit [Ping timeout: 260 seconds]
<InPhase>
Okay, lesson learned. Don't do things the right way.
<JordanBrown[m]>
Never.
<InPhase>
Our testing infrastructure doesn't update at all if you do your builds in a build directory like you're supposed to. :)
<JordanBrown[m]>
"doesn't update"?
<InPhase>
Or I guess it does, but then it's hiding in the build directory, where I didn't think to look for it.
<JordanBrown[m]>
Well, yeah, all build products go into the build directory.
<InPhase>
Kind of obvious, but I didn't realize that would get vectored into there, because it wasn't part of what I was trying to build.
<InPhase>
And unfortunately it decimates the code that makes the venv, somehow.
<InPhase>
In addition to don't do things the right way, don't do them the wrong way either. CMakeCache.txt is such a leaky abstraction. This is why I had been so dedicated about building in build directories.
ur5us has quit [Ping timeout: 256 seconds]
ur5us has joined #openscad
Lagopus has quit [Ping timeout: 248 seconds]
Lagopus has joined #openscad
guso78 has quit [Ping timeout: 260 seconds]
greenbigfrog has quit [Ping timeout: 252 seconds]
<InPhase>
Okay. I got it working correctly on the full battery of tests.
<InPhase>
It seems we have quite a pile of images that are wrongly out of date. e.g. tests/output/opencsgtest/text-font-symbol-actual.png tests/regression/opencsgtest/text-font-symbol-expected.png
<InPhase>
This one I can confirm the last release reproduces close to the "expected", but master branch is deviated significantly from it in the font layout. That should have been recognized long ago.
<InPhase>
Maybe it was a purposeful change, but we sure should have noticed it. :) That's what the tests were for.
greenbigfrog has joined #openscad
<InPhase>
Here, one surface went from 2 triangles to 14 triangles, and this was not previously flagged. tests/output/opencsgtest/linear_extrude-parameter-tests-actual.png tests/regression/opencsgtest/linear_extrude-parameter-tests-expected.png
<InPhase>
Yeah, I'm sold. 23 new test failures, and it seems they all should have been.
<InPhase>
It's getting late. Working out the cmake mess took too long, so I'll have to PR it tomorrow.
<InPhase>
If this comparison modality causes an inconvenience in the future, my apologies in advance. :) But it certainly seems to match up significantly better with our full set of current tests.
<kintel>
Very cool! We did indeed have a too lax comparison and it's good to weed out these
<kintel>
I'll submit my PR in the meantime, to get the ImageMagick implementation updated, just in case anything goes wrong
<JordanBrown[m]>
InPhase The textmetrics work did include a couple of deliberate layout changes. One, that affected everything, was that there was a 2.4% error in all spacing, that I fixed. There were also bugs in vertical text layout. I had to fix a number of tests, but I didn't analyze the tests that passed to see if they *shouldn't* have passed.
use-value1 has joined #openscad
<JordanBrown[m]>
I did a pretty complete writeup at the time; I could dig it out of the mailing list archives if you're interested.
<InPhase>
JordanBrown[m]: And, thanks. I think I will end up bundling the test updates with the PR updating the tester. At least I know those were on purpose. :)
<InPhase>
The linear_extrude ones were probably a byproduct of that twisting while extruding work. Was that peepsalot doing something with adding layer lines in some cases there?
<peepsalot>
there was segmentation of outlines added, but i think the expected files were changed with that, unless i made some later minor tweaks and didn't catch the difference
<peepsalot>
too hard to remember, git bisect required if you really wanna know :P
guso78 has joined #openscad
use-value has quit [Ping timeout: 264 seconds]
use-value1 has joined #openscad
<kintel>
peepsalot I think I understand the libfmt challenge now.
<kintel>
This is a tricky library to debug btw.
<peepsalot>
kintel: yeah, and did i mention i'm not fond of the documentation :-/
<kintel>
My understanding is that we pretty much have to define our own format spec for our custom datatypes
<kintel>
..which is in itself a bit tricky, as it's a variant
<kintel>
..but as you hinted towards, the spec would say thing like: every time you encounter a float, use ".6f" etc., just need to encode that somehow
<JordanBrown[m]>
I got a printf-like function almost working.
<JordanBrown[m]>
I failed on variable widths, the equivalent of %*d; libfmt really wanted those to be integers and the OpenSCAD values were doubles.
use-value has joined #openscad
guso78 has quit [Quit: Client closed]
<peepsalot>
kintel: yeah, i really don't understand why I can't even pass a valid double format string directly to a Numeric. it seems to only work with no added specifier "{}"
use-value1 has quit [Ping timeout: 265 seconds]
<kintel>
JordanBrown[m] ..are you also trying to use libfmt to print OpenSCAD variants?
<JordanBrown[m]>
Back in 2021 I was trying to use libfmt to create a formatting function that you could call from OpenSCAD.
<JordanBrown[m]>
That is, from OpenSCAD-language programs.
<kintel>
ah, that sounds like a similar challenge
<kintel>
peepsalot Did you look into how range formatters utilize the {::} (double colon) format spec?
<JordanBrown[m]>
I don't remember libfmt's format specification language, but I think I had most of the cases working, except for that variable-width case.
<peepsalot>
yeah, that's a bit different, but also something that we would want to keep in mind (user-defined formatting at some point)
<peepsalot>
kintel: yeah, I tried but couldn't get it working
<kintel>
Modifying one of your failing cases makes it work:
<kintel>
..but that's merely a shot in the dark. I haven't yet looked into how individual formatters consume the format strings
<kintel>
..but I assume that "::" is a signal to stop unpacking to allow application of the format string recursively
<peepsalot>
kintel: ok now i'm really confused. if n1 is still Numeric as the comment says, that's not even a range...
<JordanBrown[m]>
Time for me to start heading toward bed.
<JordanBrown[m]>
I dimly remember that in mine, the %s equivalent would basically do a toString on whatever you gave it, so it was capable of printing things like lists but didn't do anything clever with them.
<kintel>
..no but my theory was that perhaps :: does something about multi-layer data structures
<kintel>
Anyway, I can continue playing with it tomorrow evening; it's way too late for this now...
<peepsalot>
yeah, possibly. I need to do some proper debugging, because I'm still unsure if I'm even re-creating the format specifiers correctly
<peepsalot>
its tricky because of 1) constexpr requirement and 2) you are supposed to parse the inside of the braces, but then in order to pass it down to nested variant, you have to put the braces back in and parse them at each level
<peepsalot>
i don't know it seems like there must be a better way, but its not clear what that would be
<kintel>
I fear it will be 500 lines of arcane template magic : /
<kintel>
..culminating in std::format support for std::variant of custom data types in C++31 ;)
<teepee>
they have an extension interface via templates but I have not looked into it in detail
<peepsalot>
kintel: did you see the thing about fmt builtin support for variant types? its too bad it wraps them in "variant(...)" with seemingly no options to change
<peepsalot>
so i still had to write a visitor class
<teepee>
I'll try to have a look, but I don't have much time over the coming days
<teepee>
I'm going to babysit a couple of production line go-live activities and I don't want to be the reason why they have problems producing more tires for their cars :)
<teepee>
or is it tyres for US?
<teepee>
oh, right, it's in Value.h obviously, I only looked in main.cpp yet. I suppose I was just too sleepy
use-value1 has joined #openscad
use-value has quit [Ping timeout: 265 seconds]
use-value1 is now known as use-value
guso78 has joined #openscad
<guso78>
when i try in cpack in MSYS2 it tells: CPack: CPack generator not specified.
<teepee>
cpack -G NSIS
<teepee>
maybe?
ur5us has quit [Ping timeout: 260 seconds]
use-value1 has joined #openscad
use-value has quit [Ping timeout: 264 seconds]
use-value1 is now known as use-value
use-value1 has joined #openscad
use-value has quit [Ping timeout: 256 seconds]
use-value1 is now known as use-value
use-value1 has joined #openscad
use-value has quit [Ping timeout: 260 seconds]
use-value1 is now known as use-value
<peepsalot>
tyres is very british
<teepee>
ah, ok, other way around then
castaway has joined #openscad
ur5us has joined #openscad
ur5us has quit [Ping timeout: 260 seconds]
teepee_ has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
califax has quit [Remote host closed the connection]
califax has joined #openscad
omegatron has joined #openscad
guso784 has joined #openscad
<guso784>
on my twitter account gadget_3d you can see right now a technical application of openscad roof function ...
guso78 has quit [Ping timeout: 260 seconds]
guso784 has quit [Quit: Client closed]
J2356 has quit [Quit: Client closed]
J2356 has joined #openscad
snaked has quit [Ping timeout: 255 seconds]
snaked has joined #openscad
snakedGT has joined #openscad
snaked has quit [Ping timeout: 268 seconds]
snakedGT has quit [Client Quit]
guso78 has joined #openscad
<teepee>
oh, twitter still works? ;-)
Guest95 has joined #openscad
califax has quit [Remote host closed the connection]
Guest95 has quit [Quit: Client closed]
califax has joined #openscad
califax has quit [Ping timeout: 255 seconds]
califax has joined #openscad
kintel has joined #openscad
Guest54 has joined #openscad
<greenbigfrog>
hm, maybe someone here can give me a pointer that'll help. I've modeled part A (socket.scad) with threads on the outside, which I'm removing from B (lid.scad), but once I 3D print it, the threads are not lining up at all. Anyone have any ideas what I could be doing wrong? https://github.com/greenbigfrog/ultimate-ptfe-coupling/blob/main/lid.scad
<greenbigfrog>
(really liking openscad btw, thanks to everyone involved)
Guest54 has quit [Quit: Client closed]
<InPhase>
What are socket.scad and Chamfer.scad?
<InPhase>
Those seem to have a lot of the meat here.
<InPhase>
Oh, I see they are in the repository.
<greenbigfrog>
yeah, I submoduled them.
<InPhase>
greenbigfrog: Well, first and foremost, you're not following the overlap rule.
<InPhase>
greenbigfrog: It'll take a little work to fix, as it appears you violated the overlap rule pretty extensively throughout.
<Guest7958>
Hallo I am new here! When i am start rendering the object loosing their color - what have i made wrong?
<JordanBrown[m]>
Rendering (that is, F6) doesn't support color.
<Guest7958>
thank you Jordan!
<JordanBrown[m]>
Similarly any use of the render() module, whether in F5 or F6.
<JordanBrown[m]>
Sure.
<greenbigfrog>
ok, yes, so it's more important then I thought (mandatory). but if I render it, I still get a closed shape. this can't be the reason for the parts not mating up, or can it?
<InPhase>
greenbigfrog: In socket.scad you also appear to have used ScrewThread where you intended to use ScrewHole (presumably, because it is applied to a cylinder). One of the reasons ScrewHole is nice is that it handles the overlap for you. But for all those manual differences, you need to do the overlap rule yourself. Often with a translate([0, 0, -0.01]) or something for the removed part, and an
<InPhase>
additional height adjustment if you want to preserve exact depth.
<InPhase>
greenbigfrog: Well I can't see what doesn't match up, because your preview is all broken. :)
<InPhase>
greenbigfrog: But if you fix that up, then perhaps you could explain what's not aligning properly.
<JordanBrown[m]>
Guest7958: Generally speaking, preview is for looking at and render is for exporting to STL or whatever for printing. Alas, there's no direct support for multi-color exports; you have to do that on your own by only generating one color at a time and then recombining in the slicer.
<InPhase>
greenbigfrog: When you print parts that you want to fit inside of each other, they also cannot be the same nominal size. You have to allow for clearance for jitter, plastic shrinkage, and other such things. If you look at ScrewThread and ScrewHole, you'll see the sizes are adjusted slightly so that threads go into holes. This is the sort of thing you also need to do if you want cylinders to go inside
<Guest7958>
OK ! Thank you - Iwill try!
<InPhase>
of each other.
Guest7958 has quit [Quit: Client closed]
<greenbigfrog>
alright. thanks. guess I'll rework it. Since the render rendered everything properly, I didn't think the overlap for removal was as important. But I guess it truly is :D
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<InPhase>
The success of renders with bad overlap should be taken as good luck.
<greenbigfrog>
:D
<InPhase>
Which can turn against you. :)
<InPhase>
If you get that fixed up and push the changes, and still have an alignment issue (if my advice was not sufficient), then ask again and I'll re-pull and check.
<InPhase>
(Or someone else if I'm out.)
<greenbigfrog>
thank you very much, guess I'll clean it up
Sauvin has quit [Remote host closed the connection]
Sauvin has joined #openscad
teepee_ has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
<peepsalot>
just updated dev-support repo with fixed up formatters
<peepsalot>
i realized that formatter<Value>::parse(...) was failing to re-create the colon when passing down format specs.
<peepsalot>
that's why kintel noticed that adding a colon (making it look like a range specifier when no ranges were involved) helped it to work before.
<peepsalot>
i think its a decent demo of the features I was aiming for. a remaining question is if we want to be able to pass any other format info to our Value types, besides just numeric precision.
<peepsalot>
for example padding and left/right/center justify of strings or other value types
ur5us has joined #openscad
<teepee>
the example can print out all types already?
<teepee>
otherwise I suppose precision and string options are the 2 interesting ones
<teepee>
is there something like "format for lists"?
<teepee>
like separator and enclosing in some sort of braces?
<teepee>
that said, I'm not even sure this is a topic for fmt::format :)
Sauvin has quit [Remote host closed the connection]
Sauvin has joined #openscad
<peepsalot>
teepee: well it is working for simplified mockups of some of our Value types. namely VectorType, Numeric, and StringType
<teepee>
it's probably not a big priority but interesting to know there's at least some built-in stuff for that, even if we don't support custom list formats at first
<peepsalot>
i left a few alternative implementations in Value.h, some working some not. selectable with a basic #if 1 ... #else ... #endif toggles
<teepee>
I'll try to have another look. hopefully after next week finishes, things settle down a bit at work
<teepee>
lol, box drawing format
<peepsalot>
yeah that is an interesting one
guso78 has quit [Ping timeout: 260 seconds]
Sauvin has quit [Remote host closed the connection]
Sauvin has joined #openscad
guso78 has joined #openscad
quiestrho has joined #openscad
<quiestrho>
Hi everyone! I face the following challenge: I have a 2D plan of how to cut 4 parts of a small boat hull from plywood. I know all necessary measurements and can easily produce objects representing these sheets in OpenSCAD. Now the challenge is to put all these together to make a 3D model. I know what are the contact edges/points of these elements
<quiestrho>
and am wondering whether there is any relatively straightforward way to take 2 objects, define few contact points on both and bent them so that they are connected. TIA.
Sauvin has quit [Ping timeout: 272 seconds]
<JordanBrown[m]>
Bending things is hard.
<JordanBrown[m]>
If you only mean to pivot the parts around the attachment points that’s not so bad, but it does require that you understand the rotations and translations involved.
guso78 has quit [Ping timeout: 260 seconds]
<quiestrho>
No, it is not only pivoting/rotations. That is what I was afraid of, it probably has to be some CAD soft that can take material properties into account and model bend and twist...
Sauvin has joined #openscad
Sauvin has quit [Remote host closed the connection]
Sauvin has joined #openscad
<J2356>
if you have a non stretching bend it can be only on one axis - but you need a lot of points as a cube with 8 points will still have straight edges after bending
<JordanBrown[m]>
OpenSCAD has no notion whatsoever of material properties.
<JordanBrown[m]>
And it really can’t do bends; you’d have to tell it to cut the object up into little pieces, and then position and rotate each of them appropriately.
<JordanBrown[m]>
There are other techniques involving deriving the polyhedron corresponding to the bent piece, but there you have to do all the work yourself.
califax has quit [Remote host closed the connection]
<quiestrho>
Thanx guys! I hoped for some library i do not know of but seems I have to go for some other soft. Thought it is a relatively straightforward and useful feature since often we get cutting lists/nets of solids and when it comes to, e.g. plywood we often use its flexibility to create curved shapes. Seems like the opposite is implemented, i.e. net
<InPhase>
quiestrho: Now, imagine that's not animated grass, but plywood. :)
<InPhase>
Notice the grass does not vary in length.
<JordanBrown[m]>
Right, OpenSCAD is very much based on mathematical models, not real world materials.
<JordanBrown[m]>
Of course you can simulate those materials, but nothing in OpenSCAD will do it for you.
GNUmoon has quit [Remote host closed the connection]
<InPhase>
quiestrho: The code for that is not particularly complicated once you make sense of the core concept. Most of the numerical complexity is just making the amusing dynamics of the animation.
GNUmoon has joined #openscad
<InPhase>
quiestrho: It would be reasonably straightforward to trim it down, remove all the fun animation stuff, and make the segments vary according to some 2D shape. Then it could be bent and twisted in the manner shown and described in the comments.
<quiestrho>
Cool! Thanx InPhase! I have some reading for the evening now! :-)
<JordanBrown[m]>
InPhase: I’ve never looked at how the grass works. Is it just a bent cuboid? If so, note that bending a larger surface will require points in the middle.
<InPhase>
JordanBrown[m]: Module recursion of translate/rotate after being fed a list of [length, [rotx,roty,rotz]] and extrude by length plus the extra calculated amount to avoid disconnects at the endpoints.
<InPhase>
JordanBrown[m]: children(0) is the 2D cross-section of the extruded element.
quiestrho has quit [Quit: Client closed]
<InPhase>
JordanBrown[m]: It takes a max_r which should be how far out the 2D object extends from the origin.
<InPhase>
That in turn is required to calculate the extra extrusion amount.
<InPhase>
This is of course a little hacky compared to my normal ClosePoints modalities, but it's elegantly compact, and has the benefit of no constraints. :)
<InPhase>
JordanBrown[m]: children(1) is then "put this at the end after all the operations", so that I could put heads on the grass. :)
<InPhase>
JordanBrown[m]: The core goal was to demo generalized path tracing with recursion, so the module is as generic as I could make it, and the meat is outside in preparing the pieces to feed it.
<InPhase>
Although the one thing I did not do generalized enough for quiestrho's purposes is varying the 2D structure. :) A module literal would be good there.
GNUmoon has quit [Remote host closed the connection]