<scrameta>
How can I request a review please? I added a PR which I now think is working well (5584). I posted on the mailing list but got no reply, I can try again but thought I'd try here first.
<J25k83>
scrameta this looks like "loft" extrude is the wrong term if the shape changes. And as long you need same vertex counts i can't see a real benefit (for me at least)
<scrameta>
You don't need the same vertex counts
<scrameta>
I can change it to loft_extrude or just loft?
<scrameta>
I added different vertex count support because otherwise its too restrictive
<scrameta>
For advanced users they can of course do everything manually with numbers and polyhedron but this adds a very easy way to do this kind of things for beginners/intermediate users.
<scrameta>
Reading on loft, looks like it's smoothed. I don't smooth for now, it's just straight lines between shapes. I've thought a few times that could be an option. e.g. find matching vertices (after interpolating) then find some kind of line that goes through them.
<J25k83>
that is cool it sure uses a new method of placing 2D in 3D space but a loft tool would be very usefull
<scrameta>
It feels intrusive to me that it modifies Polygon2d, wondering if it can work without that...
<J25k83>
without lazy union you can't input a loop of shapes
<J25k83>
but you could use this like a chain hull for some smoothing.
<scrameta>
It adds a back lazy using by patching 'union=False' onto for.
<scrameta>
-back + basic
<scrameta>
I wonder if that should be removed and just require lazy union to be enabled
<teepee>
not going to happen, lazy union needs to be fixed and reduced in scope
<teepee>
the current state is not working
<scrameta>
So perhaps best to leave 'union=false' on for and just improve it a bit.
<teepee>
basically I think we need to get the "return lists" part out of it and make non-experimental
<teepee>
the other stuff needs to be dropped
<scrameta>
Out of lazy union?
<teepee>
sort-of, basically making lazy union a 100% invisible feature
<teepee>
we should check with kintel what his view on that topic is, but I belive the original idea of lazy union is not working
<teepee>
but the internal returning of lists and delying operations is very useful
<teepee>
*delaying
<scrameta>
OK, so ... we have: rename to 'loft', remove 'union_false' thing from for, investigate if the core 2d/3d changes to Polygon2d are really needed, if not handle locally to 'loft', talk to kintel regarding 'lazy union lite' to pass lists through at least for, perhaps generally.
<teepee>
not skin()?
<scrameta>
+ perhaps some vertical smoothing option on the vertices
<teepee>
yep, it would be nice to not need unoion=false
<teepee>
heh, unonion :)
<scrameta>
Hmmm yeah skin seems more appropriate. I'm not familiar with either term to be honest so just googling here...
<teepee>
I think BOSL calls it that and to me it sound like a good fit, but I don't know official CAD wording
<kintel>
scrameta Ideally, I would propose that each of the new core features added are integrated into OpenSCAD as independent, composable features.
<kintel>
e.g. 2.5d polygons: Will it be possible to hull() two 2.5d polygons?
<kintel>
If we could add that feature specifically as an experimental feature, and bring it out of experimental mode once modules are upgraded to support it, that would be awesome. Otherwise, we may end up with this blocking the next release for a long time until someone has time to clean up
<kintel>
same for for() -> lists; can we then deprecate intersection_for() ?
<kintel>
In terms of name, skin() feels like a good name considering existing effort in this domain
<scrameta>
The original author said for (union=false) could replace intersection_for. Not sure what you mean on 2.5d polygon hull. Do you mean just that hull should also be modified to support polygons in its children as well as full 3d objects?
<kintel>
hull: Yeah, if 2.5 d polygons are allowed _somewhere_, they should be allowed everywhere it makes sense
<scrameta>
I see. Yeah consistency is important.
<kintel>
But it's unrealistic to land that in a single PR, so we should find a way to iterate
<scrameta>
Regarding blocking release, was thinking 'skin' would remain experimental for a while so could be merged without blocking. Though perhaps the experimental feature becomes '2.5 support' instead of 'skin' in particular.
<kintel>
The for stuff is annoying. Ideally for() should never union, but we might have locked ourselves in. I haven't thought about this in a long time though
<scrameta>
With lazy union on it just worked without that. Though I was told that lazy union goes a bit too far and runs into other complications.
<kintel>
Yeah, finding a way of sweeping most of this under an experimental feature would be good
<kintel>
Yeah, we never managed to solve lazy union in a backwards compatible fashion
<kintel>
It would be awesome if we, somehow, could re-scope lazy unions to only apply to for()
<kintel>
i.e. make for() return a list of objects, and let operators receiving a list of objects decide how to interpret them
<kintel>
..which may mean a breaking change for `intersection() for()`, but I think if that's the only breaking change, it might be ok
<teepee>
I think the last part is key, and that should work in other places too
cart_ has quit [Ping timeout: 260 seconds]
<kintel>
I can be tricky to get it right though
<kintel>
But: As an experimental feature, we can do union=false for now, and try to fix it while in experimental mode :)
<teepee>
it should be fine with a 2 level structure, a single list does not work
<teepee>
it needs to be a list of static slots defined by the AST and each one can have a list of meshes
<teepee>
so difference can handle the list of objects from the first slot and then difference the other ones
<kintel>
yeah, list as a separate node type, not a group
<kintel>
it does open for deep trees of lists, which is where we need to think
<kintel>
..and we need to think about what module Foo() for() {...} returns etc.
<kintel>
The old "modules return groups" decision wasn't the best : /
<kintel>
All is to say: The rabbit hole goes all the way down
<scrameta>
Yeah, looks like it's a bit of a can of worms. Keen to contribute but don't want to do a full rewrite :D
muesli has quit [Quit: NO CARRIER]
muesli has joined #openscad
<kintel>
heh, there's a reason nobody has managed to land this feature yet ;)
<kintel>
Anyway, I'd say try to aim for an experimental feature, and hide everything behind an experimental flag.
<kintel>
..and find a way of making it work without enabling lazy union
<scrameta>
Most of it is, but not all. So I'll try to clean that up.
<kintel>
Whatever is not experimental, we just need to review more carefully
<kintel>
Sometimes it's helpful to open a PR _only_ with cleanup/refactoring to make those parts faster to turn around
<scrameta>
I'll look over the code structure a bit and see what can be done to make for work without for(...union=false) and without full lazy union.
<scrameta>
Got to run now, dinnertime! Many thanks.
<kintel>
We're a lot more careful these days, as we're trying to count down towards a release, so I prefer minimal risk in the non-experimental code paths
<kintel>
InPhase You had some irc comments on https://github.com/openscad/openscad/pull/5603 - did things get resolved? Awesome if you could approve the PR if you think it makes sense. Trying to offload having to look into the details myself :(
<tja>
InPhase: feel free to ping on that
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<teepee>
I'm not sure it can happen, but it would look safer if it would still handle the delta == 0 case, looks like it did not do that before though
<InPhase>
kintel, tja: Yeah, looking back at it again, it looks good to me. Nothing stands out as a potential problem.
kintel has joined #openscad
scrameta has quit [Quit: Client closed]
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Abhishrestha has joined #openscad
<Abhishrestha>
I hope this message finds you well. My name is Abhishrestha Tiwari, and I am currently a third-year undergraduate student pursuing a degree in Information Technology.
<Abhishrestha>
I am new to the world of open source contributions and would love to start my journey by contributing to your organization. I have experience with C, C++, Javascript , and I am eager to apply and enhance my skills while learning from your team.
<Abhishrestha>
Could you kindly guide me on how to get started or suggest any beginner-friendly projects within your organization? Your advice would be invaluable to me.