<feep>
quick update: fncad is coming along~ it has parameters and vectors and a nice help popup, but no variable declarations or for loops yet.
<feep>
I'm changing a tiny bit from openscad, in that for loops evaluate to a list of objects that is interpolated in the caller. so there shouldn't be a need for intersection_for, because you can just intersection() for().
<feep>
also I'm tempted to make variables require an explicit declaration, var a = 3; and in exchange make reassignment actually *change* the value. so if you a = 4, any access to `a` after that will yield 4. I'm not sure if that breaks anything.
<feep>
but that aside, the syntax is very familiar so far~
guso78k has quit [Quit: Client closed]
Reisga2449 has quit [Quit: Ping timeout (120 seconds)]
Reisga2449 has joined #openscad
kintel has joined #openscad
<kintel>
guso78 Re. else: "if" is actually a module, not a language construct, and it needs an "else", so I think passing an optional else was the easiest way to get that plumbing in place
<InPhase>
kintel: You had me worried there for a second that children() might evaluate to the else in an if. :) But it does not.
<InPhase>
This is the only surprising consequence of if being a module. I don't think I ever consciously realized that if could be children. But it makes sense semantically. x = 5; module Foo() { children(); } Foo() if (x < 10) { cube(10); } else { sphere(10); }
<kintel>
heh, not even sure we have a test for that
<InPhase>
Now I've made for a child before, but never used it with "children()"
<InPhase>
I think.
<InPhase>
Well, maybe I did.
<InPhase>
But I'm not sure if I ever thought about it as being evaluated inside.
J24k has quit [Quit: Client closed]
J24k has joined #openscad
foul_owl has quit [Ping timeout: 246 seconds]
<kintel>
pca0061325 For whenever you're around: I want to be able to achieve the following when using Manifold as a submodule:
<kintel>
OpenSCAD will use Clipper2 as a submodule, and build the Clipper2 target as normal. Then when building Manifold, I want Manifold to pick up the Clipper2 we just built
<kintel>
..and AFAIU, the only thing we have to go on right now is that the "Clipper2" cmake target is defined, but not sure if that's a great thing to check for in Manifold's CMake config. Still looking for other options..
foul_owl has joined #openscad
<kintel>
^all of the above is "necessary evil corner cases" - I hope that the regular build will just build both clipper and manifold externally and use Find macros
<JordanBrown>
If all of your model is #ed - for instance, the model is just "#cube(10);" - then the model is displayed in opaque orange rather than translucent pink. Anybody know why?
<JordanBrown>
It is as if the model is displayed both highlighted and normally; "#cube(10);" is the same display as "#cube(10); cube(10);".
<JordanBrown>
kintel any ideas? ^
<kintel>
No idea, but it worked in 2015 :)
<JordanBrown>
I think there's a bug when the CSG rendering chain is empty.
<JordanBrown>
I haven't looked at the sources, but for simple #cube(10); the CSG Products Dump has the
<JordanBrown>
cube listed in both "CSG rendering chain" and "Highlights CSG rendering chain".
<JordanBrown>
But when you add in a normal sphere the "CSG rendering chain" is only the sphere.
<kintel>
Sounds like a bug. I'm surprised we don't have a test for this
<JordanBrown>
Probably something simple. I'll file it.
<kintel>
I guess there might be some requirement somewhere that we cannot have an empty rendering chain.
<JordanBrown>
I'm not feeling quite awake enough to dig through the previewer - that's tough when I'm at 100%.
<JordanBrown>
Given that the highlight and background chains are allowed to be empty, it's hard to believe that the normal chain has a real problem with being empty.
<pca0061325>
kintel: I think there is a way to override find_package...
<guso78k>
@kintel, thanks for the explaination. Yes, " If" as module appears logical . "If" in functional context not very applicable as variables cannot be overwritten
guso78k has quit [Client Quit]
Joel has quit [Remote host closed the connection]
Joel has joined #openscad
ccox has quit [Ping timeout: 276 seconds]
JakeSays_ has joined #openscad
JakeSays has quit [Ping timeout: 248 seconds]
JakeSays_ is now known as JakeSays
JakeSays_ has joined #openscad
JakeSays has quit [Ping timeout: 260 seconds]
ccox has joined #openscad
hyperair has joined #openscad
J24k16 has quit [Quit: Client closed]
J24k16 has joined #openscad
JakeSays has joined #openscad
JakeSays_ has quit [Ping timeout: 252 seconds]
hyvoid has quit [Ping timeout: 260 seconds]
hyvoid has joined #openscad
JordanBrown has quit [Read error: Connection reset by peer]
aiyion has quit [Remote host closed the connection]
aiyion has joined #openscad
mmu_man has joined #openscad
Guest52 has joined #openscad
mtm has quit [Ping timeout: 246 seconds]
mtm has joined #openscad
Guest52 has quit [Quit: Client closed]
SamantazFox has quit [Quit: Bye]
snaked has quit [Remote host closed the connection]
SamantazFox has joined #openscad
J24k16 has quit [Quit: Client closed]
J24k16 has joined #openscad
teepee_ has joined #openscad
teepee has quit [Ping timeout: 264 seconds]
teepee_ is now known as teepee
aquila has quit [Quit: aquila]
invultri has joined #openscad
<invultri>
Is there a way to do profiling on your functions?
halloy2705 has joined #openscad
halloy2705 has quit [Quit: halloy2705]
<invultri>
(other than sticking in an echo statement and counting with grep "ECHO" | sort | uniq -c for at least an idea on how many times a function is called)
<pca0061325>
invultri: you mean functions in openscad, instead of csg operations?
<InPhase>
invultri: Not really... I would usually just calculate it from principles, as in most cases this is from some obvious mathematics. In some cases the count will be weirdly hard to predict though, especially if doing some wonky fractal stuff. In that case a slow echo-like approach would be the only in-place approach.
<InPhase>
invultri: Do note that large amounts of echo add substantially to execution time though.
<InPhase>
invultri: If I really wanted to deep-analyze a functional approach, I might pull it out into an equivalent in Python and use some globals to keep track of records. I tend to explore mathematically complicated stuff in Python more. I view "echo" as more just for debugging in OpenSCAD.
<invultri>
pca0061325: yes, function execution time.
<invultri>
InPhase: well, count is only a proxy of course, and yes I did notice that echo is quite a clobber on performance.
<InPhase>
invultri: You can of course tally up by rewriting your functions to return recursion counts as a parameter. But that can be extra work, and modifies things.
<InPhase>
And it'll probably clobber tail call optimization.
<invultri>
yup
<invultri>
I also find it hard to judge if I have to worry about list rewrites.
<InPhase>
There are some spectacular optimizations that have been worked in with a nice lazy-list-flattening feature, so if you construct lists on the way down, it will only flatten them at the first time you read them. This avoids excess copying, turning O(N^2) into O(N). It makes it behave more like Lisp lists.
<InPhase>
They become embedded vectors, functioning like a tree, up until that first read. So you only bump back to O(N^2) if you are constructing/reading/constructing/reading/...
<invultri>
as I would do with a hashmap ;)
<InPhase>
I'm not sure if that's even documented anywhere in the manual. Mostly it's just in there as a feature that magically makes things faster, hopefully without people needing to think about it. But there are a few cases where knowing that can help you make things much faster.
<InPhase>
For example, if you need the last-added value, passing it along is much much faster than re-reading it from the list.
<invultri>
I'll keep that in mind, luckily that means that recursively calling concat has that magic optimization.
<InPhase>
It should work for both concat and each.
<InPhase>
I usually preference using each.
<invultri>
depends on what I do. For raw list construction it is each, in folds I tend to use concat.
* InPhase
nods.
<invultri>
is there a difference between append and insert for lists? I can do a cache based on "always append and use native search with the vector as a key feature" or "keep a list sorted and use binary search but then insert in the correct place"
ToAruShiroiNeko has quit []
<InPhase>
The embedded feature should work identically for any ordering.
<InPhase>
It forms a tree-like structure, constructing a new vector with one element being an embedded vector which is the previous vector, and then it does a traversal to read out the linear order and convert it when reading a vector marked as not flattened.
<invultri>
so the which is best is probably down to cache hits in that case. Thanks, something to ponder on.
<InPhase>
peepsalot and I spent some time talking this out before he implemented it, and that seemed to us pretty close to optimal for almost all normal OpenSCAD usages.
ToAruShiroiNeko has joined #openscad
<InPhase>
Yeah, maybe. Although I'm not sure how often things at the level of cache hits can impact performance for OpenSCAD. While vector elements ARE done as in place variants, the space efficiencies aren't great, and there's so much dynamic allocation going on, that I'm not sure if our numerical performance hits great cache utilization. :)
<InPhase>
But it's actually a rare thing to have a design where computational time exceeds geometric computation time. Those lists going O(N^2) was one of the rare cases where this was happening. Hence the merit of making it go away.
<invultri>
oh for sure, but apparently having a way to perform boolean operations on the points of multiple polygons is a pain and probably not a normal OpenSCAD usage.
<invultri>
and I am suspecting I could re-use intersection calculations, maybe.
<InPhase>
If you make something that hits that balance of comprehendible (perhaps a testcase extraction from something more involved) but also underperforming expectations, it'd be worth sharing, and maybe even documenting as an issue. It's nice to find awareness of edge cases that could use attention.
<InPhase>
Although maybe there's an implementation tweak possible before an issue is needed. It depends on what you can find.
<InPhase>
It's very often faster to do calculations on points than on geometries, but when doing on geometries, if you have exactly identical components in use, they do get cached.
<invultri>
but if I want the points, then I can not use the geometries :) Besides, I do expect that native cgal is a a bit quiker
LordOfBikes has joined #openscad
aquila has quit [Quit: aquila]
mmu_man has quit [Ping timeout: 252 seconds]
mmu_man has joined #openscad
Guest79 has joined #openscad
<Guest79>
hello
Guest79 has quit [Client Quit]
mmu_man has quit [Ping timeout: 252 seconds]
<ali1234>
is roof() in a stable release yet?
mmu_man has joined #openscad
invultri has quit [Quit: leaving]
Guest85 has joined #openscad
<Guest85>
olá
Guest97 has joined #openscad
Guest97 has quit [Client Quit]
Guest85 has quit [Ping timeout: 240 seconds]
mmu_man has quit [Ping timeout: 244 seconds]
mmu_man has joined #openscad
kintel has joined #openscad
<kintel>
ali1234 Not yet, the original author dropped out, so we're trying to find a new owner for it
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<feep>
teepee, InPhase: Alright, it's now ~two weeks after I announced I was reimplementing openscad from scratch and I'm finally ready to share~ https://feep.life/~feep/fncad/
<feep>
not exactly feature complete but now that it has variables it's arguably actually usable.
<InPhase>
feep: Interesting. Now draw the rest of the owl. ;)
<InPhase>
feep: Did you base on libfive?
<feep>
InPhase: there's genuinely not *that* much owl left. It's slow rn for large scenes cause I have zero acceleration, but I've 3d printed things that came from it.
<feep>
InPhase: nope, it's 100% custom.
<feep>
it's a sdf backend using interval arithmetic, basically it builds an octree of the boundary, pulls a mesh from it and does some finetuning
<feep>
I wanted to do the simplest thing possible.
<InPhase>
Apparently your cubes are default centered. But I added "translate([2, 2, 2]) cube(4);" to the end of the smoothed diff, and it has an aesthetically pretty result.
<feep>
yay~
<InPhase>
There might be some owl left. :) But it does look like a visually pretty start.
<feep>
the rendering is done by a totally separate sdf shader path. let me be clear, there is a LOT of owl left. this is like 0.1.0.
<feep>
it's just the first version that's not a *complete* toy.
<Friithian>
just use eevee for rendering :D (and yes, I know I said ``just'')
<feep>
wow, that library is genuinely ungoogleable
<feep>
oh, the blender thing?
foul_owl has joined #openscad
<Friithian>
yeah
<feep>
yeah... I already removed one editor plugin cause it was too large :P I'm not shipping the blender render engine in webworker
<Friithian>
Im just ignoring reality and believing that you can just plug it into eevee
<feep>
XD
<feep>
also, just because it was pretty useless in working with openscad... this is like 6.7kloc of typescript, and it's all ai written~
<feep>
though admittedly towards the end I started hitting skill limits, and the async task system is an affront to god
<feep>
they say "if you're just smart enough to write something, you are not smart enough to debug it". my hope is that large language models will get smarter faster than fncad gets more complicated :D
splud has quit [Ping timeout: 248 seconds]
foul_owl has quit [Ping timeout: 244 seconds]
foul_owl has joined #openscad
splud has joined #openscad
guso78k has joined #openscad
guso78k has quit [Quit: Client closed]
L29Ah has quit [Ping timeout: 244 seconds]
J24k16 has quit [Quit: Client closed]
J24k16 has joined #openscad
califax has quit [Remote host closed the connection]