Hi,
When I validate the model, I get this message. There’s no hint which face it is. Any advice? thanks.
Hi @xavierzhou, This is a great feedback. We have improved the validation errors to include the problematic geometry in most cases. We should probably add this one to the list.
@chriswmackey, is that possible to do?
Hey @mostapha ,
If you are getting this error from the validation routine, it means that the there is a Face with zero vertices that is actually written into the HBJSON that way. So it’s not like the Face is evaluating to zero vertices at the tolerance or something like that but that there’s no geometry associated with the Face and it should not have been written into the HBJSON in the first place. I imagine it is straightforward to identify cases like this as the Rhino plugin is writing out the HBJSON and my suggestion for @mingbo would just be to ignore the Face or delete it from the model whenever there are fewer than 3 vertices.
So I am going to assign this one to @mingbo because, even if I was able to put the ID of the Face into the error message, I doubt it would help much since I would assume that a case like this has no real geometry in the Rhino scene for you to zoom in on.
@xavierzhou ,
Can you upload the .3dm of your model here so that we can recreate the situation on our end and fix the bug?
Hey @chriswmackey! Thank you for your comments.
@xavierzhou will tell us more about this case but I have seen cases that this error shows up after solving adjacencies.
I actually think it will still be helpful even if the geometry ends up being a single point. At least it shows the user which room/area is causing this issue. Right now there is no information to help the user to resolve the issue.
I second this, @xavierzhou! If you can share the model, it will be much easier to help you with this issue.
Thanks, @mostapha ,
As I said, all of the cases where this happens should be really straightforward to fix with just an extra check as @mingbo is writing the HBJSON from the Rhino geometry. Once we have this in place, there’s going to be no need for a ValidationError since these cases don’t require any input from the user to fix. They just require us as developers to skip over the geometry when writing it.
The only person who will be served by adding more information into the error message is a developer like us, who is willing to open the HBJSON in a text editor and manually delete the problematic Face. If you think having the ID of the Face for us developers is worthwhile, I can add the ID of the failing Face.
But it’s not going to be feasible in the near term to return an object where you can zoom in on Rhino geometry for a case like this, even when there is one or two points. This is a Fatal Error, which means it’s a mess-up on our end as developers and so it’s not something that an end user can easily fix on their own. Fatal Errors prevent all of the other checks from running because you’re going to get all different types of cryptic exceptions if we try to run things things like planarity and self-intersection checks when we are given invalid geometries with less than 3 vertices. At least in this case, we know what the problem is as developers and we know how to fix it.
Thank you both for the reply. For this error I found out the cause: after solving adjacency, there’re some small triangles created in some rooms, which escape the check adjacency (default 0.005-0.01 range)
I’m working on a confidential project and under very tight timeline, so please bear with me I don’t usually have time to extract the problematic portion of the building for your check.
I’ve found one more bug: imagine a tall and a low adjacent buildings, solve adjacency with airwall activated, so part of the shared wall becomes airwall, another part external wall. Then the rebuild room function wouldn’t be able to change the airwall back to external wall, even though the reset boundary condition is yes.
Hi @xavierzhou ,
We understand the tight timeline and, if you can share the .3dm file via PM, we will get it fixed for you so that you are not blocked until we release a new Rhino plugin that handles this case correctly. And it’s fine if you just give us a link to the full model (no need to narrow things down).
I’m not sure I understand the bug that you’re noting here. Did you set MergeCoplanarFaces to Yes when you did the RebuildRoom? That should merge everything back to a single exterior Wall.
If you don’t merge the coplanar faces, then the boundary condition will be reset from Surface to Outdoors but AirBoundary is not a boundary condition. It’s a face type. So the Face will remain an AirBoundary unless you change its type to Wall.
Hi Chris, I’m afraid I can’t share the model with you either, your seeing the model would constitute my breaching the confidentiality… or not?
Thank you, @xavierzhou! That’s something that your legal team can decide depending on the project contract. Usually, it is fine to share part of the model or an anonymized version of the model for debugging purposes but you should check with your team. If you can find the room that is causing the issue, that will be all that we need.
1 Like
I forgot to update this question, but the validation routine now displays the problematic geometries for errors whenever possible.