I am creating a dimensioning tool and am having issues with selecting the correct reference for the walls. My code will select the outer core for normal walls but not for the flipped walls. It is using FAIR59-style stable reference but doesn’t seem to want to work correctly. Any thoughts on how to fix this or another possible approach would be helpful (I initially used the Wall Layer References clockwork node and had the same issues). Here is the code for reference:
# Hybrid wall core exterior reference extractor
Combines reliable FAIR59 fallback with geometry-based references when available
import clr
clr.AddReference(‘RevitAPI’)
from Autodesk.Revit.DB import *
clr.AddReference(‘RevitNodes’)
import Revit
clr.ImportExtensions(Revit.GeometryConversion)
walls = UnwrapElement(IN[0])
if walls is None:
OUT = None
quit()
if not isinstance(walls, list):
walls = [walls]
core_outer =
fmt = “{0}:{1}:{2}”
nines = -9999
for wall in walls:
if wall is None:
core_outer.append(None)
continue
doc = wall.Document
uid = wall.UniqueId
try:
# Try API-based core exterior face first
refs_outer = wall.GetSideFaces(ShellLayerType.CoreExterior)
# Fallback to finish exterior face if core exterior not available
if **not** refs_outer:
refs_outer = wall.GetSideFaces(ShellLayerType.Exterior)
# If still nothing, revert to FAIR59-style stable reference
if **not** refs_outer:
if wall.Flipped:
refString_outer = fmt.format(uid, nines, 2)
else:
refString_outer = fmt.format(uid, nines, 2)
ref_outer = Reference.ParseFromStableRepresentation(doc, refString_outer)
core_outer.append(ref_outer)
else:
# Use geometry-based reference
if wall.Flipped:
core_outer.append(refs_outer\[0\])
else:
core_outer.append(refs_outer\[0\])
except:
# Catch-all fallback to stable reference
try:
if wall.Flipped:
refString_outer = fmt.format(uid, nines, 2)
else:
refString_outer = fmt.format(uid, nines, 2)
ref_outer = Reference.ParseFromStableRepresentation(doc, refString_outer)
core_outer.append(ref_outer)
except:
core_outer.append(None)
OUT = core_outer
i can’t see the initial value of core_outer from the browser. after i fixed the code formatting, syntax, and indentation, your first GetSideFaces call will basically always fall into the first except block. regarding ShellLayerType, i only found Interior and Exterior in rvt doc. i’m not sure if older builds actually had CoreExterior. anyway, just looking at the second try block, at least that one still gets you a reference. tbh, the simplest and most straightforward solution is just to replace the 2 with the actual index of the reference you want.
also, i’m not really sure what you meant by “FAIR59-style”. are you talking abt FAIR59 from api forum? i’m sensing a bit of llm here, but to be fair, relatively speaking, aec stuff is pretty niche, there’s not a ton of training data, and hallucinations happen a lot. i’d just take those answers with a grain of salt and rely more on the official docs.
Thanks for taking the time to respond. tbh I am relatively new to coding and probably in over my head, but I feel like it is so close. I have worked to replace the index in the second try block with the appropriate index, but it seems to float depending on which direction the wall is placed and the wall type that is used. Do you know if there is a way to determine which reference is at the exterior face of core? That is where I keep running into a wall.
but it seems to float depending on which direction the wall is placed and the wall type that is used.
it changes with wall’s transform? unlikely. but it varies among different wall types? sure.
tldr: just reverse engineer it and get the two magic indices, swap them if the wall is flipped.
my 2 cents. i suggest u don’t get caught up in trying to write a function that retrieve that reference which works universally across different wall types. just place some dimensions with mouse & keyboards, query what those references consist of and build a representation like the way you’re doing. after that, create a dictionary to match up with different wall types.
from my experience and what i glean from the internet today, my testing might just save u a bit of time. beside people saying this is impossible and the only viable approach is to reverse engineer, i tried with GetCompoundStructure() thenGetFirstCoreLayerIndex which supposes to return the idx u need. but it’s not always the one that should be put in the string. when they don’t match, that could be idx +/- a constant. that const is a mystery to me. u would think it is the number of layers that has 0 thickness since that actually makes the layer sequence match what you see visually. but nope, not always at least.