<phryk>
took me like 4 hours to animate, also had to copy the last frame 60 times so it doesn't end so abruptly^^
<phryk>
oh, and had to manually create the last frame, too with imagemagick and gimp :F
<teepee>
that does look amazing
<phryk>
thank you. that kind of stuff is what I'd love to have proper builtin utilities for in opencad.
<teepee>
yes, so we may need a switch for animation type
<teepee>
but for now good night :)
<phryk>
aye, nighty.
ur5us has quit [Ping timeout: 250 seconds]
<peepsalot>
phryk: gimp can set the delay of individual frames for animated GIFs
<InPhase>
phryk: If you want really good animation packing, try this tool, found in the webp package in Linux repositories: img2webp -v -loop 0 -d 33 -lossy -q 97 -m 4 frames/frame*.png -o Decomposition.webp
<InPhase>
phryk: The -d parameter specifies the milliseconds between frames. The rest are some decent quality attributes. -loop lets you turn looping as default on or off per your preference.
<gru3hunt3r[m]>
I'm curious if Fornjot has been discussed in this forum https://www.fornjot.app/faq/ - it's like SCAD (geometry as code), but built in RUST and internally uses what the fornjot author refers to as "boundary representation"
<gru3hunt3r[m]>
So my question(s), has b-rep already been discussed in openscad?
<gru3hunt3r[m]>
And this topic for me is a bigger picture question, since OpenSCAD is built presently in C++ with a bit of python. I see there's already a WASM package, so obviously the need for interop with other languages WASM is !@#$ awesome future .. I expect deno containers will *mostly* obviate docker and all that (imho)... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/67cff87591ccd4023d20d7105c0e8dce32996f21)
<gru3hunt3r[m]>
* And this topic for me is a bigger picture question, since OpenSCAD is built presently in C++ with a bit of python. I see there's already a WASM package, so obviously the need for interop with other languages WASM is !@#$ awesome future .. I expect deno containers will _mostly_ obviate docker and all that (... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/264cadee993d3d8a90f7591864d2f2fd7b58552f)
<gru3hunt3r[m]>
s/*mostly*/_mostly_/
<gru3hunt3r[m]>
I realize OpenSCAD is a volunteer org. so I'm not proposing anybody other than me do these types of things, but rather I want to avoid building supported forks or things just for myself, adding complexity where it's not necessarily appreciated and everybody has opinions, especially programmers. So I'm hoping to survey enthusiasm level of interest from existing OpenSCAD devs & community, is there already a format/template for
<gru3hunt3r[m]>
enhancement proposals?
<gru3hunt3r[m]>
(I assume it's most appropriate to discuss here in matrix before writing a proposal, or perhaps even a yak-shaving exercise building a _template_ for a New Issue & enhancement proposal, linking/answering some of these questions)
<gru3hunt3r[m]>
my sense is that this isn't highly formalized method?
<gru3hunt3r[m]>
I'm proposing a convo topic for the senior OpenSCAD devs -- specifically RUST & C++ -- into OpenSCAD engine, and I'd propose that B-rep (from Fornjot, if the author is inclined for it's inclusion) to allow RUST interfaces be exposed to enhance future OpenSCAD.
<gru3hunt3r[m]>
I'm not super familiar with OpenSCAD source at this point, but I know both RUST, C++, as well as Python & Typescript.
<gru3hunt3r[m]>
I might also apply-for & co-sponsor for a grant from the RUST foundation.
<J2276>
phryk you set 30 frames and you get 30 frames 0-29 what is wrong with you?
qeed has joined #openscad
ur5us has quit [Ping timeout: 250 seconds]
<InPhase>
gru3hunt3r[m]: Rust interfaces for what?
<InPhase>
Just for package management components?
<InPhase>
Most proposals end up as just a github issue, although there is good benefit to discussing out some nuances on channel first. Issues can get a bit chaotic and spiral into turmoil if they are too far off from community needs at the first go. (Although one can always close and start again after some more thought.)
<InPhase>
gru3hunt3r[m]: As a start at this, can you justify what rust interfaces for cargo crates would provide that competing choices would not, and give some sense of how you picture that fitting a usage workflow?
<InPhase>
(I'm heading to sleep, but will check the response later.)
rvt_ has joined #openscad
RichardPotthoff has quit [Ping timeout: 276 seconds]
<gru3hunt3r[m]>
so I realize the cargo package-manager & RUST language bindings convos will happen concurrently, but they are separate. Cargo is the package manager for RUST it's a neo-modern package manager that was built after pip, npm, etc. (with those in hindsight) and so it's perhaps a bit more intuitive, certainly more... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/dc72d3288b5fad82d59d913430b9b5f96c02bd7a)
<gru3hunt3r[m]>
* so I realize the cargo package-manager & RUST language bindings convos will happen concurrently, but they are separate. Cargo is the package manager for RUST it's a neo-modern package manager that was built after pip, npm, etc. (with those in hindsight) and so it's perhaps a bit more intuitive, certainly more... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/6c9b5a58a1259d6be3149a8f8950ff31d6528b51)
<peepsalot>
its like people open issues before even running the program these days
<teepee>
yeah, the GUI docu is not perfect, but that should be possible to find just in the menu
<Scopeuk>
I mean it does also look like ! and # would probably get them a lot of what they want much quicker
<Scopeuk>
I wonder if people fall into the github issues in the same way they would fall into a general user forum
<peepsalot>
yep modifiers are more useful for debugging like that in my experience as well. although I'd say the disable modifier * would be more appropriate
<Scopeuk>
I suppose its "remove this" vs "isolate this" but yes * as well
ricekot has joined #openscad
ur5us has joined #openscad
ur5us has quit [Ping timeout: 252 seconds]
qeed_ has joined #openscad
qeed has quit [Ping timeout: 248 seconds]
ur5us has joined #openscad
GNUmoon has quit [Ping timeout: 240 seconds]
GNUmoon has joined #openscad
nedko has quit [Remote host closed the connection]
fling has quit [Remote host closed the connection]
fling has joined #openscad
<InPhase>
gru3hunt3r[m]: I'm already sold on the future merits of Rust, and on the decision to start migrating portions of the Linux kernel (particularly drivers) to Rust. Although here we have slightly different requirements than the Linux kernel and don't face the same struggles with security and robustness. We've had only minor and rare security issues, and our robustness issues tend to center around
<InPhase>
external libraries. So we must reason out a balance between some specific clear benefits and the extra burden of the complexity of adding a new interface type and a new language that full-source contributers would be expected to know.
<InPhase>
gru3hunt3r[m]: For example, what fraction of GSoC contributers would know both C++ and Rust? I posit a very small fraction at present. So then no GSoC projects could touch features which cross this interface without a learning lag which significantly reduces what can be done.
<InPhase>
I'm not certain it's a bad idea, but I think that needs to be explicitly thought through as a set of problems that come with it in the present environment, to sort out the scope of costs and benefits.
<teepee>
also lets not forget all the builds need to be possible, I'm not sure we can build the windows binaries with rust
<teepee>
also is rust-Qt a thing?
arebil has quit [Quit: My keyboard has gone to sleep. ZZZzzz…]
nedko has quit [Remote host closed the connection]
nedko has joined #openscad
<gru3hunt3r[m]>
👍Yes, can generate both dll /so /dylib) and win binaries with
<gru3hunt3r[m]>
--target x86_64-pc-windows-msvc
<teepee>
question is not if it's possible *in general*
<teepee>
question is how to do that for all the builds we have, which is a quite massive list
<gru3hunt3r[m]>
<teepee> "question is how to do that for..." <- My understanding is yes, rust is a polyglot language, designed to interface easily with many languages so it has some "foundational" support for most targets, obviously I can not personally attest to the stability/maturity of each crate specifically (other than to say they would be obstacles that would need to coordination prior to the merge, no platform left behind should be a forgone
<gru3hunt3r[m]>
conclusion imho).
<gru3hunt3r[m]>
I hear you completely on the long term support.
<gru3hunt3r[m]>
First off rust is a systems engineering language, so it's actually exceptionally rare that old stuff stops working. (more so than other languages), second I would say that it makes sense to have the author/team of any dependency (not just rust crates) should at least confirm that he is aware the venerable openscad is using thems software, maybe contribute/share some regression tests.
<gru3hunt3r[m]>
s/he/they/
<gru3hunt3r[m]>
<Scopeuk> " "created_at": "2010-11-03T20:2..." <- Work on rust began in 2010 too, at Mozilla (as a secure language that couldn't crash/have memory buffer overruns), first release was 2012, so there was no way that openscad could have used rust.
<gru3hunt3r[m]>
Since y'all know scad, and we are talking about rist. For syntax, What does scad look like in rust. (is this listed as a library on the website?) would it be appropriate to have that hosted/transferred to openscad github while the author is still alive & active?
<Scopeuk>
that looks largely like an auto code tool
<Scopeuk>
there are quite a few of those kicking around ,particularly python, for some reason people like re-inventing the wheel in python
<Scopeuk>
generally I would consider those to be outside the application core and separate projects in their own right. in the same way that qt's auto code generation tools are not part of llvm or gcc
rvt_ has joined #openscad
J22 has quit [Quit: Client closed]
J22 has joined #openscad
<linext_>
is it possible to round the edge of an imported SVG that uses linear_extrude?
<teepee>
yes, but I doubt it will produce what you intend
<teepee>
it convex hull, so all cutouts are gone
rvt_ has joined #openscad
<linext_>
i'd like the points to join to the nearest neighbor underneath
<peepsalot>
if you can decompose your object into convex-only shapes, then you can do the hull trick and recombine them afterwards
<InPhase>
linext_: There's no magic general purpose transition to nearest neighbor points, although it is a common desire. It's easy to mentally imagine for these obvious shapes, but hard to define in the general case where things are not so clean, so it remains unclear how to specify it for the general case. This is what motivated my ClosedPoints library, to think about how to lock it down to a restricted
<InPhase>
input specification. (One which your image does not actually satisfy, as it has unequal point counts tracing out the perimeters.)
<J22>
you can subdivide each line to match the point number but that problem is something each CAD lofter has to deal with
<InPhase>
linext_: The best result you will obtain is something like: minkowski() { hull() { cylinder(r=2, h=0.1); translate([0,0,3]) sphere(r=2); } offset(-2) import("foo.svg"); }
<InPhase>
Oops. Plus a linear_extrude(height=0.01) in there left of the offset.
<InPhase>
Make sure the 2's are smaller than half the width of the thinnest features.
<InPhase>
Anything less than that thickness will be eaten away in the middle.
<J22>
or have a path and sweep it
<InPhase>
You could also choose to do a for loop of stacked cos() squished roof calls, if you do the math very carefully to offset in the right amount before each subsequent roof.
<InPhase>
My intuition is the roof stacking method will be slower in the end because of the small volume extra faces from the overlap.
<InPhase>
Even if the roof is faster than the minkowski, that will likely eventually charge you back for the leftover cruft.
<linext_>
yes, i agree that cos/sin would produce smoother curves
<gru3hunt3r[m]>
absolutely the an auto-code tool. absolutely should have it's own separate repo.
<gru3hunt3r[m]>
the principal benefit of having a centralized, org-maintained language binding, especially when the repo is hosted under the organization is it conveys a reduction in the probabilistic degree of difficulty "maybe this will work" what I would call a "hope signal" toward any new person joining a community (these n00bs, might be evaluating 2-5x approaches to do what they want without too much surprise). a well maintained language
<gru3hunt3r[m]>
library which is regression tested by the organization (or auto-generated) upon release is imho 'best practice' .. I was suggesting this might be a point for inclusion in the RUST convo, or a good place to start for people/eyeballs who might contribute to bringing the ability to use RUST to extend OpenSCAD internally (rather than simply drive it externally)
<gru3hunt3r[m]>
<gru3hunt3r[m]>
* absolutely the an auto-code tool. absolutely should have it's own separate repo.
<gru3hunt3r[m]>
<gru3hunt3r[m]>
the principal benefit of having a centralized, org-maintained language binding, especially when the repo is hosted under the organization is it conveys a reduction in the probabilistic degree of difficulty "maybe this will work" what I would call a "hope signal" toward any new person joining a community (the n00bs, might be evaluating 2-5x tools that *could* do whatever goal/effect they desire).
<gru3hunt3r[m]>
A well maintained language library which is regression tested by the organization (or auto-generated) upon release is imho 'positive signal of hope' .. I was suggesting this might be a point for inclusion in the RUST convo, or a good place to start for people/eyeballs who might contribute to bringing the ability to use RUST to extend OpenSCAD internally (rather than simply drive it externally)
<gru3hunt3r[m]>
* absolutely an auto-code tool. absolutely should have it's own separate repo.
<gru3hunt3r[m]>
the principal benefit of having a centralized, org-maintained language binding, especially when the repo is hosted under the organization is it conveys a reduction in the probabilistic degree of difficulty "maybe this will work" what I would call a "hope signal" toward any new person joining a community (the n00bs, might be evaluating 2-5x tools that _could_ do whatever goal/effect they desire).
<gru3hunt3r[m]>
A well maintained language library which is regression tested by the organization (or auto-generated) upon release is imho 'positive signal of hope' .. I was suggesting this might be a point for inclusion in the RUST convo, or a good place to start for people/eyeballs who might contribute to bringing the ability to use RUST to extend OpenSCAD internally (rather than simply drive it externally)
GNUmoon has quit [Ping timeout: 240 seconds]
foul_owl has joined #openscad
<Scopeuk>
gru3hunt3r[m] as this is IRC edits on matrix cause reposting we have three copie of that, something to bear in mind
<gru3hunt3r[m]>
apologies, I keep forgetting this is a bridge.
GNUmoon has joined #openscad
<Scopeuk>
It's very easily done
GNUmoon has quit [Ping timeout: 240 seconds]
nedko has quit [Remote host closed the connection]
nedko has joined #openscad
lastrodamo has quit [Quit: Leaving]
redlizard has quit [Remote host closed the connection]