<M6piz7wk[m]>
<JakeSays> "6piz7wk: you can pass functions" <- pass meaning?
<JakeSays>
they're first-class citizens, so you can pass them to modules/other functions
<M6piz7wk[m]>
that's the idea i want to implement them in the p_board module, but i don't like the declaration as it's hack using cylinder with $fn = 1 and lot of transforming and rotating
<M6piz7wk[m]>
add a mounting solution to the peg board so that it can connect two boards together bcs i am limited by the 3D printer on 235x235x60 dimensions and need 4000x2000 board
<M6piz7wk[m]>
so i want to use a wedges and then connect them with a clip
<othx>
InPhase linked to "Toothbrush / Toothpaste Holder, Philips Sonicare and More by rcolyer" on thingiverse => 3 IRC mentions
<InPhase>
That was robust enough to survive abuse by the destructive children who used it for at least a year until I sold the house.
foul_owl has quit [Ping timeout: 250 seconds]
<M6piz7wk[m]>
InPhase: That seems to be defining a complex polygon.. i don't think i have that option assuming that the design is scalable and is expected to be double mirrored
<M6piz7wk[m]>
.. at least it would need a lot of complex calculations for the coordinates
<JakeSays>
M6piz7wk[m]: why couldn't you define your own polygon?
<JakeSays>
you only need to define the polygon once
<InPhase>
M6piz7wk[m]: Well I didn't imagine you would copy/paste it for a completely different type of design. :) But sometimes a reference example which previously worked helps.
<JakeSays>
M6piz7wk[m]: your polygons are pretty straight forward
<InPhase>
If I did it over again, I'd probably angle the top of the wall-mounted wedge piece inward a little for easier insertion.
foul_owl has joined #openscad
<InPhase>
I recall the handful of times I slid it off to clean it, there was a little bit of wiggling involved with reinserting it. This wasn't a big deal because it doesn't need done often, but it's always nice to have a thing slide together with ease.
<M6piz7wk[m]>
<JakeSays> "6piz7wk: why couldn't you define..." <- because then you have to do a calculations for the coordinates?
<M6piz7wk[m]>
and the design scales with size.. so that seems like a nightmare to do
foul_owl has quit [Ping timeout: 256 seconds]
<JakeSays>
M6piz7wk[m]: you define the polygon and then you translate/rotate it
<JakeSays>
M6piz7wk[m]: in what sense does it scale with size? (also, scaling is easy)
<M6piz7wk[m]>
JakeSays: projected to scale after 400x400 by 0.5% per 50x50
<M6piz7wk[m]>
trying the polygon now
<JakeSays>
so the whole thing scales in 3 dimensions?
<M6piz7wk[m]>
projected to yes, but currently not important to handle
<M6piz7wk[m]>
also it will be double mirrored so that the shape is on all 4 corners.. so polygon a bad idea?
<JakeSays>
not at all
foul_owl has joined #openscad
<M6piz7wk[m]>
i have no idea how to define the polygon and i am about to throw my 3D printer through the monitor
<JakeSays>
lol
<JakeSays>
InPhase: so is there an issue with subtracting a polyhedron from a cube?
<InPhase>
Only if it's a malformed polyhedron, which is easy to do.
<JakeSays>
it doesn't render correctly in preview mode, but the render is fine
<InPhase>
Do View Thrown Together on the polyhedron and look for the purple faces that indicate a bad winding order.
<InPhase>
Hmm. Usually it's render that messes up and preview that is fine. Although a particularly complicated design will sometimes have a convexity issue in preview mode.
<JakeSays>
lol every side is purple
<InPhase>
Okay, well fix those. ;)
<JakeSays>
i took the faces directly from function render()
<M6piz7wk[m]>
figured out that writting the shape down on a paper to figure out the coordinates makes the polygon definition painless
niyawe_ has quit [Ping timeout: 268 seconds]
niyawe has joined #openscad
<Scopeuk>
that's fair, probably even easier on squared papper
<M6piz7wk[m]>
good idea
ickk has quit [Ping timeout: 260 seconds]
ickk has joined #openscad
voxpelli has quit [Ping timeout: 250 seconds]
voxpelli has joined #openscad
raboof has quit [Ping timeout: 252 seconds]
Joel has quit [Ping timeout: 250 seconds]
raboof has joined #openscad
fling has joined #openscad
Joel has joined #openscad
J22 has joined #openscad
<J22>
you can make a module that is naming and showing coordinates for each point
lastrodamo has joined #openscad
ccox has joined #openscad
nanoflite has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ochafik has joined #openscad
ochafik has quit [Remote host closed the connection]
ochafik has joined #openscad
ochafik has quit []
ickk has quit [Ping timeout: 260 seconds]
nanoflite has joined #openscad
snaked_bruh has quit [Ping timeout: 256 seconds]
snaked_bruh has joined #openscad
TheAssass1n has quit [Remote host closed the connection]
TheAssassin has joined #openscad
JakeSays has quit [Ping timeout: 250 seconds]
JakeSays_ has joined #openscad
snaked_bruh has quit [Ping timeout: 240 seconds]
snaked_bruh has joined #openscad
snaked_bruh has quit [Ping timeout: 256 seconds]
<lf94>
I am such in a bind. I don't know what to do. All the Code CAD have weaknesses.
<lf94>
OpenSCAD can't do really funky stuff like generate complex lattice, without heavy computation
<lf94>
But it can do everything else
<lf94>
CADQuery is the same, but can't really do CSG, which is huge for me.
<lf94>
Curv is horribly inefficient, and so can only generate certain models which don't output massive GLSL files.
<lf94>
And finally my solution Epifaneia is just so much work on my own.
<lf94>
But solves all the above.
<lf94>
And I don't want to use multiple languages. One language is enough.
* teepee
looks at the channel topic
<teepee>
well, I guess the answer you'll get *here* is pretty clear
<teepee>
although I have said in other place that I'd like for people considering dev work to at least consider joining an existing effort
* teepee
points at one of the earlier FOSDEMs
<teepee>
10:00 "how I created a new PCB CAD tool to fix the kicad library handling"
<teepee>
14:30 "how I designed a new project because kicad libraries are not fixable"
<teepee>
16:00 kicad: how our new library handling solves commonly reported issues
<teepee>
* slightly paraphrased ;-)
snaked_bruh has joined #openscad
<lf94>
Yes teepee, this is the core of my problem.
<lf94>
I am now divided as to where to put my efforts.
<lf94>
I am considering things like: what would it take to offset some computation to GPU for OpenSCAD?
<lf94>
With my new found WebGPU knowledge, I should be able to do this, if I choose to
<lf94>
My other issue with OpenSCAD is "legacy cruft", but, this is not really a problem at the end of the day.
<lf94>
I'm so stuck x_x
<Scopeuk>
lf94 I guess i would suggest accepting multiple languages as the compromise, no tool is perfect for all circumstances and having the approiate tools in the kit is as important as having any one of those be the best of its kind
<Scopeuk>
I enjoy working with c and knowing every register twiddle etc on a micro but sometimes the right tool is to cludge together a handful of libraries from the arduino ecosystem
<lf94>
Not true though. There can be a single language tool that can satisfy it all.
<Scopeuk>
But would it be three languages in a trench coat?
<lf94>
No, it would be JS and WGSL
<lf94>
One for high level, and one for low level
<lf94>
This is openscad's biggest weakness
<lf94>
You can't deconstruct sphere
<lf94>
But it's futile to work on a separate project. It really is.
<Scopeuk>
There is an effort that moves the underlying geometry into userland using point clouds, i forget which of the regulars created it. It allows that flexibility. I doubt its quite the freedom you are looking for. As with many of these things anything is a tradeoff. Usually with power/flexibility comes complexity and a higher barrier to entry. It also
<Scopeuk>
tends to lead to a situation where a simple option is skipped over because a more complex solution to achieve the end is implimeted
<lf94>
I might use openscad for the core modeling, and blender for fancy stuff, like surface texturing.
<lf94>
Curv is nice, but it's export story is terrible.
<Scopeuk>
I would argue a collection of tools that achieves the ends is a good compromise
<Scopeuk>
It is a compromise and imperfect but its better than spending forever hunting perfect
<lf94>
Yeah.
<lf94>
I want to create things. Not be stuck.
<teepee>
that's the beauty of joining an established project, if you can get your self unstuck, that may do the same for a number of other people too
<teepee>
now sharing source code on github is great, but not everyone can build and run that, and maintaining this is quite some work
<teepee>
moving the CSG stuff into GPU would be awesome, potentially as library that compiles to WASM too, so it would even open up more flexibility
<teepee>
I've been looking at this "realtime CSG rendering" stuff but I'm not clear how it works yet. but even OpenCSG on GPU would be cool
<InPhase>
lf94: Implement a built-in for OpenSCAD which turns function literal based SDFs into mesh geometries.
<lf94>
I have no idea how I'd do that :/
<InPhase>
Steal.
<lf94>
teepee: real time CSG is different because openscad is mesh based, but SDFs are ... pixel based?
<lf94>
CSG is just super cheap
<teepee>
yes, and having both would be nice too
<teepee>
you said offloading stuff from openscad to GPU
<lf94>
InPhase: don't we already have functions in openscad that can create polygons?
<lf94>
ah, yea
<teepee>
which *at this point* would be mes
<lf94>
As in, compute shader
<teepee>
mesh
<InPhase>
It seems apache 2.0 code, which curv is under, can be shoved into GPL projects.
<lf94>
InPhase: well I could shove my project in too, but it involves Rust and JS.
<InPhase>
I don't know if there are sdf processing pieces that are useful there or not. Maybe libfive alone is enough.
<lf94>
Yes, libfive is probably enough
<InPhase>
But I think going in that direction opens up the pathway to solve those hard problems in OpenSCAD while still riding on the back of the good computational geometry tools, export tools, and other aspects.
<InPhase>
Plus it would really put those nice function literals to solid use.
<InPhase>
The best practical solutions are not pure, because pure solutions tend to not fit the diversity of real world problems. Multi-paradigm languages dominate the programming world for a reason.
<InPhase>
So it seems reasonable to go with multi-paradigm CAD.
<lf94>
So to make sure I understand: you propose we translate OpenSCAD functions to say, libfive functions?
<lf94>
This sounds actually very feasible.
<lf94>
Like, "I can do this in a week" feasible
<lf94>
(On top of you know, regular work)
<InPhase>
sdf_mesh(myfunction_that_calls_many_other_functions); // Magic things happen
<InPhase>
Or something like that.
<teepee>
alternative, tag a subtree with something like @SDF
<InPhase>
With a specification for the expected parameters of the top-level functions that get passed to the sdf_mesh (or by another name).
<InPhase>
teepee: Well function literals are the perfect thing for this. Modules don't return values, so it's a different sort of syntax than our usual geometry creation. But passing one into something works with normal language flow.
<InPhase>
Then it's like a polyhedron call, except potentially a lot more useful.
<teepee>
true, this would give even more flexibility
<teepee>
but even rounded union might like implictcad would be an incredible useful step
<InPhase>
And library support for such a built-in could get quite intensive. And then we can decide what library features to bundle in later if it turns out to be high value.
<lf94>
You guys would be ok with vendoring libfive?
<teepee>
if that brings useful features and builds on all platforms, why not
<InPhase>
I think we mark it experimental, but it seems very sensible to me.
<teepee>
well, and we don't do lisp :P
<InPhase>
The core of libfive appears to be all C++.
<InPhase>
But I assume we'd treat it like a library and not try to merge it.
<InPhase>
There's already an active team working on libfive.
<InPhase>
Development on it seems to have picked up massively last year.
<teepee>
oh, yes, "using as library" is pretty much the only option
<InPhase>
If it works well, this could potentially be high on the list of top major changes to OpenSCAD in terms of really changing what can be done.
<InPhase>
Function literals were important, and basically setup for this. I'm still very excited about that massive speed boost PR, data = render() is potentially big introducing reflection, and bundling in sdf support opens a flexibility flood gate for smoothness.
<lf94>
Well it's essentially interfacing with libfive via openscad, right?
<lf94>
I'm really coming full circle.
<lf94>
openscad -> cadquery -> curv -> my own solution -> openscad
<lf94>
csg + sketching is so immensely powerful. That's why I really loved Curv.
<lf94>
(because it could do csg super well, and also newer than openscad)
<lf94>
But Doug has disappeared. I'm actually worried he might have died.
<lf94>
I've been looking around at obituaries but none. I know where he lives and his name, but yeah, nothing.
<teepee>
lets hope he has not, one of those messages per month is really enough :/
TheAssassin has quit [Ping timeout: 276 seconds]
TheAssassin has joined #openscad
JakeSays_ has quit [Ping timeout: 256 seconds]
<lf94>
Maybe I should just do JS bindings to libfive.
<lf94>
Gah, there are way too many paths to take.
<teepee>
your time, your decision
<teepee>
I personally don't see much use in that
<teepee>
but if you want to have it, go for it
<teepee>
otherwise, I agree with InPhase the overall opportunities with openscad are much bigger ;-)
<lf94>
Minkowski and hull really are the two features which would not be possible in libfive.
JakeSays has joined #openscad
<lf94>
or anything
<lf94>
Also: I cannot get over the precision of 3D printers. My printer is printing at 0.2mm diameter, and 0.18mm height. It's incredible to see the lines.
<teepee>
yeah, that's a restriction we may get when trying to export STEP too
<lf94>
You guys are trying to export to step?
<lf94>
interesting
<lf94>
With my sketch api, I am thinking of keeping edge data along with operations
<lf94>
So you can traverse it and do stuff with them
<lf94>
like fillet
<lf94>
no more annoying manual fillets
<teepee>
there's no code that's anywhere near usable, but there's some sort of demo PR for an external tool and the disucssion comes up always
<lf94>
I've been developing a sketch api that is CSG agnostic, as long as it supports an operation to create closed shapes.
<lf94>
So, I could easily bring this to openscad also. It started in Curv.
<lf94>
I'm currently stuck on implementing all the arc sketch operations. The math is hard for me :-
<lf94>
:\
Matt76 has joined #openscad
<lf94>
For me the most interesting aspect of the sdf function will be: surface textures, and smooth union.
<lf94>
That will cover _everything_ I ever want from a code cad tool.
<lf94>
engineering, csg, organic.
<lf94>
It can be done. But the man power needs to exist.
<InPhase>
lf94: 95% of the usages of minkowski in OpenSCAD are trying to do things sdf would have done better. This is where the power of a merged solution kicks in where we can do sdf components in OpenSCAD.
<M6piz7wk[m]>
ooops sorry didn't know it spams the chat
<JakeSays>
lf94: speaking of curv, what does '<<' mean?
<JakeSays>
or is it >>
<teepee>
JakeSays: a slightly different style of defining 2D shapes using constraints
<InPhase>
lf94: I wish I knew the actual userbase size of OpenSCAD, but I don't know how to measure it. One thing I'm pretty sure of is that it is extremely massive. I often talk to random people with no project affiliation and they've already used it.
<InPhase>
lf94: So the impact is guaranteed to be large.
<teepee>
M6piz7wk[m]: how it could look like, lf94 might show in a minute or two ;-)
<M6piz7wk[m]>
eh?
<teepee>
not sure if you followed the discussion, but we are just talking about the sketching code lf94 worked on (which I think is currently based on curv?) but might be possible to add to openscad too
<teepee>
if it's similar to what cadquery does, their documentation might give an indication too
<JakeSays>
teepee: i thin it's kind of ugly
<teepee>
what is? the cadquery style of 2d sketching?
<JakeSays>
curv's '>>'
<lf94>
> also to have the ability to convert text ...
<teepee>
ahh, yeah
<lf94>
teepee: exactly. I have done this basically too.
<lf94>
svg2curv was planned to do this.
<lf94>
Sorry, I'm quite busy atm, will get that code for you
<teepee>
well, we have the reading part of the code already :)
<teepee>
just right now it's generating the 2d polygons directly
<InPhase>
JakeSays: Well we don't need the curv syntax.
<JakeSays>
InPhase: good. lol
<InPhase>
JakeSays: I think the OpenSCAD syntax is pretty accessible to new designers, and is reasonably self-consistent. What we'd want is the core sdf features integrated smoothly.
<M6piz7wk[m]>
teepee: oh i didn't know you were talking about it O.o
<lf94>
teepee: that's what mine is doing too.
<JakeSays>
i'm going to have to read about this sdf thing
<teepee>
JakeSays: for interesting overview, maybe check the iq pages
* teepee
goes finding the link
<InPhase>
JakeSays: I have three words for you. Inigo Quilez youtube
<InPhase>
I mean, then you have to read about it to understand, but that's the motivating example. :)
<teepee>
yep, lets keep it that way while making it more powerful for people who want to use that :)
Matt76 has quit [Ping timeout: 256 seconds]
default__ has quit [Ping timeout: 250 seconds]
<lf94>
teepee: sorry, you're right
<JakeSays>
teepee: but i do think there could be value in having a lower level language that openscad can use to build new primitives. such a language wouldn't be available to the end user.
<teepee>
JakeSays: right now that's limited to c++, integrating something else would be possible but at this point very likely not maintainable
ferdna has joined #openscad
<JakeSays>
why wouldn't it be maintainable?
<teepee>
at this point kintel is luckily doing MacOS stuff, all other builds are pretty much on me (except linux distro packaging)
<teepee>
and while I would like to have a 30h day, that's not granted so far
<JakeSays>
i'm not sure i follow.
<teepee>
each dependency can and will change at any point in time, OS versions, libraries with new versions, compilers with new versions
<teepee>
e.g. there's just a new CGAL version out, which we probably want to use
<teepee>
so going round updating all the builds, while partially automated is still quite some work
<JakeSays>
i wasn't talking about requiring new compilers, etc. this would be a part of openscad
<teepee>
and updates on platforms tend to break builds also
snaked_bruh has quit [Ping timeout: 268 seconds]
<teepee>
I did play with a python("<write some python code which will generated data>") and that's not trivial and also would break anything we have as plus in regard to security on server side
<JakeSays>
yeah i'm not sure we're talking about the same thing
<teepee>
possible
<JakeSays>
i'm talking about a DSL implemented in c++ inside oscad
<teepee>
so what would that lower level language do as a specific example
<teepee>
a DSL inside a DSL?
<JakeSays>
i dont think so, no.
<JakeSays>
i dont see it being based on openscad code
<teepee>
then I'm lost what it means
<JakeSays>
"implemented in c++ inside oscad" - oscad == the binary, not the scad language
<teepee>
yes, I understand that part, but the user level side of openscad scripting is already a DSL
<JakeSays>
correct
<teepee>
so it would be like use current script or use a completely other script but not mix?
<JakeSays>
this would be a "system dsl" so to speak
<JakeSays>
the latter
<JakeSays>
a microcode so to speak
<teepee>
not being able to mix scripts would be like 2 applications in one?
<JakeSays>
no
<JakeSays>
primitives of scad are implemented in.. fooscript
lastrodamo has quit [Quit: Leaving]
<JakeSays>
so for example new_super_cube() would be implemented with a bunch of fooscript instructions instead of c++
<teepee>
what would it have over using either scad (user level library) or c++
<JakeSays>
easier to implement
<JakeSays>
assume that feature X is complicated. doing so in c++ would require a lot of work and it's not feasible to do it in scad
<JakeSays>
teepee: actually, i think it's very similar to what the csg product dump view shows
<JakeSays>
although i'm not sure lisp would be my choice. lol
<JakeSays>
or maybe the csg tree
<JakeSays>
so perhaps new_super_cube() is written in "csgscript", etc
<teepee>
csg tree actually *is* scad code, just simplified without modules and functions
<teepee>
(minus some glitches with NAN and INF)
<JakeSays>
will it compile as scad code?
<teepee>
yes
<JakeSays>
oh cool
<teepee>
not that lisp style product stuff, that's the tree for preview
<teepee>
what you can export as *.csg files
<JakeSays>
i didn't even know group() existed
<teepee>
yeah, another of those glitches, it's probably not supposed to be public but it leaks via CSG
<teepee>
and it's valid code too
<JakeSays>
very interesting
<teepee>
I believe that was meant to be transfer to slicers which would be able to slice that directly
<JakeSays>
so as an end user are there things i can do in csg that i can't do in "public" scad?
<teepee>
but I'm not sure that ever existed
<teepee>
no, I don't think so
<teepee>
I think it's essentially a subset of scad. ignoring the glitches it's a strict subset
<JakeSays>
i just looked at the csg for one of my designs. very interesting
<JakeSays>
lol sure enough. i pasted it in to a new scad document and it worked
<JakeSays>
would be an interesting way to obfuscate code
<teepee>
if you put in some 1/0 it probably fails as it exports something like "a = inf;" which would then not parse
<JakeSays>
well, probably the only way my fooscript concept would be useful is if it was maybe a higher level shader language or something.
<M6piz7wk[m]>
Is there any default path that is used by OpenSCAD for 3rd party libs?
<teepee>
yes, it's shown in help->library info
<M6piz7wk[m]>
thanku
<teepee>
or file->open library folder
<M6piz7wk[m]>
found `/home/kreyren/.local/share/OpenSCAD/libraries` it doesn't exist by default?
<teepee>
it might be created when using the file->open lib folder menu entry. not sure
<M6piz7wk[m]>
ehh what does it expect ? just lot of foo.scad files?
<M6piz7wk[m]>
or can it use invidual directories e.g. ../libraries/something ?
<teepee>
nothing, whatever you do
<teepee>
you can add more folders using OPENSCADPATH variable
<teepee>
I usually just git clone stuff into that folder, in most cases it's possible to use that way
<M6piz7wk[m]>
so it's just looking for .scad files and then lets it to be called using `use <pegboard.scad>` ?
<teepee>
yes, it will just go though the PATH as operating systems do for binaries
* M6piz7wk[m]
wants to do the alternative to FreeCAD models directory which is just one huge git repository with lots of submodules that are all browsable from the editor
<M6piz7wk[m]>
i see O.o cool
<teepee>
with snapshot version it will even do autocomplete for those
<M6piz7wk[m]>
hmm is there a way in open-scad to execute a command when the library is called ?
<M6piz7wk[m]>
*openscad
<M6piz7wk[m]>
like `use <pegboard.sccad>` to invoke git to pull submodule and make that lib available
<teepee>
nope, but I really want to have some sort of minimal library fetcher at some point soon-ish