<kintel>
peepsalot: It would also be cool to add a short description to each special .clang-format rule, just to capture the gist of why it's there, and whether it's intended to be temporary. No biggie, I'm just personally suffering from not writing enough stuff down ;)
<peepsalot>
kintel: you mean for the .clang-tidy checks which are omitted? the checks are all listed within one big string, so I don't think there is a way to have comments inline
<peepsalot>
but i suppose the list could be repeated in a comment before or after, with reasons included
<kintel>
oh, it's a big string. What an odd format..
<peepsalot>
yeah, I added newlines and indents for better readability. thankfully it is ok with that, but it does make it a pain to comment on each
la1yv has quit [Read error: Connection reset by peer]
la1yv has joined #openscad
Guest6927 has joined #openscad
Guest6927 has quit [Client Quit]
Sauvin has quit [Remote host closed the connection]
Sauvin has joined #openscad
Sauvin has quit [Remote host closed the connection]
Sauvin has joined #openscad
Sauvin has quit [Remote host closed the connection]
Sauvin has joined #openscad
Sauvin has quit [Remote host closed the connection]
epony has quit [Remote host closed the connection]
Sauvin has joined #openscad
Sauvin has quit [Remote host closed the connection]
Sauvin has joined #openscad
Sauvin has quit [Remote host closed the connection]
Sauvin has joined #openscad
Sauvin has joined #openscad
castaway has joined #openscad
califax has quit [Ping timeout: 255 seconds]
califax has joined #openscad
califax has quit [Remote host closed the connection]
califax has joined #openscad
<rapha>
InPhase: thanks for the explanation. Yes, teepee was correct: i wanted to remove enclosed holes. And then possibly scale the whole object up a little, but that's really easy.
<rapha>
Meanwhile also took a look at Blender but decided I don't have the time or the mind to get into that at the moment.
<rapha>
Perhaps my question created an XY problem.
<rapha>
What I have is: a little aluminum box with a closable see-through lid which is just a little bigger than my TinyWhoop. but it's too tall and I'm out of any sort of easily cuttable foam. So I want to take the STL for the quad's frame (https://www.thingiverse.com/thing:3457299) and take its outer shape, make that a little bigger, and subtract it from a solid cube. it'll be like an inset for the alu
<rapha>
box inside of which the quad can rest without banging around during transport.
<othx>
rapha linked to "frame Mobula 7 v12 light by max131274" on thingiverse => 1 IRC mentions
<rapha>
ohai bot
califax has quit [Ping timeout: 255 seconds]
califax has joined #openscad
<Scopeuk>
rapha I think I would be tempted to try modeling it that can probably be done with 4 cylinders and a square or 5 cylinders
<rapha>
true, would actually not be that difficult
<Scopeuk>
If they are big enough you might get away with just 4 cylinders (centered on each rotor cage and over sized)
<rapha>
only needs to be a rough match anyways
<InPhase>
rapha: Honestly I'd just make an inset out of cardboard instead. It will protect contents better than a printed box, and it's trivial to build a small cardboard box out of a larger cardboard box. Just measure and cut out the 6-element rectangular solid shape, fold it up, and tape it together.
<InPhase>
rapha: Also, crumpled paper and plastic grocery bags make good shipping padding.
teepee_ has joined #openscad
J2364459 is now known as J23
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
<rapha>
not intending to ship her!!! poor Hildegard, we're having so much fun flying together!!
<peepsalot>
oh wow, i was just looking at manifold library and they have a WASM app now too http://manifoldcad.org
<peepsalot>
looks like spheres default to subdivided octahedrons
<teepee>
yes, I think someone is working on a javascript api or so
rapha has quit [Quit: WeeChat 3.5]
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<InPhase>
peepsalot: Nice. I don't see any documentation of this javascript/typescript interface. But the capabilities of the library are looking intriguing as a potental CGAL swap-in.
<teepee>
especially if it does what the name implies which was a specific design goal
<InPhase>
I suppose we need to keep an eye on the readiness of this, and maintain some active contact with this Emmett Lalish. He seems to have precisely the OpenSCAD use case in mind for it. And it sounds like he has exactly the right educational and experience background for this task.
<InPhase>
He seems to have a mathematically strong background in his PhD with a 3D modeling career focus, but also a software engineering mindset so that the library is much more likely to retain a clean API.
<InPhase>
Although I wonder how he has done error handling, given the google aversion to exceptions.
L29Ah has left #openscad [#openscad]
<InPhase>
I should also note that his manifoldcad.org rendering quality is prettier than ours... Apparently his background in doing lighting has helped a bit. :)
<InPhase>
That Heart example with the warp function is excellent.
<peepsalot>
the rendering uses environment mapping. the three.js viewer might have some presets to just enable that easily
<peepsalot>
we could do that in shaders
<teepee>
ugh, yes, the shader stuff is also still pending in a PR
<InPhase>
I see he's also using a glb output format by default, which cura can in fact handle.
<InPhase>
Although it seems glb is more targetting display systems, as it includes textures and lighting. But it seems to have enough for 3D printing as well.
ToAruShiroiNeko has quit [Ping timeout: 264 seconds]
<JordanBrown[m]>
I've been thinking about a POV-Ray exporter, to let POV-Ray do the photorealistic stuff. Probably in conjunction with a general-purpose note() node that lets you annotate a subtree for use by later consumers.
<teepee>
which makes me say that annotations should be annotations not nodes :)
<JordanBrown[m]>
Eh, shrug. Yes, you could say that any node could have annotations, but that means that either you have to teach every node-creating primitive to accept annotations, or you end up littering pointless group() or union() nodes around just to carry the annotation. ISTM that it would be overall easier to have a node and corresponding primitive that has the sole purpose of saying "here are annotations for this subtree". For most
<JordanBrown[m]>
OpenSCAD purposes it would be the same as group() or union(), but exporters could consume the data.
<teepee>
I'm not saying it's impossible, I'm saying other languages have adopted actual annotations for a reason
rvt has quit [Ping timeout: 252 seconds]
<JordanBrown[m]>
just have npte() take arbitrary name=val pairs; what they mean is up to the consumer.
<JordanBrown[m]>
You mean the obscene decoration-style annotations, often introduced by punctuation?
<teepee>
it *is* decoration in that case
<teepee>
specifically it's meta data that is not part of the normal data structure but potentially used by external tools
<JordanBrown[m]>
Yeah, but they are always in some funky syntax that isn't really related to the language syntax.
<JordanBrown[m]>
Also note that they are usually annotation the *program*, where here we are annotating the program's *output*.
<teepee>
not always, it could also add data about the program, like libary component definitions and such
<JordanBrown[m]>
If we wanted, for instance, to have some kind of annotation on a function, it would have to not be tied to the CSG tree, because functions do not generate CSG nodes.
<JordanBrown[m]>
Still, that's information about the program.
<teepee>
a bit like Java has source code annotations and runtime annotations
<JordanBrown[m]>
I don't like the @. Other than that, shrug, yeah... note that the @Dxflayer() annotation described is structurally very similar to the note(dxf={layer: "layer1"}) that I would suggest.
ToAruShiroiNeko has joined #openscad
<teepee>
yes, of course it's similar
<JordanBrown[m]>
But I specifically would *not* make the "dxf" part or the "layer" part be keywords; I would make them be defined by the consumer so that adding a new jpg exporter would not introduce new keywords.
<teepee>
but it's not creating new branches in the AST, but adds to the nodes, like # or %
<JordanBrown[m]>
I just had to work with # and % for the geometry-value stuff. Nodes are cleaner :-)
<teepee>
and it introduces the main name directly instead of some node name + some predefined name attribute giving that
rvt has joined #openscad
<teepee>
maybe we can have nodes, but those only work for module invocations
<teepee>
annotations work for assignments everywhere
<teepee>
including function arguments
<JordanBrown[m]>
Indeed.
<JordanBrown[m]>
I'm not sure that they should be the same thing.
<JordanBrown[m]>
The stuff I'm thinking of is very much about annotating the CSG tree.
<teepee>
maybe those can be nodes, I'm not sure they have to
<teepee>
but for customizer we do need to annotate assignments if we want a similar logic to the current one
<teepee>
and that's something I'd like to have for years :)
<JordanBrown[m]>
Yes.
<JordanBrown[m]>
For the CSG annotations, it just seems cleaner if they are separate nodes. If they're merged into the primary nodes, that means either new syntax for CSG (which could, admittedly, just be the same as the OpenSCAD syntax), or have to live in the same namespace as the primary nodes' arguments.
<JordanBrown[m]>
Where if they are separate nodes, they can have their own namespace for arguments carried through all with the current syntax.
<teepee>
I don't think it's always clear. e.g. they impose a strict tree order which they don't really need to have if they are independent
<JordanBrown[m]>
If they are independent... of what?
<teepee>
also every place dealing with nodes now needs to know there are nodes that are different
<JordanBrown[m]>
But they aren't really different. You'd have to know that a note() node is like a group() node. Or maybe, since group() doesn't have much semantics of its own, a note() node *is* a group() node.
<JordanBrown[m]>
one node could carry any number of annotations for different consumers.
<teepee>
that is horrible, mixing random stuff into one node is really just a mess for any tool that is supposed to handle that data
<teepee>
while we probably want to keep it prety much restriction free, it's valuable to allow tools to do some linting
<teepee>
if you have a dedicated named annotation you can do that
<teepee>
a random mix of things makes it impossible
J23 has quit [Ping timeout: 260 seconds]
<JordanBrown[m]>
You could still have linting. You could have a metadata file that says that there's an "svg" annotation type with arguments "strokeWidth" and "strokeColor".
<JordanBrown[m]>
But it shouldn't take *any* core C++ changes to introduce a new SVG exporter option, or even a totally new exporter with its own options.
<JordanBrown[m]>
And certainly not parser.y or lexer.l changes.
<teepee>
that's not needed for either of those things
<JordanBrown[m]>
Sorry, I'm not sure what "that" and "those" bind to.
<teepee>
and I obviously agree to that :)
<teepee>
there's no annotation suggestion I would support that needs c++ changes other then the case if that annotation is actually evaluated in the core
<JordanBrown[m]>
If you have @Foo(...), then either (a) something in the parser, lexer, or C++ knows what Foo means, or (b) Foo is an arbitrary identifier meaningful only to the consumer.
<JordanBrown[m]>
The former is bad, and the latter seems equivalent to what I said.
<teepee>
why is that?
<JordanBrown[m]>
BTW, the consumer might not even be inside OpenSCAD. It might be something that consumes a text CSG file.
<teepee>
since when do we do c++ code changes when introducing new variable names in a script?
<JordanBrown[m]>
You seemed to be objecting to the notion that note()'s argument-names and the structure of the data value would be transparent to the infrastructure.
<JordanBrown[m]>
It seems like @Foo() is either transparent - and so has the same lintability questions - or is understood by the infrastructure and so has extensibility problems.
<JordanBrown[m]>
Have you had a chance to look at or think about the objects/geometry work?
teepee_ has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
<teepee>
on pure technical terms the linting might be identical, giving things an obvious name instead of having all named note() with arguments could still make a difference in actual use
<teepee>
like: you *can* write readable programs in Perl
<JordanBrown[m]>
i suppose that it's a matter of taste, but I think the style I suggested is more readable.
<teepee>
I started playing with the objects PR, what I want to do is put it against the OpenSCAD2 proposal and match ideas / features
<teepee>
I think Dougs proposal is very similar to the hybrid solution
<teepee>
the note() style still does not work for quite a number of use cases I'm interested in :P
<JordanBrown[m]>
I like that there's a layer of hierarchy, that once you reserve one word for a particular consumer it then has an unrestricted namespace, versus having all parameters for all consumers jammed into one namespace.
<teepee>
e.g. customizer and bom generation
<teepee>
hm? the @annotation does that even more obvious
<teepee>
as it's *only* having that name space as top level name
<JordanBrown[m]>
@Dxflayer jams the consumer (dxf) with the individual parameter (layer).
<teepee>
then maybe it should just be @Layer who knows
<teepee>
but that question is identical to the note() solution
<JordanBrown[m]>
Customizer, yes. A clear need for metadata. BOM, maybe, maybe not. Should BOM tags be tied to geometry?
<teepee>
there's just one more name that always is the same "note" and it not contributing any additional information
<teepee>
bom tags would be attached to the module *declaration* and bind values
<teepee>
the result would be attached to the generated geometry
<JordanBrown[m]>
That's true... it's got the same role as the @, but without needing to define new syntax.
<gbruno>
[github] thehans pushed 1 additions 19 modifications 4 removals (Merge pull request #4067 from thehans/malloc Use cmake for install and packaging with Windows. Also package tests with Windows .zip archives, with various fixes for running outside of build environment.) https://github.com/openscad/openscad/commit/0788d61376afa60bbf30c44258ab5d703a718787
<WeyounDax[m]>
my question? I'm trying to get the rod of the engine to move in line with the crankshaft (spinny bit closest to 0x, 0y
<WeyounDax[m]>
it seems that the timing is right, but the rod and crank intersect crossing past each other
<peepsalot>
<JordanBrown[m]> there's your lib3mf for msys2 ^^
<JordanBrown[m]>
I'm not seeing an intersection, though it looks like the pivot point between the two cubes isn't staying in the same place. Maybe that's just an illusion.
<JordanBrown[m]>
peepsalot cool!
<WeyounDax[m]>
JordanBrown[m]: yeah, I think that's what I mean
<JordanBrown[m]>
Hold a moment, let me look at the program.
<JordanBrown[m]>
I'm sure that others have done a lot more with this kind of mechanical design than I have, though I did simulate a complex hinge once with similar problems.
<JordanBrown[m]>
The way that I would approach it is to simulate the mechanism. I see that you're independently calculating the positions of each of the three components.
<JordanBrown[m]>
Instead, I would simulate the crankshaft first, finding where the pivot point is at the moment.
<WeyounDax[m]>
yep, that's what I thought I got wrong lol
<JordanBrown[m]>
That gives you one end of the rod. You know that the other end of the rod is constrained to the centerline, so you should be able to solve for the depth. (I'd have to draw it out to solve it; my trig is tolerable but not excellent.)
<JordanBrown[m]>
Once you know where the other end of the rod is, that tells you where the piston is.
<WeyounDax[m]>
alright, thank you.
<JordanBrown[m]>
Hope that made sense.
<WeyounDax[m]>
I had that in the back of my head
<JordanBrown[m]>
Ah, the "where is the other end of the rod" is not even trig. It's Pythagoras.
<JordanBrown[m]>
The rod is the hypotenuse of a triangle, and the distance from the centerline to the pivot point is one side of the triangle.
foul_owl has quit [Ping timeout: 252 seconds]
<JordanBrown[m]>
a² + b² = c²
<JordanBrown[m]>
so the other end (relative to the crank-rod pivot point) is sqrt((length of rod)^2 - (distance off center)^2)
<JordanBrown[m]>
Noting that the lengths are from one pivot point to the next, not the total length of the piece. When you do it with more detail, you'll want the pivot point not to be at the end.
<JordanBrown[m]>
But then you do need some trig to calculate how to rotate the cube. That's going to involve an atan2(), most likely
<JordanBrown[m]>
If you're curious, here's the hinge simulation: https://bpa.st/XINEY
<JordanBrown[m]>
I never got around to tuning it up so that the separation between the cabinet door and the wall was right.
<WeyounDax[m]>
eureka
<WeyounDax[m]>
thanks!
<JordanBrown[m]>
Sure.
<JordanBrown[m]>
Happy to help.
<JordanBrown[m]>
If you look at that hinge simulation, with five independently moving parts, you'll see that $t only controls one of them - the angle BAC - and that everything is derived from that.
<WeyounDax[m]>
oh okay
<peepsalot>
argh, why is the windows build broken this time
<JordanBrown[m]>
maybe somebody just pushed a change that broke it? :-)
<teepee>
peepsalot: it switched to lib3mf-v2 and triggered a bug in that code path?
<peepsalot>
and I made an inconsequential change today (removing a duplicate line from a cmake module). I think maybe something in the clang-tidy fixes ended up conflicting somehow