Trying to get back to normal.
saso wrote: ↑Fri Aug 30, 2019 12:00 pm
as for distinguishing the planes from your example... what exactly do you mean?
I meant it in the sense asked for in the first post, or by RatonLaveur, ...
RatonLaveur wrote: ↑Tue Aug 20, 2019 3:31 pm
I never know which direction they are oriented until my sketch is mapped drawn and extruded.
... which is basically "what will happen if I use this DatumPlane". And, of course, I want to know
before doing anything else because it would be double work - which we may agree is not desired - if it has to be changed.
If I map a sketch containing a circle to each of the planes shown above and pad them I get:
- Snip macro screenshot-887199.png (5.9 KiB) Viewed 3820 times
- Snip macro screenshot-6bd92c.png (5.99 KiB) Viewed 3820 times
- Snip macro screenshot-79f0f0.png (6.16 KiB) Viewed 3820 times
Which are clearly different. It would have been easy to anticipate if the DatumPlane had shown locally something like the global View->Axis cross:
- Snip macro screenshot-3d3008.png (2.1 KiB) Viewed 3820 times
- Snip macro screenshot-440b21.png (2.25 KiB) Viewed 3820 times
- Snip macro screenshot-222fee.png (2.49 KiB) Viewed 3820 times
DeepSOIC wrote: ↑Fri Aug 30, 2019 1:35 pm
An alternative way of tackling the problem is to get rid of every case where plane origin is used. That is, change the default attachment mode of PartDesign Sketches to a new mode, that always projects the body origin to become sketch origin, and always reconstructs h/v axes directions, instead of inheriting those from the plane. I think that's a rather good way to go, too.
That's closer to the common mathematical definition of a plane. However, looking at the models I have seen here and my own, in most cases the center of the DatumPlane (i.e. (0,0,0) of its placement) has a special meaning in the attached sketch. So it would mean double work to attach the plane and afterwards to get that point again. In some cases it would be extremely difficult, e.g. with inertia AttachmentModes. So I would prefer DeepSOIC's first proposal as shown in the last three images here.