Open hannobraun opened 2 years ago
Lots has changed since I opened this issue, and I'd like to update it. This remains a desired feature, and since we're probably not too far off from being able to sketch on surfaces (we already have a very clunky precursor to that functionality), it's also becoming more relevant.
I won't be tackling this for the time being, but in case anyone else wants to, here are some notes on how I would approach it:
algorithms::transform
, for legacy reasons. At some point, all transform code should be living in operations::transform
.operations::transform
as a 2D-only module, then subsume the 3D stuff afterwards.fj-math
as required.Hope that helps anyone who might be interested!
A note to anyone interested in tackling this, any work on this issue is likely going to collide with work on https://github.com/hannobraun/fornjot/issues/2116 and https://github.com/hannobraun/fornjot/issues/2118, which I'm planning to tackle soon. If anybody's interested, then feel free to tackle this. Just be aware, things are going to be in flux shortly, and there might be extra effort involved in doing this now, versus waiting until the dust has settled.
As always, please make sure to package any work into small and self-contained pull requests, to minimize the likelihood of merge conflicts with other ongoing work.
Fornjot supports both 2D and 3D shapes (sketches and solids). While the kernel is more nuanced about this, from the perspective of the CAD model, all those objects live in 3D space and can be transformed using 3D transforms.
It would be nice to add a bit of type safety, and only allow sketches to be transformed in 2D space, using 2D transforms. That would prevent unintended and possibly confusing mistakes, and also remove any ambiguity about what should happen, if a 3D-transformed sketch is to be exported to an external 2D-only file format.
I am not sure, if it should be possible to transform sketches in 3D space at all. I think this is definitely not needed right now, as the only use case I can think of is to prepare for a sweep operation. But the user could just as well sweep first, then 3D-transform the resulting 3D shape. Maybe there is a use case for 3D-transforming 2D objects once we support building shapes from b-rep primitives (which is currently a wishlist item).