<dTal>
a "color" command that only nudged the colors of its children, instead of overriding them completely
<dTal>
that way you could arbitrarily tint subassemblies, or do cool recursive tricks :p
ActionDave has joined #openscad
<teepee>
dTal: how so, hue shift or something
<dTal>
well I was imagining nudge([r,g,b]) where each factor can take a value of -inf to inf, and where a factor of 1 halves the distance to full saturation of the component and -1 halves the distance to full desaturation, and where nudge(n) nudge(n) is equivalent to nudge(2*n)
<dTal>
something like that anyway
<dTal>
can't quite work out what formula ticks all those
<JordanBrown[m]>
HSV or one of the other color-wheel schemes would probably be better. RGB is incredibly unintuitive.
<JordanBrown[m]>
Which raises another possibility: color specification by HSV or some other scheme, instead of RGB.
<dTal>
maybe, but that's an orthogonal issue. If someone wants to impement HSV for OpenSCAD I'm all for it :p
<JordanBrown[m]>
Those might just be straightforward arithmetic functions that take (e.g.) HSV as input and return RGB.
<dTal>
should be quite easy actually, just a keyword argument to color() and a bit of linear arithmetic
<JordanBrown[m]>
It's orthogonal in a sense, but I bet that adding and subtracting HSV values would be a lot easier to understand than adding and subtracting RGB values.
<JordanBrown[m]>
extra points if you can figure out how to make red + blue equal purple.
<xloem[m]>
i’ve done rgb rendering. i don’t know how to add/sub hsv, but in rgb r+b=violet. adding them is comparable to adding or overlapping light. multiplying them is comparable to placing a filter in front of them or lighting a colored surface with a colored light source. in hsv, e.g. hue would need a nonlinear transform.
<dTal>
The idea would work with any component model with values ranging [0,1]
<dTal>
nudge() could take the same keyword argument as color()
<JordanBrown[m]>
Not that I've looked at it deeply, but the problem with HSV there is that adding "red" and "blue" isn't meaningful in HSV. "red" and "blue" are both absolute positions on the color wheel, and the only things you can add are an absolute position and a relative change. So you could say "red plus 10 degrees", but not "red plus blue" or "10 degrees plus 20 degrees".
<JordanBrown[m]>
(Except that you might take the 10 degrees as being implicitly relative to the absolute position 0 degrees, whatever color that is.)
<dTal>
you can average the two hue values
<JordanBrown[m]>
Yes.
<xloem[m]>
this would make red+blue=green (0deg+240deg)/2; you’d want to convert to rgb and avg that
<JordanBrown[m]>
which is A + (B-A)/2. A is an absolute position, B is an absolute position, B-A is relative, (B-A)/2 is relative, and thus A+(B-A)/2 is OK.
Lagopus has quit [Read error: Connection reset by peer]
<dTal>
I was mostly picturing nested brightness changes allowing you to "highlight" parts, which is easy enough to do (roughly) in RGB
Lagopus has joined #openscad
<JordanBrown[m]>
Hmm. Yeah, (A+B)/2 would work too, but is harder to justify in terms of the units involved.
<dTal>
but sure you'd get more aesthetically pleasing results with HSV, which is also true for the rest of OpenSCAD
<xloem[m]>
i think they’re arithmetically the same
<JordanBrown[m]>
yes, but arithmetic is not always sensible for units.
<JordanBrown[m]>
It is not sensible, for instance, to add the freezing point of water (32F) to the boiling point of water (212F).
<JordanBrown[m]>
Even though subsequently dividing by two would yield a reasonable average.
<JordanBrown[m]>
If your intermediate values don't make sense, your calculation is in jeopardy.
<xloem[m]>
i didn't think of that; it was just the expression i'd memorized. your approach maked sense
<dTal>
...it's perfectly sensible to add those two things?
<dTal>
especially to calculate an average
<JordanBrown[m]>
If you average the UTC times of all earthquakes worldwide, you will find that they average out to 4AM Pacific time.
<JordanBrown[m]>
Or if you average the UTC times of all Pacific-TZ earthquakes.
<xloem[m]>
dTal: i was thinking how when intrrmediate values represent something real it protects against mistakes; this is how it makes sense to me
<JordanBrown[m]>
Yes, exactly.
<JordanBrown[m]>
I didn't say that your calculation would be *wrong*, only that it is in jeopardy.
<dTal>
212F + 32F = 244F
<JordanBrown[m]>
Indeed... which is not at all a meaningful combination of those two values.
<InPhase>
dTal: I've done what you call a "nudge" in OpenSCAD. You create the original geometry, then you create one 0.1 larger in all dimensions, and then you color the outer one with an alpha value.
<dTal>
it's perfectly meaningful
<InPhase>
dTal: It's just not always trivial to make the 0.1 larger. Minkowski can always do it, but that comes with a price.
<dTal>
the amount of thermal energy to raise an object by 244F is equal to the amount required to raise it by 32F + the amount required to raise it by 212F
<JordanBrown[m]>
Ah, and you hit on a subtle units problem.
<JordanBrown[m]>
32F as a temperature is not the same as 32F as a temperature *change*.
<dTal>
The 0 point is arbitrary and has no effect on the validity of adding the two
<JordanBrown[m]>
15:00 as a time is not the same as 15:00 as a duration.
<JordanBrown[m]>
If you try to add 3pm and 4pm, you might do 15.00 + 16.00 = 21.00, but that wouldn't be meaningful.
<JordanBrown[m]>
oops 31.00 of course
<dTal>
InPhase: that's very interesting, if horrifyingly inefficient. Do the alpha shells nest?
<dTal>
it is meaningful, it's 31 hours after midnight
<JordanBrown[m]>
3pm plus 16.00 hours is totally meaningful. But I'd say that 3pm plus 4pm is not meaningful at all. Probably we just need to agree to disagree on that.
<dTal>
all linear scales are implicitly a distance from some reference point
<InPhase>
dTal: I used a very similar method in the SCADvent calendar for the last segment of the Caterpillar tribute.
<JordanBrown[m]>
Anyhow, both color-nudging and color schemes other than RGB are interesting possibilities.
<xloem[m]>
re temperature, if we imagine values being tagged with their context and use, and one of these tags is measured as temperature, adding them and not removing the double unit would indicate an error because the zero point is an arbitrary property of the unit. the result is different in F, C, K. but the same when divided by 2 again. you could tag values lots of ways and propagate the tags with checks but usually people don't do this.
<InPhase>
dTal: And yes, it can nest. e.g. nudge("white", $t) nudge("blue", cos(3*360*$t)^2) color("red") cylinder(r=5, h=10);
<InPhase>
FPS: 30, steps: 300
<dTal>
I'd love to run that, if I only had the code for nudge() :p
<InPhase>
I gave it in the paste...
J23 has quit [Quit: Client closed]
J23 has joined #openscad
<dTal>
oh I missed the paste, apologies
<InPhase>
:)
<InPhase>
Obviously for this monocolor example this is a silly way to do it. But if you have a multi-color starting geometry, then it can be useful for a transition effect. Which is what I used it for.
<dTal>
InPhase: that alpha trick is great, thanks
<InPhase>
This demonstratse multicolor. And it demonstrates how slow minkowski gets sometimes. ;) nudge("white", $t) nudge("blue", sin(3*360*$t)^2) { color("red") cylinder(r=5, h=10); color("green") cube(6); }
<JordanBrown[m]>
Hypothetically, define a Color object that incorporates a color schema and values. Create one with, e.g. Color.rgb("red") or Color.hls([100,100,50]). Combine with Color.add(colorval, [values]), Color.difference(colorval, colorval), et cetera. Wave hands furiously at what to do when units don't match.
<JordanBrown[m]>
Have the color module accept a Color object.
kintel has joined #openscad
<InPhase>
dTal: The 0.001 extrude gets a little flickery for me.
<dTal>
You're only supposed to look at it along the Z axis
<InPhase>
0.002 transitions it into a single transparent red circle with the blue pattern swirling along.
<teepee>
considering that good old romily was also in that price range IIRC
<kintel>
Nice, those a beefy enough that we can casually build stuff without waiting around forever
<teepee>
twice the memory would be useful though ;-)
<kintel>
Did you imagine spinning up VMs etc. on those for things like Windows-testing?
<teepee>
not so much for the normal testing, but for some longer running stuff from time to time or so
<teepee>
plus maybe running some additional stuff like a web playground and such
<kintel>
Could be nice if we ever get into running geometry caching over a long time
<teepee>
like a simple version of what linext is building
<teepee>
but no storage and maybe not even customizer
<kintel>
yeah, pirate pad for OpenSCAD :)
<teepee>
that would be even cooler yes
<teepee>
also live examples for the tutorials and so on
<InPhase>
Probably the most important utilization of funds would be a library hosting server.
<linext>
now that i'm back writing the web app, do you want me to put an embed system for openscad.org ?
<teepee>
I do hope we don't need to host forum and/or matrix though :)
<linext>
it can be hosted on your own server, or an embedded iframe to mine
<InPhase>
It looks like the funds and fund accumulation rate are such that library hosting is actually a viable option.
<InPhase>
We would just need, you know, the entire infrastructure for it too.
<teepee>
linext: I would not mind if the files come from your server with a little "hosted by 3dcustomizer" either
<linext>
i'm thinking a two pane view
<JordanBrown[m]>
@InPhase Cooler in a way would be if we could figure out how to download libraries directly from github.
<teepee>
InPhase: hosting an index, I can see, but I'm not sure we want to go into full hosting business
<linext>
code/customizer on the first pane, and rendered file on the second pane
<kintel>
teepee: All of this is just static hosting, though, or did you want a backend for something?
<InPhase>
JordanBrown[m]: I've proposed syntax for that a few times. The idea gets mixed reception.
<JordanBrown[m]>
Simple use<URL> or include<url> is a little scary. But maybe there's something else that would be OK.
<teepee>
kintel: as static as possible, for now we only have those minimal backend services that fetch stuff from CIs and handle things like the advent calendar via cron
<InPhase>
JordanBrown[m]: My "lets have no server" proposal was based around the notion of library-grabbing modules. Like include<git@ ....>
<InPhase>
JordanBrown[m]: Where there is then a git module in charge of that fetcher. And then a central library manager for managing and deleting what libraries are already cached on disk.
<teepee>
kintel: in my view it would be ideal if we don't actually need to host user stuff
<JordanBrown[m]>
should be include <git:...> since conventionally in A@B A is an object on B. URL-style scheme: seems more appropriate. But yes.
<teepee>
It's nice to see a couple of sites growing that do this
<JordanBrown[m]>
The big question is whether you can do something sensible with version requirements on top of the URLs that github publishes.
<InPhase>
JordanBrown[m]: But a central server eliminates the complexity of managing a large number of different modules, or of needing a scripting language for the modules.
<JordanBrown[m]>
I'm not immediately convinced that you need either of those things. But I'm also not convinced that you don't.
<InPhase>
JordanBrown[m]: Well by the time you have git@ printables@ thingiverse@ customizer3d@ and so on, it gets to be a little messy.
<kintel>
I haven't read up on the details, but at some point I noticed Deno (https://deno.land), which seem to import directly from URLs
<teepee>
I can't say if deno is a good idea
<teepee>
that said, with the current code, I think the only option is to start externally
<teepee>
we really don't want to do a github lookup at 30fps for animation ;-)
<kintel>
heh, it sure hasn't gotten that much traction, as node.js refuses to go away
<InPhase>
JordanBrown[m]: "Python scripts would help" was my attempt at "how do we manage the mess, given that sites outside of our control change around a lot?"
<InPhase>
JordanBrown[m]: But a server within our control would not have this issue.
<JordanBrown[m]>
InPhase given that each "scheme" is probably little more than stuffing a name into the middle of a URL pattern.
<teepee>
deno has that stuff built-in from the start, so it might work well, I'm sure our code is not really prepared for that
<InPhase>
JordanBrown[m]: Well, but you probably want to express things in a way that's "natural" for a given site.
<kintel>
we'd probably need to rethink imports a bit..
<JordanBrown[m]>
Indeed, a server in our control would make everything easier. But would also mean that we would have to administer that server, decide who can post things there, who can update things that are posted there, that people will say "I downloaded this from openscad.org, it must be official", et cetera.
<teepee>
an arduino style index pointing to github might be a good start
<InPhase>
JordanBrown[m]: Pretend you want to have a library grab on github get all files in the repository for the Aug 5, 2022 commit of this: https://github.com/rcolyer/closepoints under the premise that the scad files have dependencies on each other so you need them all. How do you even solve this for github?
<InPhase>
JordanBrown[m]: Getting "current master" is easy. Getting a fixed commit point for all files is a bit more nuanced.
<JordanBrown[m]>
I'd like to think that just stuffing a name into a Github URL would be enough, but it's not, for two reasons:
<JordanBrown[m]>
* Grabbing the most recent version won't play well with caching, because tomorrow one of the files might change.
<JordanBrown[m]>
* Github URLs really have three parts - repo name, branch name, and path.
<teepee>
use releases
<JordanBrown[m]>
Ideally I don't think you would need to grab all of the files, only the ones that you actually need at the moment.
<kintel>
teepee: Anyway, in terms of getting a server, I don't thing we need to block that on a bunch of policies, so if you can make use of one, let's just sign up, and we can probably scale it up/down as needed.
<InPhase>
JordanBrown[m]: Well, if you wanted something like BOSL2 it's interdependencies all the way down.
<InPhase>
JordanBrown[m]: You really need the whole thing.
<JordanBrown[m]>
Doing that is technically easy. It's https://github.com/$repo/blob/$changesetid/$path
<JordanBrown[m]>
Github keeps history forever, so you can always retrieve an old version.
<kintel>
also, Github is just one commercial outfit, as an Open Source project, we should probably aim for something that isn't tied to their repo layout
<teepee>
kintel: right, that should be possible
<JordanBrown[m]>
Sure... You would need N provider schemes, and it should be easy to plug in new ones. But mostly they would just be maps from some number of inputs to a URL.
<teepee>
yeah, I'd say plan for N schemes, start with one :)
<JordanBrown[m]>
The changesetid is the ugly part. You wouldn't want humans to deal with the raw IDs, and it's ugly to turn anything human-friendly into one.
<JordanBrown[m]>
Plan for N, start with two. That makes it harder to accidentally bake in a dependency.
<InPhase>
JordanBrown[m]: Getting the list of all the files is itself tricky with git. I don't see a clean way to do it without scraping.
<JordanBrown[m]>
Why do you want a list of all the files?
<InPhase>
JordanBrown[m]: To know what all to put into $path?
<kintel>
When I thought about this a long time ago I imagined passing in a URL, and expected to find smth. like and openscad.json or smth. there, which would contain the info needed to import
<kintel>
since we already have a json file used for customization, we could repurpose that as a project/library descriptor
<JordanBrown[m]>
I don't think you need a list of all of the files.
<teepee>
that sounds like the arduino style packaging :)
<teepee>
oh, you mean the local info
<kintel>
yeah, we "just" need a json format which will survive for a long time as that's not part of the stable API
<teepee>
I think it's pretty useful to have something like a repo designator that is set in the local dependency
<teepee>
plus some definition of where that actually is
<teepee>
direct urls are *really* annoying in any scenarios where you have a VPN or a proxy
<JordanBrown[m]>
The ugly part is the 46b5bf2 part, but that might go away if Revar used tags.
<kintel>
yeah, but if a URL or a file path would give identical results, you could just download that folder, and the library becomes independent of where its official online home is
<JordanBrown[m]>
But downloading the folder is harder :-)
<kintel>
By "download" I meant something a human does to keep all the files local
<JordanBrown[m]>
Seriously, consider your web browser. Only in unusual cases do you download all of the components that go into a particular page. Other than that, you use caching and you download each component as needed.
<JordanBrown[m]>
Since we expect that these things are versioned, we (maybe) don't need to have cache entries that expire or check to see if there's a newer version.
<JordanBrown[m]>
Or maybe we do do those things.
<JordanBrown[m]>
Loading a model and hitting F5 would get all of its dependencies into your cache.
<JordanBrown[m]>
Maybe there should be an F5-prime that *only* grabs dependencies.
<JordanBrown[m]>
If you really want to have a local copy of all of BOSL2, yeah, sure, but that can be a harder process.
<kintel>
yeah, caching against well-behaving servers would be important, but now we need UI to manage the cache, force-reload etc.
<kintel>
..but nobody said this would be a one-liner ;)
<JordanBrown[m]>
Sure, some. How much is unclear.
<teepee>
and that I would postpone
<JordanBrown[m]>
Yes.
<JordanBrown[m]>
Might be as little as flush-caches.
<teepee>
having a separate thing first is still useful
<JordanBrown[m]>
Depends on how much we want to be able to just run on top of other people's infrastructures.
<teepee>
not everyone has always internet access
<JordanBrown[m]>
Not having to do our own curation and access control seems like a big win.
<JordanBrown[m]>
Indeed, but you'd only need internet access when you want to add a dependency.
aiyion has quit [Remote host closed the connection]
aiyion has joined #openscad
<JordanBrown[m]>
Hmm. At a quick look, it looks like it will let me publish a new version of your library. That Would Be Bad.
<teepee>
there are some automatic checks, I don't know if they check for conflicts in name
<JordanBrown[m]>
Reading quickly through their checklist, I didn't see anything about ownership.
<JordanBrown[m]>
Maybe humans have to vet PRs.
<JordanBrown[m]>
A central registry certainly has value, but I don't know if we want to get into the curation or access control businesses.
<JordanBrown[m]>
After Revar submits BOSL2, can I submit a new version of it? Can I submit B0SL2? BOSL3? BOSL2a?
<JordanBrown[m]>
We're only talking about a registry of pointers, so one hopes there are no copyright issues.
<JordanBrown[m]>
One thing that might be tough with any simplistic scheme: give me the latest version of library FOO, version 2.x. Don't give me 1.x, don't give me 3.x. Do give me 2.2.4 in preference to 2.1.5 or 2.0.
<JordanBrown[m]>
Maybe that could be handled using Github tags, putting the onus on the library developer.
<JordanBrown[m]>
The library developer would have to maintain a "2" tag that always pointed at the latest version 2 release.
qeed has quit [Quit: qeed]
<JordanBrown[m]>
I've scared you all away... I'll shut up now :-)
<InPhase>
JordanBrown[m]: I was off reading with the kid. I stipulate it could be done the way you describe, but it's a bit messy for the notion of library management. Users can end up with a partial download of a library such that they might enter a different execution path due to changing a parameter a year later, need to download one more file, and suddenly the library is incomplete (and missing online).
<InPhase>
JordanBrown[m]: Also it removes some standard things like grabbing docs or examples with libraries.
<InPhase>
JordanBrown[m]: Also, maybe a library does something like try to load an svg file of a Santa, where that svg filename has been generated dynamically by some string operations that might or might not have depended upon user-provided input. How is OpenSCAD supposed to know whether that should be a local file or a library file to grab?
<InPhase>
We certainly don't want it firing up connections to try to grab filenames that were never a part of the library. That could leak private information into server logs, with the user being oblivious.
L29Ah has quit [Read error: Connection reset by peer]
epony has quit [Quit: QUIT]
<peepsalot>
i'm still struggling a bit with libfmt's API
epony has joined #openscad
<peepsalot>
the latest version supports `std::variant`, as long as each contained type has a formatter defined on it.
<peepsalot>
i want to set the float precision at some top level, so that when formatting one of our `Value` types, that format specifier propagates recursively down to any doubles (the `Value` could "points", holding a VectorType of VectorTypes of doubles)
<peepsalot>
this would be so that we can create CSG format at full precision, and leave echo at its current 6 digit precision. and eventually probably some way to specify float formatting (and other formatting provided by the library) from user script. i think `print()` instead of `echo()` had been suggested in some github discussion?
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
guso78 has joined #openscad
califax has quit [Remote host closed the connection]
califax has joined #openscad
<guso78>
where would you most logically like to see the "enable python" function ?
Sauvin has quit [Ping timeout: 265 seconds]
Bocaneri has joined #openscad
Bocaneri is now known as Guest4106
<J2375>
xloem[m] did the ub.scad solved your need for cycloidal gears?
epony has quit [Read error: Connection reset by peer]
<peepsalot>
guso78: experimental features are typically added into `class Feature` (build must be configured with `cmake -DEXPERIMENTAL=ON ...`), then checkboxes to enable should show in the Preferences
<J2375>
as the Cycloid() and CylGear() will give you just the polygon or a gear with cycloidal teeth (instead of an involute gear)
<xloem[m]>
<J2375> "xloem do you want to develop..." <- i’m a developer but i have a severe mental disability so i only contribute a little. when most of the work is missing my spaghetti lashing to make things work tends to be poor quality. but i value developing shared systems.
<J2375>
ok if i understand this right the library modules will not be enough for you
<J2375>
if you tell me how the result should be used i can alter the code to your needs - it may be difficult to understand what i did if you are not familiar with how cycloidal gears are constructed
<J2375>
xloem[m] else i ll post this vanilla design on printables (after i printed it and made sure it works as expected)
<xloem[m]>
i’m just getting started, it’s very slow, i’m dreaming of making parametric motor housings to turn common motors into something geared with a rotary encoder, or to simply 3d print an encoded motor with a gearbox.
<xloem[m]>
i’m just looking around, though, because i am really just starting exploring 3d printing. i’m also looking at freecad.
la1yv has quit [Remote host closed the connection]
la1yv has joined #openscad
keppla has joined #openscad
<J2375>
just come back when you feel ready for it, no pressure
<guso78>
dxf_dim dxf_cross render child children intersection_for dxf_linear_extrude dxf_rotate_extrude group color missing fontmetrics concat lookup search version version_num norm cross .... is my total number of missing functions. all others are done
<guso78>
wondering if they are actually the same nowadays
<J2375>
2012 Ü .. every union will be a group in the csg tree
<J2375>
lazy union allows to export overlapping objects but only in 3mf
<J2375>
as stl doesn't support multiple objects
J2375 has quit [Quit: Client closed]
J2375 has joined #openscad
teepee_ has joined #openscad
<peepsalot>
<J2375> 2012 Ü .. every union will be a group in the csg tree
<peepsalot>
no. unions do not get converted to groups. a group is just... a grouping of geometries (which counts as an implicit union **unless** lazy-union is enabled)
<peepsalot>
control statements and user-defined modules become group nodes in csg tree. because CSG format means basically all expressions and control statements have been evaluated, loops unrolled, etc.
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
<guso78>
hi peepsalot !
<guso78>
i am about to issue 1st attempting pull request but i would prefer link in to an experimental branch in your side(maybe python ? )
<peepsalot>
<J2375> lazy union allows to export overlapping objects but only in 3mf
<peepsalot>
no. it should work in any format, unless things have changed since I last checked. stl doesn't need to "support" multiple objects, you can provide overlapping group of independent triangle meshes
<J2375>
peepsalot thanks for clarification
<peepsalot>
and most slicers are apparently able to process this no problem even when two closed surfaces overlap
Guest21 has joined #openscad
Guest21 has quit [Client Quit]
Guest2118 has joined #openscad
Guest2118 has quit [Client Quit]
<J2375>
from my experience stl interpreter try to get this right but from the format stl there are just a bunch of triangles and as soon you have coplanar triangles it can get messy
<peepsalot>
for example: if(true) { cube(2); sphere(1); } would become group() { cube(2); sphere(1); }
<guso78>
yes i can confirm, stl ist just triangles with 3 points each and one normal. nothing more. it has ascii and binary format though ....
<J2375>
peepsalot but even with lazy union that example will be just one object
<peepsalot>
it should be one triangle soup containing all the faces of the two geometries. no actual union would be performed if lazy-union is enabled
<J2375>
i was wrong .. strange
<peepsalot>
^^ (if exported to stl)
<guso78>
latest cura enginine can place objects overlapped on the heatbed. presume very much, it will print the "union"
<peepsalot>
lazy-union also allows for overlapping outlines in 2d export formats, which can be useful for laser cutting etc.
<peepsalot>
guso78: i don't know what you mean by "link in to an experimental branch in your side"
<J2375>
hmm so the if example is a group and become two objects exported but a user module with those is also a group (ast) but become one object exported
<peepsalot>
yeah user module is trickier to get right for reasons I can't recall at the moment. that's why lazy-union is still experimental, it is only partially implemented
<guso78>
peepsalot, in understand, that each pull request is handled in a separate git branch anyway, right ? so openscad is safe
<J2375>
in csg view the "if" group got removed with lazy union - while the user module is still a group
<guso78>
BTW enabling the Python stuff which a Feature Checkbox was an easy task
<peepsalot>
a pull request usually is a request to merge into the master branch. i suppose a separate branch could be set up in openscad's repo, which you could PR to. its rather unusual though (at least for openscad's typical workflow)
<guso78>
peepsalot, yes, but as the additions with python are rather distributed, i suggest to create an extra branch first in your side
<J2375>
peepsalot so i understand groups and unions are different - but when exporting or using them i can't find any difference is there any?
<guso78>
at least when the openscad code is parsed its different "Nodes" used for union and group
<guso78>
union is on of the CSG's whereas group is just a container
<peepsalot>
J2375: did you try actually exporting my example to STL? load that in eg meshlab, and position the camera inside the cube, you can still see the "outer" faces of the sphere. if it were a proper union, there would not be faces inside the cube like that.
<peepsalot>
if you are testing with lazy-union enabled/disabled from the same process, you will probably have to Flush Caches in between render/export steps
<J2375>
ah
<J2375>
made a group() and a union() (both with sphere and cube) and both become one object in 3mf export
<peepsalot>
J2375: preview this: `if(true) { cube(); sphere(); }` then look at the CSG Tree. the group is "optimized away". if you explicitly specify a group though, apparently that doesn't get removed from the tree
<peepsalot>
another good reason that group() isn't documented nor meant to be used directly by users
<guso78>
quite some dxf functions are there and not very visible documented for the same reason probably
<guso78>
great to see a python-support branch on your side.
<guso78>
was it just created now or already 9 hours back. did not see it before.
<teepee>
it's 8 minutes old :)
<teepee>
I don't think group() is meant to be used in scripts, I believe it's more an implementation detail leaking
<teepee>
there's 3 dxf function I can think of, things like dxf_import are deprecated for ages
<peepsalot>
J2375: so technically `group()` still performs an implicit union even when lazy-union is enabled. the underlying nodes which *would be* converted to group, are (in many but not all cases) basically omitted from CSG display and internally represented as a ListNode as opposed to GroupNode
<teepee>
no, wait, just 2? dxf_cross() and dxf_dim()
<J2375>
would be nice if group(ID) could be used to create a separate object.
<guso78>
I believe its more then these 2 dxf functions, there are also dxf_linear_extrude and dxf_rotate_extrude
<guso78>
compilation of my python thing works well lcoally but it will be some sort of challenge to get it working on the other OS's
<teepee>
Giordano
<teepee>
all those other dxf things are deprecated
<guso78>
Bruno is a first name here in austria, i was irritated.
J2375 has quit [Quit: Client closed]
<teepee>
yeah, I know that problem, my last name is a pretty common first name in US
J2375 has joined #openscad
<teepee>
our gbruno has it's day work as astronomer :)
<guso78>
teepee, does your nick relate to your name and where are you from ?
<teepee>
yes and no
<teepee>
it has nothing to do with the english word
<teepee>
I'm german and if you just speak it, it's my initials
<guso78>
ahh so its neither an indian's tent X-P
<J2375>
like Eminem ..
<teepee>
cool new world, Tweetbot developer posts status updates on Twitter API not working via Mastodon while the Twitter status page says "All Operational"
<J2375>
how does giordano becomes gbruno? .. where is the b and u from
<J2375>
Iordanus Brunus Nolanus; born Filippo Bruno .. so fbruno Ü
<teepee>
the one burned for staying with the heliocentric model
<J2375>
and the church needed only 400 years to acknowledge it was wrong
guso78 has quit [Ping timeout: 260 seconds]
<teepee>
indeed and current times have quite scary echoes of that behavior
<J2375>
every time i read about the delayed quantum eraser .. i came to the conclusion that time is an illusion and not existent in a higher dimension of space
califax has quit [Read error: Connection reset by peer]
califax has joined #openscad
<JordanBrown[m]>
I have a fondness for Giordano Bruno, since if you do some name translation... it's Jordan Brown.
J2375 has quit [Quit: Client closed]
J2375 has joined #openscad
tcurdt has quit [Ping timeout: 255 seconds]
Guest117 has joined #openscad
<peepsalot>
JordanBrown[m]: whoa, nice
Guest117 has quit [Client Quit]
guso78 has joined #openscad
<guso78>
i have just seen, the python branch is pass on 2 platforms already, i am impressed !
tcurdt has joined #openscad
<guso78>
hallo tcurdt
<teepee>
guso78: I agree with the comments JordanBrown[m] made on github, for keeping things tidy it would be useful to have the code separated
<teepee>
we probably need a compile time switch anyway so it's possible to build without the python interface
<teepee>
I don't think small files will make a huge difference in compilation time, but if that looks annoying, it's not a problem to group multiple nodes in one file
<guso78>
ok np.
<guso78>
i have put the python parser function into the same module because all the header files and node definitions were already present.
<teepee>
we don't have too many rules on that side, the much more critical discussions are more on the user visible side and that is not touched as such
<guso78>
shall i try to separte as jordon proposes, or does anybody else wants to do to "get it correct" ?
<teepee>
I understand, but now imagine a compile switch that disables building the python engine
<teepee>
now you have to stub out things in every single code file
<teepee>
if the files are separate, it's just a matter of giving a list of files that are either compiled or not
<teepee>
the input driver code does that in a simple way with just a couple of files for example
<guso78>
personally i prefer having the file pyopenscad.h, pyopenscad.cc, then maybe pyopenscadfunctions.cc . what do you think ?
<guso78>
i have once been there, but sadly amd closed the center in dresden. whats your contacts; name ?
<teepee>
see PM
<kintel>
right, so the OpenSCAD UI, operates on the string passed to output() and parses that as .scad?
<kintel>
Not to derail any activities, but I wonder if it would be feasible to layer this on top of a more general mechanism for calling into language preprocessors
<guso78>
Hi Marius! Nice to message you in person! My Main idea is to have python interpreter instead of the openscad yacc interpreter to set up the node tree. the final result of the python call is "injected in "MainWindow.cc" as result_node.
<kintel>
-> so many people have written OpenSCAD processors for python, ruby, javascript, coffeescript, C++ etc., if we had a common interface, that could open up this to a much wider audience
<guso78>
output gets a python variable. but effectively its the result node from all CSG operations
<teepee>
yeah, and I think this solution is much better than those generate scripts cases
<teepee>
it should even be possible to mix at some point
<kintel>
ah, so the output is really the .csg subset of OpenSCAD?
<guso78>
yes. you dont need to install a preprocessor and you and you dont need to handle 2 files. but isn't my IDEA really BOLD ?
<guso78>
marius: yes!
<guso78>
teepee, i dont know your contact name
<kintel>
..but still just plain text? ..or are you intending on building an in-memory AST?
<guso78>
kintel: the source file i propoese is python code. and its plain text. do you know python programming language ?
<kintel>
I was wondering about the interface back to OpenSCAD. Is it a plain-text .csg string, or is it some sort of data structure?
<guso78>
ahh i got it.
<guso78>
as i said. I managed to inejct back my result in MainWindow.cc. i cant recall the exact name of the variable. but i can look it up to you if you want
<guso78>
its a datastructure. its type it AbstactCsgNode
<InPhase>
guso78: How is security managed for this?
<guso78>
or AbstractNode
<guso78>
Inphase: you refer to "Sandboxing issue" ?
splud has quit [Ping timeout: 272 seconds]
<InPhase>
guso78: Yeah, as in keeping downloaded scripts from doing the bad things.
<guso78>
Every user which enables the PythonEngine feature needs to be aware of the security risks implied
<teepee>
yes, I think for starters we'll handle it like deno does network access. you have to flip a switch and then accept the implications
<InPhase>
We should generally assume they are not. It would require some notification.
<guso78>
i have never seen a Popup in openscad. does it exist?
<teepee>
popup?
<teepee>
usually we don't want extra dialogs but warnings show a banner in the viewport for example
<InPhase>
Also, enabling it has complicated implications. If a scad file can import a python file, then any complex scad library might have python code hidden deep within its dependency files which could do the bad things. It means that while it is turned on, every library requires a full security audit.
<guso78>
you do something in openscad. now where comes a new window which a message, which hides openscad and wants to tell you something really important
<kintel>
guso78: Thx, I see what you do now
<guso78>
can't we assumer, that pythonl libraries downloaded with "pip" e.g. are secure ?
<InPhase>
No.
<InPhase>
Not to the level of scad files.
<kintel>
guso78: I did a bunch of Python in the past; wrote an AI inference chip simulator in Python; was an interesting experience. Now I only use it for code that I intend to run myself :)
<InPhase>
scad gives a pretty strong guarantee. It's a domain specific language with no features that can do the bad things (intentionally, by design).
<guso78>
Kintel you are linked to microchips, too ? ...
<kintel>
I was, but I went back to software; HW companies tend to have ...interesting cultures
<guso78>
my main focus in photeon/dornbirn is to set up and maintain PDK's , and of course adopt DRC.LVS PVS/Calibre runsets
<InPhase>
One way to handle it is not to make it a global feature that can turn on/off, but a specific approval tied to every file or library. "Explanation of risks of python extension..." then "Approve this python file" / "Approve all python files in this run" / "Cancel run"
<InPhase>
And then have a window to manage existing approvals.
<guso78>
InPhase, this sounds like perfect, but i can't achieve this by myself. are you willing to help us out here ?
<InPhase>
Perhaps with a checkbox, defaulting to on, for "Always approve these python files in the future"
<kintel>
guso78: ..but you're not a full-stack developer unless your stack extends to transistors, or at least RTL ;)
<teepee>
:)
<InPhase>
For command-line it would require an additional "--enable-python" option that would have to be turned on for every comand-line run which requires it.
<guso78>
kintel: i can do frontend, backend, semi-custom, full custom. synthesizer .. i know a bit of everythign
<teepee>
I was surprised that Globalfoundries jumped on the Google Open Source PDK train lately
<guso78>
we are mainly using cadence software. doing many skill scripts to make the life of our designers easier
<InPhase>
guso78: Just make a record of these suggestions, or modifications of them, and at PR time make a note of those in the PR post, and request assistance with them in the PR.
<guso78>
inPhase. i believe i will remember
<InPhase>
Oh, I see you already have the working PR open.
<teepee>
I think a dedicated switch is a good first step, more detailed control would be extremely useful, maybe we'll get more people intrerested in helping on that part
<kintel>
Anyway, with my earlier comment on generic infrastructure, I was essentially wondering: If extending this to say JavaScript support, how can we make that relatively clean? i.e. can we decouple the interfaces so that they become more like "language plugins" ?
<InPhase>
teepee: I think the detailed control is almost mandatory before wide deployment. People will turn it on and forget it, and that undermines our security model.
<guso78>
Inphase: actually i insisted on having an exrtra branch on openscad side becuse i believe it will be big effort
<InPhase>
teepee: Although there might be other solutions that achieve the same objective.
<kintel>
-> I'm kind of expecting an inrush of comments to the tune of "why Python? Lang X is so much better for Y" etc. - having an idea how to structure that would be awesome , but no immediate blocker
<InPhase>
Python is the only sensible choice if we're doing anything of this type. I have your back on that part guso78. :)
<InPhase>
Except, of course, for the security issue.
<InPhase>
There are other sandboxed languages that could be safer, but they don't have anywhere close to the benefits you'd get from Python.
<InPhase>
numpy and related features are hugely important for complicated math.
<guso78>
kintel. i chose python because a) i like it more than javascript b) its more accessibble then javascvript IMHO c:) its more intuitive than javascript but its of course very subjective
<InPhase>
Also, Python interoperates with basically every file format in existence.
<InPhase>
OpenSCAD is closer to a data science problem than a website problem, and Python is THE data science language right now.
<kintel>
I get all the Python arguments, I tend to look at that as an implementation detail. In theory you could fit anything in there, and trying to think about it could help designing a good integration concept/API
<guso78>
kintel,. you are are free to integrate ANY additional language with openscad. i decide to come up with python
<kintel>
In terms of security, we can probably learn a lot from looking at existing user-facing software embedding Python.
<kintel>
..even considering the Jupyter model where there's a well-defined "front-end" and "back-end", separated by a process
<InPhase>
kintel: I think we have a bigger hazard to mitigate than most, because we're not doing plugins here, but sharing "models" that become executables.
<guso78>
kintel: do you have special referral software in mind ?
<InPhase>
kintel: In other words, there's a huge amount of sharing from untrusted sources.
<InPhase>
People might grab dozens of files per hour, and aren't going to review them or know how to review them. So they at least need to know if a hazard is sneaking in so they can pause and evaluate.
<guso78>
i believe it will be very easy to use the python-openscad in jupyter. we also use juptyter in our company
<InPhase>
guso78: Jupyter will be tricky because we have nothing appropriately structured for a repl.
<InPhase>
guso78: You cannot define variables, functions, and modules, produce a figure, and then use those variables, functions, and modules in the next cell.
<InPhase>
State will be lost.
<guso78>
i never setup something for jupyter, but jupyter "log" looks very impressive
<kintel>
I haven't researched python app scripting, but I know TouchDesigner is gaining a lot of traction, and has a similar model: Distribute a sketch and run it
<kintel>
..but without looking I kind of assume that the security model is based around curated, included libraries
<guso78>
i understand: openscad will need to become a background process interacting to jupyter frontend
<kintel>
pip install in general is very challenging, as you'd need a pull Python dev env, with compiler support, AFAIU?
<kintel>
..unless you're lucky and get to download prebuilt wheels for your platform
<guso78>
pip has always worked for me, but i always requested common things found int he internet
<guso78>
right now my basic concern is
<guso78>
how can openscad with python libraries compile in all platforms ...
<InPhase>
guso78: Windows is the only tricky one.
<guso78>
it compiles in MacOS already interestingly
<guso78>
InPhase, i realized! But theere exist Python for windows, and its very popular!
<InPhase>
Yes. We just can't rely on the system helping. It would need to basically be fully embedded.
<guso78>
we can find out, if "python for windows" also has libries to link to ...
<InPhase>
I firmly believe all serious (non-embedded) systems should come with Python pre-installed as a cross-platform baseline. But, Microsoft does not believe this. They are the only platform keeping this from being such a baseline.
<guso78>
M$ ??? ::)
<kintel>
guso78 Keep in mind that "compiling" and "packaging" are different beasts. In the CI, we install a bunch of custom stuff which users may not have available. To package for distribution we need to be careful to choose good versions of stuff that's available on the supported versions of target platforms. macOS may be the most tricky on to pull off there.
<kintel>
..but for Python itself, we can require people to install it, in the same way we require people to install OpenGL drivers?
<guso78>
kintel i am aware that packaging is most tricky! Interesting fact is that MacOS did compile alreay my branch ....( in included in 2 of the 5 OS's)
<kintel>
yeah, Apple ships python3 libs now :)
<kintel>
..but they're shipped as /Library/Frameworks/Python.framework/Versions/3.11/lib/libpython3.11.dylib
<kintel>
..meaning it may break once Python 3.12 becomes the default. <- that's the sort of challenges that takes time to sort out
<guso78>
was developping software for apple before and it was always a hazzle when new OS's came out haha
<guso78>
BTW I also own the Book "Programming with OPENSCAD - A Beginner's guide to coding 3d-printable objects"