<kintel>
Scopeuk Yeah, definitely, manifold makes previews a lot less necessary. ..except things like minkowski with a concave operand, so we're not quite there yet
<kintel>
My thoughts are generally that once geometry evaluation is fast enough, the next natural step would be to bring geometry evaluation and language evaluation closer together. i.e. geometry as first-class objects. But let's first get a new release out to buy ourselves some time for the next steps :)
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
TheCoffeMaker has quit [Quit: So long and thanks for all the fish]
TheCoffeMaker has joined #openscad
kintel has joined #openscad
califax has quit [Remote host closed the connection]
califax has joined #openscad
little_blossom has quit [Ping timeout: 248 seconds]
<gbruno>
[github] t-paul pushed 18 modifications (Allow setting export parameters via command line parameter -O. The parameter -O can be given multiple times to set values, reusing the parameter structure used for settings (section/key=value). Examples: * export-3mf/color=#ffff00 * export-3mf/color-mode=selected-only * export-pdf/page-size=A3) https://github.com/openscad/openscad/commit/7ccda4f522d513d6e473ce923c135f319dd8d5fe
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Guest62 has joined #openscad
Guest62 has quit [Client Quit]
hyperair has joined #openscad
mmu_man has joined #openscad
hyperair has quit [Ping timeout: 252 seconds]
mmu_man has quit [Ping timeout: 252 seconds]
guso78k has joined #openscad
<guso78k>
InPhase, you chose the only example where direction is NOT obvous - all the cases where v2 is completely opposite to v1(eg v2=-1) and v1.v2 == -1. All the other cases are will defined when also stating to take the shorter angle of the 2 options. Aircrafts which fly from europe to new york also fly over alaska even though it appears not intuitive
<guso78k>
- but its the shortest way
<guso78k>
in any case, i am happy with my offset polyhedron until now. i will create separate objects for the edge and the corner objects and union them in the end. that way i can fix self-intersections at concave edges
<InPhase>
scrameta: If you catch kintel around here, he can advise on the nuances of macos dependency issues, as he's usually on top of those.
<InPhase>
I do remember that extrusion_for PR from way back, but I sort of forgot about it and lost track of the status of that one.
<InPhase>
scrameta: The version you're working with, have you tested both with and without lazy union enabled?
<InPhase>
scrameta: It seems lazy union still lives in a sea of small little issues, despite being a 10 year old idea.
<scrameta>
I'm not familiar with lazy union. I'll enable it and see.
<InPhase>
I think this involves the "extrude() for(...)" version versus "extrude_for(...)"
<scrameta>
I've only tried extrude() for(...) and extrude() { squares }.
<scrameta>
That seems to work with and without lazy union. Using its own union=False extension in for.
<scrameta>
Seems they try to do the same thing, so perhaps might clash...
<scrameta>
i.e. forward children to the parents through for
<InPhase>
I approved running of the tests on the PR.
<teepee>
some parts of lazy union are likely to live on. I think the ferature itself is broken and dead
<InPhase>
You should get a report on that within an hour. Although you can also run the testing suite locally for more direct interaction.
<scrameta>
I see, if I enable 'lazy union' then the arch example still works without 'union=False'
<InPhase>
I'd recommend adding a post summarizing your testing of the interaction with manifold and current lazy union features on and off, as that will help have the PR contextualized as to its current readiness.
<InPhase>
Oddly I don't actually spot any outstanding stop-gap issues lingering in the old PR. So I'm not sure what impeded its prior integration.
<teepee>
one important step would be test cases
<InPhase>
A good point, yes. :)
<teepee>
the core change is allowing 2d shapes in 3d space, which would allow other things too, so thats the main feature to look at
<InPhase>
scrameta: I guess that part somewhat raises the importance of figuring out how to locally run the testing suite. :) See ./doc/testing.txt for instructions
<teepee>
like it could then also enable simple hull of 2 2d-shapes in 3d space
<scrameta>
I'll check that testing doc... I added a PR comment regarding manifold/lazy union.
<InPhase>
scrameta: So this part is not necessarily a stopgap for integration, but we need to have comfort with whatever happens on it... The original post declares, "The shapes must be identical in
<InPhase>
outline count and vertex count, and may not cross the plane of the
<InPhase>
neighboring shape."
<InPhase>
Sorry, bad paste there.
<scrameta>
Yeah I saw that it checks that in the GeometryEvaluator.cc.
<InPhase>
Now this requirement is okay. In fact the requirement is verbatim the requirement of my ClosedPoints library which performs a similar task. (It's possible it was copied as a requirement.) And there is a good rationale for why that is a requirement. But once we integrate it as a built-in feature, we also need to know precisely what happens when a user violates this requirement. The program cannot
<InPhase>
crash, for example. And we should ideally have some sort of satisfactory outcome for violating this condition under all the conditions like manifold or not manifold.
<InPhase>
scrameta: We also need to test for the one other requirement that I happen to know such approaches typically have which is not stated there, which is winding order. Although this is mentioned as a possible issue with a discusison about mirror in that PR thread. It could be tested perhaps with an extrude over two polygons that go in different directions, or a sequence translate() square();
<InPhase>
mirror([1,0]) translate() square();
<InPhase>
Two possible approaches are to fix winding order in code if there's an issue, or to just document this as a requirement and pass the obligation along with the others, finding a way to explain the nuance of this carefully.
<scrameta>
That works, though is someone spinny. Mirroring about Z will instead will make it complain about the planes intersecting.
<InPhase>
Yeah. Maybe try that with circle instead of square to challenge it more.
<InPhase>
Also tests should go in both directions, to make sure there's not a handedness requirement. Like, difference() { extrude() { translate([0,0,2]) square(2); square(2); }; translate([1,1,1]) { square(2); translate([0,0,2]) square(2); } }
<InPhase>
That checks to see if things get inside out (and locks this down so no one in the future can accidentally make stuff go inside out without a test catching it.)
teepee_ has joined #openscad
<InPhase>
scrameta: I also think it will be important to check polygons with holes, like this: polygon([each [for (a=[0:360]) 10*[cos(a),sin(a)]], each [for (a=[0:360]) 5*[cos(a),sin(a)]]], [[for (i=[0:359]) i], [for (i=[360:719]) i]]);
<InPhase>
scrameta: A reason to use polygon manually to make a hole is that this allows taking that inner loop, and doing a second version where the inner path goes backwards, like [719:-1:360]
<InPhase>
scrameta: This is the sort of paranoid pathological testing that a feature this elaborate needs to make sure we really grasp and lock down its behavior.
teepee has quit [Ping timeout: 264 seconds]
teepee_ is now known as teepee
<scrameta>
The good news is that seems to work, backwards too and mixing/matching backwards. Anyway I've got to drop off now but will try add some tests later.
<InPhase>
Cool. Keep in touch with how it's going. :)
<InPhase>
The other good news is the PR broke nothing in the existing tests.
<InPhase>
It passed on all platforms.
scrameta has quit [Quit: Client closed]
<teepee>
I wonder if extrude is actually the correct name fot this
kintel has joined #openscad
<kintel>
scrameta To build on macOS, it should suffice to do ./scripts/macosx-build-homebrew.sh, followed by a regular cmake invocation.
<kintel>
Depending on the macOS version you're using, you may run into Qt issues. Qt6 is recommended for any recent macOS
<kintel>
..and of course if you're trying to build on a very old version of macOS, you're on your own as that's not tested; all build are done on macOS 14 and (occasionally) 15
<teepee>
kintel: it seems there's an issue with colors where it always bakes in the theme color directly into the polyset
<teepee>
otherwise I'm going to declare the export-dialog PR feature complete before it totally gets out of hand with more formats :-)
<kintel>
teepee Is this issue also in master, or just in your branch?
<teepee>
should be in master, I don't think I touched anything in that regard
<teepee>
like union one cube with and one without color, I'd expect one having -1 as color index
<teepee>
indicating "use color scheme"
<kintel>
gotcha, that does sound like a bug..
LordOfBikes has joined #openscad
<teepee>
otherwise I would need to take out that option in the 3mf export where it's supposed to give the option of overriding the theme color on export
<teepee>
ha! all checks are green again, whew
<teepee>
oops, 56 files changed
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
snaked has quit [Remote host closed the connection]
<teepee>
peek into the future (via mastodon): "My mom asked why I keep a gun in the kitchen. I told her it’s in case one of those Transformers turn up. She laughed. I laughed. The toaster laughed. I shot the toaster."
kintel has joined #openscad
<kintel>
teepee I guess the challenge of "-1 colors" is that, after a difference, there are two colors pulled from the color scheme; the front color and the back color
<kintel>
..so if we want the front color to be overridable, should the back color be as well?
<teepee>
I would expect that if the differenced object was colored, it's overwritten, if it was not, then it stays -1
<teepee>
not sure if that's possible though :)
<kintel>
right, but today we export with both front and back colors
<kintel>
..so if we want to keep that, we'd need -1 and -2, or some other concept to index into the color scheme
<kintel>
Of course, the question is of default back color is even desirable. It just happens to be the current solution, as we use it for rendering
<teepee>
right, export in the sense of display
<kintel>
"export to polyset" :)
<kintel>
I think I'd be ok to consider negative indexes indexes into the color scheme. Might take some careful work to implement though
<teepee>
benefit: file export could do same color scheme too
<teepee>
right now it's somewhere between behaving differently for no-color-at-all and colored
<teepee>
probably not the most critical use case
<kintel>
yup. We already have a similar issue with rendering: If you change the color scheme after rendering, the objects stay the same color as the previous selectinon
<kintel>
..until you re-render
<teepee>
right, same effect
<teepee>
talking colors, in 2d we have not much of a chance doing colors? I'm not sure how that would work at least
<kintel>
We should clean up 2D too, but that's deeper work
<teepee>
maybe I'll do an export svg dialog at some point, that would at least allow some minimal global influence on the export
<teepee>
but one step at a time... with the dialog stuff finially going green again, do you want to have a look?
TheCoffeMaker has quit [Quit: So long and thanks for all the fish]
<kintel>
One Q: "Use selected color as default": Is the intent to override the default front color with the selected color, and leave everything else as is? i.e. like a light-weight color scheme?
<kintel>
I wonder if we're better off removing that option for now, until the above discussion is resolve
<teepee>
yes, that's the reason for the question
<teepee>
I'll remove it then
<kintel>
I'm still chipping away at rendering; currently dealing with wireframe support for Manifold. Once I get to the color stuff I might look into this again
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]