Automated Revit annotation and simple IFC roundtripping

[theoryshaw]

@yorikvanhavre @dimven

Hey guys, let's continue the conversation here...

I added a very rough IFC detail to the IFC Roundtrip folder. Basically each object has a "description" attribute ( common to all ifcproducts ) that contains the text to be extracted for annotation. Not sure how usable it is, but it's a start!

• @yorikvanhavre, As you can see from the following video, i don't have access to the "description" parameter. https://www.youtube.com/watch?v=3CJvjOzjxkw&feature=youtu.be
  • @dimven what your thoughts here? a particular parameter we should embrace?
• Also, @yorikvanhavre, as you'll see i copied one of those 3-dimensional studs, the one that was editable. Hopefully upon another roundtrip all 3 of those studs will be editable.
• Workflow proposal...
  • how about we use 'detail_MASTER.ifc' as the file we merge our individual branch files into (detail_Yorik.ifc & detail_Ryan.ifc)
  • would you like to try and use Constructivity to see if the merge works? Or do you want me to do it?
    • also, do you think this is the tool we should use for merging. Seems to me the only one viable at them moment.

[yorikvanhavre]

This is strange, when I reimport my own IFC file, indeed the lower stud comes cleanly, while the 2 others have some defects. This is clearly a flaw somewhere in the exporter, I'll try to locate the problem. The very good thing is that Revit is apparently able to edit any object as long as it doesn't come triangulated. We might be able to improve the workflow a lot, because normally FreeCAD's IFC exporter should only triangulate when absolutely unavoidable (curves that it can't attribute to a 2D profile).

About the master file, we could try something like this: leave a couple of objects there (for example the exterior panel, or the window), then each of us models different parts and we try to merge...

About Constructivity, unfortunately I cannot run it at the moment (crashes on Linux and in my Win7 virtual machine), but Tim said he would have a new version son that might solve that problem. Anyway, we should certainly explore it. But having several partial IFC files, I think both FreeCAD and Revit can handle it.

About the "description" field, I'll try to store the same info inside an IfcProperty too, let's see if it works better.

EDIT ok, found the problem already...

[dimven]

I'll copy my e-mail from yesterday to ease further discussion:

Thank you for your detail. My initial observations are that if you open the IFC file straight away in Revit, all the intelligent data is wiped. That eliminates the option of editing anything in the file inside Revit before linking.

Luckily if you link it directly, all the juicy bits remain inside.

When annotating 3d views, there are a few things to keep in mind:

- The 3d view will need to be locked first. Upon unlocking and navigating the 3d view, tag placement will need to be redone.
- We cannot use generic annotations in 3d views.
+ One possible solution is to straight away use text fields. Read the information from the component and write it to the text field.
+ Another solution is to place placeholder components and copy the data from the linked entity to the placeholder component, finally tagging the placeholder component with the appropriate tag.

The below is a quick mock-up:

During the previous weekend I toyed around with one of Yorik's previous models - the FreeCAD-testhouse. I understand that this is an older file and that now FreeCad's export functionality has progressed and the outcome is most likely differnet. However I think it's important to share my observations. I saw different behavior between linking vs. opening the IFC file.

When linking, the "void" forms from the solid Boolean operations performed in FreeCad seem to remain inside the file as an "IFCOpeningElement".
Some forms seemed to be exported as an "IFCSpace".

The above mentioned elements fail to be created when opening the file, instead of linking.

When opened:

As it appears when linking:

To further add to my observations every time the IFC file is opened natively inside Revit, the file is supposedly being "updated". I believe the information is lost due to FreeCad's IFC file format being more recent than Revit's IFC format. If possible, we should experiment by exporting the FreeCad model to all supported IFC formats.

[theoryshaw]

This is strange, when I reimport my own IFC file, indeed the lower stud comes cleanly, while the 2 others have some defects. This is clearly a flaw somewhere in the exporter, I'll try to locate the problem.

okay, sounds good. Just curious, did my IFC file with the new copied studs come in triangulated?

