FC ArchAxis - bugs, concept and possible improvements

[doia]

Hey, after a deep dive into the Arch WB, specifically the ArchAxis element, I found some bugs and possible improvements I’d like to share and discuss.

First the current bugs. I am using

OS: macOS 10.16
Word size of FreeCAD: 64-bit
Version: 0.20.26720 (Git)
Build type: Release
Python version: 3.9.9
Qt version: 5.12.9
Coin version: 4.0.0
OCC version: 7.5.3
Locale: C/Default (C)

The bugs can be also reproduced with the latest v0.19.3 on a Mac M1 (macOS Monterey 12.1) as well as with both versions on a Mac Intel machine (macOS Big Sur 11.6).

1. If an axes is selected, neither the bubble shape nor the number does change to the selection color, only the axes line does
2. The same holds for the preselection color, only the actual axes line shows that the mouse is over the axes, the bubble and head number do not change to the preselection color
3. On selecting an axes and changing to use a specific font, this font is not shown on the axis head, it always stays the default serif font
4. The same holds for the label
5. The drawn bubbles do not line up correctly with the axis line, if the view is zoomed closely in, the quadrant of the circle should be aligned to line
6. If a limit is set on the axis, the bubbles don't line up correctly, line numbering gets mixed up and the defined labels on the axis disappear
7. If an axis is created, its base point is placed at (0,0,0), the bubble identified by start is not positioned at (0,0,0) but the bubble defined by end is -> IMO this should be changed

ArchAxis - only line shows preselect color

Bildschirmfoto 2022-01-04 um 16.58.33.png (430.78 KiB) Viewed 1624 times

ArchAxis - no preselect color is shown if mouse is over bubble or number, but axis is preselected (visible on the bottom report line)

Bildschirmfoto 2022-01-04 um 16.58.51.png (425.1 KiB) Viewed 1624 times

ArchAxis - no visible font change even if other font is selected

Bildschirmfoto 2022-01-04 um 17.02.48.png (491.33 KiB) Viewed 1624 times

ArchAxis - misaligned bubble and axis line

Bildschirmfoto 2022-01-04 um 17.03.22.png (12.19 KiB) Viewed 1624 times

ArchAxis - messed up bubble position if limit is set

Bildschirmfoto 2022-01-04 um 17.07.35.png (477.33 KiB) Viewed 1624 times

Now for some considerations about the conceptual development of the ArchAxis feature. Within the current concept and implementation:

1. Current axes can have multiple sub-axes, which share all the same direction orientation and are just separated by an offset, the default FC functionality creates 5 sub-axes with an offset of 1.0. This leads to a problem: Which axis of the parallel axes has an intersection with which other axis? If I have AxisA with 5 sub-axes (default in FC) and perpendicular AxisB with 5 sub-axes as well, which all intersect: how do I unambiguously define an intersection?

Here I would make an ArchAxis a truly unique object, where an AxisGroup would be combined by several parallel Axis which share the same direction but are differentiated by an offset. The IFCGrid and IFCGridAxis definition are a good concept how to handle this.

2. Axis should allow for a radial line, this way radial axis systems would be possible.

3. This is more a usability issue, which is IMO well handled by a well-known commercial arch program. An axis in FC is a two-dimensional line, that is only effective/visible in the plane it is drawn, but has no effect on a perpendicular plane. E.g. if an axis is drawn in the XY-plane and the view is set to front/XZ-plane, the axis lines are not shown (only the width of the axes heads/bubbles if these are set). If I want to show the same axes in the front view, I have to create another axis. But these two axis do not share the same data, e.g. the axis number. If I change the number of an axis in the XY-plane, I have to manually change the number of the corresponding axis in the XZ-plane.

IMO an axis should be more like a 2-dimensional plane, e.g. like axes in a building structure is usually valid for multiple levels and not only in the ground plane. The drawn axis line and bubble should only be the visual representation in a view plane, but the underlying AxisPlane should hold the actual reference data, which could be useful for alignment and attachment of object to axis intersections. This way if I would change the axis number in one view it could easily update in all views where this axis is shown.

4. Axes are misused as a graphical representation for a section cut line. I think this is fundamentally a bad idea to mix two different concepts together. The presentation of section cut lines should be separated from Axes and conceptional tied to ArchSectionPlane, so that a change in the position of a SectionPlane updates the representation automatically.

5. (Possible future concepts) Potentially separate the visual representation of an axis from its underlying data in the form of creating a kind of a preset system, where you define different visual styles (line type, bubble form and size, font etc.) which can be swapped out very easily. The well-known commercial app does this with families. I once started a forum discussion about style presets https://forum.freecadweb.org/viewtopic.php?f=8&t=62590

So, my proposal for the future development of ArchAxis and ArchAxisSystem:

