<teepee>
hmm, considering the BSD license, calling a sub process might be easier
<anotherlucas[m]>
uggghhhhh
<anotherlucas[m]>
what's the licence on openscad?
<juri_>
not free enough.
<juri_>
:)
<anotherlucas[m]>
man, that's game over, basically
<teepee>
openscad itself is GPL-2+, due to CGAL which is used for meshing binaries are GPL-3+
<teepee>
well, not for just running openscad
<teepee>
Manifold is Apache-2 I think, but there's no Manifold-only version
<anotherlucas[m]>
yeah, but it would have to be distributed separately (I guess)
<teepee>
not really, shipping GPL stuff is just fine regardless of how you ship it
<teepee>
you can't modify and link with BSD and ship as BSD though
<juri_>
calling it as a subprocess might work out.
J23 has quit [Quit: Client closed]
J23 has joined #openscad
<teepee>
yes, my understanding is that running GPL binaries the way they are normally intended to be used is just fine always
<teepee>
different story with AGPL
<anotherlucas[m]>
I'm not so up on this, if I forked openscad and modifed it, would I be able to include it?
<anotherlucas[m]>
I guess the licence must at least say part X is BSD and the openscad bit is GPL?
<teepee>
sure, you can, but if you link everything, the binary will be GPL-3+ as that's trumping all the other combinations
<teepee>
the code can stay whatever it's license is
<teepee>
we already have that, like I said above, openscad source code license is different from it's final application license
peeps[work] has quit [Ping timeout: 250 seconds]
<anotherlucas[m]>
there could be objections to making the binary GPL
<juri_>
then you have a problem.
<teepee>
there's already some work towards running openscad as server process for the Language Server Protocol
<teepee>
so one option would be running openscad as "normal" binary, a bit like thingiverse does
<juri_>
pardon me if i'm intruding, but depending on how simple the model is, and what your tolerances for holes in the objects are.. you might be able to use implicitcad instead. i have an "http server" mode.
<juri_>
ImplicitCAD is even worse written for merging with other code, but it does parallelize well, and has an http speaking binary.
<juri_>
it's Not openscad, tho. the language used is a very simplified form.
<teepee>
how would that interact with the AGPL license?
<juri_>
are people talking to the http server? then you have to give them the source code if they ask.
<juri_>
is software talking to the http server? then you have to give the users in question a copy of implicitcad's source code. doesn't effect the thing doing the talking tho.
<teepee>
hmm, that's not my understanding of AGPL, but might be irrelevant if that part is BSD anyway
<anotherlucas[m]>
I think I prefer the implictcad syntax
<juri_>
teepee: pretty much.
<anotherlucas[m]>
I think putting Haskell into the codebase would get me shanked though
<juri_>
i'm not sure my isp is obligated to give people a copy of implicitcad because they serve it, but..
<teepee>
just don't tell anyone :)
<juri_>
anotherlucas[m]: you just made my evening. that's funny.. :)
* teepee
looks at the clock
<juri_>
teepee: ok, morning. :)
<teepee>
whew
<juri_>
yeah, making a request is just using the software. there's no requirement on the license of the thing making the request, only that if you set up a big implicitcad server on your network, and people make requests 'manually', they can request the implicitcad source.
<InPhase>
anotherlucas[m]: So perhaps give a little more details about what exactly you want to do. If the license of Manifold itself is suitable, it might actually work for you to use Manifold directly.
<teepee>
and of the whole environment stuff running implicitcad, at least that's what I understood as non-lawyer
<InPhase>
anotherlucas[m]: I'm not sure if you're familiar with SDF functions, but if you're a physicist (or at least working on physics software effectively), then this approach probably will not scare you.
<juri_>
teepee: i don't think it's that toxic, but also non-lawyer. :)
<anotherlucas[m]>
what's manifold
<anotherlucas[m]>
?
<InPhase>
Wait. I'm citing the wrong library.
<InPhase>
Well, I guess right library, wrong brain state.
<InPhase>
I was thinking of libfive, but that's actually MPL which I think is not fully compatible with BSD. But Manifold is apache, which I think is fully combinable.
<anotherlucas[m]>
The general issue that I think SCAD solves is that its well established and fairly easy to use.
<InPhase>
anotherlucas[m]: So forget SDF. Manifold is a library which does low level computational geometry operations. https://github.com/elalish/manifold
<InPhase>
anotherlucas[m]: Can you give a specific example of something parametric that you you might like to embed support for? That can guide the advice.
<InPhase>
anotherlucas[m]: And maybe an example of the user workflow for this.
ur5us_ has joined #openscad
<anotherlucas[m]>
So, a simple example would be an ellipsoid (though we have better models for things like this)
<anotherlucas[m]>
you might parameterise the different dimensions
<anotherlucas[m]>
how long and thin it is
ur5us has quit [Remote host closed the connection]
Av8r has quit [Quit: Connection closed]
<anotherlucas[m]>
then, you do a scattering experiment which gives you a blurry incomprensable squiggle
<anotherlucas[m]>
the model predicts said squiggle for a specified parameter, the software iteratively modifies the parameters it until the squiggles match
<anotherlucas[m]>
basically, you would give it a general shape, and have the software tune the parameters until it best resembled measured data
<anotherlucas[m]>
a lot of simple shapes can be solved analytically
<anotherlucas[m]>
including triangles
<anotherlucas[m]>
so, you can make a general approximate model by making a parametric triangular mesh
<anotherlucas[m]>
it would be far from completely general, but it would give some flexibility
<anotherlucas[m]>
I can add more detail if you want to know more about something specific
<juri_>
is this reverse statochistical modelling?
<anotherlucas[m]>
just standard model fitting
* juri_
nods.
<anotherlucas[m]>
there are different kinds of fitting methods the user can select, one is a Bayesian method
<anotherlucas[m]>
but least squares usually
ur5us_ has quit [Ping timeout: 252 seconds]
<juri_>
ok, bed for me. good luck!
<anotherlucas[m]>
thanks
kintel has joined #openscad
ur5us_ has joined #openscad
LordOfBikes has quit [Ping timeout: 240 seconds]
fedorafan has joined #openscad
fedorafansuper has quit [Ping timeout: 260 seconds]
LordOfBikes has joined #openscad
pharonix71 has joined #openscad
J2386 has joined #openscad
teepee_ has joined #openscad
J23 has quit [Ping timeout: 260 seconds]
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
fedorafansuper has joined #openscad
fedorafan has quit [Ping timeout: 248 seconds]
fedorafansuper has quit [Ping timeout: 248 seconds]
<InPhase>
anotherlucas[m]: So you want to parametrically specify some shapes, turn them into a mesh, and run the numerical analyses using the mesh as the input?
<InPhase>
anotherlucas[m]: I looked at the MPL 2.0 license more carefully, and it is in fact (by my non-lawyer reading of it) permissible to use the MPL 2.0 license in a BSD project without altering the license of the BSD project. The MPL 2.0 license says only that the MPL 2.0 portions of the source code stay that way. Therefore, you could in fact use the libfive library, which provides a straightforward way to
<InPhase>
turn a functional description of a volume into a mesh, and typically works quite well for the types of shapes you might be interested in. If you are interested in this sort of approach, there are a ton of Inigo Quilez videos on youtube which are fascinating to watch, where he illustrates how to think about shape modeling with Signed Distance Functions (SDFs). Rounded shapes, and deformed rounded
<InPhase>
shapes, are particularly straightforward. Large lattices are also pretty easy, and combinations of these.
<InPhase>
anotherlucas[m]: Your choice going forward really depends on what type of interface for shape design you want to provide your users. If you want the scad language, then you run openscad as an executable engine in the background, and provide the results or error message responses. If you want an SDF, then you could embed libfive, and you provide a mechanism for writing compositions of functions.
<InPhase>
libfive is a C++ library, but also has some support for processing functions in scheme. But scheme might not be familiar to your users, so you might consider a different way of expressing this.
<InPhase>
anotherlucas[m]: Ultimately I'm on team "parametric cad" as a general concept, so I'm not going to try to sell you on one thing or another. Although from a pragmatic standpoint, OpenSCAD run as an executable is probably the easiest thing to implement because you can piggyback on all the existing documentation and work on OpenSCAD. But it might be that direct writing of volumetric SDFs ends up more
<InPhase>
natural to your userbase, and fits the needs better for the unusual functional forms I could imagine a scattering analyst wanting.
<kintel>
teepee InPhase peepsalot In case any of you have opinions on this: OpenCSG as a submodule, to allow us to decouple from a slow moving distro-packaged library: https://github.com/openscad/openscad/pull/4596
<InPhase>
anotherlucas[m]: But, I can show you tricks for making arbitrary functional forms in OpenSCAD too if you are interested. For example, I have a corectly computed two-slit experiment model printed out on my work desk that I modeled with OpenSCAD.
<kintel>
^ no-op for now, but this would allow us to move faster to fix stuff like https://github.com/openscad/openscad/issues/4595, plus if the GSoC project goes through it opens the door for OpenGL modernization
<InPhase>
kintel: Although wasn't it Debian that doesn't like submodules? What's the game plan for the next debian release?
<InPhase>
Just recursively grab them all and zip it up? :)
<kintel>
InPhase yeah, that's the caveat. Ship with rendering bugs on Debian if they complain?
<kintel>
..and later: Ship without EGL support
<kintel>
It's still possible that we can upstream OpenGL modernization to OpenCSG, in which case, it will transparently work again :)
<kintel>
I just have a creeping feeling that non-routine maintenance may be off the table for the OpenCSG dev
<kintel>
..in which case we can declare our submodule a rewrite and "not a library" :)
<kintel>
In terms of Manifold, I think we're slowly convincing the dev team to be nicer about packaging, and hopefully allow non-submodule usage of their most common dependencies
<InPhase>
The Manifold team seems very pleased that we're making use of it. This is a welcome change of pace from what feels more like CGAL's reluctant acceptance that we use it. :)
<InPhase>
It just seems more like open source partners.
<InPhase>
That's a good mix with it just being absolutely staggeringly fast.
<kintel>
Yeah, there is definitely more philosophical alignment with Manifold
<InPhase>
I wonder if they wrote sdf as staggeringly fast as their other code parts.
<lf94>
nah im good
<lf94>
you guys can do it lol
<InPhase>
It actually looks ridiculously simple. That's basically the interface I was wanting it to have, as that's almost identically the interface of the OpenSCAD module that was added.
<InPhase>
And it has an added execution policy specification so you can try to do the sdfs in parallel. Which I think we could do as long as we take care to guard that OpenSCAD embedded vector auto-flattening routine.
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<lf94>
I suppose no one has some sort of openscad thinkpad keycap code eh
<lf94>
Printing the clamps is impossible on this
<lf94>
I've tried 2 different models that "apparently" the authors were able to print
<lf94>
I call bullshit
<lf94>
I'm using a 0.2mm nozzle also at 0.1mm height
<lf94>
Would an extra 0.4mm make a difference? probably not
<lf94>
I measured the little space the post has to fit into and it's 1mm
<lf94>
but these are all printing at 0.6mm
<lf94>
maybe super glue would be a better attachment
fedorafan has quit [Ping timeout: 246 seconds]
fedorafansuper has joined #openscad
ur5us_ has quit [Ping timeout: 240 seconds]
<InPhase>
lf94: On something with constraints that tight, you often have to print just ever so slightly snugger than it should be, and then post-process and sand or carve it down very gently with a particularly sharp knife taking of very thin layers.
<InPhase>
s/of/off/
guso78 has joined #openscad
<guso78>
teepee, it was quite easy to get libfive compiled for Windows using MXE compiler.
<guso78>
but it created a DLL instead of static link
<guso78>
and it created a crazy size of 0.4 GB. Any suggestions to direct compilation to the right direction, i already checked the option keywords in mkeeters CMakeLists.txt
<guso78>
kintel, i have seen your PR to make tests pass even without EXPERIMENTAL set to 1. Anther very similar topic is to get tests pass without any VBO optimization enabled. once this is fixed the ctests for my texture branch would also work much better. (background is, that my textures only work without any VBO buffers and only with plain
<guso78>
gl Programming)
<guso78>
InPhase, this is the exact reason, why I wanted to have offset3D *realized*, you just offset by -0,3 before printing, but apparently the "postprocessing" and santizing of the algorithm result is a very big challenge ...
fedorafansuper has quit [Ping timeout: 246 seconds]
peepsalot has quit [Read error: Connection reset by peer]
guerd87 has quit [Read error: Connection reset by peer]
guerd87 has joined #openscad
ur5us_ has joined #openscad
guso78 has quit [Quit: Client closed]
guso78 has joined #openscad
KimK has quit [Remote host closed the connection]
KimK has joined #openscad
J2386 has quit [Quit: Client closed]
J2386 has joined #openscad
ur5us_ has quit [Ping timeout: 265 seconds]
guso78 has quit [Quit: Client closed]
guso78 has joined #openscad
J2386 has quit [Quit: Client closed]
J2386 has joined #openscad
snaked has quit [Quit: Leaving]
<anotherlucas[m]>
@InPhase Yeah, its about the user experience. It would be pretty simple (but time consuming) to write a geometry engine and/or a new specification DSL - having a established language with a community of users is really valuable, and is the sort of thing I can't necessarily create on my own.
<anotherlucas[m]>
You might be right about different functions - this would be in addition to a rather large suite of analytical solutions.
<anotherlucas[m]>
The other option is to specify the shape using python...
kintel has joined #openscad
<anotherlucas[m]>
python will scare people off though
<juri_>
not as effectively as haskell will! :)
<teepee>
:)
<anotherlucas[m]>
python will scare off the users, Haskell will scare off the developers too
<Scopeuk>
so it's agreed, cobol it is!
<guso78>
or fortran
<juri_>
hey now. i like fortran.
<Scopeuk>
pre or post proper variable declaration?
<guso78>
and as always: what ever language it is.. its optional. If somebody does not like/know it , its safe to not even know about its existence as long the Feature is not enabled
<guso78>
variables are usually declared ?BEFORE? usage
<Scopeuk>
early versions of fortran do type definition from variable name. it's only relatively recent versions that let you give a variable of any name a type of your choosing
<kintel>
guso78 Yes, VBO is an experimental feature, so that's included in the issue about tests and -DEXPERIMENTAL
<kintel>
..but I expect VBO to be the way forward, so we really need stuff to work with it
<kintel>
-> "plain gl programming" will soon be deprecated :)
<kintel>
(for some definition of "soon")
<teepee>
I was very much tempted to activate vbo finally just did not find the time
<teepee>
it's in there for long and essentially all reports were "it's much better enabled"
<guso78>
kintel, i agree with you. VBO is much faster and should be used everywhere!
<kintel>
tbh, it feels like the VBO code is kind of a mess and needs some thorough cleanuo
<guso78>
When I want to deliver my texture information also along VBO i need to "incorporate" with an existing memory layout.
<guso78>
is it somewhere "documented" how VBO memory is allocated ?
<kintel>
guso78 documented in general, or specifically how OpenSCAD does it?
<guso78>
kintel apparently OpenSCAD wants to use VBO buffers to store coordinates, indexes, colors ???
<guso78>
I believe when i want to use it for other information in addition, i need to adhere to certain rules/layout ?
<anotherlucas[m]>
guso78: there might actually be a bit of fortran in there already
<kintel>
guso78 Yeah, every vertex attribute needs to be stored in buffers, so if you're adding more per-vertex information, you either need to create a separate buffer for it, or modify the existing buffers if they're interleaved.
<kintel>
All of that is standard OpenGL, but finding the exact places to modify requires reading the code carefully, especially since the VBO feature in OpenSCAD is a collection of various strategies
<guso78>
kintel, yes i was thinking about the interleaved approach. i am wondering if there is documentation and/or a programming interface already which removes the need to reverse-engineer existing code
<guso78>
yep, will look into it later. thank you
<kintel>
I think reverse-engineering is the way. All of this was contributed from outside the core team.
<kintel>
..but the source code is there :)
<kintel>
Btw., if this is about textures, keep in mind that you'll likely end up in a situation where the same vertex will have multiple different texture coordinates associated with it, depending on which polygon it's part of. ..in which case you probably have to duplicate the vertex, or split the object into separate objects.
<guso78>
hmm, very good input! let me first get textures working with VBO at all .
<guso78>
lately i was questioning why my textures are not working anymore with VBO's turned on
<anotherlucas[m]>
thanks for the chat guys. It helped me think through my options a bit
<kintel>
guso78 it's also possible to use non-interleaved arrays, but I'm not sure if you can combine interleaved with non-interleaved.
<kintel>
Once I get the time to review the VBO code in detail I'll know more
<guso78>
just thinking about, what needs to be documented about the python stuff, so somebody else can easily extend functionality. having a scripting engine literally fires demand to add more "functions" (assuming it finds its way at all)
<kintel>
^ in case someone feels like digging. I haven't tried hammering this locally yet
<teepee>
I've seen 024 crash in a recent PR again, so looks like the concurrency fixes from latest manifold did not help with that one either
<kintel>
Yeah, not sure if it's the same bug or not, perhaps opening a separate issue would be smart
teepee_ has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
guso78 has joined #openscad
<guso78>
kintel, i am just look into the shown PR 4330. its actually interesting to me what "marked polygons" mean. did not yet understand. And in GSoC 2022 i see code parts if "Manifold" which was added just recently. Github appears to me to be one of the few places where you can change your past ...
<kintel>
I recently resolved the conflicts of that PR, by interactively rebasing all the commits.
<guso78>
Haha like "Back to the Future" or "Millennium" . You can change your past as long as you still "exist" in the new future ...
<kintel>
teepee I wonder if those test flakes are related to resource exhaustion on the CI VM, e.g. a malloc failure causing an exception?
<kintel>
guso78 ..or: each PRs are considered a possible future
<kintel>
I ran the 006 test 1000x locally with no failures
<guso78>
kintel, yes exactly! git is a multiversum and each PR is pushing to come true, but its same as in evolution ... only best derivates survive ....
<InPhase>
kintel: Hmm. So I have this script I run: https://bpa.st/3GST6 I use it to monitor the maximum memory utilization during every openscad run, and log it to that ~/.openscad_mem.log file. I have my system to divert and run this as a wrapper every time I launch openscad, like: log_scad_mem openscad myfile.scad
<InPhase>
kintel: What I'm "Hmm"ing about, is I wonder if this would be a useful sort of thing to add to the testing approach to track which ones use which amount of memory. Obviously we could only do this on certain platforms, unless we thought of a way to do it cross-platform. But some knowledge and tracking of memory utilization is better than none.
J2386 has quit [Client Quit]
J2386 has joined #openscad
<InPhase>
kintel: I based it around the fact that the verbose run of /usr/bin/time (different from just running "time") on Linux also outputs the "Maximum resident set size".
<kintel>
InPhase do you know how that deals with parallel runs?
<kintel>
ctest -j1000 didn't noticeable increase maximum resident size for me..
<kintel>
But I got my test run down to 48 seconds with -j1000 ;)
<InPhase>
kintel: That /usr/bin/time only reports the memory consumption of the process it is running itself.
<InPhase>
kintel: Although -j1000 could theoretically lead to some substantial memory consumption. :)
<InPhase>
i.e., total.
<InPhase>
But each individually should still report the individual total.
<InPhase>
s/individual total/individual amount/
<InPhase>
When I started running that for my own stuff, it was rattling in the back of my mind that it's a problem that we don't monitor memory consumption of tests. This seems like something we should really be tracking over time in some manner.
<InPhase>
I'm not sure what we should be doing with this information, but I certainly feel like we should know what we're doing to memory consumption with all these radical changes.
<InPhase>
I just didn't act on it because I wasn't sure what the right solution or approach is, and I don't know a way to do it cross-platform. But, I raise it here and now as a thought because of your concern that there might be memory exhaustion on the CI for some tests. Knowing which tests take more RAM would certainly make that a more straightforward thing to consider.
<kintel>
We can ssh into the CI, so when I have some time & motivation I may try to force the failure to happen in real-time
<kintel>
Once we know the issue, it's more motivating to build infra to avoid it ;)
<InPhase>
Logical. :)
<InPhase>
I assume the CI tests are running with no parallelization?