In the latest progression of our companies use of Pollination and IESVE, we are going to be hybrid on any projects that have existing to be pollination into Trace XML exports and New projects to be exported to the GEM.
On the topic of TRACE Exports, I am curious about the following options:
Can wall names be given custom values? Right now, the walls are some string of smart terms - “Room_3cc0e08e-b531-46c7-abea-701626fc96cc-00926956Face1” which is great if you’re a computer program, but unnecessary for the user. My preference is that East oriented walls (Direction = 90) are named “E ###SF”, cardinal direction letter followed by area of the wall. If this is something that can be built in or given some custom option to define how walls are defined, that would be fantastic!
Windows and doors are restricted to Revit architectural models. As far as I am aware, architects still have a healthy mix of Revit models vs CAD Background Models. In the cases of CAD background models, I am curious if it would be possible to define windows and doors while using Rooms, Spaces, or Areas with a Flat CAD reference instead of Revit elements. Right now, my solution is either build those architectural elements in the Revit model (exterior walls, windows, and doors) and then follow suite on the rest of the workflow for cleaning the pollination model. If there is a way to define doors as a standard to be 3’x7’ from ground level and windows to have parameters to give window sill height from ground, width of window, and height of window… that would make for some powerful modeling capabilities.
Overhangs are still needing to be defined in TRACE700. This one seems rather impossible, consider how TRACE700 operates with Overhang libraries… So what if pollination could access the overhangs that are in TRACE700? This one seems more far fetched, but “what if” changed the world.
I’m happy to clarify any of my ideas above. Regardless, I am excited to have my colleagues now adopting pollination.
I appreciate all your efforts and look forward to future features and QoL updates!
As usual thank you for sharing your thoughts. As you know I highly appreciate it. I wrote a response on my laptop when you posted the question, but turns out I never published it. So here we go!
Well put! This is happening because we use Revit room IDs for naming the walls. As you said, it works well for computer programs.
Similar to the rooms’ display name, it looks like everyone has their different preference for naming. I imagine the best way to address this is to provide you with a Python script to let you rename the faces based on your preference. @chriswmackey is the right person to comment on this.
Meanwhile, if you run this code, it should make the names more human-friendly!
from model_editor import Editor
editor = Editor()
editor.model.reset_ids()
editor.update()
It will use the rooms’ display name and a counter to name the faces.
I understand the pain point here, and your solution is very valid, but I have to resist the temptation of making the Model Editor a Model Builder for now so we can focus on the editing functionalities. I remember @stefan also asked for this feature, but this is the area that I would like not to get to until after we release Model Editor v2 and Revit plugin v3. Both of them are currently under development. There are several technical reasons for this that I won’t get into right now. But trust me, we will get there eventually.
For now, you should use the Rhino plugin for those cases that you don’t have access to a Revit model.
Hmm. I need more information about this. If there is a property in gbXML that can be used to include this information, we should be able to help with this. Is there a video online that I can watch to understand how the overhangs work inside TRACE700?
Appreciate you taking the time to document your feedback! Some of those Qol updates take a bit longer to implement, but one item that I can guarantee is that we read and suggestion every single suggestion carefully.
Are you only asking about this in the context of the TRACE XML export, @josiahfce ? If so, we already need to do so much editing of the geometry when we export it in order for TRACE to accept it such that I can add a routine close to what you suggest in the TRACE exporter.
If, instead, you are asking about how to customize the individual Face names for all other engines, this has to be done on the 3D Honeybee model rather than the 2D plan version of the Model that people edit in the Model Editor. The wall faces just don’t exist yet when they are inside the model editor’s native (dragonfly) format. So the answer now is “you can easily customize individual face names to your heart’s content outside the model editor in the Rhino plugin, Grasshopper plugin, or in a Python IDE.”
But exposing this in the model editor is very tough without removing the model editor’s greatest strength - the ability to easily edit room geometry by just moving around floor plate vertices and not worrying about how the consequences for all of the windows, roofs, adjacent boundary conditions, etc.
For this stage of the Loads process, it’s pointed toward the TRACE exporter. If the exporter pumped out names of multiple East facing walls on one space/room, it makes sense to me to name them all “E Wall” or “E1 Wall, E2 Wall, E3 Wall…” Whereas windows are not allowed to be named the same on one wall. (This doesnt seem to be a problem, since it appears that the TRACE Exporter simplifies all windows on an exterior wall to be made as one group window.)
At some point, we would likely benefit from making similar names for .gem files going to IESVE, but in general, IESVE has a smoother interface to make mass changes to names across the project.
On that note, I have noticed doors don’t always make it through to the trace model. Maybe I can give a more specific example later on this one, but it seems TRACE openings are limited to windows only, despite when the snapshot model has doors visible in the preview. maybe all openings are being crunched together, windows and doors alike.
Is it an option that can be added to make each individual opening separately defined (Trace need unique opening names, so that may need some iterative naming help)
I agree with this, and I was expecting it not to be possible since the walls are basically segments and don’t exist. That said, I think there is a middle ground possible solution to expose a few options for the patterns that is used to generate the surface names when translating the geometries from DFJSON to HBJSON. From what I have seen so far, the popular options are:
@josiahfce, I might be wrong, but IESVE doesn’t have names for individual faces. It only has name for the rooms and the faces are enumerated starting from 1. @maxhanning or @katebom can confirm.
It is possible to expose this as some type of pattern for the 2D > 3D translation process but it is not a trivial effort since it would break things like Surface boundary conditions in the current translator. In other words, it’s going to take some time to identify all of the places in the code that need to be updated if we want to expose customization of face names in a way that is not buggy.
Just uncheck the “Single-Window Merge” option in the Trace Export menu and you should find that the doors make it into the TRACE XML:
Jut be prepared to wait a long time for TRACE 3D Plus to import the model if you have more than a few hundred windows or doors. I remember we waited about a half-hour for TRACE 3D plus to import all of the windows and doors of this Revit sample model:
That is why the default is set to merge all of the fenestration into a single window per wall.
Also, if you want the doors to be included in the TRACEXML and you also don’t want to wait a long time for TRACE to import the model, I recommend checking out the Simplify Windows command in the model editor.
Thank you, @chriswmackey. Just for the sake of understanding this better, don’t we use the identifier to keep track of boundary conditions? I thought changing the display names should not affect any of the other relationships between the objects. My proposal was limited to changing the display names and not the IDs.
Ah, I didn’t realize that we were only talking about the display name here. You are right that just exposing something to set the display name of the Face in the resulting 3D model is very straightforward and won’t break anything given that the IDs won’t change. Furthermore, because gbXML supports a name property separately from the ID (just like our schemas), these names should make it into the TRACEXML and so I think it would address @josiahfce 's request. Ok, maybe I’ll just take a day or two at some point and add this in the core libraries.
I’ll have to do some research into Rhino. Yet another software we may need, but if we can make do without, it would be nice to make it work as is.
Model Editor v2 and Revit plugin v3 seem like the correct priority. And per some of our earlier conversations, I understand the hesitation of making a model builder, while maintain having few clicks as possible is the goal.
I am just letting you know that I have added some automatic re-naming of the room faces, windows, and doors as part of the TRACE translation process:
These changes will be in the next release of the Revit plugin.
Right now, I have kept the naming of everything fairly simple with all faces following the convention:
[SPACE_NAME] - [FACE_TYPE] - [ORIENTATION]
When there are more than one face type on a space facing a certain direction, there will be an integer enumerator added. Here is a sample gbXML exported from our latest libraries so that you can import to TRACE to see for yourself:
Hi @chriswmackey,
Thanks for letting me know this new method has been developed!
Am I understanding correct that it’s live now and I just need to update the revit plugin to use the new naming feature? And considering the standard unit conflict, it makes sense to hold off on square footage.
Sorry, I probably should have posted here once we had a version released with the change. It’s not available yet but the next version of the Revit plugin we release will have it. @mostapha can let you know once it is available.
Hi @josiahfce, We’re currently blocked from creating a new release, but we will create one as soon as the blocking bug is resolved and send you a notification. Cheers.
This is happening because we use Revit room IDs for naming the walls. As you said, it works well for computer programs.