1. Code cleanup - I already wrote a forum post about this and would like to split up the current ArchAxis.py file in smaller files https://forum.freecadweb.org/viewtopic.php?f=23&t=62575
2. Make an axis a truly single object -> multiple axis with the same direction but an offset between them could form an AxisGroup or AxisList
3. Make an axis a 2D plane so it has an effect in all perpendicular views to that axis
4. Allow grid axis with radial layouts

Let me know what you think.

[paullee]

2. Make an axis a truly single object -> multiple axis with the same direction but an offset between them could form an AxisGroup or AxisList
3. Make an axis a 2D plane so it has an effect in all perpendicular views to that axis
4. Allow grid axis with radial layouts

Hope @yorik would make some comments

Personally, after some attempts to use ArchAxis, not using it to start modelling at all It is good for me to be show in a Drawing to help providing setting-out information, but not to guide modelling in the first place. Also found some bugs and good to have more peoples to help developing and debugging

Curious to know how do you use in your usecases? So why do you want each Axis be a single object - seems you can just define 1 axis in the current ArchAxis (by providing only 1 figure in both Angles and Distance) to make it single axis.

What are the usecases for other suggestions?

Thanks.

Test_ Arch Axis_ 01.FCStd

(3.9 KiB) Downloaded 21 times

Screenshot from 2022-01-08 03-37-25.png (182.47 KiB) Viewed 1492 times

[doia]

Curious to know how do you use in your usecases?

My very basic use case is setting out an axis grid and placing/locking structural columns on the axes intersections. This allows the columns to move along when changing the distance between axes, and adjusting connected structural beams depending on span width (adjust beam height). This complex system helps in testing different axes layouts and the resulting structural dependencies, e.g. column/beam dimensions.

Another use case is that we test axes for furniture placement depending on the structural building axes. We have a main structural grid and an in-between furniture grid, which changes and moves along with the structure. That way the rows of shelves move depending on the structural layout.

So why do you want each Axis be a single object - seems you can just define 1 axis in the current ArchAxis (by providing only 1 figure in both Angles and Distance) to make it single axis.

UX: Sure, I could place a single axis with the current functionality, but's it is just too much manual adjustments OOTB, especially if you work primarily in the GUI. Instead of just selecting the Axis command and define the placement and direction with 2 clicks on screen (start/end point), OOTB multiple axes are created which I have to clean up and move into position.

Domain/Conceptual Model: From this perspective it feels conceptually not right and very ambiguous. What axis/intersection exactly do I place and lock a column to? Is it the clearly defined intersection of axes 123/ABC or the intersection of these but actually some subaxes with an offset of x/y. That's very confusing.

The coded basics are good. But I think for future development it needs a very clear and unambiguous mental model, even if it’s just for handling and UX.

On a personal note: I don't like coding within a dynamically typed language, as it shifts too much burden on the inner mental model if you try to understand the code base. What parameter is expected, what is returned, where the hell comes this variable from? IMHO Python is perfect for shorter scripting but not for complex model systems like a complete AECBim framework.
But it is what it is and the Wants are always more than the available time. I would love to rewrite the complete WB in C++ based on a DomainDriven model, but that's just not feasible.

[paullee]

Thanks for the comments

My very basic use case is setting out an axis grid and placing/locking structural columns on the axes intersections. This allows the columns to move along when changing the distance between axes, and adjusting connected structural beams depending on span width (adjust beam height). This complex system helps in testing different axes layouts and the resulting structural dependencies, e.g. column/beam dimensions.

You are using the current feature provided in ArchStructure + AxisSystem right? This combination allow the automatically propagation of a Structure object (e.g. a column) be repeated at intersection of Axes.

Another use case is that we test axes for furniture placement depending on the structural building axes. We have a main structural grid and an in-between furniture grid, which changes and moves along with the structure. That way the rows of shelves move depending on the structural layout.

Sounds intersecting, any demonstration?

UX: Sure, I could place a single axis with the current functionality, but's it is just too much manual adjustments OOTB, especially if you work primarily in the GUI. Instead of just selecting the Axis command and define the placement and direction with 2 clicks on screen (start/end point), OOTB multiple axes are created which I have to clean up and move into position.

Maybe you clean up for the 1st Axis object, then Copy and Paste for the rest? But then there is no information about the distance between each Axis object....

Domain/Conceptual Model: From this perspective it feels conceptually not right and very ambiguous. What axis/intersection exactly do I place and lock a column to? Is it the clearly defined intersection of axes 123/ABC or the intersection of these but actually some subaxes with an offset of x/y. That's very confusing.

The coded basics are good. But I think for future development it needs a very clear and unambiguous mental model, even if it’s just for handling and UX.

On a personal note: I don't like coding within a dynamically typed language, as it shifts too much burden on the inner mental model if you try to understand the code base. What parameter is expected, what is returned, where the hell comes this variable from? IMHO Python is perfect for shorter scripting but not for complex model systems like a complete AECBim framework.
But it is what it is and the Wants are always more than the available time. I would love to rewrite the complete WB in C++ based on a DomainDriven model, but that's just not feasible.

I am not sure I understand all these comments Hope other programmers/developers can response