<lf94>
Day 5 of Scadvent 2021 runs in like 4 seconds now in libfive
<lf94>
Takes like a full on minute to render in Curv
<InPhase>
Is libfive still under active development?
<InPhase>
I've contemplated bundling libfive for an sdf feature in OpenSCAD.
<lf94>
matt still maintains it, yeah
<lf94>
But it's basically done
<lf94>
he did a gpu-enabled variant too
<lf94>
but it's less powerful
<lf94>
in terms of expression
<InPhase>
kintel the log reader: Congrats on the baby! Good luck with the sleep.
<InPhase>
lf94: I think adding sdf functionality will be a major boost, even if we have the natural one-way restriction on combining the approaches.
<lf94>
the cool thing about libfive is it works even outside of sdfs, like it can use meshes and stuff
<InPhase>
It will open a door to nicely solving a whole class of problems in part design.
<lf94>
via "oracles"
<InPhase>
Well I think we should bring it in for the sdf features, but once in, it could be used for other things "because it is there".
<lf94>
it'd be really easy :)
<lf94>
(to integrate libfive)
<lf94>
at least now that I've written full on ffi bindings all by hand... I understand it pretty well
<lf94>
I just dont know what language extensions openscad would use / need
<lf94>
sdf { .... }
<lf94>
and that returns a mesh I guess
<lf94>
via libfive_tree_render_mesh
<teepee>
some sort of annotation to mark a subtree as SDF
<lf94>
This could honestly be done in one night of crazy hacking
<lf94>
But I'd need an openscad language expert with me
<teepee>
not really, you can get things initially going by just assuming sdf everywhere
<lf94>
ahhh yeah, that's an option too
<lf94>
I was thinking more proper but if I start with that, it'd make it much easier
<lf94>
I think I'd do that then pass it off
<lf94>
then watch me come back to scad...
<lf94>
I can get smooth blending then and no reason to complain anymore.
<lf94>
if openscad could obliterate cgal i'd be so happy
<teepee>
maybe not fully, but if it would remain only for a number of operations, you can opt to not use those :)
<teepee>
but in the end, what does it matter? when designing stuff, the important thing is what you can get done
<teepee>
As I said earlier, an initial libfive backend might look quite similar to https://github.com/openscad/openscad/pull/4533 - I could be wrong, I have not looked at the API but this PR is really quite small, just 31 files changed
<teepee>
and most of the changes are build system
<teepee>
most of the *files*
teepee_ has joined #openscad
Guest4423 has joined #openscad
Guest4423 has quit [Client Quit]
<InPhase>
lf94: The input to sdf will be function references, so sdf(...);
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
<InPhase>
lf94: You could look at the structure of polyhedron() for an example. It's basically the same, except taking a function reference instead of a list. Both then do some operation, and shove a geometry into place as a result.
<teepee>
not starting with CSG?
<InPhase>
As input?
<teepee>
yes, like "normal" scad code
<teepee>
a function reference would be extremely powerful but also a bit more tricky to get started with
<InPhase>
Well, that's not what sdf's do. There should be a function that has 3-axis inputs returning a signed float which is 0 at the surfaces. Then we need an sdf() built-in that takes this function, a domain limit for it, and returns the mesh of the boundaries.
<InPhase>
Everything else about adding sdf support will be about thinking through some new function literal built-ins to help out the process.
<teepee>
well, yes, SDF is functions, but cube() can generate the cube function
<InPhase>
Well, fcube, funion, etc.
<teepee>
why? a tree annotation similar to # would work too
<teepee>
for maybe an sdf() module as mentioned before, but I still don't like those
<InPhase>
Because then you cannot create custom operations with natural syntax.
<InPhase>
modules have no return.
<teepee>
they return an internal geometry object which currently is a mesh, but could also be a sdf function
<teepee>
it would limit possibilities first I suppose but would be a start without much need for language changes
<InPhase>
The "This CSG solid" example I could picture as a syntax tree interpreted differently. But "low-level definition of a cube" and the remap-shape example I cannot imagine being anything other than function literals, as they are, fundamentally, functions.
<InPhase>
Likewise for that beautiful blend example.
<InPhase>
How do you min inside of module type syntax?
<teepee>
a possible blend syntax is shown by implictcad
<InPhase>
Oh, I'm proposing no language changes at all.
<InPhase>
Other than "now there's an sdf built-in". And "we could add a few function literal built-ins to get people started".
<InPhase>
Syntax-wise, zero changes are needed.
<InPhase>
teepee: You already wrote everything we need. :-P
<teepee>
maybe for the people dreaming math that's totally enough
<teepee>
it would just be nice to basically use the same script (without minkowski and probably hull) to go through SDF by just tacking on a marker to do so
<teepee>
like that high-level example
<InPhase>
Give me a minute to check on the kid, and then I'll try to type up the syntax example in my head. I don't think it will be confusing to the masses.
* teepee
needs to go to bed :)
<teepee>
waaaaay too late already, need to get a new production line online in a couple of hours
<teepee>
now I wonder what the english name for those is
<InPhase>
We just need to get you on Eastern US Time.
<teepee>
heh, "honen" translates to Honing (metalworking)
<InPhase>
Well, if it takes me longer to type it up than you stick around after you say you're leaving, then goodnight, and let me know your thoughts tomorrow. :)
<teepee>
goodnight :)
* teepee
grabs 5,5h of sleep...
<InPhase>
teepee: I think this is a proper reproduction of the corresponding examples on that libfive page, but fully within existing OpenSCAD syntax. https://bpa.st/T4GF2
<InPhase>
We need to consider both kinds of cases. The top one is "different" from standard OpenSCAD module syntax, but because it's fundamentally doing something very different. It is, however, extremely similar in structure, and should be very intuitive. The bottom example shows why it needs to be this form, because that's how you would do that blend function from the libfive example.
<InPhase>
Each one of these needs to return a function reference that can be called with x,y,z, and each one needs to be able to pass x,y,z into one or more function references received as arguments.
<InPhase>
So fsphere, for example, would be a built-in function literal which returns a function literal that can be called with (x,y,z)
<InPhase>
fsphere(r=2)(2,0,0) would return 0. fsphere(r=2)(5,0,0) would return 3. Although a user would basically never call them with these (x,y,z) parameters, except maybe some people interested in nuanced debugging.
<InPhase>
If we ignore support for diameter and such (which should be there in the real case), fsphere's built-in definition would be equivalent to: fsphere = function(r) function(x, y, z) sqrt(x*x+y*y+z*z);
<InPhase>
Simple enough that these can all be written out in scad code for early testing. sdf is the only piece we really need as a built-in.
<InPhase>
Oops. fsphere = function(r) function(x, y, z) sqrt(x*x+y*y+z*z)-r;
<InPhase>
And sdf's definition is to take this one function reference that takes (x,y,z) and returns the distance float d, plus a bounding box (or a reasonable default for that).
teepee has quit [Remote host closed the connection]
<lf94>
InPhase: that sounds like a good first step.
<lf94>
also: I adjusted the resolution and bounding box and meshing is now near instantenous for day 5.
<InPhase>
Nice.
<InPhase>
lf94: Now... How big is a binary stl generated from this? That will be a nice side method of deducing how well it's handling edges.
<InPhase>
OpenSCAD is producing 77884 bytes.
<InPhase>
And presumably this is the optimal value for the design, as OpenSCAD is by design doing this. So in the best case we would expect libfive would match it, but more likely it's some larger value. But how much larger?
KimK_ has joined #openscad
KimK has quit [Ping timeout: 255 seconds]
J235335 has joined #openscad
J2353 has quit [Ping timeout: 260 seconds]
ur5us has joined #openscad
Guest9381 is now known as buZz
ur5us has quit [Ping timeout: 260 seconds]
Lagopus has joined #openscad
fling has quit [Remote host closed the connection]
fling has joined #openscad
Bocaneri has joined #openscad
Bocaneri is now known as Guest7624
Sauvin has quit [Ping timeout: 260 seconds]
guso78 has joined #openscad
Guest7624 is now known as SenFache
fling has quit [Remote host closed the connection]
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
guso78 has joined #openscad
Andy-pants has joined #openscad
kintel has joined #openscad
<Andy-pants>
Is it possible to use a for a loop to generate a set of modules that can be passed as children to another operator? I want to generate a solid that's an arc from one point to another, which tapers down as it gets to the second point. So far, I've used dotSCAD's `bezier_curve`to generate the path, which I then use dotSCAD's `polyline_join`to
<Andy-pants>
generate the hull. However, it currently doesn't scale. `polyline_join` can operate on one or more children.
<Andy-pants>
But, I can only get a single module as a result of a call to for
<teepee>
no, that will need some different feature
<Andy-pants>
That's what I was afraid of
ur5us has joined #openscad
<teepee>
yes, right now the implicit union prevents that, but even with that changed it will not work
<Andy-pants>
ooh, that seems to be exactly what I'm looking for!
<Andy-pants>
Fortunately, the polyline_join function is pretty simple, and I can write my own with the scaling of each child built-in
<Andy-pants>
Thank you for your time teepee!
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<J235335>
Andy-pants can you elaborate what the result should be .. i assume there is a different approach maybe recursive calls
J235335 is now known as J23
<Andy-pants>
I got it working, actually. :) I was thinking about the problem imperatively instead of functionally. I needed to replicate the polyline_join implementation, and scale the object being used to generate the hull as it's generated.
<Andy-pants>
Though, the result is not nearly as smooth as I'd like. But, I'm making progress nonetheless. :)
<J23>
If you are not saying what you try to accomplish i can't help you .. sounds a bit like a chained hull
<Andy-pants>
I was able to accomplish what I was looking for, actually.
<J23>
Andy-pants you said "result is not nearly as smooth as i'd like" and that you accomplished what you was looking for - that is a contradiction .. however great that you got what you wanted ..
guso78 has quit [Quit: Client closed]
Andy-pants has quit [Quit: Client closed]
kintel has joined #openscad
<kintel>
Linux/EGL: Does anyone happen to know how to select which GPU to use for offscreen rendering using EGL? Using eglQueryDevicesEXT, eglGetPlatformDisplayEXT, but it seems to always choose my primary GPU.
Andy-pants has joined #openscad
<Andy-pants>
J23, my issue is that I was not using the correct dimension for the next item in the chain when creating the hull for that "segment". Instead, I was using the same dimension for the start/end of that segment, creating a stair step effect.
<teepee>
kintel: no, I could only test with a single one and the device behavior was confusing enough already
<teepee>
I did reference against the egl code of retroarch at the time, maybe they have some pointers
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
kintel has joined #openscad
<kintel>
teepee: This is prob. mostly useful for multi-GPU server-side stuff, so it's not too critical. I just want to understand it :)
<teepee>
I understand Wayland always does EGL, so it may get more interesting for desktop too
<kintel>
yeah, but the specific issue of rendering to a different GPU than is driving your screen is prob. a bit esoteric in GUI mode
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<teepee>
what I always found slightly funny: openscad is bad as it sometimes is computational unstable
<teepee>
status of the project: it's computational unstable
<teepee>
that said, the idea of direct slicing is not exactly new, as I understand that was the whole idea for the CSG format
<teepee>
plus icesl does it too
<J23>
if you completely circumvent the 3D part by generating only 2D layers and do all the operations just in 2D - but not sure if this works for hull or minkowski
<teepee>
I like the fast and stable 3d solution better :)
kintel has joined #openscad
snaked has joined #openscad
<teepee>
ochafik is teasing some amazing stuff
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]