BHoM / BHoM/Revit_Toolkit

Shall we automatically extract nested geometries from facade elements?

Open
#1,373 3 comments 0 reactions 5 assignees Claimed by @vietle-bh View on GitHub
type:feature type:question
Dominant language
C#
Stars
35
Forks
16
Avg merge
7d 29m
Merged PRs (30d)
2

Description

#### Description:

Recently I bumped against an issue related to querying solids and physical bounds of a curtain wall. I noticed that although a curtain element has a bounding box and solid representation with volume and area, its faces and edges collections are empty 🤯

![image](https://github.com/BHoM/Revit_Toolkit/assets/26874773/27f65627-9c0b-4ee3-a8b5-7313e730c49c)

This results with `GeometryPrimitives` query returning nothing due to the following lines:
https://github.com/BHoM/Revit_Toolkit/blob/f22d01a54c418836931280b0a4d8610b2fb192bd/Revit_Core_Engine/Query/GeometryPrimitives.cs#L72-L73

The above trickles down to `Solids`, `Faces`, `PhysicalBounds` etc. queries, which all return nothing now. As long as this is correct if we map the process 1:1 against the curtain `Element` object, is seems a bit counterintuitive that we need to query each individual panel and mullion each time we want to get the geometry of a facade element.

It tempted to me to add a few lines extracting panels and mullions inside `GeometryPrimitives` query (using `BH.Revit.Engine.Core.Query.ICurtainGrids`), but it feels like a risky shortcut taken it touches the core of the entire geometry extraction process. So I wanted to check with everyone (@enarhi in particular, taken it is facade business) how do you feel about making the change:
1. Shall we extract nested elements from curtain ones automatically when querying geometry
2. If so, any opinions where should that happen?
3. What workflows will be affected and need to be tested?

All comments welcome.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.