@mostapha , @chriswmackey , Another example that might worth mentioning as below:
Is there a way to identify which surface(s) is causing the zone as non-watertight object? I even cant understand what does it mean by “non-watertight object”? do you mean the airtightness? if yes, then shouldnt “rebuild” or “cap” functions fix the issue?
Thanks
This is a good question, though I would more accurately say that you just want to identify where the hole in the room is since you could have multiple surfaces around the hole that are to blame here. Have you tried running the native Rhino DupBorder command on the Room PolyFace? That can usually help identify where the hole is. If you don’t get any result here, then it’s possible that something odd with tolerance is going on here.
If that’s the case, I imagine that the could get the PO_ValidateModel command to always show you where the hole is. We have a command in the core libraries that shows you all of the naked and non-manifold edges of Room volumes. I imagine that we could work the output of this routine into the validation error for non-solid Room geometries so that you can always reliably see the edges that are causing the problem in the interface of the PO_ValidateModel command.
Yea, we use all of these terms interchangeably: solidity, weathertightness, air-tightness. But they all mean that we can’t accurately compute the Room volume since there’s a hole in it somewhere. In the core libraries, I tried to stick to using “solidity” as the term for this but it looks like we inherited the Rhino term of “weathertightness” in a few cases, which I imagine became a Rhino convention because early users of Rhino often used it to design ships and water vessels (I know this was one of the early value propositions of NURBS). In any event, I’m sorry that the etymology of this term creates confusion.
“Cap” will only work if the hole is perfectly planar and can be filled with a single planar surface. I don’t think rebuild will get rid of holes usually, though it helps clean things up so that you can then usually move a few points or edges to close the hole.
I use the ShowEdges command to find the naked edges in an Open Brep.
If Rhino identifies the geometry as a closed Brep, then you should look into the solutions that @chriswmackey is suggesting. Also, in my experience, some of these issues don’t really matter in the IES world. The concept of closed or open is based on the tolerance.
Thanks for posting this! I’ve run into similar issue.
Will try solutions below and look out for improved PO_Validate command to locate the problem edges.
Hi @Chris,
This command didnt work me, maybe I am missing sth here…
It seems this option isn’t working too. See below (this is a different model imported from Revit):
all good, thanks for the explanation.
Cheers,
I also always first used ShowEdges command to analyze breps. I’m not sure if flipped normals would screw up pollinations reading of a brep but it’s possible. You can use the Dir command to check. Also McNeil has a bunch of bad object advice at the page below.
Thanks for clarifying, @amirtabadkani .
Would you be able to send us a sample model that has the non-watertight object in it so that we can better understand what happened here?
@mingbo ,
Do you have any thoughts on how the Rhino plugin is identifying these objects and not watertight yet they don’t have any naked or non-manifold edges?
Hi @amirtabadkani,
As @chriswmackey said, it would be great if you could send us a sample model to test.
But could you try the command “PO_RebuildRoom” for one of those non-watertight rooms if you can’t find any open edges of those rooms?
So what this command will do is it will try to fill the gap if the gap is within the tolerance and make the room valid if possible.
In the Rhino plugin, we just use Rhino’s method “Brep.IsSolid”. I think we will need the sample geometry to investigate more.
@chriswmackey, @mingbo - I added you to the private discussion so you can access the model.
