use-value has quit [Remote host closed the connection]
use-value has joined #openscad
Lagopus has joined #openscad
Av8r has joined #openscad
<teepee>
Av8r: export_pdf is part of the core that should not depend on Qt so it can be used without GUI
Lagopus has quit [Ping timeout: 252 seconds]
<Av8r>
teepee: Got it. Will proceed as previously planned...
ali12341 has quit [Remote host closed the connection]
ali12341 has joined #openscad
J2353 has joined #openscad
J23 has quit [Ping timeout: 260 seconds]
Ademan has joined #openscad
<Ademan>
I think I come and ask roughly the same question every time I start a new openscad project, but is there a way to find out information about a child module?
<Ademan>
For instance it would be super useful to be able to be able to fit the smallest cylinder around a child module and get that radius (and height, I suppose, if desired)
<Ademan>
(you could provide the axis of course
<Ademan>
also getting the bounding box as well, probably
<InPhase>
There's a PR working on this. It'll take a little time, because it's a lot bigger of a change than you might think.
<InPhase>
The PR introduces an entire geometric object syntax and semantics, a consequence of which would be the ability to extract such information in a reasonably efficient manner.
<Ademan>
cool, any idea if it's likely to be merged?
<InPhase>
Yes, but it will take time because it's a major change and we need to hit each other with nerf bats until we come to a conclusion about the best way to not shoot ourselves in the foot with future syntax and semantics problems from such a major change to the language.
<InPhase>
Also JordanBrown[m] would like to remind me to do my part and review it thoroughly.
<Ademan>
maybe I'll mess with it, can't hurt to have testers I suppose, even if it is a moving target
<JordanBrown[m]>
It isn’t moving that much, though I just had an idea about introducing something akin to list comprehensions.
<JordanBrown[m]>
The concepts are not likely to change much.
<JordanBrown[m]>
InPhase: the two things I really want are comments about usability, and help on a context leak that leads to an assertion failure.
<JordanBrown[m]>
Not really ready for code review, because one of the two object literal syntaxes is going to go away.
<Ademan>
oh interesting, full object support, that was kind of my initial thinking on solving this problem (specifically things like specifying all of the parameters describing a screw hole (head diameter, countersink depth, shaft diameter, length) without adding 4+ parameters to every module)
<JordanBrown[m]>
And yes I am very interested in people playing with it.
<JordanBrown[m]>
Yes.
<JordanBrown[m]>
I would not yet say “full”, but it’s some. One next-phase idea is a $this, so that if you say o.func() or o.mod(), the function or module called gets $this that points at the object. Rather like JavaScript.
fling has quit [Remote host closed the connection]
fling has joined #openscad
fling has quit [Remote host closed the connection]
fling has joined #openscad
teepee_ has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
teepee has quit [Remote host closed the connection]
teepee_ has joined #openscad
teepee_ is now known as teepee
fling has quit [Remote host closed the connection]
fling has joined #openscad
Av8r has quit [Remote host closed the connection]
guso7836 has joined #openscad
guso7836 has quit [Client Quit]
guso7877 has joined #openscad
guso7877 has quit [Client Quit]
guso7847 has joined #openscad
<guso7847>
Teepee did you Test by Chance If manifold can Union self intersections?
<guso7847>
In i doubt that any company would Insert delay Loops into their Tool, when they want to compete with the market
guso7847 has quit [Quit: Client closed]
<Scopeuk>
guso78[m] they sell multiple versions, the more expensive one is "much faster" the slower one is a slightly older core and spends a lot of time sleeping when inspected
<Scopeuk>
The slower one is the one they let other companies bundle with their tooling
Ademan has quit [Quit: leaving]
ali12341 has quit [Remote host closed the connection]
ali12341 has joined #openscad
LordOfBikes has quit [Ping timeout: 252 seconds]
ali12341 has quit [Remote host closed the connection]
ali12341 has joined #openscad
LordOfBikes has joined #openscad
KimK has quit [Ping timeout: 255 seconds]
KimK has joined #openscad
<guso78>
Scopeuk, i dont actually think its sleeping, rather the algorithm used is very inefficient. if its sleeping, you could very easily find even in the binary code.
<guso78>
BTW i just compiled the published branch of ochavik but i could not yet perform my self intersection experiment.it appears polyhedron are not yet supported.
<lf94>
scroll to the bottom for two small examples of using js with libfive
linext__ has joined #openscad
linext_ has quit [Ping timeout: 252 seconds]
linext has quit [Ping timeout: 252 seconds]
linext has joined #openscad
linext__ has quit [Client Quit]
linext has quit [Ping timeout: 252 seconds]
linext has joined #openscad
* lkcl
insights begin
<lkcl>
i am... how-to-say-diplomatically... let me first say i have nothing but the deepest respect for openscad-as-it-stands, that it does a job and does it fantastically well
<lkcl>
(respect for openscad and the people who contribute to it)
<InPhase>
"but" ;)
<lkcl>
also as context: bear in mind that i have been using *pyopenscad* for 12 years, in which there exists an in-memory full, complete and 100% perfect "representation" of the objects being created
<lkcl>
InPhase: :) working towards it carefully but without using "but" oh darn it
* InPhase
prepares the "it is not that way by design, so that" and "yes, that is a known problem and is actually hard because" hotkeys.
<lkcl>
also, the scad language is very bare-bones and nowhere near as complete or powerful as something like python, or lua.
<lkcl>
(i looked up "python openscad" a couple of days ago and was stunned to find *over six* separate and distinct python-based generators of SCAD ASCII files)
* lkcl
running-commentary: InPhase, ah i worked out a good way to put it
<teepee>
only six? you did not search very hard :)
<lkcl>
teepee, lol.
<InPhase>
Probably just the first page of results.
<lkcl>
thus, it would be perfectly natural - in my mind - to take the *python* in-memory tree, and perform *python* based analysis of modules/child-objects, and in *python* get that code to return a cylinder that contained all objects
<lkcl>
with python being known by 1/3 of the world's programmers, the probability that a 3D manipulation library already exists that could perfectly well do that job is (without actually searching) likely to be around the 0.995 level
<InPhase>
lkcl: That is the reasoning behind the Python PR on openscad's github. Although there is a very good reason why this is unlikely to be the primary method of using OpenSCAD, and why these other libraries have not caught on as a primary method.
<lkcl>
thus, one might ask one's-self, with the amount of time and effort it would take to duplicate such libraries in c/c++ and integrate them behind the OpenSCAD language, one might ask "is such efforts a productive use of time"?
<InPhase>
lkcl: In fact I happen to be a huge Python fan, so I get it. But an absolutely critical difference between Python and scad is that the scad languge is a domain specific language with zero security risks. This has been a huge asset in developing a model and library sharing community where people can use libraries and models from other people with zero security risk.
gknux has quit [Quit: ....and i am outta here....]
<lkcl>
InPhase, if someone includes libraries that introduce security risk from using python, they're doing something drastically, drastically wrong
<InPhase>
lkcl: It is a different target market than many other programming languages because most modelers are in fact not programmers, or not skilled programmers, and thus do not actually have the capability to do security audits.
<lkcl>
not only that but this is *python* we're talking about, and if there's a security hole in *python* then that's an extremely serious matter that should be immediately reported to the Python Software Foundation's security Red Team
<lf94>
Any code CAD DSL introduces a new language, one that isn't close in semantics to what the rest of the world uses - I think this is a problem
<lkcl>
because millions of programmers and the software that they write will be seriously adversely affected
<lf94>
"zero security risks" - what's the threat model here?
<InPhase>
lkcl: Every Python program one downloads and executes can compromise a system. It's super easy to slip something in there covertly if the person running it is not a programmer and doesn't know how to look for it.
<lf94>
I'm sure someone could conjure something malicious for OpenSCAD
<lkcl>
lf94, yes, basically. SCAD programmers != python programmers. the expertise does not necessarily cross over
<InPhase>
lkcl: So if models can execute arbitary code, it makes it unsafe to use shared models.
<lf94>
Also: no, this is not true. Most people are downloading single SCAD files. The same can be done for Python: single Python files.
<InPhase>
lf94: There is nothing malicious that can be done with scad other than crash the OpenSCAD program. We've had a handful of security risks identified in the OpenSCAD executable itself through libraries and such, and we took care of them upon realization.
<lf94>
It takes one person to make a "OpenSCAD package manager" and the same problem arise.
<lkcl>
InPhase, ok so we're touching again briefly on the conversation we had the other day. if you're not familiar with e.g. debian and how its packages are effectively inviolate (long story) then it can be easy to assume "insecure"
<lkcl>
but
gknux has joined #openscad
<lkcl>
butbutbut...
<lkcl>
debian is a special-case.
<InPhase>
lkcl: Debian does it by a network of trust in maintainers.
<teepee>
no a package manager will *not* introduce a random scripting issue
<lkcl>
windows users get trojans all the time.
<lkcl>
InPhase, ah glad you know about that! you may be fascinated to learn i did a review and identified *eighteen* separate and distinct requirements involved in the network-of-trust behind distros (!)
<InPhase>
lkcl: But you cannot have a network of trust among OpenSCAD model makers, because this group is almost anyone out there, and most of those people will be complete unknowns.
<lf94>
InPhase: you cannot guarantee an OpenSCAD project doesn't ship a makefile downloading who knows what
<InPhase>
lf94: OpenSCAD does not support makefiles.
<lkcl>
InPhase, indeed. however lf94 makes the point that individual python files may be downloaded
<lf94>
InPhase: you can have projects that use Makefile... come on :p
<lkcl>
openscad is a target application *used* by Makefiles
<InPhase>
lf94: If people use makefiles, or .exe files, that they download while trying to grab a model, then that's an outside problem.
<teepee>
if people download makefiles and execute those, it's not an openscad issue
<lf94>
Are we not talking about "outside problems" ??
<lkcl>
why on earth would anyone download a .exe??
<InPhase>
lf94: No, we're talking about inside problems.
<lf94>
Python is also perfectly saf ethen
<lf94>
Never accesses anything outside the system: all good
<lkcl>
if they've downloaded python from a trusted source - because it's signed by the Python Software Foundation - they're fine
<InPhase>
lkcl: No?
<lf94>
I'm guessing you're saying someone can do "rm -rf /" within Python and not OpenSCAD
<InPhase>
lkcl: Good grief no, it's the Python scripts that are the risk. :)
<InPhase>
lf94: Exactly.
<InPhase>
lf94: That and worse.
<lkcl>
InPhase, ok, so let me state what i think you're saying: can you correct/confirm? (might need a few iterations)
<InPhase>
lf94: In fact we use that as a threshold for excluding features from the scad language, on purpose.
<lkcl>
paraphrasing: what you are saying is that because openscad *can't* do network sockets (or anything else), that it's significantly reducing the potential attack surface and that's a good thing for [security-non-savvy] OpenSCAD users?
<InPhase>
lf94: Nothing is allowed in that breaks the strong sandbox.
<InPhase>
lkcl: Yes.
<lkcl>
okaaay. then that's very sensible.
* lkcl
thinking this over
<InPhase>
lkcl: And more than just the individual users, it fosters the sharing community that is the foundation of OpenSCAD's success.
<teepee>
it's not the only reason but part of the reasoning why there's no write() call
<teepee>
and no read() for generic data, only parsed file content
<lkcl>
teepee, totally get it.
<teepee>
so unless password files go json at some point it's hard to read those :)
<lkcl>
you *don't* want a turing-complete language, in other words
<InPhase>
lkcl: I actually think it's great that there are Python front ends to OpenSCAD. This sort of thing can be super handy sometimes, especially for people who know what they're doing. It's just that the results of this are not a good part of the sharing community, and are better off shared between sets of people who also know how to evaluate and manage those risks, as people would for other Python files
<InPhase>
they grab. It is a different target cross-section.
<InPhase>
lkcl: I do actually execute Python files I grab from random unknown people. But I read them first!
<lkcl>
InPhase, yes, likewise :) it gets unwieldy for things like scipy and numpy though.
<InPhase>
I read scipy and numpy code pretty fast, as that's a big part of my day job.
<lkcl>
i want to create a steering wheel for the FOSSHW car, and i want to make it out of Voronoi 3D-printed arc segments
<lkcl>
i mean the actual scipy and numpy *libraries*. you're not going to be reading that in a few minutes! :)
<InPhase>
These are trusted sources.
<lkcl>
so because i am using pyopenscad there's no way i'm going to be using a SCAD library/module for voronoi objects: i'll have to do them myself
<InPhase>
Although I do actually look at many parts of them, I haven't read it all and don't track all changes. But they are a trusted reputable project, like other core system components.
<InPhase>
Much like people are regarding the OpenSCAD developers as a trusted supplier. We watch each other through the git tree and pull requests.
<lkcl>
that means i need to find a python-based voronoi library and patch it together with the spline-surface-library i created, in some way.
<InPhase>
lkcl: Well, OpenSCAD is finite-Turing-complete so you can calculate anything within it.
<InPhase>
lkcl: But absolutely some things are much easier to calculate externally with the help of other libraries, and then feed into it.
* lkcl
already thought of an awesome simple way to use the 3D "spine surface" generator i wrote, and to use it for interpolation... hmmm
<lkcl>
i hadn't realised before the intricacies of domain-specific security when it comes to SCAD.
<InPhase>
3D offset is a work in progress, because it is actually a very hard problem.
<lkcl>
yes!
<InPhase>
Although you can fake 3D offset inward with negatives and minkowski with spheres and then another difference, this starts to get slow really fast.
<InPhase>
What I prefer to do instead, is to design my objects parametrically, and then reduce the size to do a hollow out.
<lkcl>
i wrote a brute-force algorithm for creating a... a... trilobe cam that could have opposing roller-bearings separated at all times by a fixed distance (a shared roller-holder-shaft)
<lkcl>
i had to take a circle of lines (spokes, QTY 1000s) then "pretend" to CNC-machine them. O(N^2) algorithm, it was awful, but did the job
<lkcl>
yes, i totally get that this stuff's real hard :)
<lkcl>
on the FOSS 15 in Laptop case (18 months work) i had to use approximations and/or construct objects from spline-surfaces
<lkcl>
(one of the reasons i created it)
<lkcl>
because you specify a 2D array of 3D points, hand it to the spline-generator and it multiplies up in first rows and then columns, and the results are handed to a routine that creates a polygon
<lkcl>
where a *second* layer is computed at a fixed normalised distance from the first
<InPhase>
Sometimes you want an almost-hollow-out, and you have to go through extra steps. This was an example where I had to tweak and couldn't go quite parametric and shrink: https://www.thingiverse.com/thing:3024518
<lkcl>
the initial version just naively added a vector to all points, which meant significant thinning at some locations
<lkcl>
oo that's really pretty
<lkcl>
correction: it's *beautiful*!
<InPhase>
I also added vent holes for the LED bulbs, and they doubled as a radiant pattern on the ceiling. I was pretty happy with it.
<InPhase>
And I confess that horizontal pattern midway up was a print defect, but I was okay with the aesthetic of that so I did not attempt to fix and reprint. :)
<lkcl>
no i can see the patterns on the ceiling. i love when function results in artistic side-effects :)
<InPhase>
Although varying the thickness on purpose might have made for a nice aesthetic. But temperature regulation issues did the work for me I guess!
<lkcl>
so, yes, where it really mattered i simply construct objects from multiple seam-interlocking splined surfaces, where they share a common edge (identical points) either along the rows or along the columns.
<lkcl>
yeah in particular that could be used to create a uniform light distribution across the ceiling
<lkcl>
sacrificing brightness unless the 3D material is either reflective or similar to... ahh... those fibreglass channel-thingies?
<lkcl>
the ones that are used to bring in sunlight into the interior of buildings? constructed from thousands of fibre-optic cables
<lkcl>
and also very awesome 70s lamps :)
<lkcl>
sorry, i am totally distracted by sparkly shiny things, this qualifies lol
<InPhase>
:)
<InPhase>
(Away for a little bit making lunch.)
<lkcl>
thank you for the dotSCAD link.
* lkcl
needs dinner and tea, too
<lkcl>
thank you, InPhase
<lf94>
I'm still not convinced OpenSCAD is any safer than Python, or any other language
<lf94>
On the surface yes
<lf94>
100% convinced
<lf94>
But I think there's more to this than meets the eye
<teepee>
try bitcoin mining then
<InPhase>
Well it's absolutely safer, because there is zero risk from OpenSCAD code unless there is a defect in the OpenSCAD program itself.
<lf94>
Surely there's mechanisms to "lock down" Python if that's a goal
<InPhase>
lf94: Actually that's quite challenging in a cross-platform way.
<teepee>
no, there is not
<InPhase>
lf94: The language is not at all designed for this.
<lf94>
Can't you just prevent import of "subprocess" or whatever
<InPhase>
Nope.
<InPhase>
lf94: For example, when you import numpy, you are running natively compiled C code.
<InPhase>
Now swap out numpy with... anything.
<lf94>
Right
<InPhase>
The massive flexibility that makes it really useful is what presents the hazard here.
<InPhase>
And, one can speak quite generally that the solution path to this problem space is to have a finite set of defined pathways for operations.
L29Ah has quit [Read error: Connection reset by peer]
L29Ah has joined #openscad
L29Ah has quit [Read error: Connection reset by peer]
L29Ah has joined #openscad
<lf94>
InPhase: there are many js environments though, as there are python - why not just say "developed for python env x" where x is some env. that's heavily locked down i.e. no ffi, no network, no fs access
<InPhase>
I know of no such Python system, and if it existed, it would remove most of the libraries that would make Python valuable for this.
<lf94>
Is it not useful to have python syntax to describe models? :p
guso78 has quit [Ping timeout: 260 seconds]
<lf94>
and yes, i'm pretty sure this doesnt exist etiher
<lf94>
but could easily be done
<InPhase>
I think it would actually be quite difficult, and would require a custom cpython implementation.
<lf94>
If openscad was a library you could do some FFI with some much "weaker" pythons
<lf94>
there are many js engines these days also that are available to use
<lf94>
so you can use js with the safety you're talking about
<lf94>
you could do v8 + openscad :p
<lf94>
but we all know that openscad is "too far gone" in terms of growth
<lf94>
it'd be too drastic to convince people to use it in another way
<lf94>
it'd be better to consume all the openscad scripts out there instead and convert ;)
<InPhase>
I'm pretty confident JavaScript isn't going to takeover the OpenSCAD language for 3D modeling. That has also been tried a few times.
<lf94>
I know :p
<lf94>
I think there's many reasons for the failures
epony has joined #openscad
<teepee>
´there's no such thing as too far gone or making it a library. it's simply a matter of interest. and there's the problem, most people want to start their own projects which is totally fine an their choice but limits the combined dev power per project
<teepee>
which is why I think the current python option is great as it has the potential of producing some synergy between diffent ways of using it
<teepee>
e.g. if that Manifold effort turns out as great as we hope, the python part will simply benefit from that too
<lf94>
"there's no such thing as too far gone" except there is... :p
<lf94>
not sure how you could dismiss once something has inertia, good luck stopping it.
<lkcl>
lf94, the rpython (restricted python) module was removed about... err... 15+ years ago due to __new__ and other low-level mechanisms providing a backdoor to escape from the restricted subset. rather annoying because i was using and critically relying on the restricted-python module at the time.
<lkcl>
zope "claimed" to have done it correctly but i just went... naah i'm not going to convert everything over to zope.
<InPhase>
lf94: What an existing base means is that change requires careful management of those changes. This can slow things down. But that management of change is done because this comes with huge benefits like preserving ecosystems and sustaining a synergy of features. These are all things one doesn't get as an option with a fresh start.
kintel has joined #openscad
<InPhase>
There ARE times when a fresh start is called for, because a new idea is so radically different. In open source projects, the vast majority of those fail. And some small handful succeed and become the new rockstar projects. Maybe Manifold will actually be an example of that? But we'll have to wait and see how it actually works under real world demands.
<teepee>
yeah, there are valid reasons, but most of the cases are "now we know how to do it, lets do it clean".
<teepee>
none of those ever worked for more than 3 years
<teepee>
remember that golang is simple so everyone can understand it? :D
<InPhase>
I don't mind people flittering about their efforts on projects that will probably fail. I explore some of those myself in many different areas. Some succeeded, many I declared failed before anyone other than myself saw them, and some "worked great" but no one else seemed to notice or care. :)
<InPhase>
But one should be clearheaded about the low probabilities of a fruitful result. It takes a special level of understanding, and a timing of the zeitgeist for something new to click.
<teepee>
yes, like I said, everyone is totally entitled to decide for their time. I still sometimes think it would be great to have more collaboration.
<teepee>
like we tried with brl-cad, and there's some cross-over with freecad but it's totally different group of people
<InPhase>
Collaboration certainly has a much higher return on investment.
<InPhase>
With OpenSCAD contributions, I know that even if OpenSCAD gets replaced in 10 or 20 or 30 years, everything we do here is part of the mental space of how to solve these sorts of problems going forward.
<InPhase>
And of course there's high utility in the intervening time.
<teepee>
indeed, plus it's actually useful for people solving design topics
<InPhase>
There are already "scad-like" languages out there.
<teepee>
I might be a bit sad if it would die at some point, but right now it gives me a tool to get designs done I need or want
* InPhase
glances in juri_'s direction, then quickly glances away and stares at a tree.
<teepee>
Haskell all the things!
buZz has quit [Ping timeout: 252 seconds]
use-value has quit [Remote host closed the connection]
<teepee>
Still need to read that book I got a while ago from Humble Bundle :)
use-value has joined #openscad
<teepee>
new year, new chance maybe
<InPhase>
Also I think in more recent years we've made the animation very impressive and more useful in OpenSCAD, with these speed developments, growing computational power, and more prominent layout placement. Which means going forward programmatic cad solutions are all going to need animation capability to play at this level.
buZz has joined #openscad
buZz is now known as Guest9381
<InPhase>
Things like Blender and Shadertoy might be besting the animation capabilities here, but they don't really have the same clean manifold model making abilities, which is the core focus. Animation though provides good design assets and abilities for showing off model features.
<lf94>
libfive can animate as well
<lf94>
(and focuses on manifolds)
<lf94>
Matt did a tremendous amount of work for libfive, but in the end, it's actually a somewhat conceptually simple library
ali1234 has joined #openscad
ali12341 has quit [Remote host closed the connection]
<kintel>
Re
<kintel>
<- had a baby arrival to deal with. I'm back now, but in a very reduced capacity
<kintel>
..but I'm off work until Easter, so I have an hour now and then. Mostly tinkering with bottom-up OpenGL stuff to try and clean up the various layers of cruft we've accumulated.
<teepee>
yay, congratulations!
<kintel>
..and I finally bit the bullet and got an Intel box (now that Macs are useless for running VMs). ..but please don't ask me to install Windows ;)
<teepee>
:)
<kintel>
teepee: Are you aware of any particular low-level OpenGL/context/offscreen etc. issues which we should address?
<kintel>
My initial goal is to kill off immediate mode (legacy) support, possibly followed by killing off OpenGL 2 support (but not sure if that's realistic), then look into adding proper GLES compatibility
<kintel>
I expect a rather deep detour into OpenCSG territory..
la1yv has quit [Read error: Connection reset by peer]
la1yv has joined #openscad
<teepee>
issues in the sense of problems, no, other than the obvious that it's being legacy
<teepee>
there's at least 2 related open PRs I believe, one the shader changes and the export-png via offscreen buffer
epony has quit [Remote host closed the connection]
<teepee>
related is the annoying behavior of GLEW to be either GLX or EGL plus OpenCSG depending on GLX, but there's just a fresh PR against OpenCSG that would allow to get rid of that - it's nothing we use in openscad
epony has joined #openscad
<lf94>
port it all to webgpu
<teepee>
no
<teepee>
it's hugely annoying that trend to force everything into a web browser
<teepee>
having this as option is great, having it as *only* option is just wrong
<teepee>
that said... kintel did you post that javascript CSG view code? there's someone trying to get something like that working but having some issues
<kintel>
Moving every to GLES-compatible modern rendering should make WebGL etc. a lot easier to support directly
<teepee>
gles3 and webgl are mostly a match right?
<kintel>
I didn't post it anywhere as it's not particularly clean, but I don't thing there are any reasons for not doing it. I didn't do a full OpenCSG implementation, just the SCS algo with limited sorting support. Most of the work was making it compatible with WebGL 1, which isn't very useful any longer : /
<kintel>
Who wanted to know?
<kintel>
Yeah, WebGL1 ~= GLES2, WebGL2 ~= GLES3
<teepee>
I think this project is mostly meant for jscad as previewer but it could be useful for server side openscad + client side csg preview or in combination with webgl