<guso78k>
apparently it can be used to use something big whereas store it small. with an additional blanket it could be a picnic table ...
<guso78k>
whats the compression ratio ?
<dTal>
arbitrary, depending on how thin you are willing to make certain parts
<InPhase>
dTal: I would call that good abstracted workflow indicative of OpenSCAD experience. :) The shape is novel to me, and pretty, and the code looks clean and orderly and using the language features well. I would also say it's a pretty good example of recommended mindsets for how to break a problem like that down.
<dTal>
InPhase: oh you're seeing the final, tidied up version :) I have about 5 or 6 draft files where I tried all sorts of ideas, messily, and whenever it started to feel like the abstraction wasn't working for me I made a new file and rewrote
<dTal>
And then of course I tidied the code before pastebinning it because I want to look cool in front of the other nerds
<dTal>
but it's true that I don't think I could have done this using any other tool that I know how to use
<InPhase>
dTal: *chuckles* Naturally.
<InPhase>
dTal: The one flaw is the lack of following the overlap rule.
<dTal>
the overlap rule?
<InPhase>
dTal: On the implicit unions of the height 1 bars of z displacement 1.
<dTal>
there's a tiny bit of self-intersection at an extreme angle because I can't quite make the shape I want in openscad :)
<InPhase>
dTal: Solvable with height 1.001 bars.
<dTal>
Erm, no two adjacent bars should be unioned
<guso78k>
there should be an easy feature to evaulate existing openscad in another fashion : only showing the overlapping section(intrersection) to show where a mechanical part might jam ...
<dTal>
the entire thing can be assembled from a whole bunch of spiralize(){bar();}
<guso78k>
the idea is great. you are still missing the center holes to put in the screws for the rotation axis
<dTal>
yeah I did all the pegs and holes in the first draft but it turned out to be tedious busywork that didn't help solve the hard problems
<InPhase>
dTal: An example is coordinate [-3.7, -9.9, -0.73]
<dTal>
at what angle a?
<dTal>
you did turn on animation right? :)
<InPhase>
I changed nothing from your pastebin.
<InPhase>
I did not.
<dTal>
then I don't know what angle you're seeing
<dTal>
a = 65*((sin($t*360)+1)/2)+5;
<InPhase>
Well, for $t=0 then. :)
<InPhase>
The animation is very pretty. Perhaps submit this to the 2023 OpenSCAD calendar.
<InPhase>
But basically that's one of the lever arms that is joined away from the spirals. They look to me to not be following the overlap rule.
<guso78k>
InPhase i feel, that models designed for animation should immediately start to animate as soon as the code is pasted into the editor. special keywords which fill the animation fields could help.
<InPhase>
guso78k: That's desireable for certain models perhaps. Some can be computationally burdensome.
<InPhase>
guso78k: I see a lot of people complaining about how slow animation is for them on older hardware.
<InPhase>
This one does 30fps for me. I bet JordanBrown, lost to us when the Matrix Bridge went down, would get more like 4fps given some of our past comparisons.
<guso78k>
InPhase i see your point. still i believe that the animation fields should be filled and at the same time there should be a play/pause button. according to my understanding pause is only possible by clearing the values ....
<InPhase>
guso78k: I'd especially appreciate if recommended FPS and Steps values would autofill.
<dTal>
InPhase: if you comment out grid(); and put spiralize(){bar();} does the resulting piece obey the "overlap rule"?
<InPhase>
I habitually put these sorts of formulaic comments at the top of all my animation files: // View, Animate, FPS: 30, Steps: 300
<dTal>
I am not bothered if different components do or do not union, because putting them all in one file is just for visualization only
<guso78k>
InPhase, this would definitely be a cool feature and i am sure i could implement. but this would probably increase the PR average count by 1 XD
<dTal>
if you were to really assemble this, you would 3d print a whole bunch of spiralize(){bar();}
<InPhase>
dTal: Yeah, looks like it is compliant there.
<dTal>
new puzzler - how to attach something at the grid points so that its orientation is constant with respect to the grid
<InPhase>
dTal: And it's not a question of bothered. It happens to work here, but it's a question of undefined render behavior.
<dTal>
I'm never hitting F6 on this thing
<guso78k>
yeah, if you press F6 you give up the colors ...
<dTal>
"undefined render behavior" meh, it borks often enough even if you stick to "defined" behavior so if it renders I'm happy
<InPhase>
"It is mandatory for all unions, explicit or implicit, that external faces to be merged not be coincident. Failure to follow this rule ..."
<InPhase>
dTal: Yeah, one of the undefined behavior results is "nothing renders at all" ;)
<dTal>
o no call the openscad police
<dTal>
the rotate extrude algorithm in openscad is not very good
<dTal>
or, I should say, "twist" while linear extruding
<InPhase>
dTal: It does exactly what it says on the label, but this is often not the desired behavior for a spiral effect.
<InPhase>
dTal: Good spirals are built out of a different orientation of faces along a helical path.
<dTal>
I don't know about that. No reasonable mathematical definition of a twist while extruding leaves bigass triangles of wildly differing normals
<dTal>
if you boolean such shapes you often see a nasty jagged staircase
<InPhase>
dTal: Yes, the one it follows does, of z-axis planes of the input polygon rotated around the axis as z changes.
<guso78k>
general policy of OpenSCAD is to stay backward compatible at all cost. of course twist of linear_extrude can be "improved" if the new approach was "way better" and backward compatible
<dTal>
that's entirely an artifact of how openscad chooses to mesh it, which - as I say - is a poor algorithm
<dTal>
one consequence is that two twists which should intertwine without intersecting frequently do in fact intersect
<InPhase>
dTal: That's not a meshing decision, so much as where your input polygon pieces are placed before meshing is done. The problem is you don't want them z-oriented probably, but you used the z-oriented linear linear_extrude.
<InPhase>
dTal: I wrote this back in 2016 after I first encountered that linear_extrude twist issue and tried to reason out what was really going wrong with it for what I was trying to do: https://github.com/rcolyer/closepoints
<dTal>
perhaps we're talking at cross purposes. I'm not talking about face-oriented extrusion. I am talking about the big chunky triangles with discontinuous slope boundaries
<dTal>
visible, for instance, around the edges of any square extruded with a twist
<dTal>
the visible triangles are a consequence of a shape that poorly approximates the specification
<InPhase>
dTal: Yes, I'm telling you why that has happened is that it is the only possible solution given the input polygon orientation.
<dTal>
it is not the only possible solution
<InPhase>
I spent a good bit of time thinking about that before solving it with a whole different library and approach. :)
<InPhase>
But if you find another way, let us know please.
<dTal>
you could, for instance, represent the extrude+twist implicitly, and run marchin cubes on it
<dTal>
not saying that's a good fit for openscad
<guso78k>
dtal you mean that the extruded shape has a slight implicit up-tilt during extrusion ?
<dTal>
you could automatically remesh the 2d into a much higher res shape
<guso78k>
I feel that its a limitiation, that a "2D Shape" which is used for linear_extrude cannot have a z coordinate different than 0.
<dTal>
guso78k: when I need to position a 2d shape in 3-space, for example to do convex hull on it, I just linear_extrude a very small value with scale=0 - this only adds a single extra point
<dTal>
for convex hull it's functionally identical
<guso78k>
yep, scale=0 transform everything into singularity ;)
<guso78k>
but its a nice approach
<guso78k>
dTal actually it adds several extra points because OpenSCAD stores 3d Objects (aka PolySets) as Triangles which Points and each Point is 3 values in Space
<InPhase>
dTal: If you explore it, you'll find that breaking into more segments still doesn't give what you want. You can get a feel for it by replacing square for your twist with: polygon([[0,0],[0.25,0.01],[0.5,0],[0.75,0.01],[1,0],[0.99,0.25],[1,0.5],[0.99,0.75],[1,1],[0.75,0.99],[0.5,1],[0.25,0.99],[0,1],[0.01,0.75],[0,0.5],[0.01,0.25]]);
<guso78k>
I am working on an indexed version to fix that but its not yet clean
<InPhase>
dTal: Note the curves that arise on the side.
<InPhase>
dTal: Math is working against you, because it's starting with the wrong inputs for your mental impression of the target shape.
<dTal>
breaking into more segments indeed doesn't give what I want, but it does give something *different*, which is a red flag that we are not approaching any kind of accurate representation of anything
<dTal>
a mathematically pure operation would not care whether a square were made of four segments or four thousand (most of which are co-linear)
<dTal>
there *is* a shape that you "expect" when you do a twist extrude, and openscad is *bad* at giving it to you
<InPhase>
dTal: And I'll tell you the answer. It's the orientation plane of the element that you want preserved. In your mind you want to see a rectangular shape preserved along the path of the helical trajectory. Which is achievable by putting it in that orientation, like the ClosePoints approach can help you do.
<guso78k>
InPhase, its just a square with 12 extra points, right ?
<dTal>
not really, I can make pefectly smooth twisted extrusions in libfive, I'm not deluded
<InPhase>
guso78k: Basically, and with weird tiny offsets so that they don't get squashed back to a square again.
<dTal>
I mean yes, I do expect that a planar cross section of a twisted/extruded square be rectangular, and not some awful jagged shape
<dTal>
at minimum it should be convex.
<guso78k>
InPhase, the concept is as great as simple
<InPhase>
dTal: Well, you picked that behavior when you hardcoded $fn=24 at the top. Try instead linear_extrude(1,twist=-90,$fn=0,$fs=0.1,$fa=1)
<InPhase>
$fn=0 is only there to turn off your $fn=24 that clobbers all other settings.
<dTal>
you made the wonky triangles very thing
<dTal>
but they persist
<dTal>
*thin
<InPhase>
dTal: Yes, there will always be triangles.
<dTal>
The problem is that you cannot get arbitrarily close to the idealized shape by increasing resolution. You just make the discontinuities (that shouldn't be there) finer
<dTal>
everywhere else in openscad, increasing resolution yields a strict increase in accuracy (and what would be the point otherwise)
<dTal>
in many places, such as minkowski and hull, the algorithm will calculate whatever number of triangles it needs to to represent the shape
J23k has quit [Quit: Client closed]
J23k has joined #openscad
<dTal>
but for twist extrude, it just makes a copy of the shape at some z offset and wires up the corresponding vertices with a very simple - broken - algorithm
guso78k25 has joined #openscad
guso78k25 has quit [Ping timeout: 246 seconds]
guso78k has quit [Ping timeout: 246 seconds]
foul_owl has quit [*.net *.split]
snakedwork has joined #openscad
foul_owl has joined #openscad
<InPhase>
dTal: It IS completely accurate.
<InPhase>
dTal: It's not making up those curvy shapes, that's intrinsic to the geometry.
<dTal>
Not curvy. Jagged.
<InPhase>
dTal: Well if that's the only part you don't like, did you try the master branch?
<InPhase>
Well the triangle segmentation was altered. The core shape is unchanged.
<dTal>
I understand
<dTal>
<dTal> at minimum it should be convex. <-- I misspake here
<dTal>
spake? spoke
<dTal>
channeling jar jar sorry
<InPhase>
Spakified.
<dTal>
there is a really lovely shape that connects those cross pieces, I am sure of it
<dTal>
something that neatly dovetails
<dTal>
you need the diagonal to get the full 90 degrees of movement
<dTal>
if you only want 45 degrees you can use a much simpler construction
<InPhase>
Also if I'm remembering correctly, I think credit to peeps[work] for fixing up the triangulation on that. There were debates about best possible solution to user intent on that, given the z-planar specification that constrains available options.
<InPhase>
Probably half the time people do that, what they were really looking for would have been closer to a rotate_extrude that varies in z as it extrudes.
<InPhase>
Or maybe even more than half.
<peeps[work]>
huh, i could have sworn that made it into the latest release, but apparently not. seems so long ago now