Closed rjcarlson49 closed 5 months ago
This seems like it could go in walls.scad. Probably needs to be named hex_wall()
for consistency with the others.
A few minor things:
Does _is_in()
do something different from BOSL2 in_list()
? Assertions have some redundancy and you should always put assertions into an assignment statement, so write your stack of assertions as
dummy = assert() assert() assert() ... assert();
Otherwise assertions run after assignments and you get errors even though you thought you trapped bad input with the assertions. You might want to use all_positive()
.
For formatting the doc string, the arguments are one argument per line, so if the description of an argument is long you just have to still put it all on one line. Shape is described as "a path". Can it be a non-coplanar 3d path? Or must it be a 2d path? Could you make pathB and pathT with calls to rect()
?
We are not going to add usage texts to every module with "help" argument, so that feature will need to go.
This seems like it could go in walls.scad. Probably needs to be named hex_wall() for consistency with the others.
Got no problem with hex_wall.
Does _is_in() do something different from BOSL2 in_list()?
Probably. Search has annoying properties so I put in _is_in(). If in_list() is part of std BOSL2 I'll start using it.
Assertions have some redundancy and you should always put assertions into an assignment statement, so write your stack > of assertions as
dummy = assert() assert() assert() ... assert();
Noted, I did not realize that asserts could be juts concatenated.
For formatting the doc string, the arguments are one argument per line, so if the description of an argument is long you just have to still put it all on one line.
Noted
Shape is described as "a path". Can it be a non-coplanar 3d path? Or must it be a 2d path?
2D only I'm pretty sure.
Could you make pathB and pathT with calls to rect()?
Probably. I did not think through whether the TOP & BOTTOM solid faces are always rectangles.
I verified that _is_in() can be replaced with in_list() with no other changes, just a replace.
I reported the F5 render bug that appears here to openScad. I believe it's only a manifold issue. Adding convexity = 8 to the linear_extrude avoids the bug.
Did you list this in the wrong place? Note that if by "bug" you mean that some surfaces are missing in F5 preview when you examine the model, and this is fixed by convexity=8, then that's not a bug. That's just what happens when you don't give a large enough convexity value.
Do you have an updated version of the hex walls based on comments above?
No, not the wrong place, I was just letting you know so that you could update the code. Just change "linear_extrude(height = ht) {" to "linear_extrude(height = ht, convexity = 8) {" in the main module.
I was led to believe that it is a bug, but avoided by adding the argument. I don't much care about it since it does not affect F6 and I rarely use F5. you can view the scad "bug" here, https://github.com/openscad/openscad/issues/5010.
I'm not sure why you were lead to believe it is a bug. It's not a bug---it's just how preview works.
I have been using this and when I went to use the shape feature I realized there is a problem with how the bounds and center are calculated when it is not a rectangle. First thought is that the shape should first be centered on it's centroid, then bounds taken from that point.
replacing the two lines centers = (bound[0] + bounds[1]) / 2; and center = = (bound[0] + bounds[1]) / 2;
with
centers = centroid(shp); and center = centroid(shape);
seems to fix the problem.
Wonder if it would make sense to anchor the general polygon case as a linear extrusion. That would give different centering options.
That might well be. I haven't looked at the anchoring case for linear extrusions, so I couldn't guess at implications.
It anchors to the polygon, or up/down from its center (which can be defined as centroid, mean, or bounding box). The problem is that for arbitrary polygons, it's tough to produce a anchoring scheme that always produces a reasonable result. But your shape is in fact a linear extrusion of a polygon, right? (In the polygon case.)
This is in the latest PR. Ended up being quite a few changes, so check the docs. If you want to reproduce the old behavior set bevel_frame=1. (This was a hard coded parameter.)
Thanks. It’ll be a little while till I can look. I’m in Victoria Falls on a safari trip!
-Bob Tucson AZ
On May 18, 2024, at 05:40, adrianVmariano @.***> wrote:
This is in the latest PR. Ended up being quite a few changes, so check the docs. If you want to reproduce the old behavior set bevel_frame=1. (This was a hard coded parameter.)
— Reply to this email directly, view it on GitHub https://github.com/BelfrySCAD/BOSL2/issues/1381#issuecomment-2118623576, or unsubscribe https://github.com/notifications/unsubscribe-auth/ANJ3IKDG552LL7KIBT3MACTZC3ERJAVCNFSM6AAAAABDMXOAY2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMJYGYZDGNJXGY. You are receiving this because you authored the thread.
Proposal For my own library I've created hex_panel(), a module that produces a panel in any shape whose inkier is a honeycomb. I believe it would be a good addition to BOSL2. I've attached a full set of code here that is attachable and complies as best I can with BOSL2 norms. There is documentation and examples.
Background Since I started using OpenSCAD, I've liked using hexagonal structures for lightness and strength. And I think it often looks cool. I have gone through several iterations of my own code, but I was never really pleased with it. A few months ago someone posted an elegant little piece of code that imposed a honeycomb on any shape. I'm afraid I don't remember who posted it. It worked and I did not have the motivation to figure out how regions work, so I have just used it as it came to me.
There were various problems with that code, especially that it did not produce a panel with the expected dimensions. Because it used stroke, the width of the stroke was added to the shape. I began playing with it to produce something easier to use. This is the final result.
Features The main input is shape. Shape can be a 3D vector. Then you have a simple rectangular panel, that lies in the XY plane and z defines the thickness. The frame argument defines width of the solid outer frame of the panel.
Shape can also be a non crossing path that defines a polygon. Concave shapes are allowed. If shape is a path, the height of the panel must be given in the h argument.
Rectangular panels, i.e. shape is a 3D vector, can be beveled, always at 45 degrees. This makes it easy to combine panels cleanly into boxes or whatever. RIGHT, LEFT, FRONT and BACK represent the 4 possible edges. Add BOTTOM to an edge to make a reverse bevel. With some work, the bevel angle could be made an argument, but I don't see the usefulness.
I've started adding a 'help' feature to my library. When the first argument is "help", the module prints a synopsis and halts with an assert failure. If you don't care for that, delete it! I've found it to be a quick way to remind myself of argument lists.
Example Code
Rectangular panels with various bevel combinations.