Revit API Forum
Welcome to Autodesk’s Revit API Forums. Share your knowledge, ask questions, and explore popular Revit API topics.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Select all physical items in model

10 REPLIES 10
Reply
Message 1 of 11
deusextechnic
5493 Views, 10 Replies

Select all physical items in model

Hi All, 

 

I am trying to select all the Model Element instances in my model. i.e. anything that is a physical object, so I can change the value of a certain Property on all of them. Property value will be different depending on where the instance is in the model. I have the below method but it is not picking up host families or the likes of ducts. Help appreciated.

 

IList<Element> GetAllElements(Document doc)
{


ElementClassFilter FamilyInstanceFilter = new ElementClassFilter(typeof(FamilyInstance));
FilteredElementCollector FamilyInstanceCollector = new FilteredElementCollector(doc);
IList<Element> ElementsCollection = FamilyInstanceCollector.WherePasses(FamilyInstanceFilter).ToElements();
IList<Element> AllModelElements = new List<Element>();


foreach (Element e in ElementsCollection)
{

if ((null != e.Category)
&& (null != e.LevelId)
&& (null != e.get_Geometry(new Options()))
)
{
AllModelElements.Add(e);
}
}
return AllModelElements;
}

10 REPLIES 10
Message 2 of 11

Your filter looks OK to me.

 

Cf.:

 

http://thebuildingcoder.typepad.com/blog/about-the-author.html#5.9

 

Cheers,

 

Jeremy



Jeremy Tammik
Developer Technical Services
Autodesk Developer Network, ADN Open
The Building Coder

Message 3 of 11
FAIR59
in reply to: deusextechnic

When you  use a familyInstance filter , you only find User Created families, and not the system families.

 

try:

 

public static class Extensions

{

public static bool IsPhysicalElement(this Element e)

{

if (e.Category == null) return false;

if (e.ViewSpecific) return false;

// exclude specific unwanted categories

if (((BuiltInCategory)e.Category.Id.IntegerValue) == BuiltInCategory.OST_HVAC_Zones) return false;

//

return e.Category.CategoryType == CategoryType.Model && e.Category.CanAddSubcategory;

}

}

 

 

List<Element> AllElem = new FilteredElementCollector(document)

.WhereElementIsNotElementType()

.Where(e =>e.IsPhysicalElement() )

.ToList<Element>();

 

 

Message 4 of 11
matthew_taylor
in reply to: FAIR59

I'd probably use .WhereElementIsViewIndependent in there somewhere also. Faster than some of the iteration/LINQ methods.


Cheers,

-Matt
_______________________________________________________________________________
Marking a post as a 'solution' helps the community. Giving a post 'Kudos' is as good as saying thanks. Why not do both?
Message 5 of 11

Dear Matt,

 

Thank you for pointing out the importance of being aware of the relative performance of quick and slow element filters versus LINQ or .NET post-processing, cf. also:

 

http://thebuildingcoder.typepad.com/blog/2015/12/quick-slow-and-linq-element-filtering.html#2

 

Your suggestion is great.

 

However, don't you think WhereElementIsViewIndependent returns the exact same result as Element.ViewSpecific, which is already checked in the IsPhysicalElement predicate?

 

Or, to be exact, the exact opposite result?

 

I would assume and hope that is the case.

 

Correction: your suggestion holds in any case, since WhereElementIsViewIndependent can be used directly on the filtered element collector BEFORE using LINQ or .NET to iterate over the collection and check Element.ViewSpecific for each element, one by one. 

 

Cool!

 

Cheers,

 

Jeremy



Jeremy Tammik
Developer Technical Services
Autodesk Developer Network, ADN Open
The Building Coder

Message 6 of 11

Hi Jeremy,

Haha, yes, your correction is what I was going to say!

Just for anybody reading this though, WhereElementIsViewIndependent would need to be used in conjunction with WhereElementIsNotElementType (as @FAIR59 showed) to get the desired result.

 

I use LINQ a lot and don't feel that performance is altered much (by using it). Using fast filters where possible certainly helps with that, though.

I used to view LINQ as 'magic'! It's now an everyday tool that simplifies many operations. (I have your blog to thank for that.)

 

Hope you're having a great day!

 

Cheers,

 

-Matt

 

 


Cheers,

