Architect updates Revit model... pollination starts new version from scratch?

Hello @mostapha and @chriswmackey,

I would like to explore this topic with you and see what your thoughts are or if there is a way to streamline to have simplifications on some external geometry.

In a project that was pollinated and exported to trace via TRACE exporter, then seeing missing glazing (which was simplified as the “single merge windows” appeared to be broken…?) I want to understand if I can run some pollination side operations to make this sort of change go smoother while maintaining zones, people, lighting, misc loads, and ventilation CFM. Below will be my attempt at documenting this issue and process used to update a lot of things manually.

  1. Old version: CHYBA V1.

  1. New Version: CHYBA V6… (took some iterations)
    • Received updated model that gave this .pomf file:
    • 2026-02-05-CHYBA Trace V6.pomf (262.3 KB)
    • Notice the windows on the Hall Abv were bad the first time… they broke for me when I fixed windows but didn’t notice. It was on this V6 model I started using the new work flow of pulling windows to the pollination model post geometry cleanup.
    • 24148 02.04.26 V5 gb.xml (2.9 MB)
    • This was exported via gbxml exporter.
    • 24148 02.04.26 V5 trc.xml (1.8 MB)
    • This was exported via Trace xml without single merge windows.

  • The primary issue I faced in updating the Trace model was the 141 Hall Abv… Because of the curvature of the the walls, there was something like 90 slices of wall to account for and all the window squarefootage to add up as well. This is the first piece.
  • The Second piece is losing the zones. Technically, the space names changes, but I still had to re do the zoning.
  1. So my questions to explore are:
    • Can curved walls facing similar directions (negligible cardinal direction angle change) and their respective windows have an option to be merged and made into one wall?
    • Can Revit name changes be re-pollinated to update names if walls didn’t change?
    • When geometry DOES change, can we update just the new parts? I feel like that would be done via merging a new snapshot with the changes into the old .pomf file.

As always, I appreciate your efforts and time into developing. Let me know if you would like the revit file versions for reference as well. Should be able to email those to you or share via google drive.

Cheers,
Josiah

2 Likes

Hi @josiahfce,

As always, thank you for documenting the question carefully. Very helpful. This is one of those topics that we come back to every now and then. Before I write a longer answer, I have some questions for you.

My first question is to get your take on what we worked on more than a year ago. Have you seen this topic? What do you think about the approach for comparing and updating geometry there?

As for this part of your question:

We are exposing properties like zones, people, lighting, misc loads, and ventilation CFM in the Pollination UI. And we’re loading them from Revit spaces. Assuming you could import them into TRACE 700 using gbXML, then that should remove the need to reassign these values inside TRACE 700 which makes the Pollination model more reusable.

My second question is, would you consider this workflow acceptable. Do you consider Revit or Pollination the right place to input these values? What would be your ideal workflow?

Let me know what you think about these two, and I should be able to write a longer answer with more detail about how we could possibly approach this.


P.S. This part for using Pollinating as a verb for exporting the models made me laugh hard. Well done! This is the moment that we learn that we officially made it. :joy:

3 Likes

Hi @mostapha,

There seems to be a lot to track here, so I will see about quoting properly.
(Post note, I didn’t quote the same way you do! Oops!)

To begin:

@mostapha: What do you think about the approach for comparing and updating geometry there?

I appreciate the video on explaining the model compare. For comparing and updating geometry, it seems great. For trace purposes, it seems like When I have attempted to export space parameters with the TRACE xml exported, I have seen no success. However, I would be curious to know if a trace model could be extracted into pollination to keep the parameters entered.

This comes from your response:

@mostapha: We are exposing properties like zones, people, lighting, misc loads, and ventilation CFM in the Pollination UI. And we’re loading them from Revit spaces. Assuming you could import them into TRACE 700 using gbXML, then that should remove the need to reassign these values inside TRACE 700 which makes the Pollination model more reusable.

Have you and the pollination team been able to extract zone, people, lighting, misc, and airflows from some space schedule in revit?

And then finally:

@mostapha: My second question is, would you consider this workflow acceptable. Do you consider Revit or Pollination the right place to input these values? What would be your ideal workflow?

This is not currently how our office navigates, but I believe keeping Revit as the master holder of design parameters to then extract from there is ideal. To my understanding, this would require our template for project set up to have a space schedule added that includes the following built-in revit parameters… See below.
Zoning:


People:

Lighting:

Ventilation CFM?:

Schedule (Clean):

Trace Single Sheet:

I will be able to provide revit files if needed, but it seems these are the starting parameters I would hope can relate to TRACE via gbxml export.

Cheers,
Josiah

2 Likes

Hi @josiahfce,

I still need some more time to give you a proper response here with more details but I just wanted to add a note about our progress so far.

We currently have a prototype for loading the values from Space Types and Space properties into the Model Editor. Here is a screenshot:

Our next steps are:

  1. Documenting what value from Revit is currently mapped to what value in Pollination Program Types.
  2. Ensuring we load the values from the expected fields. Your screenshots are extremely helpful for this item. Thank you!
  3. Implementing a new gbXML exporter that includes loads, etc. Our current gbXML exporter doesn’t include those as you mentioned above.

Finally, as of today, Chris and I have a new software added to the collection. An oldie but goodie! :smiley: That should make it easier for us to test the Pollination → TRACE 700 translation using gbXML. But we need first to make sure we parse the correct information from Revit.

Hi @mostapha,

Your update brings a lot of excitement with how much it will help the process. I imagine as a feature, it would be worth while to allow pollination users to do similar features for other heat load software. Not sure if other offices just have a different flow of don’t mind the repetition.

Sidenote, TRACE being in your software suite is fun news. Hopefully, it streamlines some of the next parts of development. Let me know if you need some revit / trace models to have example models to play with.

Kind regards,
Josiah

1 Like

Hi @mostapha ,

Looking to bring this back to surface and check in with you on current status.

Can I provide any models to help beyond the earlier references and screen shots?

Cheers,
Josiah