I’m working on a Dynamo script that colors Revit elements based on the Global Warming Potential (GWP) values stored as parameters within the materials already in the model.
Here’s what I’m trying to do:
Extract GWP parameter values from each material.
Match elements to the materials they use.
Apply graphic overrides in the active view based on GWP thresholds (e.g., green for low, red for high GWP).
However, I’m getting multiple warnings and null values — and the override logic isn’t applying as expected. Attached is a screenshot of the current state of the graph.
I’d really appreciate guidance on:
Correctly accessing material parameters from assigned materials.
Structuring the override logic cleanly.
Making sure the script runs without errors and applies visual feedback in the view.
You screenshot is entirely illegible. Read up on how to export your workspace as an image and post that so we can have some context.
Usually this type of issue is because you aren’t reading the right element - i.e. you’re looking at the instances instead of the types, or the elements instead of the materials, etc..
For the display, I also recommend not doing any sort of override in view. That’s problematic as it’s a manual process to remove them and it gets ugly quick. Instead write to a parameter on the element, and let a filter do the overrides.
Thank you very much for the exporting image tip! And for the clarification as well! I think I might need a bit more context to fully understand the distinction you’re making between types and instances or elements and materials. Would you mind pointing me to a specific example or scenario where this kind of mistake typically happens?
Also, your point about using filters instead of manual view overrides makes sense — I hadn’t considered that approach. If you have any reference or resource I could look into for setting that up correctly, that would be really helpful!
Image still is not legible. Zoom in on one node and then use the export feature linked above. It will include everything even nodes you can’t see when you hit the button.
For filters… that is rather basic Revit stuff - I suggest checking the help documentation. No need to automate it via Dynamo as you do it once and then you can transfer it from the template project into others for reuse.
Ive tackled this inhouse, and materials are not the route to take here in all honesty.
We focused on types, and determining a rate to measure each by. E.g. concrete walls are m3, partitions are m2. We developed rates for compound construction elements to multiply their related metric by instead.
Materials are not naturally extractable in an easy way, you need to get into element geometry, figure out the material of each piece etc. Nested families and compound structure make this a nightmare as well.
Focus on treating it more like a QTO is my advice. E.g. if you know the volume of material in 1m2 of a stud wall you dont need material by volume in revit.
This is basically the setup we use but instead of cost we use carbon rate which we calculate separately as an exercise. We built an addin for the user to index a rates table to assign to element types, but it could be done manually by users as well of course.
Its a far better approach for accounting for transport as well. Most systems will be prefab in future so truck loads wont be assumeable by constituent material parts, its based on system transportation.
We began where you are at a 700pax firm and i had to waste a lot of money and time to convince my firm away from volumetric material approach, but they see the light now. Hopefully helps you avoid the same trial. Having non technical people actually learn about embodied carbon beyond a simple number was key
As a heads up, some jurisdictions already have a requirement to do (and show) the material based method for pulling permits. It might not be where you are, but others are going to have to do it the harder way at some point. However because regulations are never easy, the hard method doesn’t use this volumetric material quantification on all elements - some element types (i.e. windows, paints) have to be calculated by area and others are by count (i.e. mechanical equipment, furniture). As a result the requirement is to first group objects based on the quantification type, then get the count of the instance based ones, the areas of the material area based ones, and the volumes for the material volume based ones.
All of that is to say before deciding to use an alternative calculation process, double check if the regulations permit the alternative.
The good news is authoring tools which account for the methods above are doable - I actually spearheaded authoring a tool that does the trick for a customer last winter. The bad news is I am not aware of any Dynamo nodes which do se of the specific calculations, so direct API calls will be required.
Yes it’s similar here, we do have to break down volume for most consistituent parts, but extrapolating that from literal revit material volume and structures is likely inaccurate and overkill. Sounds like youre on that page too though with your approach so i agree, ultimately has to meet the reg reqmts (although i hear there is a lot of fudging going on around the world with this process, generally - commend you for being one of the good ones that made a solution).
In our case we also break down assemblies into sub-rates in excel to align them to raw material breakdown when needed. E.g measuring concrete as concrete is flawed, allowance needed for reo proportion even if not modelled etc.
If I have time I’ll see about writing up a demo on extracting material volumes from element geometry as there is a TON of value for various workflows there (phasing animations, trade organization and work planning, embodied carbon calculations, identifying where you need a concrete sleeve vs a GWB penetration, etc.). Oddly enough the C# code is shockingly simple when you see it (I did a double take anyway) as the Revit API makes you think you ahve to do ALL THAT WORK but really you only have to do a little bit. I haven’t looked into it in scripting languages yet (i.e. Python) though, which is what I’d share.
Another route to take here is to use schedules in Revit, removing the need to code almost entirely. This is how I did costing back in the day (well before GWP was something we cared about in a typical practice).
First schedule allows entry of the GWP (or cost) parameter values for each material. These are ideally reused, but you’ll have to update them often.
Third schedule shows material quantity based elements by GWP (or cost). Group by family instance or similar and don’t itemize every instance. A Dynamo graph could read the total GWP for each element and compare that to a ‘relative to baseline’ value, setting stuff to a scale you define. One example would be values between 0 and 10 where 0 is WAY UNDER the expected GWP, 10 is WAY OVER, and 5 is the expected GWP. That value is what would drive the filters for the color override, which could be applied to any view you want.
Third schedule shows material instance based elements for GWP (or cost). If you give an element a value here (anything greater than 0) they should not show up in schedule 2.
The hard part with all of that, is the required documentation and UX. While schedule manipulation, grouping and filtering makes complete and total sense to me, I feel like 99.99% of architects and designers are unable to comprehend anything formatted as a table if it isn’t displayed in Excel…
