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: https://github.com/OpeningDesign/Sports_Complex/commit/a499c59c7f32338912856d5028227d9feffe245c

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]

Thanks for your generous offer to help, Angel. I asked around and got a great tip from Andreas Dieckmann for a way of extracting materials from model in-place families. It's a very round-about work flow and I'm trying to make it a bit more robust:

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

[theoryshaw]

That's awesome @dimven! thanks for the help @andydandy74.

@AngelVelezSosa thanks, as well, for the reply.

Just to summarize, if you're curious what we're trying to do, we're trying to automate the annotation of a linked IFC file--an IFC file that we we're roundtripping between Revit and FreeCAD. A very barebones roundtripping, that is only use IFCBUILDINGELEMENTPROXY entities and simple extrusions only--objects that are typically editable in the 'other' platform.

I'd affectionately like to call it our FreeMVD workflow. Would be nice to expand it to other platforms as well. But we'll see.

Thanks Guys!

[dimven]

I've made some partial progress. The last api hack was limited to just reading the material parameter. So I tried a new approach and now I can extract the extrusion object from inside the MIP and manipulate it directly. However a similar approach fails for "Import Symbol" objects because they don't have any material settings.

https://youtu.be/X-SF1M1xV9w

I'm not quite sure why the change in material is only applied once you go into the MIP...

I've also tried experimenting with creating some custom templates for the initial IFC import into Revit. I wanted to add some project parameters to the template that match the containers inside the IFC file but I've had zero success so far.

[theoryshaw]

Hi @dimven, you don't necessarily have to worry about accommodating 'import symbols' because for the ultimate rountrip workflow we'll eliminate all of those--they'll be editable extrusions. (just haven't fixed those yet)

[theoryshaw]

Hi @dimven Thought i'd share this: http://thebuildingcoder.typepad.com/blog/2015/04/whats-new-in-the-revit-2016-api.html

Probably some nice nuggets in there you could potentially use. :)

How's it going otherwise?

[dimven]

@theoryshaw , I had a thorough look through the new changes in 2016. It has a lot of cool new features but nothing stood out to me that could be helpful for our particular case.

MIPs just aren't supported by the API yet and every operation performed on them has to be through an undocumented hack. Therefore process has been quite slow.

https://www.youtube.com/watch?v=uH870OU_TDA

I've managed to automate the process completely now but the code is a jumbled mess of API calls, python, dotNet and C#. It also expects that you've customized the Revit instance's keyboard shortcuts.

[theoryshaw]

Hi @dimven sounds good, although this is pushing outside my bounds of experience.

Once you're able to pull that material data out, will the annotation part be relatively straight forward?

Thanks.

[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 https://github.com/OpeningDesign/Sports_Complex/issues/18#issuecomment-100248047 .

[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!