The IfcGridAxis is the actual axis of your IfcGrid that your design in based on.
The IfcAnnotation, as the name suggests, annotates that the grid is semantically important to a viewer of a particular drawing. These annotations are linked back to the IfcGridAxis (via IfcRelAssignsToProduct) but do not necessarily correlate geometrically. For example, in some drawings, we may choose to not show all grids for the purpose of drawing legibility. In an elevation, grids are shown vertically and parallel grids are hidden. In other drawings, grid extents may be cropped to help explain a situation.
This general situation of of how drawings may selectively annotate BIM data is used throughout a lot of IfcAnnotation types. For example, an IfcAnnotation that annotates an elevation drawing may have its symbol placed elsewhere than the original elevation drawing's centroid. Another example is storey levels in a section, you may have many IfcBuildingStoreys in a project, but only choose to annotate a subset of them for a particular drawing.
Dumb question, what happens if you have 20 drawings, with 20 IfcAnnotation(ObjectType:Grid) objects and you need to move the grid? Do you have to move the (20) instances?
If you move the original IfcGridAxis, then go back to a drawing, it will intelligently realise that it is outdated and will regenerate itself in the updated location. Alternatively you can force it to recalculate by just deleting the annotation and reactivating the drawing.
The mechanics still need to be polished so that the refresh is smarter and happens across sessions, etc but the basics are there.
Same goes for things like elevations and section annotations. If you move the original elevation or section, all references will auto refresh.
Very cool, got it!
Would it be a hassle to make IfcGridAxis a plane, vs, a line? That way, you can move it in either section or plan.
Also, helps when modeling, that you can 'snap' to that grid, whether it's in plan/section.
Just some thoughts.
Unfortunately IFC seems to specify 2D curves only. I wonder if @aothms has some thoughts on this - there's definitely value in it I feel. Grids sometimes don't extend to infinity in the Z direction - typically buildings would have a site grid that might apply to say a basement carpark but a different grid for a residential tower above.
IfcGridAxis is strictly bound to a IfcCurve. I think IfcGrid is more like the representation of a grid in a drawing than a good native model of the semantics of a grid.
But I'm not sure what that would like like in Blender and whether that'd actually help with synchronizing plans and elevations. I'm not sure I fully understand the discussion.
It's probably more a Blender UX issue where if you are viewing your model perpendicular to the 2D line like in a section the snapping doesn't work quite so well. There's probably a solution for this but I reckon there are bigger UX fish to fry right now :)
Comments
The IfcGridAxis is the actual axis of your IfcGrid that your design in based on.
The IfcAnnotation, as the name suggests, annotates that the grid is semantically important to a viewer of a particular drawing. These annotations are linked back to the IfcGridAxis (via IfcRelAssignsToProduct) but do not necessarily correlate geometrically. For example, in some drawings, we may choose to not show all grids for the purpose of drawing legibility. In an elevation, grids are shown vertically and parallel grids are hidden. In other drawings, grid extents may be cropped to help explain a situation.
This general situation of of how drawings may selectively annotate BIM data is used throughout a lot of IfcAnnotation types. For example, an IfcAnnotation that annotates an elevation drawing may have its symbol placed elsewhere than the original elevation drawing's centroid. Another example is storey levels in a section, you may have many IfcBuildingStoreys in a project, but only choose to annotate a subset of them for a particular drawing.
Dumb question, what happens if you have 20 drawings, with 20 IfcAnnotation(ObjectType:Grid) objects and you need to move the grid? Do you have to move the (20) instances?
If you move the original IfcGridAxis, then go back to a drawing, it will intelligently realise that it is outdated and will regenerate itself in the updated location. Alternatively you can force it to recalculate by just deleting the annotation and reactivating the drawing.
The mechanics still need to be polished so that the refresh is smarter and happens across sessions, etc but the basics are there.
Same goes for things like elevations and section annotations. If you move the original elevation or section, all references will auto refresh.
Very cool, got it!
Would it be a hassle to make IfcGridAxis a plane, vs, a line? That way, you can move it in either section or plan.
Also, helps when modeling, that you can 'snap' to that grid, whether it's in plan/section.
Just some thoughts.
Unfortunately IFC seems to specify 2D curves only. I wonder if @aothms has some thoughts on this - there's definitely value in it I feel. Grids sometimes don't extend to infinity in the Z direction - typically buildings would have a site grid that might apply to say a basement carpark but a different grid for a residential tower above.
Cool. Could see a "plane logic" being used for something like reference planes, too, in the future.
IfcGridAxis is strictly bound to a IfcCurve. I think IfcGrid is more like the representation of a grid in a drawing than a good native model of the semantics of a grid.
If you really want to associate a surface with a grid axis, then probably the way out would be to use a p-curve https://standards.buildingsmart.org/IFC/DEV/IFC4_3/RC1/HTML/schema/ifcgeometryresource/lexical/ifcpcurve.htm i.e curve on surface. The surface could even be a IfcSurfaceOfLinearExtrusion.
But I'm not sure what that would like like in Blender and whether that'd actually help with synchronizing plans and elevations. I'm not sure I fully understand the discussion.
It's probably more a Blender UX issue where if you are viewing your model perpendicular to the 2D line like in a section the snapping doesn't work quite so well. There's probably a solution for this but I reckon there are bigger UX fish to fry right now :)