<JordanBrown>
Sorry, been pretending to do real work.
<lf94>
no problem lol
<lf94>
lemme know
JordanBrown1 has joined #openscad
<JordanBrown1>
came up fine
<JordanBrown1>
survived that switch-away - switch-aways seem to be one of the things that kills it.
JordanBrown1 has quit [Read error: Connection reset by peer]
<JordanBrown>
Did not survive that switch-away.
<JordanBrown>
When I say "switch-away" I mean that I have my KVM switch switch the VGA connection to my work computer.
J23k61 has quit [Ping timeout: 248 seconds]
JordanBrown1 has joined #openscad
<JordanBrown>
Let's try the same, but putting it on the other monitor.
<JordanBrown1>
survived that time.
JordanBrown1 has quit [Client Quit]
kintel has joined #openscad
<kintel>
JordanBrown scanning some history: In terms of vector iterator vs. unordered_map value iterator, could you transform an unordered map iterator into a value iterator by doing smth. like this?
JordanBrown1 has joined #openscad
<JordanBrown>
something like what?
<kintel>
std::transform(map.begin(), map.end(), ...) and use [](auto pair){return pair.second;} as a unary op
<kintel>
I guess the challenge is that you need somewhere to write, so it's more of a transformation than an iterator wrapper
<JordanBrown>
Right, and if I copy the data then that's bad.
<JordanBrown>
We could define a general iterator class and then have VectorType and ObjectType supply subclasses of it.
<JordanBrown>
But I just bit it and got rid of the visitor and replaced it with a switch, in the two places it was used.
<JordanBrown>
It seems that the STL does not support the notion of generic collections with generic iterators.
<JordanBrown>
Another approach is to have each type supply a walker that walks across the values, and pass in a lambda function.
mmu_man_ has quit [Ping timeout: 255 seconds]
<JordanBrown>
It's fixed in my build for now. When we're closer to integration and getting code review maybe somebody will come up with a better answer.
<lf94>
How. do. we. solve. fillets. in. csg.
<lf94>
I'm tired of this problem
<lf94>
We need the greatest minds in here
<lf94>
to come together and unite
<lf94>
to defeat this demon
<kintel>
Writing custom classes like that gets really messy
<kintel>
Sounds like what you really want is a lazy iterator transformer
<JordanBrown>
fillets are easy if you're willing to set the radius to zero.
<kintel>
I feel like boost should have something like that..
<kintel>
JordanBrown heh, C++ iterators have very specific features, since C++ it supposed to be a zero-overhead language
<JordanBrown>
It looks like it's entirely possible, but might well be more than zero overhead.
<JordanBrown>
VectorType already has its own iterator; it's just not a subclass of a superclass that ObjectType could also have a subclass of.
<kintel>
yeah, but the vector iterator relied on the data being stored in a contiguous array
<JordanBrown>
no, it recurses into embedded vectors.
<JordanBrown>
but also it doesn't matter.
<kintel>
oh, in OpenSCAD. Yeah, that's one of the more messy areas :)
<JordanBrown>
the whole idea would be to be able to return an instance of a superclass that iterates across the object, however it does, and returns Value.
<kintel>
Anyway, I was thinking, to make a map iterator function similar to a vector iterator, try something in this direction:
<JordanBrown>
VectorType could do it one way, while ObjectType does it another way.
<kintel>
auto myrange = mymap | boost::adaptors::transformed([](const auto& value){return value.second;});
<kintel>
..then to lazily evaluate: for (const auto &val : myrange) {
<JordanBrown>
alas I have little idea what that really does :-)
<kintel>
myrange in this case would be a iterator range: I believe essentially a pair of iterators
<JordanBrown>
in particular, if it copies the data objects, that would be bad. (And would probably fail, because Value specifically prohibits copies.)
<kintel>
..and ideally, the data type of this would be the same as if you just built an iterator range from vector iterators
<kintel>
No matter how you turn this around, it's likely a bit tricky, and probably best prototyped as a minimal stand-alone example in godbolt or smth. :)
<JordanBrown>
Yep. Though maybe I am just naïve; it seems like it should only be six or eight lines to define the superclass and a dozen or so lines to implement in ObjectType.
<JordanBrown>
Especially since for our purposes it doesn't need to be generic, which might be the big obstacle that the STL faced.
<JordanBrown>
kintel: I would appreciate it if you would look over the features proposed and give any opinions you might have on them. The comment chain on PR#4478 is pretty long; I could come up with a summary if that would be better.
<kintel>
oh, that's a big one..
<kintel>
Are all those features coupled, or could the final PR be separated into multiple, stand-alone features?
<JordanBrown>
I think they are mostly separable, though as I noted in the PR commentary I wanted to play with them together because their use cases interact and their syntax might (and in some cases does) interact.
<JordanBrown>
Without walking through it to be sure, I think there are four mostly-separable features:
<JordanBrown>
* geometry values. You can say, for instance, {{ cube(); }} and that gives you a value that you can put into a variable, pass to a function, et cetera. Eventually you would probably add it to the model.
<JordanBrown>
one noteworthy thing there is that render(geometryvalue) yields an object/array structure that describes the resulting mesh - some metadata, and all of the points and faces.
<JordanBrown>
* object literals and object comprehensions. We've had objects (what Python would call dictionaries and some would call associative arrays) since I introduced the textmetrics and fontmetrics functions, but there has been no way for users to create them.
LordOfBikes has quit [Ping timeout: 258 seconds]
<JordanBrown>
* an object() function that creates objects, combines them, et cetera. Might not be necessary any more, since I came up with an object comprehension syntax.
<JordanBrown>
* module literals and references, akin to function literals and references, so that you can pass a "pointer" to a module to a function or another module, put it in an array, et cetera. Geometry values make this less interesting than it might be, because you can have a function that returns a
<JordanBrown>
geometry value.
<kintel>
gotcha. render function feels like a challenge, as it could now take forever just to evaluate the code, but I see the value.
<kintel>
..it does open the floodgates for crazy new stuff so it makes sense to take that slow
<JordanBrown>
yes, the render function can be slow (just as resize() is).
<JordanBrown>
and yes, it allows for all kinds of weirdness. Bending, for instance.
<JordanBrown>
Though of course it is easy to distort a legal polyhedron into an illegal one.
<JordanBrown>
I played with some examples that added noise into the locations of the points in an object and that stretched an object at its midpoint.
<JordanBrown>
But probably the dominant use would be "center this" and "what is the bounding box of this".
<JordanBrown>
The neat thing is that I can make self-describing train cars and then link them into a train like you see at lines 274-280.
LordOfBikes has joined #openscad
<JordanBrown>
Or self-describing track pieces and link them together, at 73-100. (They're broken into three segments so that the switches can link from one to another.)
<JordanBrown>
Going back to separability... strictly, render(g) could be split away and implemented after geometry values.
<JordanBrown>
(going back to real work for a while now)
<kintel>
JordanBrown Can you also do mygeom = cube();
<kintel>
..or is that what the {{ notation is for?
<kintel>
I guess this is where having separate module/function namespaces come back to haunt us..
<JordanBrown>
That's what the {{...}} notation is for. And yes, the reason you need it is because of separate module/function namespaces.
<JordanBrown>
Note that I use {{ cube(); }} as the canonical example, but you can put arbitrary OpenSCAD statements inside those double braces.
<JordanBrown>
Also because modules don't exactly return anything.
<JordanBrown>
Design detail: geometry values are CSG trees.
<kintel>
man, so many unfortunate decisions in the past : /
<kintel>
yeah I got that, that makes sense
<JordanBrown>
C'est la vie.
<JordanBrown>
One early draft pseudo-specification represented the CSG trees as object/array structures that you could inspect or, in theory, construct on your own.
snaked has joined #openscad
<JordanBrown>
The one or two people who reviewed it said that was too complicated for too little payoff.
<kintel>
would be cool though
<JordanBrown>
Cool, yes, but valuable?
<JordanBrown>
Though if you really want to, I think you can str(g).
snaked has quit [Remote host closed the connection]
paddymahoney has quit [Read error: Connection reset by peer]
snaked has joined #openscad
<kintel>
I've been wondering though, if it would be possible to merge the module/function namespaces
<kintel>
..and let modules return a geometry object
<JordanBrown>
I was disappointed to find that I couldn't just splice one CSG tree into another. Or maybe I couldn't do it twice. I had to clone the tree when splicing it in.
<JordanBrown>
There's some kind of object index that has to be unique.
<kintel>
a lot of that stuff is also old cruft which could be redesigned, but it takes time to sort out
<JordanBrown>
Merging the two namespaces is a compatibility break.
<JordanBrown>
Probably. Or if it isn't, it's a great opportunity for confusion.
<kintel>
yeah, I was mode thinking: Calling something without using the return value is by convention a module
<kintel>
everything else is a function
<kintel>
..so once you use a return value, you could force the module and function to share namespaces
<JordanBrown>
But today you can have both a cube module and a cube function.
<JordanBrown>
so which does x = cube(); get?
<kintel>
yeah. it has the potential to break existing libraries, as you'd at that point you're have to enforce uniqueness
<JordanBrown>
You could probably say that the function wins and be compatible, but at the expense of making it easy to get very confused.
<kintel>
This has been discussed so many times, and in the end the only solution is to clean break and let each .scad file define its own language version. ..which never got any traction
<kintel>
..it would just be so nice to deal with the namespace issue, as the resulting syntax challenges would be so much more manageable
<JordanBrown>
Indeed.
<JordanBrown>
One of the syntax challenges for both module references and geometry values is that it's easy to get syntax conflicts.
<JordanBrown>
f(a)(b)(c);
<JordanBrown>
can be either a module f with argument a, with child module-reference b with argument c
<JordanBrown>
or a function f with argument a, returning a function, calling that function with argument b, returning a function (or module), calling that function with argument c.
<JordanBrown>
Right now I "solve" that by not allowing a function call at the top level. You can still do one, by wrapping it in parentheses.
<JordanBrown>
But I'm not happy about it.
<JordanBrown>
oops, that last example should be that f(a)(b) returns a module reference; it can't return a function.
<JordanBrown>
Well, except that when you bring geometry values into the picture it *can* be a function that returns a geometry value.
<JordanBrown>
(Well, "should". Again, I disallowed that to solve the ambiguity.)
<JordanBrown>
One of the unresolved questions is how you add a geometry value to the model. Right now the preferred answer is that you can have a statement that is a slightly restricted expression, that returns a geometry value.
<kintel>
yeah, because it's essentially a "module instantiation"
<JordanBrown>
Well, sort of.
<JordanBrown>
It's not a module instantiation, in that nothing *runs*. It just splices the existing, already-created, CSG tree into the model.
<kintel>
=> _hidden_root_node.append(mygeom);
<JordanBrown>
You can say "g;" to add a geometry value from a simple variable, "a[i];" to add one from an array, "o.g;" to add one from an object, et cetera, and you can put parens around an arbitrary expression that returns a geometry value.
<JordanBrown>
Yeah, that's pretty much what it does.
<kintel>
having the csg tree as a first-class citizen + remove namespaces could really clean up a lot of stuff
<kintel>
..but yeah, it's openscad2 territory
<JordanBrown>
But it's *not* a module. If the original construction depended on $ variables, or had randomness, or did echos, that's all in the past and none of it matters when you add the geometry value to the model.
<JordanBrown>
If I was going to do an OpenSCAD2, I'd probably try really hard to adopt a general-purpose language, rather than reinventing a bunch of language wheels.
<JordanBrown>
There are two big problems with that: (a) it's got to be totally sandboxed, and (b) I really want the minimal program to be along the lines of "cube();", without needing any additional boilerplate.
<JordanBrown>
Obvious schemes based on existing languages require "add(cube())" or "cube().add()" or "return (cube())" or something like that.
<JordanBrown>
And bonus points if "cube(); sphere();" unions them, as today's OpenSCAD does.
<JordanBrown>
I think that's mostly do-able; as you say, the behavior would be that if a statement evaluates to a geometry value, the geometry value gets added to the model.
<JordanBrown>
But that alone is something that no conventional language that I know of can support.
<JordanBrown>
and some languages, like JavaScript, would be actively in trouble because assignments return the value assigned, so "x=cube();" would put a cube in x, but would also add it to the model.
<JordanBrown>
Anyhow, those considerations are why I'm not moving toward another language and why I'm willing to spend effort on this one.
<JordanBrown>
And language design is fun, even when it is reinventing wheels.
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<teepee>
and totally unrelated, in crazy specification news: The M3 Pro is a 37-billion transistor chip, which is 3 billion fewer than the M2 Pro.
<InPhase>
10 billion here, 10 billion there... and pretty soon we're talking about really large numbers of transistors.
L29Ah has quit [Ping timeout: 240 seconds]
L29Ah has joined #openscad
teepee_ has joined #openscad
teepee has quit [Ping timeout: 256 seconds]
teepee_ is now known as teepee
<teepee>
The M3 Max has almost 100 billion, so 10 billion almost is a rounding error ;-)
<JordanBrown1>
A one-transistor radio is much better than a crystal radio, and a two-transistor radio is better still. Imagine how good a 100 billion transistor radio would be.
<teepee>
I assume we need the extra transistors mostly for commercials and cookie banners
<dostoyevsky2>
What's the difference between openscad and opengl? doesn't opengl also allow you to create 3d object programmatically?
<teepee>
one is an application you run, the other a programming interface to graphics cards
qeed has quit [Quit: qeed]
qeed has joined #openscad
<JordanBrown>
and, if I understand it correctly (and I should note that I have only a very high-level view of OpenGL), OpenGL is fundamentally for display; it accepts 3D information and turns it into a 2D image. That's great when you want display and useless when you want a 3D model for, e.g., 3D printing.
<JordanBrown>
Anybody around who has worked on the customizer in the last couple of years? Looks like there's been a regression since 2021.01: arrays with zero or more than four entries no longer work at all.
<teepee>
it never worked correctly including on thingiverse
<teepee>
a text field with a separate parser is not a good idea
<JordanBrown>
In 2021.01 you can have x=[1,2,3,4,5] and it displays as a single text box with [1,2,3,4,5] in it, and more or less works.
<JordanBrown>
In the bleeding edge (and apparently for at least a year), x=[1,2,3,4,5] just doesn't appear at all.
<teepee>
yes and it totally breaks with strings for example
<JordanBrown>
I believe that, but if it worked for numbers and not for strings, the right fix is not to break it for numbers :-)
<teepee>
sure, if someone does it
<JordanBrown>
If someone does what? Fixes it for strings?
<JordanBrown>
But it seems that somebody broke it for numbers and didn't fix it for strings.
<teepee>
make it work without crashing mostly compatible with thingiverse I suppose
<teepee>
there is not going to be a 100% guarantie for the GUI part, ever#
L29Ah has left #openscad [#openscad]
<teepee>
I think it would be nice to have it back, but not as text field parser but as actual List GUI
ferdna_ has joined #openscad
<teepee>
with Thingiverse maybe coming back to live, it might be useful to compare the state of both customizers
<JordanBrown>
It removes support for editing vector parameters other than vectors of 1-4 numbers. This functionality was very buggy in a hard-to-fix way, not supported by MakerBot, and not very valuable, because it only presented a text editor widget where you could edit the raw openscad code for the variable
<JordanBrown>
e source code directly). This can be added back later, if someone can think of an editor component for arbitrary vectors that is both reliable and useful.
<JordanBrown>
(which is not hugely more useful than just editing th
<JordanBrown>
Ah well, maybe I'll look at that if I ever get #4478 integrated.
<teepee>
I still hope I'll find some time again too, but so far always something else crashes like now almost a month fighting with the mailing list
<teepee>
thankfully Michael does most of the work
jonasbits has quit [Quit: No Ping reply in 180 seconds.]
jonasbits has joined #openscad
JordanBrown1 has quit [Read error: Connection reset by peer]
<JordanBrown>
Ah, well, past time to pretend to do real work.
<teepee>
also mixing up things, Jenny is at Hackaday it seems not Make
<linext__>
nope, it's from make magazine issue87
<teepee>
looks like OpenSCAD formatting for an article is a huge challenge with the narrow columns :)
<teepee>
oh, 87, the website still shows 86
<linext__>
i'd send you the pdf but i only bought the paper copy
<teepee>
to table of contents for 87 yet
peeps[work] has quit [Quit: Leaving]
<teepee>
thanks, it's fine, I still have stuff to read in queue :)
<teepee>
always hoping for some quiet time that never comes
<linext__>
leave your books in the car and bring them to appointments where you have to wait
<linext__>
in the usa workers get two 15-min breaks and a 30-min break for lunch
<linext__>
i used to read in my car during the breaks
<teepee>
I mostly work from home, so I'm tempted to watch news at lunch break
<teepee>
hmm, digital subscription is more expensive than paper?
<teepee>
ah, maybe for archive access
<linext__>
yes
<linext__>
i was able to build an archive with some help
peepsalot has joined #openscad
L29Ah has joined #openscad
misterfish has joined #openscad
cart_ has quit [Ping timeout: 260 seconds]
<InPhase>
linext__: Looks like a textbook-level use-case there for OpenSCAD. :)
<InPhase>
"We make regular polygons with parametric side lengths."
<peepsalot>
except for the whole tiling thing
<peepsalot>
(all tiles getting unioned into a flat sheet)
<InPhase>
Well, you'd just need to epsilon them all out a notch. :)
guso78k has joined #openscad
<juri_>
ugh.
<juri_>
i was just ranting at someone about epsilon being evil. :)
<teepee>
aww, that poor letter
<InPhase>
How can something so small be evil? It's so cute and tiny.
<juri_>
because if it has a value, you're probably using it wrong.
<InPhase>
Well, the alternative is to find a way to express everything as platonic forms or something.
<InPhase>
But that's sure going to limit what can be expressed. :)
<juri_>
no, it's to track floating point error in your calculations as you're doing the math, then interpret that error correctly when getting answers from your algebra.
guso78k1 has joined #openscad
<juri_>
"correctly" is doing a lot of job in that sentence.
<juri_>
work, too.
<InPhase>
s/vertex/blurtex/
<juri_>
they're all blurtexes.
<InPhase>
Finite representation approximations at present.
<InPhase>
But you could in fact tuple everything into coordinates and an accompanying uncertainty value.
<InPhase>
Making use of that uncertainty value at the right time in the right way in all cases would have some challenges.
<InPhase>
teepee: lol. That trophy is awesome. :)
<guso78k1>
looks like a printer problem on 1st sight :')
<InPhase>
I have gotten that result a few times...
<InPhase>
Back before I added enough sturdy adhesive to all the stepper motor gears. Relying on set screws per the original design of my printer was certainly inadequate.
<InPhase>
Every once in a while at high speeds the whole XY plane would just shift from slippage.
<guso78k1>
big issue with the "cheap" printers is that they dont have an actual position feedback but have to rely on the steppers to make their step.
<InPhase>
That's pretty reliable as long as things are held in place.
<guso78k1>
no, if the piece does not stick to the heading bed anymore, it will constantly move and the 2nd floor would not look so nice
<InPhase>
The bed distance is the one place where it gets significant, because that's not relative within run, but a drift over long periods of time.
<InPhase>
Within run it's pretty robust.
<guso78k1>
i am quite sure that the shown trophy picture was made like this by intent. the 2nd floor did not have support and still did not fell down.
<InPhase>
But the z-axis is also the one axis most resistant to slippage in a classic FDM design.
<InPhase>
It's just a slow drift problem that it faces.
<InPhase>
guso78k1: Yeah. There are lots of makes of it on the printables page linked.
<InPhase>
guso78k1: Several people assembled the layers at slightly different offsets.
<JordanBrown>
For those who don't speak CSS, I think the gag is that if you don't get your CSS right nothing lines up.
<juri_>
for those who don't speak CSS, don't worry about it, you'll never win the trophy anyways.
Guest58 has quit [Quit: Client closed]
Guest31 has quit [Quit: Client closed]
<guso78k1>
https://imgpile.com/i/Gu4BFX this sphere is meshed with my own SDF mesher. in contrast to marching cubes, its does not follow X/Y/Z raster, but is completely amorph instead. still aiming to have 6 triangles in each point
<peepsalot>
anyone here using Cura slicer? i read that there is a support blocker where you should be able to omit supports from some areas of the build volume, but the icon/button seems to always be disabled. i just tried in latest 5.5.0
J23k54 has quit [Quit: Client closed]
J23k54 has joined #openscad
<peepsalot>
asked the same in #reprap, but not a lot of activity there at the moment
<guso78k1>
peeps you need to select your model for the support blocker to become active
<guso78k1>
if nothing is selected, support blocker is also grayed out in my place.
guso78k has quit [Quit: Client closed]
<peepsalot>
ah yeah i see now
<guso78k1>
support blocker is a per-object setting. there are many options, you can even print an stl like support only ;)
<guso78k1>
i think there is a youtube video explaining all the settings and their meaning/usage
<peepsalot>
trying to block a round hole with a square peg
<peepsalot>
is there adjustment of the blocker size or shape? seems really awkward to work with
<guso78k1>
sorry, i never really used them, I just shared my tiny knowledge '=D
<peepsalot>
i think i'm starting to get the hang of it, you can scale the blocker cubes at least, and doesn't seem to be a problem if the blocker shapes significantly overlap the actual model.
arebil has quit [Quit: arebil]
J23k54 has quit [Quit: Client closed]
J23k54 has joined #openscad
<guso78k1>
teepee, did you have some time to look into the nettle issue ?