I am facing an issue with the brep.IsPointInside command:
For a list of points (length = 1500) I want to check wether each point is inside a list of breps (let’s say 500). to speed it up, I merge the individual breps into one so I don’t have to loop through every brep for every point:
oneSpaceMerged = Rhino.Geometry.Brep() for item in listOfSpaces:
oneSpaceMerged.Append(rs.coercebrep(item))
When I check wether a testpoint is inside the merged brep, it gives me strange results.
It works well when I test it with the individual spaces.
It works like 90% when I merged the spaces into one. At certain spots, it does not recognize that the pt is inside the merged brep although it is. When I move the point just a little bit, it again returns true. print oneSpaceMerged.IsPointInside(testPt,tol,True)
I could provide a full C# demo (using a // thread safe approach) that would be totally different from your P little thingy (and waaaaay more complex: say something with 300-400+ code lines) … but the fact is that there’s no auto C# to P translation.
Plus various options would be available (for instance: convert the Brep to Mesh for some(?) speed OR run a pre test/check on a Brep/Mesh BoundingBox [testing pt X,Y.Z VS Box Intervals] OR … etc etc).
BTW: If there’s N Points around and M closed Breps/Meshes (sampled in some GeometryBase Type List) this is a classic Clustering puzzle where the criterion is the Pt containment (or some others as well). Obviously if Mesh/Brep contains Mesh/Brep … this makes things a bit hotter.
Hi Peter
Thanks a lot for your offer to help out! We will have an expert in our team soon – I guess it makes more sense if she gets back to you for more details.
Cheers
Max
Tell her that IF she has plans to play with // Methods … well … I do hope that she knows what a thread safe approach is (plus numerous other related things).
BTW: If you have GeometryBase Type containers with planar faces (like a Facet Dome so to speak) the pt containment is just a matter of dealing with DotProducts (and is very fast: around 50 milliseconds for 5+K pts and, say, 200 containers). The same approach MAYBE can been used for Meshes (if you can tolerate a bit things: Brep to Mesh … blah, blah). Of course there’s a RC Method for Meshes as well (not working always correctly - apparently not based on DotProduct logic).
BTW: A proper class (where Properties monitor container Index and Pt Index) is a must: that way you can query (LINQ/PLINQ) anything imaginable: like find the container with the max pts inside (or outside), find points contained in many containers … blah, blah.
Like this (350 lines of code) for instance (using just Polylines for the test domes):
Using - on purpose - an ancient I5 (a 12gen I9 could yield results in about 5-10 milliseconds).
Notice that in this example a pt is possible to be contained in more that one container (but user can change the search mode if he’s sure that this is not happening [i.e. separated containers around]).
What is the purpose of your quest? I mean why you are after contained pts? Do to what? Or maybe you just want random pts inside Breps for some reason?
BTW: solving any problem - the pro way - via code is kinda riding fast a proper Ducati: you may think that what you need is ponies … but in fact you need proper suspension (avoid “smart” re-active nonsense forks/shocks).
I have surfaces that represent walls and next to them closed breps that represent spaces. For every wall srf I create three random points and shift them along the normal vector of the srf, in both directions. Than I check for containment of those pts within the space breps to see wether there is a space on both side, only one side or no side of the wall. does it make sense?
Well … if you want to play AEC BIM games… use a BIM thingy (like AECOSim - my game). If you believe in Parametric in AEC (I don’t) use Generative Components (geared to AECOSim). Plan B? Use some AutoDesk app (like Revit - I hate that) and Dynamo (ditto).
Other than that your issue is very easy to resolve in the way that you ride fast a Ducati (i.e. NOT taking into acount the ponies).
For instance and for any given N of Breps (Boxes or other) is rather elementary to do a Connectivity Tree that tells you what Face (on a Brep basis) is adjacent (prox or in contact) to what else. Elementary my dear Watson (again using a proper Class makes related queries [simple/nested/whatever] very easy).
You’ll need some rules as well: for instance if a FF adjacency is found does this mean that we need a separator? (Space Schedules/Finishing Tables and client requirements [+ regional Building regulations blah, blah] can help on that). Why we need Finishing Tables? Well … if Space X dictates real granite finishing (not the ultra thin STO fake thing) and Space Y the same and some Face is adjacent to some other … that X/Y separator can’t be a simple dry wall (say a KNAUF W112).
Provide ANY number of Breps (the “spaces”) in R5 Format.
Moral: forget rnd pts (and containment) do the Connectivity thingy.
not so sure about this one but she knows how to ride it real fast, from here to moon in just a couple of days. At least that’s what she said wen I asked here
Anyway … this is what Face/Face contact (or proximity) Connectivity (a Tree of Type int) means. Note that since we relate Lists of Breps and Lists of Faces … the “format” is a bit different from a “standard” Conn Tree (like the ones for Meshes/Breps etc).
Using demo Spaces from Planet Pink (that are like Voronoi Breps - buildings in Pink differ from ours: Spaces have no openings nor inhabitants).
