cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 
2024 Technology Preview Program

2024 Technology Preview Program:
Master powerful new features and shape the latest BIM-enabled innovations

Wishes
Post your wishes about Graphisoft products: Archicad, BIMx, BIMcloud, and DDScad.

Section Cropping & Change Log

DGSketcher
Legend

The Change Log / Revision Management is great in AC, but I have a problem with it generating false / irrelevant revisions.

 

The problem comes when cropping sections (and elevations). Where elements touch the crop / range boundary and are changed and logged, even though they are not visible they are included in the Revision History object. As an example, if I illustrate a wall using the section tool and crop to the underside of a beam sitting on top of the wall, then any logged changes to that beam will also be reported in the drawing revisions. This applies to all butting objects, where changes to the adjoining object are reported.

 

What I would like to see is AC make a more reasoned decision on whether to include a change in the Revision History object based on not whether an element is touching a boundary, but is there a substantive part of that element contained within the Section Range e.g. an element needs to fall within the range boundary to be considered.

Apple iMac Intel i9 / macOS Sonoma / AC27UKI (most recent builds.. if they work)
4 REPLIES 4

I don't think it even warrants user intervention, it is in the end simple maths e.g. the Revision History should consider only the elements with nodes, vertices or faces that are displayed PARTIALLY or ENTIRELY WITHIN the Section / Elevation boundary / limits, those that sit on or are outside the boundary and do not cross it are excluded. What tolerance GS need to apply to eliminate false positives based on value rounding is down to them. 

 

This is slightly at odds with the way the Marquee works, but I would not want to suggest that it is changed as using it for a Selection Tool is very different to considering element visibility.

Apple iMac Intel i9 / macOS Sonoma / AC27UKI (most recent builds.. if they work)

Yes, the case with elements on the boundary is straight forward and should definitely be fixed. I was thinking about the case with elements shown just for reference and which should not be checked for change - perhaps excessive functionality.

Bit of a grey area that one, literally & metaphorically in my workflow. 😉

Apple iMac Intel i9 / macOS Sonoma / AC27UKI (most recent builds.. if they work)