I think user1234 is concerned about shifting cosmetic geometry or the fact that it doesn't rotate in step with the view.
My concern is about being able to flip through auxiliary views to show true lengths or true shapes of geometric elements.
It is about using an intermediate coordinate system to bind all geometry that has to rotate with the view and use the existing coordinate system for elements like annotations that do not need to rotate. Neither should be visible by default, but there are special cases where it might be useful to display a representation of local or global axes (just a wee portion starting at the origin).
wandererfan wrote: ↑Thu Jan 19, 2023 7:05 pm
- 2d cosmetic geometry is specified in the coordinates used to draw the View (X horizontal, Y vertical). If any aspect of the View changes (ex direction, rotation, scale), the cosmetic coordinates are not changed to match. Drawing coordinates are of limited usefulness to the user.
- 3d cosmetic geometry does not respect rotation (or scale?) and is converted to 2d geometry that is only accurate at creation time.
This is how it seems to be done now.
If cosmetic geometry doesn't rotate with the whole view it is worthless as the current view origin and the current view axes. The goal should be to bind all of them to an element of 2D geometry that rotates in step with the projected image of the model.
In my imagination this is represented by two axes of a coordinate system and I would call it a LCS.
wandererfan wrote: ↑Thu Jan 19, 2023 7:05 pm
- the orientation of derived views (ex sections) are specified in terms of global XYZ. It would be more convenient to describe them in terms of the parent view.
I'm not sure but I tend to say that the orientation and the placement as well should be "specified in terms of global XYZ". But their vectors should be extracted from measured values such as angle and offset of the parent view's geometry.
If angles and offsets are measured against a LCS (as described above) it wouldn't matter how the view is rotated.
wandererfan wrote: ↑Thu Jan 19, 2023 7:05 pm
- the existing view centerlines (aligned to the drawing coordinates) are not useful. At the least, they should reflect rotation and scale used.
Yes. If they'd reflect rotation they could help to align with the parent view if desired.
wandererfan wrote: ↑Thu Jan 19, 2023 7:05 pm
- it is desirable to show the alignment of the global axes on a view.
Yes, if you design aviation or automotive parts you need to check the position and alignment of the part against the global coordinate system of the aircraft/carriage which has to be included in the document (usually the GCS of the document). Its offset can be large and so you would show it, check it, and hide it immediately afterwards, because it enlarges the view massively.
You could check if a view lies parallel to a grid plane by looking at the representation of the GCS: If more than 2 axes are visible the view is not parallel. OK, this can be done by looking at the vector and rotation angle, too.
wandererfan wrote: ↑Thu Jan 19, 2023 7:05 pm
- there is a need to measure angles that can't be done easily now. I'm not sure if solving the above points would resolve this or not.
As above, sometimes it is useful to check angles and offsets against coordinate systems. It might be required to be documented on the drawing. The view coordinate system is worthless in such a case.
If you have a LCS "specified in terms of global XYZ" of which the XY plane is displayed in the view you can draw a section line and measure its start and end point against the LCS's X and Y axes. Their coordinates can be transferred back into 3D space by a "little bit" of vector math or directly via a suitable corresponding 3D element like a PartDesign plane or a PartDesign CoordinateSystem. An edge created from the 3D points in connection with the supporting element could be used to extrude a section plane.
In my imagination an intermediate coordinate system would help to resolve measuring issues.
wandererfan wrote: ↑Thu Jan 19, 2023 7:05 pm
- the is a problem with centre of the View being (0, 0) instead of (x1, y1) (?). Maybe this is just having the location of the source object available in order to ??????
The view center has X and Y offsets from the page coordinate system (controlled by the user) and a LCS would have X and Y offsets from the view coordinate system (computed automatically so that the center of the view and the center of the bounding box of the model's projection are identical). If the view has to be rotated it would be around the center of the view. The LCS (including all bound geometry elements) would follow since it is attached to the view.
I tried to describe a way how a workflow to derive auxiliary views (and similar for sections) could look like and I am quite convinced that an element like a LCS or similar is the key to create the needed funktion. (And provide a support for auxiliary geometry instead of only cosmetic)