About the master file, we could try something like this: leave a couple of objects there (for example the exterior panel, or the window), then each of us models different parts and we try to merge...

About Constructivity, unfortunately I cannot run it at the moment (crashes on Linux and in my Win7 virtual machine), but Tim said he would have a new version son that might solve that problem. Anyway, we should certainly explore it. But having several partial IFC files, I think both FreeCAD and Revit can handle it.

sound good. I'll look at running merge tests with our 'detail file' as we evolve it.

About the "description" field, I'll try to store the same info inside an IfcProperty too, let's see if it works better.

sounds good. From my perspective, i feel we should look into using the IFCSURFACESTYLE or the IFCMATERIAL property. Having run tests, upon import, Revit translates those properties to Revit's native material property.

If we approach this way, i can from Revit's side globably change a material throughout the file, if necessary, instead of changing each instance if we went with another parameter for example.

@yorikvanhavre, would it be the same from FreeCAD's side, that is changing the material property globally?

@dimven what's your thoughts here?

When annotating 3d views, there are a few things to keep in mind:

• The 3d view will need to be locked first. Upon unlocking and navigating the 3d view, tag placement will need to be redone.
• We cannot use generic annotations in 3d views.
• One possible solution is to straight away use text fields. Read the information from the component and write it to the text field.
• Another solution is to place placeholder components and copy the data from the linked entity to the placeholder component, finally tagging the placeholder component with the appropriate tag.

Actually i wasn't looking to view our 3D details in an axon view. I was looking to model in 3D, but view and annotate this content in 'plan' and 'section' only.

examples...

[yorikvanhavre]

Yes your file opened correctly. I updated mine too, I believe now the 3 studs should be editable.

At the moment FreeCAD will export "basic" material info as IfcSurfaceStyle, but will create a separate one for each object. I could change that easily I think.

Replying to some @dimven's observations above:

