<tcurdt>
I don't quite see how to define the start and ending vectors.
<tcurdt>
and the shape would also need to change along the way
<tcurdt>
made some progress and added it to the gist
LordOfBikes has quit [Ping timeout: 264 seconds]
<tcurdt>
but still not quite right
LordOfBikes has joined #openscad
J23k97 has joined #openscad
<peeps[zen]>
where is your bezier_curve defined?
<tcurdt>
peeps[zen] ah ... that's "use <dotSCAD/bezier_curve.scad>" but "path = [ for (p=points) p ]" would also work for testing
<tcurdt>
the problem is that I kind of need both ... skin AND sweep
J23k64 has quit [Ping timeout: 245 seconds]
<tcurdt>
and I don't quite see how
mmu_man has quit [Ping timeout: 252 seconds]
<peeps[zen]>
idk your top example doesn't make a lot of sense being 2d. you want one end to be oval?
<peeps[zen]>
applying 3d transformations to 2d circles i mean
hyvoid has joined #openscad
teepee_ has joined #openscad
L29Ah has left #openscad [#openscad]
teepee has quit [Ping timeout: 246 seconds]
teepee_ is now known as teepee
<tcurdt>
peeps[zen] well, it's just to explain the start and stop positions .... ofc it should end up being a 3d object .... I would think the update should make clear where I want to be heading?
L29Ah has joined #openscad
<tcurdt>
the lower should be an oval ... the other should be round
<tcurdt>
hence the skin vs sweep
qeed has quit [Remote host closed the connection]
<peeps[zen]>
tcurdt: i haven't really used list comprehension demos code much, but seems like you may want to try incorporating multiple transforms for your path like in the sweep-test example
<J23k97>
peeps[zen] the last version was 2019 - in 2019.05 the folder doesn't exist .. nor in 2021 or 2023 - but i also have seen some files use assign which causes warnings and some utils are redundant as new commands exist like offset or hull. But the sweep stuff is probably quite useful for some people.
<peeps[zen]>
J23k97: are you talking about scad utils?
<J23k97>
yes
<peeps[zen]>
it was never part of build afaik. historically "mcad" was the only "official" library, and that is its own package (under debian based distros at least)
<J23k97>
i have that folder in version 2019 but maybe i copied it there
<J23k97>
but it is also in 2018
<peeps[zen]>
a folder called "utils" under what path? and it has .scad files in it?
<J23k97>
libraries/scad-utils/
<peeps[zen]>
you have to place libraries there yourself, none are packaged with openscad
<peeps[zen]>
also "assign" has nothiing to do with userspace libraries
<peeps[zen]>
that is an obsolete builtin
<peeps[zen]>
i don't understand what you are looking at to determine that libraries is tied to specific versions, any version should share the same user's libraries path
<peeps[zen]>
yeah i don't think it has been maintained much over the years. you could open an issue about it. i thought you were meaning that you expected assign to be defined *inside* of "scad-utils"
<peeps[zen]>
"let" should work as a dropin replacement for "assign", afaik
<J23k97>
And maybe they could be delivered within the examples if not as libraries
<peeps[zen]>
that hull stuff is so ancient that I think it was before "hull()" module was a builtin to openscad. still interesting I suppose to have a userspace implementation
<tcurdt>
I am now trying to skin and translate and morph at the same time ... but even after mucking around with "augment_profile" I cannot seem to get it to work.
<kintel>
FYI: In case people didn't notice: OpenCSG 1.6.0 is out, and they dropped GLEW support in favour of GLAD. Will update OpenSCAD. This could be good news for X11-less offscreen rendering
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<teepee>
yep, I'll add some OBS builds for it as soon as I have some time to spare
<teepee>
what stuff are they snorting at circle-ci?
<teepee>
that AI is not going to take over the world though. clicking that button gives:
<teepee>
Error Generating Recommendation: An error occurred while generating a recommendation for this step output. Please try again later.
<teepee>
awesome technology
<teepee>
oh, btw, kintel - that's a warning - treated as error due to -Werror leaking from Manifold. That's supposed to be fixed in latest Manifold master
<peeps[zen]>
they should be setting target properties rather than global CMAKE_FLAGS etc.
dustinm` has quit [Server closed connection]
<peeps[zen]>
that's why i made an effort to make our own CMakelists leakproof a while back
<peeps[zen]>
at least not leaking in the direction of openscad -> dependency
dustinm` has joined #openscad
<teepee>
I think that's what they did now, I could not merge due to always getting new errors
<teepee>
not sure how the last one happens, I only globally enabled the STL sorting but that badly broke one of the invalid mesh cases, not just due to sorting it seems
<peeps[zen]>
although I was under the impression that subdirectories couldn't leak upward in directory/project structure, but maybe that's not entirely correct
<teepee>
hmm, I don't think it leaks upwards, it's still inside Manifold, but it should not force -Werror on applications
<teepee>
it's fine when they build directly - and that should be the case now I believe
<teepee>
at least I did not get any build errors anymore in the PR, but now the STL testing errors due to Manifold not ensuring stable mesh order, which is fine im my view - we need to fix that on our side
fling has quit [Ping timeout: 246 seconds]
fling has joined #openscad
pbsds has quit [Ping timeout: 246 seconds]
pbsds has joined #openscad
teepee_ has joined #openscad
teepee has quit [Ping timeout: 246 seconds]
teepee_ is now known as teepee
kintel has joined #openscad
ToAruShiroiNeko has quit [Ping timeout: 255 seconds]
ToAruShiroiNeko has joined #openscad
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]