Metadata fields not being pulled into 3D Repo for elements that are part of a Revit system

[carmenfan]

Description

see https://github.com/3drepo/3D-Repo-Product-Team/issues/332

[sebjf]

This bug can be reproduced in a straightforward way:

1. Create a new Revit Project
2. Place two plumbing fixtures on a wall (Systems -> Plumbing Fixtures)
3. Use the "Draw Pipe", from right clicking the attachment point on one of the sinks. (This puts that sink in a system.)
4. Export to 3D Repo

[sebjf]

Note how the Element Id of the faulty object in 3D Repo does not match the Id in Revit, whereas the non-faulty object does.

This bug is caused by ODA outputting two OdGiDrawable for Elements that belong to a MEP System. The first call to DataProcessorRvt::draw(const OdGiDrawable* pDrawable) contains the Fixture (with the correct metadata), but the vectorizer does not tesselate any geometry. The second call contains an OdGiDrawable that represents the MEP System itself. (It is possible to select this Element using the Manage -> Select by ID option in Revit, but the element is not directly selectable in the scene.) It is this second OdGiDrawable that contains the geometry.

The most likely fix at the moment is to see if the second OdGiDrawable contains a reference to the first (perhaps as a parent?), and use that to gather the metadata (conditional on the element being a MEP system?).

I have asked on the ODA forums for some additional explanation of this behaviour beforehand however, in case it's a bug:

https://forum.opendesign.com/showthread.php?23199-OdGiDrawable-for-element-that-is-part-of-MEP-system-has-no-geometry&p=93711#post93711

[sebjf]

There is no reply from ODA. It is not obvious from exploring the Db in OdaBimApp if the associations between the system types and elements are two-way (and it is the type - the system instance is not vectorized).

However, there is a simpler fix available: to check if the OdGiDrawable is an OdBmRbsSystemType in fillMeshData. If so, fillMeshData returns immediately. This means the GeometryCollector is never updated, and so all geometry goes into the previous element (which is the 'true' element).

Simply filtering the System Type OdGiDrawable is likely the best solution, since logically, a Type should not have geometry or metadata.

This fix works for a sample Revit file containing HVAC, Plumbing and Electrical components & systems. We still need to test on LOR's model to make sure nothing has been missed.

[sebjf]

This has now been fixed. A new unit test has been added that checks there are elements with the appropriate Ids and geometry after import.

647 has to be pulled in too for the updated unit tests to pass. (I get the impression #647 is commonly triggered by Rvt 2024 files).