• FreeCAD exports to the IFC 2x3 format, which is the current "stable" release. IFC 4 (older notation: 2x4) is already there but not yet considered "official". Normally, 2x3 is what Revit also uses. If anything FreeCAD produces is not good, then it's probably a bug in FreeCAD.
• Having IfcOpeningElement and IfcSpaces "pop up" as separate, solid objects is strange, because these two objects are specifically meant to represent spaces, not solids... In any case FreeCAD exports them correctly, IfcOpeningElements are subtractable voids for walls, and IfcSpaces represent open spaces... Maybe something to configure in Revit? Is this the case with other IFC files that have IfcOpeningElements or IfcSpaces? (for ex this one: http://ifcopenshell.org/ifcopenhouse/v4/IfcOpenHouse.ifc )
• I also see that some of the curved walls don't appear for you... Unfortunately I cannot test right now because my Revit chose to not start anymore :(
• From your screenshots above, it looks like all Ifc properties get lost when opening (instead of linking). I suppose then that by using an IfcProperty to put the text, instead of the IfcDescription, we won't get much better results... But I'll try anyway.

[dimven]

@yorikvanhavre
I'm getting similar behavior with the IfcOpenHouse.
When opened:

When linked:

This is all running on Revit 2015 UR5 (build 20141119_0715)
I tried playing with the "Import IFC Options" but that doesn't seem to have any effect on lined files.
"IfcOpeningElements: seems too be its own element type when opening the file but it's grouped under the "Generic Models" category.

@theoryshaw
It would be great if we could get the material properties to work for sure, however that would mean that we'll need to open the Ifc file in Revit and that might flush the parameter data.
One alternative we could explore is to instead create view filters for linked files:

Another interesting find was that when you link the file, import and ungroup, the parameter data remains inside.
https://www.youtube.com/watch?v=bHeMDG55Nzo&feature=youtu.be

[dimven]

I've been digging through the API. It seems like Revit 2015 has two modes of opening an IFC files - Reference and Parametric. This might be what is taking away the parameter data.
Edit: I created a simple dynamo definition to ease the ifc to rvt conversion. You don't need to link,bind and ungroup to keep the parameters anymore. Please test it and tell me if it works as expected for you.
@yorikvanhavre I'm not sure if Dynamo can run on a virtual box. You'll need the latest dotNet libraries ( 4.5+)

[theoryshaw]

Sure, i'll test it.

as you hinted above, the objects are not editable when you bind an IFC file into Revit.
as shown here: https://www.youtube.com/watch?v=yYa3OibySK0

[dimven]

Yes. Unfortunately the above dynamo graph makes elements uneditable as well. It seems that during the conversion process from IFC to RVT components, the assigned parameters are lost. The dynamo definition bypasses the conversion process by importing the file in "Reference" mode.

[theoryshaw]

resultant files: a499c59

video workflow:
https://www.youtube.com/watch?v=BSUHKhMzAx0

Unfortunately we need those objects/parameters to be editable for roundtripping.

Can we entertain using IFCSURFACESTYLE or the IFCMATERIAL property? Those translate into revit's native material parameter.

[dimven]

Hmm, ok I think I've got some ideas how to fix this.
Revit (2015 and above) has a dedicated method that supposedly can handle this kind of parameter mapping:
http://revitapisearch.com/html/87327a4b-94fd-5a21-df33-9beb1921cb4d.htm
However it seems to be based on dictionaries, which at the moment are not working with Dynamo's ironPython version. I think I can rig something similar tho. The great news is that the IFC file is a plain text file and you can extract any information from it. That and also Revit seems to preserve the IfcGuid parameter. We can use it to match the components with the appropriate data:

Another alternative would be to use a Revit macro( that can handle dictionaries), but I'm not sure if my c# skills are not up to the challenge.

[theoryshaw]

sounds good. I would only say let's keep an eye toward future expand-ability to other platforms (archiCAD, microstation, for example). If we embrace a parameter that is already consistently translated with existing MVD's like CV 2.0 then it will make it easier to translate this roundtripping workflow to those platforms in the future.

Obviously the automated annotation part of this will be Dynamo/Revit specific, but let's try and keep the ability to roundtrip the object/parameter/value as agnostic as possible. (or as close to an existing MVD, as possible) If that makes sense.

[yorikvanhavre]

@dimven dynamo works in a virtual machine, I just installed it and seems to work fine. Cool! Now I need to look a that python thing. You might not be aware of that, but FreeCAD can be imported as a python module in another application (once the path is set in sys.path, a simple "import FreeCAD" does it) imagine freecad running inside dynamo, sickening wild possibilities!

I'm working on proper materials support in FreeCAD now (discussion here if anyone interested http://forum.freecadweb.org/viewtopic.php?f=23&t=10503 ), not finished yet but we'll soon have something reliable I think.

[theoryshaw]

Thanks @yorikvanhavre for the update.

including these for others...
https://twitter.com/theoryshaw/status/587697778190635008
https://twitter.com/theoryshaw/status/587698122794672130

openIDF or BSDD might not be appropriate here, but wanted to log nonetheless.
Defer to you on best approach.

Thanks.

[theoryshaw]

Hi @dimven

It appears, via the back/forth with @yorikvanhavre that we'll be embracing the IfcMaterial parameter.

Just wanted to check in with you to get your thoughts on the annotation part. Would like to use this solution, if possible, for the CDs we're putting together for the State Submission, which will be in a couple weeks.

Here's the latest detail_ryan.ifc file.

[dimven]

Hi guys, unfortunately I've been hard-pressed for time lately and haven't been able to contribute much to the workflow.

First of all, the new detail looks great. However I have some comments.
At the moment each element is a "Model In-Place" family. MIP components are sub-optimal due to many reasons (each family instance is a separate unique entity, file size issues,hard to edit sometimes, etc.). One of the problems with MIPs is that they are not exposed to the Revit API and that greatly limits my control over them.
On the matter of materials, on the Revit side to be able to control the material property of MIP elements from external sources, we'll need to expose them first. Have a look at the below example:

https://www.youtube.com/watch?v=kWzGKjihrFE&feature=youtu.be

On the FreeCad/IFC materials side, I am not sure how other software solutions handle IFC materials but at least for Revit my observation is the following:
every time you open or import an IFC file, you either need to specify a template else the default UI template will be used for the newly created document. From what I can tell the only material information used is the name of the material in string format. If the Revit template has a material that matches it, that material will be assigned. If not, a new material will be created with Revit's default material properties and the IFC material's name. Thus controlling the materials' appearance of FreeCad imports might be as easy as controlling their name during the export processes of each individual component. I tried experimenting with the above theory but my version of FC seems to fail when I try to export to IFC:

This is how the material is extracted from Yorik's original detail:

[theoryshaw]

Hi @dimven Unfortunately, when you assign a material via a 'material parameter' as your video illustrates, it's lost upon a roundtrip.

On a high level, what other object types could we use, other than a MIP, that will holdup to a roundtrip?

So Dynamo cannot extract the material 'text string' from objects inside a MIP?

[yorikvanhavre]

Wow, pretty simple system (map from the name "concrete" to a "concrete" material found in Revit's presets...) Could lead to major problems if one is not very careful!

I'm working on something in FreeCAD now ( @dimven it is normal that no material info gets exported from your version), that I think will be good, and be ready in the next days, with total control over material properties. I didn't look much yet at how you store these properties in an IfcMaterial (for ex: how do you store that a concrete material must have a certain color, or a certain finish (rough, smooth, etc), but it is certainly possible (probably with this: http://www.buildingsmart-tech.org/ifc/IFC4/final/html/schema/ifcmaterialresource/lexical/ifcmaterialproperties.htm ). Then we'll be able to store and retrieve all that from/to IFC files. Curious to see what Revit can do with it...

@theoryshaw can you try dong something like that in Revit? For example, a blue concrete. I'd be curious to see how it comes in the IFC files. So far the materials you used in the detail don't seem to have any extra property stored (unless I'm wrong), just their name...

In IFC there also seems to exist a lot of presets ( such as http://www.buildingsmart-tech.org/ifc/IFC4/final/html/schema/ifcstructuralelementsdomain/pset/pset_concreteelementgeneral.htm ). Unfortunately it seems to be a big mess (wood pset contains different entries than concrete pset, for ex), not sure how/if that can be used efficiently.

This discussion is extremely interesting and useful. Many people theorize about IFC workflows, few try to actually do it. Hurray!

[dimven]

@yorikvanhavre
To further test my theory, I copied Revit's default arch. template and copied the brickwork material, renaming it to two material instances found inside your original IFC file:

Then I made sure I assigned the new template from Open>IFC Options:

Opened the detail as usual and switched to the "Realistic" visual style and ta-daa we've got bricks! :)

However when you go back to the "Shaded" visual style things look a bit different. It seems that the shading of the material gets overwritten as per the IFC file:
#8561=IFCCOLOURRGB($,1.,0.670588254928589,0.501960813999176);

[dimven]

@theoryshaw
Unfortunately neither Dynamo nor a macro can access the info inside the MIP. It acts as a wrapper around the default FamilyManager utility so that it can imitate the family creator inside a project file. It's one of Revit's many temporary hack-jobs (one of the reasons why Revit's API looks like a mess sometimes) that was quickly developed to bring in new functionality and then implemented as a permanent solution. It simply hasn't been exposed to the API yet/ Hopefully that will change soon. The API has made great progress with the 2014 and 2015 iterations and they're steadily patching up these issues.

As you're probably well aware, there are three classes of parameters inside Revit - Instance, Type and Family. Dynamo's approach is quite robust and can access any exposed parameter of an object like so:

Which export settings are you using when exporting to IFC? (Assuming you're using the alt. exporter from here: https://apps.exchange.autodesk.com/RVT/en/Detail/Index?id=appstore.exchange.autodesk.com%3aifc2015_windows32and64%3aen&autostart=true )

I cloned the "IFC2x3 Coordination View*" settings and tried experimenting with the advanced settings to see if I can preserve the material assignment from the MIP families but nothing seems to work.

There's one more option left - experimenting with the category assignment of the MIP objects. the GenericModel category just doesn't seem to process well. I'm pretty sure that if we assign the elements to better handled categories like Door/Wall/Column/StructuralFraming, the parameters will be preserved. I'll try to switch the MIPs to different categories and see if that helps.

[theoryshaw]

damn... @yorikvanhavre, how about automated annotation on your end? :)

[theoryshaw]

Hi @AngelVelezSosa, per @dimven's comment above, do you guys have any plans of exposing the parameters/values inside MIP families?

[dimven]

Quick update. So changing the In-Place's category does have some effect. The most potent ones seem to be Walls/Columns/StructuralColumns. When assigned as a wall, you can access the material property from the wall type's composite structure layers(hard). When assigned to columns, the material can be accessed as a type property. When assigned to structural columns, the material can be changed as an instance property. However this approach is sub-optimal because:
a) it's tedious and slow
b) the resulting components are trying to behave like a walls/columns (have top and base restraints, have drag points, etc.) and seem to be hard to move/copy/edit
c)not sure if it will survive a trip to FreeCad

In-place components are great for drafting the detail because they're really easy and quick to create and edit but it seems like they're not very robust once exported to IFC. Unfortunately I can't think of a good replacement. Do you guys have any other ideas?

[yorikvanhavre]

@dimven ok that's great. So we would have already a quick way to map materials... Would be just a question of giving them a defined name when exporting from FreeCAD, and the trick is done. But I added yesterday a first draft of material support to FreeCAD's arch workbench, I think it will prove pretty powerful. Now I'll adapt the IFC exporter and importer to work with it.

At the moment, in FreeCAD, in IFC and apparently in Revit too, object color and material color are two different things. In IFC, an object can have both an IfcMaterial and an IfcSurfaceStyle. Revit apparently uses one or the other depending on the view level... In FreeCAD, I just unified these (the material now dictates the object color). Not sure it is the best solution, it's more a test to see how it goes. Anyway, both will have the same color when exported to IFC.

This WE I'll probably have first tries at IFC files with full IfcMaterials.

About objects that are not editable in Revit, frankly I would only try up to a certain point, then leave it... I think we will always end up with a couple of objects that are uneditable, both in Revit and FreeCAD. The thing would be to consider that, if these objects must be changed, then they must be remodeled, and restrict that to as few cases as possible... At least, if these objects don't create further problems (they appear correctly in 2D projections, etc), I think it's manageable...

[theoryshaw]

About objects that are not editable in Revit, frankly I would only try up to a certain point, then leave it... I think we will always end up with a couple of objects that are uneditable, both in Revit and FreeCAD. The thing would be to consider that, if these objects must be changed, then they must be remodeled, and restrict that to as few cases as possible... At least, if these objects don't create further problems (they appear correctly in 2D projections, etc), I think it's manageable...

totally agree... currently dialing into that lowest common denominator.

[dimven]

Hi guys,
I've been doing some homework and I found the following articles to be very helpful. Have a look if you have the time.
https://www.augi.com/library/myth-buster-revit-ifc
https://www.augi.com/library/myth-buster-revit-ifc-part-2-the-saga-continues
https://www.augi.com/library/myth-buster-revit-ifc-part-3
https://www.augi.com/library/myth-buster-revit-ifc-part-4-a-new-hope

[AngelVelezSosa]

There are a lot of comments to go through here, so I'll add some information.

For Link IFC, Revit imports the IfcOpeningElements and the IfcSpaces. This allows you to schedule the information and also update them (since we store their GUIDs). These can be turned off under Generic Models visibility - unfortunately the API doesn't allow a great way to do this automatically, but once you do it once, it should remain off through updates.

As far as the entities that don't get parameters on Open IFC - that's a bug, so we'll put it on the list. Link IFC has already fixed that bug as mentioned in the thread.

Note that Link IFC also has some support for IFC4 in addition to IFC2x3. If you do import faceted geometry, you will see the edges, unfortunately.

If you have some more specific questions, I'll be glad to give it a shot at answering them.

Angel

[dimven]

The material isn't the most crucial point of our work flow, I just wanted to get it out of the way. I have an idea for transferring all the parameter data over to the MIP components that I will explore this long weekend. I'll keep you updated once I make any progress.

[dimven]

A very interesting link:
http://collectivebim.com/dynamo-solibri-using-ifc-via-anvil-xbim/

[theoryshaw]

for sure... thanks for sharing. Exciting days.

[dimven]

Parameter extraction from the IFC file is ready:
https://youtu.be/wpfqYA9UF1I

I start off by setting the default template to the one you uploaded.

1. Open the IFC file.
2. The script will silently link the same ifc in "reference" mode. (that preserves the parameter information but converts the elements to simple DirectShape objects and thus makes them un-editable.)
3. The linking process has two benefits:
   a) it creates a RVT "container" that holds the parameter information from the IFC file.
   b) it creates a Shared Parameters file that contains all of the parameter definitions.
4. Select parameters are created on the fly with the info obtained from the SP file. (currently I've chosen "IfcMaterial" to store the material name and "Reference(PropertySet)" to store the element's description)
5. The values are copied from the linked file and the link is discarded to save resources.

At this point the RVT file and the shared parameters file can be discarded. The parameter creation proved to be a bit tricky but previous work from Konrad Sobon and his archi-lab.net package proved invaluable. (http://dynamobim.com/forums/topic/create-new-revit-project-parameter-from-dynamo/) (http://archi-lab.net/)

To preserve the parameters on export, we'll need to modify the IFC export settings and enable "Export user defined property sets" similar to the description here (http://sourceforge.net/p/ifcexporter/wiki/Custom%20parameter%20mapping/)

I think the next step of the round-trip will be to apply revit materials as per the IfcMaterial parameter. I'll try to make the material override work flow a bit more robust and then integrate it together with the parameter population work flow.
We'll either need to expand the materials found in the template or choose a material that is as close to the content of the IfcMaterial parameter. This is a list of the currently available materials inside the template:

Once I sort out materials, I'll focus on view generation, annotation and finally sheet generation.

What are your thoughts on the process so far? Any comments or ideas how I can improve this further?

[theoryshaw]

Hi @dimven

Sorry for the delay, have been buried.

This looks good.

There's a couple things i'd like to hash out and discuss. Too nuanced for github discussion.

Would it be possible for us to schedule a conf. call?

Phone: 302.202.5900
screensharing: https://join.me/ryanschultz

I'm fairly open, mornings, my time, work better.

@yorikvanhavre Please let us know if you'd like to join as well.

Let me know what time works for you guys.

Thanks Much, Ryan

[yorikvanhavre]

Yes! (For me skype/hangout will work better than phone, though). Anytime is good for me (I'm on GMT-3)

[theoryshaw]

cool. Yorik, once you go to https://join.me/ryanschultz there's an option to have it call you via a VOIP, no phone number necessary.

[yorikvanhavre]

you're good at finding these cool apps :)

[theoryshaw]

we'll see how cool it is after testing the limits of this São Paulo, Singapore, Wisconsin stream. :)

I'm at GMT-5

[dimven]

What's the best middle ground between GMT -5, -3 and +8 during this weekend? :)

[theoryshaw]

cool, i shot out a time tomorrow via Google calender, also can do same time sunday too, if that works better. Cheers.

[yorikvanhavre]

Okay for me both days

[dimven]

I'd prefer if we could push it to Sunday, same time ?
On May 8, 2015 10:31 PM, "Yorik van Havre" notifications@github.com
wrote:

Okay for me both days

—
Reply to this email directly or view it on GitHub
#18 (comment)
.

[theoryshaw]

np... yes, 8pm on a saturday night in Singapore would be pretty rough. That's well into cocktail hour. :)

[dimven]

Our last discussion was extremely helpful and helped me set goals better aligned with your expectations.
Placing tags coherently seems to be a lot harder than I originally thought :)
I've finally sketched out a rough work flow that manages to accomplish something decent. The graph builds up on my previous work for extracting parameters. This graph is targeted for Dynamo 0.75(and the 0.76 dailies), I'm not very happy with the way 0.8 handles parameters and distances at the moment. We go through the following steps:

• I've updated the template with a rudimentary generic model tag that reads the comments field.
• The IfcMaterial string is copied to the elements' comments field. If the field was empty, I replace it with "None". (should I leave it empty instead?)
• I isolate all the GM elements visible in the current active view.
• I've created some basic checks that make sure tags are placed properly. The first check places the tag either on the left side or the right side of the element based on the overall position of all elements. The next check offsets the tag a certain distance from the element and checks if any two tags overlap. That's using the "tagoffset" and "overlapcheck" distances at the moment. I'm not sure yet what those should be based on, my guess is the view scale primarily and then probably the view extents. I'll need to do further testing to get a better idea on that.
  Here's how it all looks at the moment:
  https://www.youtube.com/watch?v=8Ta6GLFQqUE&feature=youtu.be

Right now it works pretty well for narrow cross sections. If you use it for longitudinal sections or elevations, you'll need to tinker with the "tagoffset" value.
Looking forward to some more feedback.

[yorikvanhavre]

Wow, very nice!

[theoryshaw]

Agreed, very nice! Let me play around with it and get back to you with comments. Thanks!

[theoryshaw]

Thanks @dimven

Sorry for the delay. Have been buried as of late.

Again, I think this is great and basically usable right now, however, here's a couple tweaks ordered from more to least important (as I perceive it anyway)....

• Have the script annotate a referenced IFC file verses the IFC file that is opened in Revit directly.
  • one of the reasons for this I can add dimension strings in the Annotation Revit File, and even if the referenced IFC is modified, the dimensions strings stay associated upon reload.
• Possible to align/justify the text to the edges of the view 'box'?... like...
  
• Can the script only annotate objects that are at a certain specified view depth. That is, don't annotate objects past a certain view depth.
  • In some details, we want the depth of the view to deep to see the object 'beyond', but we don't necessarily want to annotate it--so we don't overclutter with a lot of annotation.
• It appears that the end of the leader is attached to the centroid of the object. As you can see below, sometimes this doesn't actually point to the object. I realize this might be a hard workaround. I'm wondering, is there a method whereby the user can manually move this point to the object and have the script intelligent enough to realize it's been moved, and ignore it, the next time the script is run? Don't know. ¯_(ツ)_/¯

• Can we have the script pull the annotation tag from the file that the Dynamo script is being run in, verses the template file? Or is there a greater reason you're using the template file?

If we can address the first bulletpoint that would be awesome, i could start using this right now. The others can wait.

Thanks Much, Ryan

[dimven]

Hi,
The first point would be the hardest to address. Right now Dynamo can only modify the actively open document. I've been doing some digging but I'm not sure if there is a way to circumvent this limitation.
The rest of the points should be easier to address.

This ( http://bim42.com/2015/07/align-tags-update/ ) was just released recently by Simon Moreau and seems to be doing exactly what we're after. One option is to try and incorporate the code to Dynamo, the other is to simply use Dynamo to write the data from the IFC file and then use Simon's tool directly inside Revit.

[theoryshaw]

Hi Dimitar,

sounds good. Let me know what you find. If there's no way, we'll just have to live with it, for now.

Yeah great solution. As you can see on twitter i pinged Simon Moreau to this discussion to get this thoughts and okay with potentially incorporating his work into our open source solution.

Best.

[dimven]

Hello Ryan,
Sorry for the radio silence - life's been ganging up on me and I haven't had as much time to focus on this as I would like. I've done a major revision of the whole workflow, trying to make it more robust and address some of the previous shortcomings.

• the script is suitable with the latest version of Dynamo.
• we can now limit the effective view depth.
• the tags are aligned to the view's crop box.
• you can select any tag type you'd like; however make sure that the tag's width and length are reported as "W" and "L".
• the leaders shouldn't be pointing to the centroid any more.

I'm having some difficulties solving the problem with crossing leader tags. I think that Symon already has a solution for that problem. I wasn't able to make much use of any of Symon's great code unfortunately. I'll need to improve my knowledge of C# and further review his work.
Here's a video of the current capabilities:

• https://www.youtube.com/watch?v=Qv1iQ7bEjJs

Please note that I am using the daily build and there's currently an annoying bug with the "Family Types" drop-down selection node ( renamed to IFC Tag Type in our workflow). The problem with the node is that it forgets the current selection and I had to re-select the correct tag type a few times in the video. This shouldn't be a problem in the stable builds.

[theoryshaw]

Thanks @dimven!

Can we schedule a chat tomorrow to go over?

Phone: 302.202.5900
Conference ID: 796-554-157
screensharing: https://join.me/ryanschultz

I'm relatively open.

Thanks.

[dimven]

Would 9:00 AM to 10:00 AM WI time be convenient for you?

[theoryshaw]

Yep...that works...thx
On Aug 3, 2015 8:21 PM, "Dimitar Venkov" notifications@github.com wrote:

Would 9:00 AM to 10:00 AM WI time be convenient for you?

Best Regards,

Dimitar Venkov

On Tue, Aug 4, 2015 at 2:38 AM, Ryan Schultz notifications@github.com
wrote:

Thanks @dimven https://github.com/dimven!

Can we schedule a chat tomorrow to go over?

Phone: 302.202.5900
Conference ID: 796-554-157
screensharing: https://join.me/ryanschultz

I'm relatively open.

Thanks.

—
Reply to this email directly or view it on GitHub
<
#18 (comment)

.

—
Reply to this email directly or view it on GitHub
#18 (comment)
.

[dimven]

Material tags proved to be more trouble than I thought. Now I understand why Revit doesn't have a "Tag All" option for material tags :)
The tricky part with material tags is that they're a bit more independent than standard category tags. They don't specifically need a host, they automatically extract the material properties of the object that is exactly under the end tip of the leader. That means that you have to be very precise with the placement of the leader end point.

I managed to tackle a lot of problems but at the same time found new limitations and trouble areas.
- tags are now aligned on the outside of the crop box edge.
- the code checks for existing tags before any new tag creation(there might still be a few duplicates due to the nature of material tags but those are highlighted and can be easily singled out and deleted)
- one major issue is the fact that you have to "nudge" the material tags before they get activated. ( the easiest way to do this is with the keyboard arrow keys - up + down or left + right)
- another limitation is split views. The API simply does not have a way of reading the individual crop box regions and can only extract the original "combined" crop box.

There's still a lot to be improved upon but at least we've got a starting step from which to experiment with and improve upon.

[theoryshaw]

I'll take a look.

Would it help us to possibly look at using the 'keynote tag'?

Thanks.

[theoryshaw]

Just so you know @dimven, i'm using Revit keynoting on certain sheets:

I started doing it on sheet A-201 in this Revit file.

We're using this spreadsheet to add/modify keynotes--of which we copy/paste into this text file.

Not that we incorporate keynoting in this #18 issue, but wanted to share nonetheless, just in case it informs the roadmap.

Thanks.

[dimven]

The new version is out and about:
https://www.youtube.com/watch?v=RCn-eFZb2FU&feature=youtu.be

I've optimized the distribution of the tag heads and I've added an algorithm for uncrossing the tag leaders. Neither is flawless but they're performing pretty well now.
I've also tried to improve error handling.

I've tweaked the leader end point position but it's still problematic in cases where you have two materials glued next to each other. The one created last will take priority. This is also a problem where an element is covering another element(there was a case where the insulation is drawn over some wall supports). I get the position correctly but due to the way material tags work, it reads only the material of the element that is on top. So I'll need to further tweak this.

Previous limitations are still in place but overall the work flow looks a lot more like a complete and should be able to handle a lot of views.

I haven't explored keynote tags option completely but so fat it looks like the API does not have support for automatic keynote placement. The only exposed functionality seems to be the addition of new keynotes in the text file.
Edit: it seems that keynotes are indeed not supported by the api: http://forums.autodesk.com/t5/revit-api/how-to-create-element-keynote-for-a-wall-and-material-keynote/td-p/3920593