Element.geometery NOT WORKING

yes it is actually, however, now it only works some of the time. I deleted the cad geometry completely, but it still has problems. I recreated the entire family here (attached) but it still doesnt work. its really strange. It seems to have something to do with the fact of when I connect it to a conduit run, dynamo loses the ability to import its geometry. lr85_1.rfa (1.1 MB)
ll85_1.rfa (1.8 MB)

@mix My guess is that you have some fittings that have been mirrored, either in lieu of using the rotate command or mistakenly using the LR in place of LL or vice versa

edit: I’m not sure why that would cause this error though. It is also not dependent upon whether or not the fitting is connected to a conduit run

edit 2: This is not specific to your .rfa; the same error occurs when mirroring other types of conduit fittings

1 Like

Well, Im sure I have a lot of mirrored conduit fittings, but this is the only one that is malfunctioning. At least from what I can tell. But it appears that what you say is the cause. For this family anyways. thank you!

@mix Just wondering, do you need the solids from the geometry or are you just using the lines? A possible solution I am testing is giving me some of the geometry (a couple of solids are excluded) so I’m thinking that there are solids that do not mirror properly…?

It seems to be a Dynamo error, though, because those failed geometries occur when converting to Dynamo geometry. :thinking: (see items 2 & 3 in the outputs)

I am able to recreate the issue periodically, and resolve it for brief periods by setting working range to “smallest”, but the issue pops back up in subsequent runs. This makes me believe you’re just asking too much of the geometry engine. I’m attempting to remove the screw head detail and a few other internal parts of the box which are not adding significant value now to confirm.

I actually only NEED the lines. since I am using it to create conduit runs. However in is nice to have the solids, because I like turning them on so I can see where all the condulets live.

@jacob.small I can recreate it undoubtedly every time just by mirroring the elements and this is including standard OOTB conduit fittings. What are your thoughts on that and my results above (i.e. being able to generate some of the failed geometry)

Here is the Python script (I’m blanking on how to transform the geometry in Python at the moment, hence the transform nodes afterwards):

import clr

clr.AddReference('ProtoGeometry')
from Autodesk.DesignScript.Geometry import *


clr.AddReference('RevitNodes')
import Revit
clr.ImportExtensions(Revit.GeometryConversion)

clr.AddReference('RevitAPI')
from Autodesk.Revit.DB import *


elements = IN[0]
geom = []
for elem in elements:
	elem = UnwrapElement(elem)
	if hasattr(elem, 'GetOriginalGeometry'):
		geom.append(elem.GetOriginalGeometry(Options()))

def getGeom(geom):
	geometry = []
	for g in geom:
		try:
			geometry.append(g.ToProtoType())
		except:
			pass
	return geometry
OUT = map(getGeom,geom)

Oops @mix and @jacob.small I don’t know if I confused myself or am seeing inconsistent results, but no it is not occurring with other family types every time they are mirrored. But it is without fail occurring with these rfas if they are mirrored. I had also failed to look closely enough at the geometry preview in Revit and it appears the lines from that script are not correct; I had thought they were because the non-mirrored geometries matched. Sorry about that.

Since mirroring is the only condition I’ve managed to find that causes the geometry error, though, I’m wondering if either of you have tested yet to see if its true for the failing elements in your files? If not, just ignore me today :sweat_smile:

I am finding that the only problem is the condulet family, not the conduit fittings.

I’m saw the same thing on the mirror issue after further testing. Almost always on the Y axis but some combinations of X and Z mirroring were present as well. I don’t have time to test the ‘why’ but I am working on a work-around that involves getting the non-transformed geometry and applying the coordinate system after the fact. This gets 90% of all geometry in the right spot, with the need to scale the geometry by -1 on the Z axis about it’s origin in a few cases but I’m still trying to nail down what those cases are.

EDIT: By the looks of it ist’ any transform that causes the basis Y to be -1 on the z axis. @awilliams can you confirm with your dataset?

Sorry could you clarify what you mean here? It appears to happen when mirrored on any axis

Thanks for all your help today guys!

Ummm… not easily… Suffice to say this DYN will get all the geometry for all condulets (or what I think are condulets - that’s a word outside my vocabulary until 2 hours ago) in the file @mix provided me.

Finding Condulet Geometry.dyn (9.4 KB)

@mix test this out on your larger data set. Let me know if you see incorrect results with any elements (yes you’re gonna have to preview them as I am just barely over the limits of my Revit geometry knowledge). @awilliams feel free to test it on whatever you have.

Once I’m done deciphering what I did into people speak, and have discussed it with a few others who much smarter than I am, I can posts the write up publically.

Well I Cant really say for certain, because as soon as @awilliams discovered the problem I went to work fixing all the offending condulets, so theoretically I shouldnt have any mirrored condulets left in my project. But from what I can tell, it seems to be working. Please see below. However, I agree with @awilliams it should probably be adjusted to fix a mirroring from any axis, if it is at all likely to cause an error which it sounds like it is. In the real world of BIM people do some crazy things, and I think our error handlers should be as robust as possible, regardless if our sample set has all of the possible problems or not. But thats just my opinion. Will this script work with all types of model elements if I change the inputs or just specifically the condulets. For example i have a problem of people mirroring Electrical equipment. Some is wall based, some is floor based, and some is unhosted. Wouldnt each one of those require “unmirroring” from different axis? Thanks!

Typically mirroring isn’t an issue (least that what my experience with furniture stuff taught me). My belief is that it’s unique to this category/type of hosting as it hosts… oddly.

The elements X and Z axis mirroring shouldn’t be an issue as they read the vectors the element is placed in. The issue with the Y axis is because the X/Z combo assumes Y is in a particular relationship to that plane so you have to check the direction. Least I think this is this case, but I can’t confirm as I don’t have a significant enough data set to say every possible transform is covered.

Perhaps it has something to do with how the family is built? Like there was multiple nested families, voids inside nested families that were grouped, a nested face based family, tiny geometry, multiple groups of geometry inside nested families. etc. Do you think any of that could be the root cause?

Maybe. Would need a large messy dataset to know. I’m wondering if this is recreatable with piping and ductwork families though.

I was starting to wonder the same thing. It’s not uncommon for us to mirror systems for certain projects and I’ve never seen this with Pipe or Duct. However, Pipe and Duct do give that “…connections have been reversed, can’t draw [element]. Instance has been deleted.” error or whatever it is. So maybe this is the same issue but conduit systems just handle it differently?

@awilliams Is there a way to make this script work with lists of any number of levels? My graphs tend to get pretty complex pretty quickly. lol

@mix My apologies - that script wasn’t actually performing as I had thought it was (I thought I made that more clear above so forgive me if you’ve wasted any time) I hadn’t enough time to mess with it more last night and the geometry kept causing Revit/Dynamo to hang. I was going to try going further with it but @jacob.small appeared to have found a good solution, however that did need to be modified with the small test file I was working on.

Is Jacob’s solution not working for you? If not, perhaps you need to make the same modification I did. I think we are both thinking there might be some sort of bug going on but I was hoping to revisit it a bit more later today when I get some time.

But just to answer your question - in general if you need to have a Python script handle list levels, the solution is to put the Python script into a Custom Node