califax has quit [Remote host closed the connection]
califax has joined #openscad
<teepee>
templating ftw!
epony has quit [Remote host closed the connection]
epony has joined #openscad
teepee_ has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
joseph_ has quit [Ping timeout: 260 seconds]
joseph_ has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee has joined #openscad
<peepsalot>
dang, you can't use std::unordered_map<std::string, Foo>'s find() or operator[] with a string_view until c++20
LordOfBikes has quit [Ping timeout: 268 seconds]
teepee has quit [Remote host closed the connection]
J2324 has joined #openscad
J23 has quit [Ping timeout: 260 seconds]
LordOfBikes has joined #openscad
aiyion has quit [Ping timeout: 255 seconds]
aiyion has joined #openscad
kintel has joined #openscad
Alexer- has joined #openscad
qeed has quit [Quit: qeed]
teepee has joined #openscad
kintel has quit [Ping timeout: 268 seconds]
qeed has joined #openscad
guso78 has joined #openscad
<guso78>
Hi, i am just wondering, what the function "fill" do. does it removed enclosed holes of an object ?
ur5us has joined #openscad
<guso78>
Hi, i am just wondering, what the function "fill" do. does it removed enclosed holes of an object ?
ur5us has quit [Ping timeout: 260 seconds]
ur5us has joined #openscad
guso7813 has joined #openscad
guso7813 has quit [Client Quit]
ur5us has quit [Ping timeout: 246 seconds]
J2324 has quit [Ping timeout: 260 seconds]
L29Ah has quit [Ping timeout: 256 seconds]
J23 has joined #openscad
<guso78>
i am very interested to get my python branch sometime merged into the main branch, but it will be a huge addition. would it make sense that openscad merges it first in its python branch first ?
<guso78>
its great! but you dont store drills there, right ?
<guso78>
do you have an idea how to store drills of different size very compactly ?
J23 has quit [Quit: Client closed]
J23 has joined #openscad
<J23>
guso78 it is for drill bits like cutter mill end mills grinding pins for rotary tools (dremel)
<J23>
the problem is not to store but to access the drills .. so you can use https://en.wikipedia.org/wiki/Circle_packing but make two rows that can be tilted so you can access them better
<guso78>
gbruno, are you real ? your messages appear little automatic
<teepee>
yep, gbruno is our github bot
<teepee>
guso78: starting with a merge in a separate branch seems fine
<teepee>
we should clarify some general things I suppose, but if we are on the same page regarding that, it might make things easier
<guso78>
ahh ok, i thought so, bruno never answered to my questions ...
<guso78>
which exact audience is meant to clarify general things. is it 2 of us, or rather the openscad group ?
<teepee>
I would ask if there's any veto from a couple of people here in the channel, but otherwise we can just discuss that between us
<teepee>
nothing strange, just the main thing I think we need to cover is that I think there should be a safety switch to disable python
<teepee>
mostly for security reasons
<guso78>
yes i agree. One proposal is to enable it only, when setting the tickbox in the "experimental settings", when run with a special commandline argument . And when active short popup that python is enabled
<guso78>
my python branch is almost ready to show to you the first time, but its a huge change in total. Do you believe its reasonable if you first try to merge it a new branch "python" newly created in your side ?
<guso78>
of course i dont need to port all the calculation and math stuff as python has it natively. need to note, that python works on radians, whereas openscad works on degrees
<teepee>
I did not really think about those details, but I suppose it's fine to have a different definition that matches the "normal" behavior
Fyr has joined #openscad
Fyr has left #openscad [#openscad]
<guso78>
did you already think about how to start when openscad has a new python lib dependancy ?
<guso78>
the used python is python 3.x
snaked has quit [Quit: Leaving]
Guest87 has joined #openscad
Guest87 has quit [Client Quit]
<guso78>
when setting up circleCI compilation for windows, i need to start everything in windows, right ?
<guso78>
this circleCI is cool, but where exactlyd does it run ?
<guso78>
hmm, python is not found, do i have the install it in circleci ?
<teepee>
I've not used the windows runners there, I would assume they have some sort of documentation of what's installed by default
JakeSays has quit [Ping timeout: 272 seconds]
JakeSays has joined #openscad
L29Ah has joined #openscad
<peepsalot>
guso78: its not clear to me what you are trying to do. any existing circleCI configuration is meant to run on externally hosted servers which run some automated checks on branches and PRs before they are merged into openscad master
<guso78>
Hi Peepsalot, thank you for your info. I am trying to run in the external server already.
<peepsalot>
and what issue are you seeing?
<guso78>
compilation does not yet work, Python is not found.
<guso78>
Could NOT find Python (missing: Python_EXECUTABLE Python_LIBRARIES
<peepsalot>
I still don't know what you are trying to do
<peepsalot>
guso78: when you look at the check mark (or X) next to a commit on github, you can see links to each individual job on different CI servers. here is the one for your latest PR commit on circleCI https://github.com/openscad/openscad/runs/10603611254
<peepsalot>
guso78: maybe you and i mean different things when we say "external". are you trying to "self-host" a CI server?
<peepsalot>
running circleCI on a local computer?
teepee_ has joined #openscad
<guso78>
peepsalot, i have added python dependancy to my openscad fork and of course now it does not work anymore. i run in an remote environment.
<guso78>
haha, this is the evalstring function, which appears to work in all environments
<peepsalot>
can you link to the circleCI build log? a single error line is difficult to interpret out of context
<guso78>
python3 sounds very promising, this is the version i am using
<teepee>
it's not listed on the MXE page :/
<guso78>
does this mean, MXE is not an option ?
<teepee>
it just makes things more complicated if it's not already published as package
<teepee>
one option is to really just start on Linux and get that working
<guso78>
in linux it works fine for me already. i am very happy with my linux binary.
<guso78>
my cmakelists.txt file works fine in linux (yes, formatting could be improved)
<teepee>
there's quite a difference between "works for me" and "can distribute to others easily"
<guso78>
i confirm. my next task is to make it working smooth ...
<teepee>
on Linux the simple ways are AppImage, Snap and Flatpak
<teepee>
as those come as full featured package
<teepee>
the distro builds are probably not a huge issue, on OBS we do Debian / Ubuntu / Fedora and OpenSUSE
<guso78>
ok thanks. whats the easiest way to head towards windows ?
<guso78>
suppose, that AppImage and co dont help here ...
<teepee>
correct, I don't think any of those work on Windows
<teepee>
it should be possible to compile python via MXE
<guso78>
I believe i have to get them compiled successfully first before i can pack them together
<guso78>
is it something i have to edit in the config.yml file ?
Guest50 has joined #openscad
Guest50 has quit [Client Quit]
<teepee>
it's possible to just do MXE locally and then see if python can be added too (or maybe I've just not found it looking through the list)
<guso78>
no, i remember that i have seen a table some time before with remarkable "python not supported"
<guso78>
Next task is to download MXE locally to my linux env ?
<teepee>
yeah, you could just clone the mxe github repo and see if there's a simple way of getting python built
<teepee>
don't just do "make" though
zauberfisch has quit [Ping timeout: 272 seconds]
<teepee>
I guess that would build *everything* which probably takes weeks :)
<teepee>
we use scripts/mingw-x-build-dependencies.sh
<teepee>
that builds all the currently used dependencies
Guest30 has joined #openscad
Guest30 has quit [Client Quit]
<guso78>
does it help to integrate python into scripts/mingw-x-build-dependencies.sh ?
<teepee>
at the end it should go there, but first thing is it find out how to even compile all that stuff
<teepee>
from a bit of googling it's not really clear to me yet how difficult it is to integrate, or if there's maybe other options too
<teepee>
like using a different pre-compiled version of python that could just be linked
<peepsalot>
with the packaging handled in cmake now, I think it would be fairly simple to set up msys2 builds to generate packaged artifacts
<peepsalot>
if that works then maybe we could drop MXE?
<teepee>
oh, that's certainly something to try
<peepsalot>
i am curious about relative performance of mxe vs msys2 builds
<teepee>
and I suppose msys2 had python already
<peepsalot>
considering the test suite runs, i would think so
<teepee>
right, good point, although we do need the embedded one, but if they build the interpreter, that should be pretty much the same
zauberfisch has joined #openscad
<guso78>
in my msys2 environment, everything ran without any issue and openscad worked as expected.
<guso78>
however the resulting exe file would not run in bare windows.
<teepee>
yes, it will need to package all the libs and other dependencies
<teepee>
so it's not trivial, but could be easier than getting python to compile in MXE
teepee has quit [Remote host closed the connection]
<guso78>
its possible to put all dependencies next to the openscad.exe file and it will run, but then qt will not initialize because of the missing "platform" plugin
teepee has joined #openscad
<peepsalot>
guso are you running "cmake --install" on your msys2 build?
<guso78>
no, i did not. (missing knowledge)
<guso78>
probably this makes a big difference
<guso78>
i did something like cmake .., then make
<guso78>
in which directory do i need the cmake --install ?
<peepsalot>
so that is "installing" it straight to the build directory. without the "--prefix" arg, i think it might try putting into Program Files...
<peepsalot>
you could also see how cpack works if your msys2 is already set up. for that I think you should be able to just run "cpack" from the build directory. and it should generate a self-installing exe plus an archive
<peepsalot>
would be good to make sure those run outside of msys2 environment
<guso78>
i saved your instructions for later use. i have to leave soon.
<peepsalot>
i have seen some other complaints in the paste, about the builds not running outside of msys2 environment, but I'm not sure what the exact issue is
<guso78>
(believe if i open the chat at home your message is not visible)
<peepsalot>
*in the past*
<guso78>
if you run msys2 builds outside the msys2 environment, the the "Windows Library Path" is beeing used, and its by no means setup correctly
<peepsalot>
i forget how the msys builds work, are the dependencies all dll or statically linked?
Trieste has quit [Ping timeout: 260 seconds]
<peepsalot>
the install section of the CMakeLists.txt may need to be tweaked to copy additional dlls for any such shared lib dependencies.
<guso78>
the dependancies are dynamically linked, but its possible to link them statically(did not get all of them statically linked)
<guso78>
set(CMAKE_FINS_LIBRARY_SUFFIXES .a) helps a little bit, but is not perfect
<guso78>
sorry FIND instead of FINS
<guso78>
need to leave now
Trieste has joined #openscad
J23 has joined #openscad
Sauvin has quit [Ping timeout: 268 seconds]
Sauvin has joined #openscad
guso78 has quit [Quit: Client closed]
kintel has joined #openscad
L29Ah has quit [Ping timeout: 264 seconds]
J23 has quit [Quit: Client closed]
J23 has joined #openscad
L29Ah has joined #openscad
teepee_ has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
ur5us has joined #openscad
<peepsalot>
weird, i'm seeing a number of `-nan` in place of `nan` from libfmt test results. can't reproduce in a simple case on godbolt though
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Lagopus has joined #openscad
foul_owl has quit [Read error: Connection reset by peer]
<xloem[m]>
hi again openscad … i’m new to 3d printing and i thought i’d try to make a parametric cycloidal gear, thinking of making actuators. my system is pretty low end, and i tried https://github.com/cyber-murmel/cycoidal-gear but it takes a very very long time to render and then slice, and when printed the huge gcode from kiri moto didn’t do anything
<xloem[m]>
on the openscad end, is there anything people recommend for a first time simple cycloidal gear? maybe something that would render and slice faster, or settings?
<xloem[m]>
the interface hangs for a very long time on boot before letting me do much of anything … is openscad the wrong tool for a low end system?
<JordanBrown[m]>
What’s low end? I use it on a ten year old laptop with 8GB.
<JordanBrown[m]>
But it does depend on the model that you are trying to render.
foul_owl has joined #openscad
<xloem[m]>
well it’s maybe comparable to that but tends have load going filling the ram and cpu some
<JordanBrown[m]>
That particular model uses Minkowski twice. Minkowski is just about the most expensive operation in the program.
<xloem[m]>
hmmm !
<JordanBrown[m]>
But hmm. That seems to be in 2d, which shouldn’t be as bad. I’ll switch to desktop and try.
<xloem[m]>
i didn’t know it ran headless, maybe that would make more sense for me when my system is loaded
<JordanBrown[m]>
Exactly what part of that model are you trying to use? cycloidal_gear(), which is 2D, previews and renders instantly for me on my antique desktop.
<xloem[m]>
i was rendering and trying to print all 6 parts from nema17-cycloidal-gear.scad together
<JordanBrown[m]>
OK, let me load that up. (I don't have NopSCADlib installed.)
<xloem[m]>
it’s a submodule :S
<JordanBrown[m]>
yep
<xloem[m]>
is this a normal way to do this: search github for a library?
<JordanBrown[m]>
Preview of that nema17-xxx file takes 45s on my desktop.
<JordanBrown[m]>
That's a very long time for a preview.
<JordanBrown[m]>
For me.
<JordanBrown[m]>
But I think it's because it's got render() scattered throughout. Trying a full render now.
<xloem[m]>
i found the UB library from your link has a cycloidal gear :)
<JordanBrown[m]>
If only I knew exactly what a cycloidal gear was... :-)
<xloem[m]>
well i’m new to them but they seem like a modern thing to use for a gearbox, everything is centered around one axis, it uses fancy curves instead of normal toothed gears
<JordanBrown[m]>
That's interesting... a full render complains that the mesh is not closed. We'll see what it ends up with.
<xloem[m]>
<xloem[m]> "hi again openscad … i’m new to..." <- not sure why this sent twice, must have slipped my finger somewhere
<xloem[m]>
JordanBrown[m]: oh maybe that’s related to the gcode failure
<JordanBrown[m]>
Might hypothetically cause a slicing problem.
<JordanBrown[m]>
A full render took 5m20s and left me with four rings and something that looks like brass knuckles for somebody with a round wrist and seven fingers.
<JordanBrown[m]>
I see that it sets $fn to 90, which is a bit high. For round things, I believe $fn can have a quadratic or maybe even fourth-power effect on performance.
<JordanBrown[m]>
Dropping it to 30 and previewing completed in 14s.
<xloem[m]>
thank you so much
<JordanBrown[m]>
I don't like using $fn, because it tends to make too many sides for small round things. With a more reasonable $fa=5; $fs=0.5 it previews in 16s.
<JordanBrown[m]>
Whether the result is round enough may depend on your application, but it's certainly plausible for preview purposes.
<JordanBrown[m]>
That's on a 2013 desktop, $600 at Costco so not the bottom of the line but far from the top, with 28GB of RAM.
<xloem[m]>
oh much more than i have
<xloem[m]>
i think you explained that very high polygon counts will be from those three special variables. i’m reading about them a bit. thinking about voxel formats.
<JordanBrown[m]>
Doesn't look like RAM is an issue at all, stayed under 400MB throughout the preview.
<xloem[m]>
nice
<JordanBrown[m]>
Will have to watch a full render.
<JordanBrown[m]>
Yes, managing the number of sides in round things is a key performance item.
<JordanBrown[m]>
You can give them a zillion sides, and they look gorgeous, but then actually doing anything with them can get very expensive.
<JordanBrown[m]>
Doubly so if you're playing with spheres, because there the $fn applies in two dimensions.
<JordanBrown[m]>
Full render (with $fs/$fa) took 1m46s and never got above 400MB.
<JordanBrown[m]>
For spheres, it looks like $fn has a quadratic effect on performance. For a union of two spheres, doubling from 30 to 60 increased time by a factor of four.
<JordanBrown[m]>
Which is a lot better than I feared; I wouldn't have been surprised if it was fourth-power.
<JordanBrown[m]>
That's for a full render; preview is instant.
<JordanBrown[m]>
So, anyhow: for several reasons, that model is pretty expensive. There's stuff you can do about it (especially for preview) by reducing $fn or switching to $fa/$fs.
<xloem[m]>
thank you !
<JordanBrown[m]>
Sure thing.
<JordanBrown[m]>
If you are curious about details, you can ask on the mailing list - nophead hangs out there and will probably answer questions about his library.