wandererfan wrote: ↑Thu Aug 15, 2019 2:47 pm
Is the behaviour of the dimensions different between geometry lines and cosmetic lines?
I think the main difference are the new situations arising from the fact that you noticed: Two centerlines (or a centerline and a geometry line) can cross without having a vertex at the intersection. Other than that, I have not noticed any differences.
This is probably edge numbers changing between executions. I'll look at a way to remember the cosmetic line number since it changes less often than the geometry numbers.
Indeed. But please note that a) the 3D-model was not modified at all between the executions, and b) the zero-valued selected (green) angular dimension is still at its correct position, i.e. it seems to be connected to the correct centerlines. Usually, when the edge numbering changes when touching the 3D-model, both the values and positions of the dimensions get distorted. In this case, just the measured value is wrong, which seems odd. Could it be somehow related to the "flip lines" functionality, when adding the centerline? Is it possible that the line directions get somehow confused when re-calculating the angular value?
Also, regarding the "flip lines" functionality in the "Add centerline between lines" tool: If adding the centerline fails with the error message asking the user to flip the lines in order to (possibly) make the formation of centerline feasible, would it be possible to automatically invert the "flip lines" property after failure, and try adding the centerline again automatically. It'd be much more convenient for the user, because most times I add centerlines I have to first guess which way the "flip lines" property should be set. Most often, the two possible results for me have been 1) correct centerline, and 2) failure to add centerline. The far more rare case at least for me is the 1) correct centerline, and 2) weird centerline, for which manual intervention is indeed necessary. But it seems to me, that the more common case could be easily solved programmatically. It would also solve the problem where pressing "add centerline between lines" does nothing (except error message), which might be confusing for a novice user. Trying both options after failure in one would always give a visible centerline, which the user could later edit and fix. If nothing gets added, there's nothing to edit. I believe the reason why the centerlines (mostly) behave like that for me is the fact that most of the edges I add centerlines for are parallel to each other and of equal length, and I suspect that's quite a common case in practice (projected holes and shafts with perpendicular ends, mainly).
You should be able to get inner and outer angles moving the dimension text across the intersection point. I think all the test cases todate were for angles with a real vertex at the apex. Two crossing lines with out a vertex hasen't been considered before this .
You can get inner and outer angles by moving the dimension, but that's different from the opposite quadrant value. In my example the quadrant values are 60°, 120°, 60°, and 120°. Outer edge quadrant values (OE = 360° - IE) are much bigger, which are in my test case 300°, 240°, 300°, and 240°, respectively. So, there are actually 8 possible angle dimensions (outer edge OE and inner edge IE for every quadrant) for the crossing centerlines, of which I can produce angular dimensions to 4 cases. This can be done by selecting the centerlines in different order (2 choices), and by selecting inner or outer edges for the angular dimensions (also 2 choices). In order to cover all the choices, it should somehow be possible to select on which side of the intersection the arrows are drawn in the crossing centerlines case. Unfortunately, dragging the dimension on the other side of the apex is already reserved for the OE/IE selection, so some other selection mechanism would be needed. As you noted, this only seems to be needed for crossing lines, which was not possible earlier.
Thanks!