-Matt
_______________________________________________________________________________
Marking a post as a 'solution' helps the community. Giving a post 'Kudos' is as good as saying thanks. Why not do both?
Message 7 of 11

Dear Matt,

 

I promise you that extracting element data from Revit to .NET and checking it there, e.g., with LINQ, costs at least twice as much time as leaving it on the Revit side and applying some kind of filter instead.

 

Therefore, whenever possible, it pays off hugely to analyse all the element properties and how they are reflected in parameter values.

 

The parameter values can be filtered using a filtered element collector parameter filter.

 

50% speed improvement over using LINQ post-processing guaranteed:

 

http://thebuildingcoder.typepad.com/blog/2010/06/element-name-parameter-filter-correction.html

 

Cheers,

 

Jeremy



Jeremy Tammik
Developer Technical Services
Autodesk Developer Network, ADN Open
The Building Coder

Message 8 of 11

Hi Jeremy,

Don't worry, I have heeded this warning in the past and I always fast filter the collector as much as possible before even thinking LINQing.

 

Cheers,

 

-Matt


Cheers,

-Matt
_______________________________________________________________________________
Marking a post as a 'solution' helps the community. Giving a post 'Kudos' is as good as saying thanks. Why not do both?
Message 9 of 11

I have a hope that it can help:

 

RevitAPI.chm (of Revit 2017.1 SDK). The ElementClassFilter class description:

 

This filter will match elements whose class is an exact match to the input class, or elements whose class is derived from the input class.

There is a small subset of Element subclasses in the API which are not supported by this filter. These types exist in the API, but not in Revit's native object model, which means that this filter doesn't support them. In order to use a class filter to find elements of these types, it is necessary to use a higher level class and then process the results further to find elements matching only the subtype. The following types are affected by this restriction:

 

Subclasses of Autodesk.Revit.DB.Material
Subclasses of Autodesk.Revit.DB.CurveElement
Subclasses of Autodesk.Revit.DB.ConnectorElement
Subclasses of Autodesk.Revit.DB.HostedSweep
Autodesk.Revit.DB.Architecture.Room
Autodesk.Revit.DB.Mechanical.Space
Autodesk.Revit.DB.Area
Autodesk.Revit.DB.Architecture.RoomTag
Autodesk.Revit.DB.Mechanical.SpaceTag
Autodesk.Revit.DB.AreaTag
Autodesk.Revit.DB.CombinableElement
Autodesk.Revit.DB.Mullion
Autodesk.Revit.DB.Panel
Autodesk.Revit.DB.AnnotationSymbol
Autodesk.Revit.DB.Structure.AreaReinforcementType
Autodesk.Revit.DB.Structure.PathReinforcementType
Autodesk.Revit.DB.AnnotationSymbolType
Autodesk.Revit.DB.Architecture.RoomTagType
Autodesk.Revit.DB.Mechanical.SpaceTagType
Autodesk.Revit.DB.AreaTagType
Autodesk.Revit.DB.Structure.TrussType

 

Message 10 of 11
FAIR59
in reply to: jeremytammik

Hi Jeremy, Matt

I agree that you should use the .WhereElementIsViewIndependent filter instead of checking Element.ViewSpecific.

 

The rest of the checks in the IsPhysicalElement predicate check properties of the Element.Category and I think those can't be filtered in a fast filter.

 

An alternative approach would be to define your own set of Categories ( maybe 20 or 30 ). All the elements in the "Physical"model would belong to that set, if you have defined it correct.
Then you can use a ElementMulticategoryFilter combined with the .WhereElementIsNotElementType and .WhereElementIsViewIndependent

 

 

cheers, Frank

Message 11 of 11
jeremytammik
in reply to: FAIR59

Dear Frank,

 

Yes, indeed.

 

That reminds me of my approaches to retrieve MEP and structural elements:

 

http://thebuildingcoder.typepad.com/blog/about-the-author.html#5.9

 

I published this discussion on the blog now, and added it to that topic group as well:

 

http://thebuildingcoder.typepad.com/blog/2017/01/dynamic-scripts-model-elements-and-vertical-alignme...

 

Thank you very much for all your highly qualified contributions!

 

Cheers,

 

Jeremy



Jeremy Tammik
Developer Technical Services
Autodesk Developer Network, ADN Open
The Building Coder

Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums  

Autodesk DevCon in Munich May 28-29th


Rail Community