L29Ah has quit [Read error: Connection reset by peer]
b34r_dev has joined #openscad
kintel has joined #openscad
<b34r_dev>
Hey folks, given the example of three dots(1). Connecting them is easy via hull(2), but what if i want a curved connection between two points(3)?
<b34r_dev>
So far i came up with pulling out the school book and implementing a beziere curve, but as this goes quite lengthy, is there an already included, or plain easier way to do this in Openscad?
<JordanBrown[m]>
InPhase: yes it should be a vec3.
<JordanBrown[m]>
b34r_dev: there are no builtins for making such curves.
<JordanBrown[m]>
However, there are libraries that implement them.
<JordanBrown[m]>
Perhaps the most comprehensive is BOSL2.
<JordanBrown[m]>
It definitely has Bézier curves and surfaces.
<kintel>
InPhase I've found another Python-related issue, this time on Debian (bookworm-slim on Docker):
<kintel>
-- Found Python3: /usr/bin/python3 (found version "3.11.2") found components: Interpreter
<kintel>
/openscad/build/tests/venv/bin/python: No module named ensurepip
<joseph_>
kintel: Thank you for the suggestion about clarifying the existence of other legacy API calls. I added a couple sentences about that to my proposal. Also teepee I just submitted a PDF of what I have so far to the GSoC dashboard. One thing we didn't talk about yet is project size (175h vs 350h). So far I have selected 175h but I am open to changing it if you think it would be better.
<kintel>
/openscad/build/tests/venv/bin/python: No module named pip
<kintel>
^ I don't quite understand what ensurepip does, but since the venv is created without pip it makes sense that it's missing if ensurepip doesn't do the right thing..
gwillen has quit [Ping timeout: 248 seconds]
<b34r_dev>
kintel: Too bad, but i already expected it. A lazy effort :)
<b34r_dev>
Thanks for the suggestion of BOSL though. Seems quite extensive. I'll have a good look into it.
fedorafan has quit [Ping timeout: 252 seconds]
gwillen has joined #openscad
fedorafan has joined #openscad
<lf94>
InPhase: great stuff. Yes, the bbox must be epsilon bigger than the object's surface
<lf94>
In my models in JS, I use Number.EPSILON
<lf94>
But, it may be sufficient to do it by `resolution` .
<lf94>
(or rather, more robust?)
<lf94>
so bb + resolution on all values
<lf94>
(well, - on the min and + on the max)
<lf94>
if openscad supports vector ops (iirc it does) then yes, it should be [x,y,z]. should be an easy change
<lf94>
I do this also in my js bindings x)
<lf94>
but man, i just slept for 3 hours. and havent been able to do any coding. our hacking session yesteday fried my brain.
<lf94>
it was well worth it. seeing you guys on this now is awesome stuff.
<lf94>
For the first release of sdf() I suggest we simply document it very well, saying sdf is experimental and can cause non-manifold if not used properly.
<lf94>
I'll port some interesting one from curv instead of my flower first. Like some fractal
<lf94>
Menger sponge maybe
<lf94>
or "shreks donut" lol.
<InPhase>
kintel: python3-venv is an ensurepip dependency for Debian.
<InPhase>
kintel: That one I actually put in the docs! ;) In testing.txt at the top.
<InPhase>
b34r_dev: Here's my compact bezier curve function. Feel free to use it. https://bpa.st/2CGRQ
<InPhase>
lf94: The segfaults for missing parameters will definitely need to be fixed up before a merge. And, at the moment I'm thinking we really should alter that sdf function signature to a vec3 instead of x,y,z. I erred in suggesting the wrong one in my first quick draft, but it seems to make many of the functions less elegant when you go to actually write them.
fedorafan has quit [Ping timeout: 246 seconds]
<lf94>
InPhase: yep and yep
<lf94>
again, I'm leaving it now to you guys :)
<lf94>
The C++ is just too much for me
<lf94>
It'd be nice to re-activate the multiple workers too
<InPhase>
lf94: I know an ugly way to fix the manifoldness, but it would make things slow. I would hope there would be an efficient way hat doesn't have the problem.
<InPhase>
What is the multiple workers thing?
<lf94>
But yeah; my purpose now is to build out the sdfs around this feature.
<InPhase>
I was about to suggest our values are all constant. But I guess they are mostly constant.
<InPhase>
Although the only thing I can think of that's not constant is that clever little vector flattening optimization for recursion.
<InPhase>
Did you two determine what was the source of the segfault?
<lf94>
"disable stack check"
<lf94>
did it
<lf94>
> Disable stack check for now as libfive runs callback in separate thread.
<lf94>
teepee's doing :)
<InPhase>
Ok. I don't know what that means. :)
<lf94>
same.
<b34r_dev>
InPhase: Damn, that's at least a whole lot more compact than i came up with. Thanks!
<lf94>
b34r_dev: I was going to ask, what school books are teaching bezier curves? lol
fedorafan has joined #openscad
<lf94>
InPhase: in particular example you'd like to see me port
<lf94>
maybe i should do gyroid above all
<InPhase>
b34r_dev: I took the bold step of reading the wikipedia page carefully, and found the recursive definition there. :) It seemed much simpler than the other approaches for OpenSCAD purposes.
<b34r_dev>
lf94: Math book, 10th class. We had them somewhere before "Abitur" in Germany.
<lf94>
Germany has damn good math program.
<InPhase>
b34r_dev: I've used it in various designs since I wrote it. Seems to work reliably.
<b34r_dev>
Very dependant on state, tbh.
LordOfBikes has quit [Ping timeout: 250 seconds]
<b34r_dev>
InPhase: Your patience in honor. Wikipedia seems to be a tad too dry for my taste every so often.
<kintel>
InPhase Thanks, I see what happened now; the venv creation failed, but didn't cause CMake to stop. It also failed in a way which left a half-functioning venv behind, so it was very confusing to debug
<lf94>
InPhase: gyroid is way simpler than I thought
<lf94>
Should do that then try an intersection with a sphere :o
<kintel>
Does anyone know why, on Ubuntu-18.04 (GitHub CI), it installs CMake-3.10, but when CMake runs it claims to be 3.25.2 ?
<kintel>
^ I want to upgrade to minimum 3.18 if possible to get support for execute_process(COMMAND_ERROR_IS_FATAL)
<InPhase>
kintel: Well either it upgrades it, or there's another one somewhere. Although I will note we should not struggle to preserve 18.04 anymore. That platform is into the "abandon it as soon as it's inconvenient" phase of support.
<peeps[zen]>
kintel: isn't 18.04 basically end of life now anyways?
<kintel>
Yeah, but 20.04 still only has cmake 3.16
<kintel>
..so I guess it's down to what minimum requirements we want to have for individual users building OpenSCAD themselves
<InPhase>
lf94: https://bpa.st/5R43K Work in progress, of course. But time for sleep.
<InPhase>
lf94: sdf calls 1 and 2 work, 4 has a blend bug, and 3 is missing the fcylinder implementation. Although fintersection was designed to make fcylinder easy with an fplane primitive.
<InPhase>
lf94: Or maybe just a stand-alone fcylinder would be cleaner. *shrug*
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ur5us has quit [Ping timeout: 250 seconds]
jonasbits has quit [Quit: No Ping reply in 180 seconds.]
jonasbits has joined #openscad
ur5us has joined #openscad
guso78 has joined #openscad
Friithian has quit [Ping timeout: 265 seconds]
Friithian has joined #openscad
ur5us has quit [Ping timeout: 250 seconds]
<guso78>
fcylinder will be defined in an openscad lib next to MCAD ?
<teepee>
depends on what you mean by next to mcad, shipping directly with openscad is probably still not a good idea due to the not ideal release cycle
<guso78>
i have raised my question very bad. will fcylinder be defined in the openscad binary or in an openscad scad script ?
ali1234 has quit [Remote host closed the connection]
ali1234 has joined #openscad
<teepee>
for the time being in script I think, I don't know if we can find a way where it help having it in code
guso78 has quit [Ping timeout: 260 seconds]
castaway has joined #openscad
ur5us has joined #openscad
use-value has joined #openscad
L29Ah has joined #openscad
aiyion has quit [Remote host closed the connection]
aiyion has joined #openscad
ur5us has quit [Ping timeout: 240 seconds]
teepee_ has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
Sauvin has quit [Ping timeout: 250 seconds]
Bocaneri has joined #openscad
Bocaneri is now known as Guest407
rumgzy has joined #openscad
Guest407 has quit [Ping timeout: 252 seconds]
use-value has quit [Quit: use-value]
use-value has joined #openscad
use-value has quit [Quit: use-value]
use-value has joined #openscad
fedorafansuper has joined #openscad
b34r_dev has quit [Quit: Client closed]
fedorafa_ has joined #openscad
fedorafansuper has quit [Ping timeout: 248 seconds]
<lf94>
yes, due to so many useful sdfs, it'd make sense to ship on the side.
<InPhase>
guso78[m]: Actually, I think strongly that a set of base functions like this should be built into OpenSCAD. But... we have complete freedom to explore definitions of these externally right now without extra C++ code, so that's the right solution for the moment.
<InPhase>
guso78[m]: And I think it will be helpful to figure out by trying things first which ones actually make sense to include, and what the function signatures should really look like.
<InPhase>
guso78[m]: And this is easier to prototype in the scad file.
<InPhase>
I suspect they will go a good bit faster as builtins later. But it's okay to be a little slower at the moment and get things right.
<InPhase>
Unlike normal OpenSCAD functions, these are going to get called a LOT.
<InPhase>
So much so that there could be motivation in the future for someone to build us a jit. :)
<lf94>
Yes. Having a JIT would be imperative.
<InPhase>
lf94: Or at least functional.
<lf94>
I still havent tried it yet on my machine. Im honestly a bit scared. It means users of sdf will have to be very careful and construct only the most specific of sdfs.
<lf94>
"a bit scared" -> literally dont want a swap kill or something
<lf94>
but since it's eval time, nothing to actually be afraid of
<lf94>
In our documentation we should stress that the sdf function should only be used to model "non-composite objects". i.e. dont try to compose a lot of shit in sdf functions
<juri_>
that's an interesting way to handle SDF functions.
<juri_>
(interesting being used as a positive term here!)
<lf94>
Suggested by InPhase :)
<lf94>
It's still in dev but yeah, cool shit
<lf94>
InPhase: Idea for bb. Instead of needing to be epsilon further of the edge, just create extra geometry where the clipping happens.
<lf94>
(This would remove an intersection with a cube on most models too.)
<lf94>
(most organic models)
<lf94>
probably not trivial though...
<lf94>
I feel it'd be something that'd have to happen inside libfive.
b34r_dev has joined #openscad
<lf94>
Nevermind, it'd be really hard. It'd essentially make a cube around the model every time.
J23614690 has quit [Quit: Client closed]
J23614690 has joined #openscad
<teepee>
yeah, cadhub is dead for a long time by now
<lf94>
how did you even
<lf94>
:D.
<lf94>
watching the issues arent you
fedorafa_ has quit [Ping timeout: 246 seconds]
<lf94>
I think there's a fundamental issue with cadhub, that if addressed, could help code cad further
<lf94>
It's like github. Github isnt executing code, whereas Cadhub is
<lf94>
Cadhub has to forego execution, despite it trying to make modifiable parameteric models
<teepee>
I'm registered to the cadhub github repo
<lf94>
ah
<b34r_dev>
InPhase: Took me a while to realize, but higher order curves work great as well. May i suggest to post it as snippet on Github, so others may enjoy the compact solution as well.
<teepee>
python execution was intentionally disabled even longer already
<lf94>
I think if Cadhub instead linked to projects that each script used, and even improved the documentation, that'd be much better.
<lf94>
and then showed an stl
<lf94>
i guess cadhub would end up like github
<lf94>
I think github can even show stl in-browser
<teepee>
yep, it can do that
<lf94>
It'd be useful to "de-facto standardize" releases of code cad objects
fedorafan has joined #openscad
<lf94>
right now everything is "throw it on thingiverse" or printables
<lf94>
There needs to be some sort of "release wizard"...
<teepee>
maintaining that would be a pain
<lf94>
would it, if all it did was tell the user what license to pick, and if there's an stl and maybe one or two other things?
<lf94>
("other things" -> probably something about discoverability)
<lf94>
something similar to a package.json
<teepee>
and upload to various services which can change any day?
<lf94>
no no, it will not upload
<lf94>
that's up to the user
<lf94>
maybe they decide to host on their self-hosted git instance
<teepee>
so a bit like make install / make dist
<lf94>
yeah
<lf94>
closer to make dist
<b34r_dev>
Why just not throw it on Github then? Every bigger recent Openscad project to be find Printables seems to do this anyway.
<b34r_dev>
*on
<lf94>
yes exactly. what i'm saying b34r_dev is just to have some consistency so unfamiliar people can easily discover these things and browse them
<lf94>
they can upload anywhere at the end.
<kanzure>
and then eventually a package manager
<kanzure>
and dependencies
<lf94>
that's not a bad idea. it would make setup for the underlying code cad engine much more accessible
<lf94>
but not necessary
<lf94>
i know you're being sarcastic
<kanzure>
i am not being sarcastic
<lf94>
oh :D.
<kanzure>
my reach often exceeds my grasp
<lf94>
normally I feel such a reply would be
<teepee>
lets have a look at entropic again
<teepee>
nope, still dead :(
<lf94>
ol
<lf94>
I think we should start with the standardization before moving onto something like that
<lf94>
Also I'm highly against a system like npm repository
<lf94>
I would rather have a "directory" people can submit their projects to
<teepee>
"Entropic: a federated package registry for anything"
<teepee>
I would have liked the federated part a lot
b34r_dev has quit [Quit: Client closed]
<lf94>
and then people get the sources wherever they are hosted.
<lf94>
this directory can be extremely easy to host and maintain
<lf94>
we should come up with categories, like "home", "car", "3d printer"
<lf94>
"meta" can be libraries
<lf94>
(or maybe use "lib" lol)
<teepee>
common
<teepee>
gotta have that always :)
kintel has joined #openscad
<lf94>
I feel this is another "evening project"
<lf94>
Maybe I'll start to poke at the idea tonight
<lf94>
and go HAM tomorrow
<lf94>
I think I'm still recovering from Saturday
<teepee>
I don't think that works as evening project
<lf94>
It's two endpoints
<lf94>
GET / for listing. ?q for filtering the listing
<lf94>
POST / for submission. Accepts json
<lf94>
And then UI is really not that complicated
<lf94>
(Im a webdev by day.)
<kintel>
Does any know good examples of how to do opengl wrangling for libraries?
<kintel>
I'm trying to break up the GLX vs. EGL being a compile-time decision (which bubbles all the way up to the distro packages)
<kintel>
Glew is
<kintel>
...obviously disqualified
<kintel>
^ this is related to OpenCSG depending on glew
<teepee>
I don't remember any other example, but I suppose there have to be some libs which need that
<joseph_>
teepee kintel: Do you have other suggestions about my GSoC proposal?
<lf94>
teepee: heh, nice plane trick
<lf94>
the plane is the center of this for sure
<lf94>
it's actually not a crazy demo, but nice presentation
<guso78>
mine is still "Hacking Youtube"
<lf94>
it's easy to do "infinite" difference as a 3D plane, so that's what's happening here, between the two shapes
<lf94>
the transition is nice between them, timed perfectly, to make it look smooth
<lf94>
and then it's an intersection also of that fractal shape
<lf94>
(this is something we can see in sdf() in openscad today if we really want :)
rumgzy is now known as Sauvin
<guso78>
i am hoping that SDF in openscad will be fast enough to do an animation.
<teepee>
joseph_: the description is good and as far as I could follow the discussion works in parallel to the stuff kintel is working on
<lf94>
guso78: it will not really be initially, you'll have to wait a looooong time
<teepee>
joseph_: the timeline could use a little bit more detail
<teepee>
guso78: then we need a separate preview renderer that would convert the sdf into a shader
<kintel>
joseph_ It's overall a little vague, as the analysis of the current codebase and hence the expected effort is not very clear, but I don't think much more can be done on a short timeline.
<teepee>
heh, docker build just hit 5000 seconds :)
<guso78>
I am wondering if its actually possible to use SDF in shaders. SDF is seeking the 0 point to draw the surface. Maybe we can use GLSL depth buffer for that after a clever coordinate transformation.
<teepee>
kintel: I suppose that mostly means we need to think about how to handle that on our side, regarding feedback and progress
<kintel>
teepee Are you building on Docker Hub already?
<teepee>
kintel: no still local, building your PR
<lf94>
guso78: yes, sdfs were popularized by shader usage.
<lf94>
shadertoy.com <- full of them
<kintel>
ah, I just found a bug in my PR, I forgot to install runtime libtbb. I'm also building locally
<teepee>
guso78: yes, most of the geometry heavy stuff in those "demo" shaders is sdf
<lf94>
The creator, Inigo Iquilez, created that site, and pretty much developed the SDF space
guso78 has quit [Ping timeout: 260 seconds]
fedorafan has quit [Ping timeout: 248 seconds]
<kintel>
teepee Updated the dockerfile with libtbb
<kintel>
Btw., those docker images build pretty fast once I up the JOBS count
fedorafan has joined #openscad
<kintel>
I wonder if switching to ninja could allow us to remove that from the Dockerfile, so we don't trigger a rebuild whenever we change that arg
<lf94>
neenjah
fedorafan has quit [Ping timeout: 246 seconds]
J23614690 has quit [Quit: Client closed]
fedorafan has joined #openscad
fedorafansuper has joined #openscad
fedorafan has quit [Ping timeout: 260 seconds]
<joseph_>
teepee Thanks for the suggestion to elaborate a bit more on the timeline. I just added an additional column. Also kintel I agree that there isn't enough time now to elaborate much more fully on planned refactoring. What I just did was add an extra section to highlight one example task in more detail. https://github.com/jbinvnt/gsoc-2023-proposal-public/commit/90b0f13
<kintel>
joseph_ One comment: "A final report in the form of a pull request should be published."
<kintel>
I would strongly recommend publishing small Pull Requests as often as feasible
<kintel>
..to avoid getting into a situation where review of the PR requires changes and you're no longer around to finalize it
<teepee>
ah, good point, the final report can also be an issue instead of a PR and just link the PRs
<kintel>
Yeah ,like a final report summarizing all PRs (open and closed) which was created during the project
<kintel>
It's a good strategy to, every time you see the need for some cleanup, to clean that up in the master branch, PR it, then rebase all your work on the cleanup PR
<kintel>
If done correctly, your final PR should be quite clean, easy to read, and low risk to merge
<kintel>
teepee Looking around a bit, I think the most reasonable approach to using OpenGL from libraries today would be to 1) manage their own GL wrangling for the subset of OpenGL they use and 2) Do _not_ touch EGL/GLX/WGL/CGL etc. - that belongs in application space
<kintel>
Unfortunately, Glew insists on messing with GLX/EGL/WGL, so it's not a particularly well-behaved citizen. If we could disable that part, it would be acceptable, but no such API option exist.
<kintel>
-> I'll try to patch OpenCSG to embed their own GLAD instance and see how that flies
<lf94>
KISS
Abrasive21 has joined #openscad
<kintel>
^ A simpler way would be to build OpenCSG inline with OpenSCAD, so they use the same GL includes as us, but Linux distros tend not to like that approach
<lf94>
Sounds like it'd be a good idea to get the package maintainers in here.
<kintel>
..or offer multiple package choices: glew-egl, opencsg-egl, openscad-egl etc., until all distros ditch GLX for good
Abrasive21 has quit [Client Quit]
b34r_dev has joined #openscad
drfff has joined #openscad
fedorafansuper has quit [Ping timeout: 248 seconds]
<kintel>
ah, you built locally and pushed the image?
<teepee>
yes, for now local builds
<teepee>
I'll try the webhook after merging
pa has quit [Ping timeout: 276 seconds]
pah has joined #openscad
<lf94>
how do you foreach a list
<lf94>
wiki isnt clear, just constructs a range
<lf94>
[for(???) x]
<lf94>
x=xs?
<teepee>
echo([for (x = [1,2,3]) x * x]);
fedorafansuper has quit [Ping timeout: 260 seconds]
<lf94>
are vectors faster than non-vector stuff in openscad for some weird reason
<kintel>
teepee Btw. while you're here: Do you remember why Dockerfile.egl has the "USER openscad" sections? The other Dockerfile builds everything as root
<juri_>
eew.
<teepee>
nope, probably just forgot to sync that
<teepee>
no, wait, debian build needs root and fakeroot does not work in docker
fedorafan has joined #openscad
<lf94>
max(q,0.0) <- I swear GLSL sometimes. q is a vec3 and 0.0 is scalar.
<lf94>
The return value is a vec3
<lf94>
How do you do the max of two vec3? Compare their distances?
<lf94>
> When one input is a vec3 and the other is a scalar, the function compares each component of the vec3 with the scalar and returns a new vec3 where each component is the maximum value between the corresponding component of the input vec3 and the scalar.
TheCoffeMaker has quit [Ping timeout: 265 seconds]
<lf94>
ah undefined ^ number
<lf94>
how is q unknown...
guso78 has joined #openscad
<kintel>
teepee the openscad user is inside the container; looks like Dockerfile builds OpenSCAD as root while Dockerfile.egl builds it as openscad, and uses root for writing to system locations
<kintel>
not a big deal, just curious
<guso78>
teepee, i am trying to merge latest changes from master into my python-support branch, but there are issues, quite outdated. web conflict resolve appears disabled.
<InPhase>
I have 64GB, plus 64GB of nvme swap, so I'm willing to try the high RAM stuff.
<guso78>
lf94, i realized that when doing SDF for a cube. depending on the resolution it can create millions of triangles. probably consider merging triangles with same normal vector
<lf94>
yes.
<lf94>
In Curv, doug recommended to use Meshlab
<lf94>
to do this
<guso78>
i got an algorithm for that somewhere in my offset 3d branch
<lf94>
When I use libfive with my nodejs bindings, just setting the appropriate resolution is enough
<InPhase>
Are they actually going to be exactly the same normal vector?
<lf94>
I think libfive actually does simplification to a degree
<InPhase>
How good is it at flattening a flat surface?
<guso78>
my algorithm is about 1.5 pages and tested it with bigger data already
<lf94>
InPhase: it'd work for adjacent tris no?
<InPhase>
lf94: Maybe if it's axis aligned.
<guso78>
no, in my alg i allow minimal deviation due to expected rounding errors
<lf94>
:thinking emoji:
<kintel>
In terms of SDF, is the idea that we'll compile OpenCSAD functions into shaders for previews?
<InPhase>
An approximate norm merge would probably be the right general solution.
<guso78>
InPhase, what do you mean with adjacent tris ?
<InPhase>
guso78: I didn't say that. :)
<lf94>
kintel: Dunno - InPhase is the design mastermind behind this operation
<guso78>
Sorry, simply not understood
<InPhase>
guso78: Adjacent triangles, meaning those right next to each other.
<lf94>
kintel: for first version I'd think the preview window will just show bounding boxes of where the SDFs will appear
<InPhase>
kintel: I hadn't contemplated any special treatment for previews. Currently the thinking was just to smash libfive into OpenSCAD in the most natural and lowest effort manner possible, using function literals for sdfs.