<JordanBrown[m]>
Difference apparently sees the cube(5) as its second argument. And that happens in both desktop and web OpenSCAD.
<InPhase>
I remember some discussion with peepsalot about that very issue a long time ago.
<InPhase>
I don't recall the conclusion of this discussion for lazy union. I just remember there was one.
J1A841096 has quit [Quit: Client closed]
J1A841096 has joined #openscad
<JordanBrown[m]>
Ah! I had been mystified by how that took out *both* ears, but, duh, the first one is positive, the second one is negative (but on the other side so doesn't do anything), and the third one is negative and takes out the first one.
<JordanBrown[m]>
So: linext: get rid of that --enable=lazy-union.
<linext>
maybe i'll add a checkbox like ofachik's demo does
<InPhase>
JordanBrown[m]: Ooooh, I didn't realize the lazy union would be related to the issue we were discussing above. I see the connection now.
<InPhase>
I thought I missed the part of what you were talking about. :)
<InPhase>
linext: And yeah, lazy-union is not ideal for general purpose use. It does some "incorrect" things like that compared to the standard language.
<InPhase>
It's not clear what the end stage will be of the lazy union efforts.
<InPhase>
But it's currently not something you can turn on, leave on, and forget is there. :)
<linext>
maybe there should be a function like mirror([,,,]) called reflect
<linext>
where reflect keeps the original and mirrors it over whichever axis is selected
<linext>
that's really what i was trying to do with i=[0:1:1] mirror([i,...])
<JordanBrown[m]>
linext no, there really shouldn't, because it's really easy to write your own.
<JordanBrown[m]>
InPhase I originally figured out that lazy-union was involved when I noticed that linext's openscad invocation was enabling a bunch of experimental stuff that I leave turned off in my desktop OpenSCAD. Everything was working ok until I turned that stuff on...
<linext>
hmmm...
<linext>
in that case, i'll make each customizer have it's own command-line arguments
<Friithian>
maybe we need a standard library of stuff like relfect
<JordanBrown[m]>
Friithian: Yes, my thought exactly. MCAD *is* a standard library, included with the distribution, but poorly promoted and maintained.
<linext>
i think mirror() is more intuitive
<InPhase>
JordanBrown[m]: Because it hits one set of needs in one style that matches a time long in the past.
<linext>
why bother reflecting something over the axis when you can just write it that way to begin with?
<JordanBrown[m]>
Sometimes it's easier that way. Also sometimes you can't control the original form.
<InPhase>
Most often when I mirror I am duplicating.
<JordanBrown[m]>
InPhase I wasn't trying to say why, only observing the apparently reality.
<JordanBrown[m]>
Yes, mirror-and-duplicate is most common for me too. (Which is why have mirrordup() in my library.)
<InPhase>
JordanBrown[m]: Yeah. I'm just expressing why I looked at it and went "meh" and struck out on my own. :)
<InPhase>
It's probably a common sentiment.
<InPhase>
Maybe a little Not Invented Here too.
<JordanBrown[m]>
The *huge* advantage of a standard library is that when we want to make incompatible changes, we can just shut down new development on MCAD, copy it to MCAD2, do new and incompatible development there, et cetera. The cost to keep around the old versions for compatibility is low, and people can more or less adopt at their own pace.
<InPhase>
Yeah. I think in general what we need is a library repository system, and a way to grab things.
<InPhase>
I've advocated in the past for the grabbing to be integrated, so that a scad file will simply say what to grab, complete with version-locked points if desired.
<InPhase>
And then some way to cache these grabs locally.
<InPhase>
And a tool integrated to browse and manage these grabbed libraries.
<JordanBrown[m]>
InPhase yeah, I generally resist adopting anybody else's OpenSCAD library. I can't rationally justify it. It's partly NIH, that I often enjoy figuring out the puzzle on my own, partly that the incremental cost to adopt a library always exceeds the incremental cost to solve this *one* problem my self, partly not wanting to drag in large dependencies, partly wanting not to have to worry about future incompatible changes, et cetera.
<InPhase>
Yeah.
<InPhase>
Locking would alleviate some of that. And automated grabbing would make it simpler to distribute. Some pretty decent fraction of the time I distribute a file that depends on a library, even if I put the dependency in the comments, people just "meh" and don't download it. :)
<JordanBrown[m]>
As for automatically dragging in libraries, a while back I was thinking about a "use <url>" scheme that I thought could be stupid on both the client and server sides, and achieve most of the goals.
<InPhase>
Yes.
<JordanBrown[m]>
I would have to reconstruct it.
<InPhase>
I've contemplated fancier versions that let us have custom python modules to manage certain download types, like git.
<InPhase>
People can then add in a github one, a gitlab one, a thingiverse one, a printables one, and so on.
<JordanBrown[m]>
The "not dragging in dependencies" part applies to OpenSCAD itself too... I wouldn't like dragging in Python.
<InPhase>
Python already exists on all target OS's except for the defective one.
<JordanBrown[m]>
But a URL-based one could *already* bring in github files.
<InPhase>
Correct, but less elegantly.
<InPhase>
You can only do it by ugly locked urls, and could not do "latest".
<JordanBrown[m]>
Besides, I don't trust Python for long-term compatibility.
<JordanBrown[m]>
InPhase traditional (pre-function-literal) OpenSCAD was almost immune to the classic middleware version problem, where application A wants library B1 and C1, and B1 wants C2, and so you try to have both C1 and C2 in the same process.
<JordanBrown[m]>
use<> isolates enough that it's hard for that to be a problem.
<JordanBrown[m]>
It can be a problem if A calls a function in C1 and gets back a value that A then passes to B1 which passes it to C2.
<JordanBrown[m]>
Function literals make that incrementally worse by making it more possible to export stuff out of a library and hand it to another library.
<JordanBrown[m]>
And of course there's the problem that at least some libraries (like BOSL2) have abandoned use<> because of its performance problems.
<InPhase>
JordanBrown[m]: If we hosted, we could go ahead and host a proper library system.
<JordanBrown[m]>
You would probably not want it to always go grab the file from the URL. You'd probably want it to prompt the user for confirmation the first time it saw a particular URL, and then store the file locally after that, perhaps occasionally looking for updates (and prompting for confirmation before grabbing those updates).
<JordanBrown[m]>
I'd say that hosting redirects is a different problem than hosting the whole library.
<InPhase>
JordanBrown[m]: But I was trying to solve the problem of accessing all the existing libraries out there, and the only way that has the necessary flexibility comes with something like Python extensions to manage it. (Which is why all the cool kids are using Python extensions these days.)
peepsalot has joined #openscad
<InPhase>
JordanBrown[m]: We could of course manually do a bunch of methods inside the code in C++, but site can change, and site arise more rapidly than our releases, so extensions are a very good way to manage it.
<JordanBrown[m]>
Oh, I understand the rationale. I just don't like the dependency implications.
<InPhase>
A proper hosted library system would solve it all if we had someone willing to develop it, and we diverted project funds to the cost, and we got community buy-in to upload to it.
<JordanBrown[m]>
Backing off a bit on my comments above, "confirmation" and "dumb client" don't play well together, because you would like a library to be able to be composed of multiple files and you wouldn't want to have to confirm each of them individually.
<InPhase>
JordanBrown[m]: Yeah, but probably there are interesting other features we could consider if we bought into the notion of that dependency. I haven't completed the thought, but there's a lot of stuff you could contemplate.
<JordanBrown[m]>
Oh, sure, like modules and functions written in a general-purpose language.
<JordanBrown[m]>
(Without it being C++ and all of the difficulty and baggage that brings in.)
Guest54 has joined #openscad
<InPhase>
JordanBrown[m]: One thing you don't want is arbitrary executed scad code. But extension libraries to the language in Python that required manual installation? Maybe I could be talked into that as well.
Guest54 has quit [Client Quit]
<InPhase>
I mean, you don't want arbitrary executed general purpose code in scad code.
<JordanBrown[m]>
that's what I thought you meant.
<JordanBrown[m]>
Yes, my thought exactly.
<JordanBrown[m]>
There should be a clear distinction between "documents" and "programs", and .scad files fall on the "documents" side of that equation.
<JordanBrown[m]>
But explicitly-installed "programs", yeah, OK.
<JordanBrown[m]>
Like, but not quite the same as, the difference in a web browser between visiting random web pages with their JavaScript, and installing add-ins.
<JordanBrown[m]>
After all, the user is already taking a leap of faith in installing and running OpenSCAD itself.
<linext>
not every user can do that
<linext>
android and iOS for example
<JordanBrown[m]>
Can do which?
<JordanBrown[m]>
install OpenSCAD?
<linext>
install and run OpenSCAD
<JordanBrown[m]>
Indeed. But that's a different class of problem.
<dalias>
if python were like lua and had no bindings to the host system, maybe
<JordanBrown[m]>
Server-side and browser OpenSCAD are interesting options in that area.
<dalias>
but hard nope to letting documents execute code with bindings to host system facilities
<JordanBrown[m]>
exactly.
<dalias>
(aside: someone should make a python implementation like lua in that regard)
<JordanBrown[m]>
But having explicitly-installed "add-ons" that have those privileges, maybe.
<dalias>
i guess you could even write it in lua :)
<dalias>
i still don't much like it
<dalias>
there's no good excuse for documents to have access to a language with that kind of system access and attack surface
<dalias>
only something computational (which should be properly isolated so that being purely computational is enforced)
<JordanBrown[m]>
People have tried. The problem is that all too often doing something interesting in Python requires some of those system facilities, and because of Python's ability for a program to look at itself, the program can find ways to get to the system facilities.
<dalias>
being able to look at itself doesn't automatically give you that
<JordanBrown[m]>
That is, people have tried to write Python sandboxes.
<JordanBrown[m]>
I'm not a Pythonista, but I did read up on the subject a bit.
<dalias>
*nod*
<dalias>
i think you'd have to stub-out/emulate a lot of stuff code assumes is available
<dalias>
i like the lua direction much better, where nothing of the sort exists by default and the embedding program has to provide whatever bindings, if any, it wants
<JordanBrown[m]>
The problem is something like that if you bring in a component that is in some fashion allowed to do an open(), even if you don't give the unprivileged program access to open() it can grovel and get access to the guts of the privileged component and get it anyway. Or something like that.
<JordanBrown[m]>
And yes, it's very sad that you can't do it with Python.
<JordanBrown[m]>
I'm surprised there hasn't been more interest in JavaScript for that kind of thing, since of course the #1 environment for JS is also one of the biggest attack targets on the planet.
<dalias>
right. that's why you don't give it access to open at all. if you need to you instead give it access to 'open' on a virtual filesystem implemented within the interpreter
<JordanBrown[m]>
There's node.js, but I think it's got the same problems that Python does... the gates are opened too far.
<dalias>
yep
<dalias>
node.js is basically just "full system bindings for js"
<JordanBrown[m]>
Without a browser attached :-)
<dalias>
yeah but there was already 'js without a browser attached' before node
<JordanBrown[m]>
But there are sandboxed JS implementations available.
<dalias>
there are even some good implementations of that
<dalias>
right
<dalias>
there's even one that's a really good *interpreted bytecode* jit, i think
<JordanBrown[m]>
I'm not completely sure, but I think that the one that FIrefox uses is available in library form.
<dalias>
(no sketchy self-modifying native code, just high-level transforms on the bytecode that runs in the interpreter)
<dalias>
yes. it and the one chrome uses are, and they're both awful
<JordanBrown[m]>
SpiderMonkey. But maybe that's an older one.
<dalias>
completely nonportable and full of vulns
<dalias>
you'd be crazy to use one out of browser because they need constant updates not to have gaping known vulns
<dalias>
especially the chome one
<dalias>
(v8)
<JordanBrown[m]>
I don't know enough to comment.
<dalias>
duktape is the simplest nice js implementation
<dalias>
small codebase purely interpreted
<dalias>
there are also some rust ones that look good
<JordanBrown[m]>
I think I would prefer a sandboxed Python, because at one point I decided that Python was a marginally better beginner language. Right now I can't remember why, though.
<JordanBrown[m]>
But my application there was an OpenSCAD replacement, putting CSG on top of a sandboxed general-purpose language.
<JordanBrown[m]>
I have tons of fun playing with how to implement new language features in OpenSCAD, but occasionally I remember that I'm reinventing wheels that were invented long ago, and were invented better.
<peepsalot>
JordanBrown[m], InPhase : for the difference/lazy-union issue, I honestly don't know anymore if that is intended behavior or not. as far as discussions, it reminded me of https://github.com/openscad/openscad/pull/3555 and some of the mailing list discussion from around that time
<peepsalot>
where it was basically determined that $children count had to be based on AST nodes
<peepsalot>
so it feels kind of wrong for difference to act that way, but idk
<peepsalot>
sorry haven't really caught up with conversation, just saw I was highlighted a while back
LordOfBikes has quit [Ping timeout: 260 seconds]
<InPhase>
dalias: What I'd be willing to consider is something like obj = python<my_installed_script.py>(some_string); but where the search path does not include the directory of the script itself.
<InPhase>
dalias: But I'm in no rush for that feature. I'm just saying it could be a side-benefit if we broke the python dependency wall and also used it for grabbing libraries.
LordOfBikes has joined #openscad
snakedGT is now known as snaked
ur5us has quit [Ping timeout: 252 seconds]
Lagopus has quit [Remote host closed the connection]
Lagopus has joined #openscad
Xeha has quit [Ping timeout: 272 seconds]
Xeha has joined #openscad
pa has quit [Ping timeout: 252 seconds]
J1A84109681 has quit [Quit: Client closed]
J1A84 has joined #openscad
fling has quit [Remote host closed the connection]
fling has joined #openscad
pah has joined #openscad
epony has quit [*.net *.split]
pie_ has quit [*.net *.split]
ndnihil has quit [*.net *.split]
muesli has quit [*.net *.split]
Ekho has quit [*.net *.split]
robert7 has quit [*.net *.split]
oldlaptop has quit [*.net *.split]
sinned6915 has quit [*.net *.split]
RichardP_ has quit [*.net *.split]
joseph_ has quit [*.net *.split]
RoyK has quit [*.net *.split]
Ckat has quit [*.net *.split]
InPhase has quit [*.net *.split]
lostapathy has quit [*.net *.split]
kanzure has quit [*.net *.split]
ndnihil has joined #openscad
kanzure has joined #openscad
robert7 has joined #openscad
sinned6915 has joined #openscad
ndnihil has quit [Changing host]
ndnihil has joined #openscad
RichardPotthoff has joined #openscad
lostapathy has joined #openscad
muesli has joined #openscad
Ckat has joined #openscad
pie_ has joined #openscad
oldlaptop has joined #openscad
joseph_ has joined #openscad
InPhase has joined #openscad
RoyK has joined #openscad
ur5us has joined #openscad
Ekho has joined #openscad
lastrodamo has joined #openscad
drfff has joined #openscad
drkow has quit [Ping timeout: 252 seconds]
teepee has quit [Ping timeout: 255 seconds]
teepee has joined #openscad
ur5us has quit [Ping timeout: 252 seconds]
aiyion1 has quit [Ping timeout: 255 seconds]
aiyion1 has joined #openscad
aiyion1 has quit [Remote host closed the connection]
aiyion1 has joined #openscad
castaway has joined #openscad
J1A84 has quit [Quit: Client closed]
J1A84 has joined #openscad
pah has quit [Ping timeout: 248 seconds]
teepee has quit [Remote host closed the connection]
teepee has joined #openscad
Junxter has joined #openscad
fling has quit [Remote host closed the connection]
fling has joined #openscad
J1A84 has quit [Quit: Client closed]
J1A84 has joined #openscad
epony has joined #openscad
cbmuser has quit [Read error: Connection reset by peer]
cbmuser has joined #openscad
J1A84 has quit [Quit: Client closed]
J1A84 has joined #openscad
drkow has joined #openscad
drfff has quit [Ping timeout: 252 seconds]
J1A84 has quit [Quit: Client closed]
J1A84 has joined #openscad
<J1A84>
Just testing PCTg .. very promising.. like PETg but tougher and more heat resistance
Guest13 has joined #openscad
Guest13 has quit [Client Quit]
<dalias>
does it have the same problems.. bad flow, stickiness, tendancy of nozzle to pick it up and drag it around, etc.?
<dalias>
i highly prefer PET (non-G) which doesn't have those problems and also has more heat resistance (comparable to ABS, and up to 100°C if you anneal it) and extreme layer adhesion (also a problem with PETG)
<Friithian>
how hard is PET to print compared to PETG?
<J1A84>
dalias can't confirm the issues you experience .. and don't have them with PCTg either
<dalias>
easy, even easier than pla, but must be (1) hot and (2) dry
<Friithian>
hot I can do, dry… well printing PVA is hell for me so
<dalias>
275 is about the min temp you can hope to print it, slow, ~285 is probably good for normal speeds. i run 320
<dalias>
it should be printed directly out of a drybox like nylon
<J1A84>
where do you get PET filament.. i know you can get PETT as T-glas
<dalias>
even freshly dried, quality will be diminished after a few hours into the print if it's open air
<dalias>
you can make your own from recycled bottles, but i get it commercially from fusion filaments
<dalias>
they call it "HTPET" to emphasize that you need high temp to print it (and that it's high hdt) but document that it's standard bottle PET
<Friithian>
ooof directly out of a drybox
<Friithian>
if only I could convince some boss to buy the ultimaker material station
<dalias>
i use cereal containers with molecular sieve desiccant (better than silica gel and similar price)
<dalias>
but fusion's spools are frustratingly large so i had to get difficult-to-find big ones to leave clearance for spool to rotate freely inside
<Friithian>
~problem is the ultimaker material station is $3.5k :D
<dalias>
:-p
<dalias>
my boxes were roughly $10 each plus maybe $1 in bearings and filament to make the stands inside
<dalias>
and maybe 50¢ each in desiccant
<Friithian>
the material station can hold 6 rolls of filament and can automatically switch between them
<Friithian>
but it isn't really priced for normal people to buy
<dalias>
ahh
<dalias>
so it's like an expensive commercial ERCF
<dalias>
the annex tradrack is coming soon hopefully, and will be affordable to normal people :)
<Friithian>
yeah
pah has joined #openscad
<JordanBrown[m]>
peepsalot InPhase it would be really hard to accept that difference behavior. It is simply incompatible.
J1A84 has quit [Quit: Client closed]
J1A84 has joined #openscad
Junxter has quit [Remote host closed the connection]
Junxter has joined #openscad
<InPhase>
JordanBrown[m]: Yes, that's a breaking change.
<InPhase>
JordanBrown[m]: It's actually a change people often want, but we cannot just go and change it. :)
<InPhase>
Object literals are the solution to wedge in that capability, rather than altering how difference works with for loops.
<JordanBrown[m]>
I could imagine a related change - in particular, so that for() would yield multiple children - but It's not possible to do that because you need to be able to calculate $children without actually executing the children.
<JordanBrown[m]>
But this appears to be visible only in difference(), which can't be right.
<peepsalot>
a specially crafted intersection would also do it
<JordanBrown[m]>
yes, I could see that intersection() for() would yield incorrect results.
<peepsalot>
union, obviously wouldn't care. because 1) lazy-union is specifically about unions and 2) union is associative
<JordanBrown[m]>
I suppose that maybe it could be an inline flag that the program would set, either globally or in a particular context, but right now I'd say that the behavior is just too weird even for that.
<JordanBrown[m]>
It could not be a global flag.
<peepsalot>
JordanBrown[m]: actually, now that I think of it, I'm pretty sure that one of the motivations or percieved benefits of lazy-union is that we would be able to deprecate intersection_for()
fling has quit [Remote host closed the connection]
<JordanBrown[m]>
Except that you can't do that by breaking the existing behavior.
fling has joined #openscad
<JordanBrown[m]>
I mean, if I get to break existing behavior, it would sure make some of the stuff I've been working on a lot easier!
<peepsalot>
basically I don't see how we'll ever be able to make lazy-union non-experimental
<JordanBrown[m]>
I don't know enough about it to say so definitely, but based on everything I've heard... yeah, either it's of marginal interest, or it can't be done. (Or somebody needs to figure out an opt-in mechanism for the program to use.)
teepee has quit [Ping timeout: 255 seconds]
<JordanBrown[m]>
There are lots of contexts that currently require an implicit union. If they don't get that implicit union, it's simply wrong.
teepee has joined #openscad
<JordanBrown[m]>
Perversely, union itself is one of the things that *doesn't* seem like it needs to do a union. If it's OK to not union things at the top level, it seems like it should be OK to not union them at lower levels too.
pah has quit [Ping timeout: 268 seconds]
<JordanBrown[m]>
But as I understand it, with lazy unions turned on, if you have two overlapping objects at the top level, you get a self-intersecting STL. I thought that was bad juju. It certainly seems worse than non-manifold designs.
pah has joined #openscad
<JordanBrown[m]>
I mean, for cube(10); cube(10, center=true); is the part in the intersection part of the model or not? It seems like reasonable slicers could disagree.
<J1A84>
it is two objects .. maybe stl is handling that wrong in 3mf this is fine .. you sure need to move one object for printing
<J1A84>
ah the stl is grouping them but there are still 2 objects
<JordanBrown[m]>
As far as I know, STL will just see them as 24 triangles.
<J1A84>
you can simply ungroup them .. but with a union around you can not
<JordanBrown[m]>
or maybe as 12 quadrilaterals, but I think we fully triangulate.
<J1A84>
now stl can handle multiple objects
<J1A84>
s/now/no
<JordanBrown[m]>
right, STL is almost-pure triangle soup. It's got orientation, but that's arguably more of a problem than a solution.
<peepsalot>
J1A84: STL is triangle soup, there are no individual objects. its up to the program reading the STL to determine if there are distinct closed surfaces and to count those as separate objects or not
<JordanBrown[m]>
... and if the consumer can't do that unambiguously, that's a problem.
<JordanBrown[m]>
Orientation is a problem because one consumer might use orientation to realize that these are two overlapping objects and treat it as a union, while another consumer might count boundary crossings and treat the center as a cavity.
<JordanBrown[m]>
Though without orientation it's still possible to figure out that it's overlapping, so maybe it doesn't really make the ambiguity any worse.
<J1A84>
hm there is a solid tag in stl .. however seems the programms do a good job .. tried two and both say it is a group
<JordanBrown[m]>
Anyhow, I'm not enough of a geometrician to really argue that end of it. I'm very concerned - like I said, this seems much more serious than merely having two objects share an edge - but I can't say anything authoritative.
<peepsalot>
J1A84: solid is more like a header/footer in ASCII STL iirc. it is only expected to appear once at the beginning and once at the end. STL is a very poorly conceived format
<JordanBrown[m]>
But the difference/intersection behavior, now, that's a clear semantic change. I haven't experimented enough to decide whether the lazy-union model is internally consistent. So far, my impression is "no", that I can't come up with a mental model that is end-to-end consistent for what it's doing.
<J1A84>
ok .. so it is mesh analysis by the software to determine there are more than one meshes
<peepsalot>
yep
<J1A84>
at least 3mf has multiple objects
<J1A84>
JordanBrown[m] i assume with lazy union there are triangles for each object, even if they share edges so the edges will exist twice in the file
teepee has quit [Ping timeout: 255 seconds]
teepee has joined #openscad
fling has quit [Remote host closed the connection]
fling has joined #openscad
<Friithian>
I wish I could change what format f7 outputs as
<Friithian>
I try to always use 3mf because multiple objects so it is mildly annoying to have to use the menu to export as 3mf
<J1A84>
ok to cubes at the same location will cause problems and software can't separate them anymore
<J1A84>
Friithian you can have a 3mf export button though
<JordanBrown[m]>
Will OpenSCAD itself import the result?
<J1A84>
JordanBrown[m] the two in one yes suprisingly it does and also renders (in union with another cube) without error .. but importing multiple objects in 3mf causes problems
<J1A84>
Friithian yes it is just a button but .. better than nothing Ü .. i adapt my workflow to the possibilities available so i export with a mouse click instead of several menu hopping
<Friithian>
tbh the workflow for openscad I dislike. I'd much rather use neovim to edit, a command line compiler and a seperate 3d object viewer
<Friithian>
but I'm also a weirdo
<J1A84>
i use the editor feature with alt+arrow but as this is not working smoothly anymore .. maybe i should switch to an external editor .. then i wouldn't have the problems with my keyboard layout anymore
<Friithian>
I do nearly all my text editing in neovim so anything else really messes with me
<J1A84>
but you can call openscad per command line to export
aiyion1 has quit [Remote host closed the connection]
aiyion1 has joined #openscad
<Friithian>
Ill eventually write a nvim macro for that
pah has quit [Ping timeout: 252 seconds]
pah has joined #openscad
<Scopeuk>
You can also edit in any other editor and set openscad to reload on save
<Scopeuk>
Whenever you save in the external editor openscad re-previews
<Scopeuk>
Command line and invoke external viewer from macro works though
<JordanBrown[m]>
I am always hesitant about syntactic changes, but historically that's because syntactic changes are subtle and Here There Be Dragons. The discussion of compatibility made me realize another reason to be careful with them: if you have a program that wants to run on both old and new versions, it can work around semantic changes (e.g. taking advantage of new functions, modules, arguments, et cetera) by checking version_num(). However,
<JordanBrown[m]>
a syntactic change - new syntax that is not legal in the old version - is not legal even inside a failing "if". A program cannot conditionally use new syntax; it will fail on an old version even if the affected section would never be executed.
<InPhase>
J1A84: I got intimately familiar with the binary stl format when writing that exporter. I can fit the entire specification in the margins here. It's 80 bytes of header which may be ignored by the loader. Then 4 bytes for an unsigned 32-bit integer of the triangle count. Then groups of 4 of x,y,z 32-bit IEEE-754 float words in little-endian order for which the first group is a normalization vector,
<InPhase>
and the next 3 groups are the coordinates for the triangle corners.
<InPhase>
There is no room in the specification for any other information unless you append it to the end and hope the loader actually listened to your triangle count, or smash it into that 80-byte header. Our header currently only says, "OpenSCAD Model\n" followed by a bunch of 0's.
Junxter has quit [Ping timeout: 260 seconds]
<J1A84>
yeah .. btw i read something about some color support in stls seems to be software specific
<InPhase>
The ascii version is basically the same but wordy with labels on each value and string floats.
<InPhase>
And if you tried to make any content other than a single string be in the 80-byte header for the binary format, you probably couldn't fit the same information into the ascii file without violating the standard and breaking some readers.
<InPhase>
Also the 2^32 limit on triangle count is awkwardly regressive, but not really an issue to date with current OpenSCAD performance limits.
<InPhase>
Hopefully we will move on from stl before this is a practical issue.
<J1A84>
the alternative would be slicer learn to read openscad Ü
qeed_ has quit [Remote host closed the connection]
<Friithian>
it'd be possible to write a cura plugin
teepee has quit [Read error: Connection reset by peer]
<Friithian>
iirc there's a plugin for blender files