I am trying to create breps with NurbsSurfaces with data (exported) from another modeling application. I tried, creating the brep from scratch but it proved very difficult to create a valid brep from raw data. But if I try using built in methods for creating and trimming breps, I am getting validity issues like following:
strong text "cv[0*cv_stride + 1] = -1.#IND is not valid.\nON_NurbsCurve.m_cv[] is not valid.\nON_Brep.m_C3[0] is invalid."
What’s even stranger is that this issue is not consistent, roughly every 1 out of ten attempts the same code produces a valid brep, with the same raw data ! If I try to put a break point and step through the code, it creates an invalid brep, then I move the execution point to an earlier line of code and run the brep creation line again, it creates a valid brep.
Can anyone explain to me what I am doing wrong? How can I reliably create a brep from raw data of surfaces and trimming curves? Any help is appreciated, thank you very much!
Rolling your own Brep can be difficult. Are you using C++ or RhinoCommon? The reason being that the Brep class in C++, ON_Brep, is heavily documented, much more than RhinoCommon.
If you are using C++, here are couple of examples you might want to review:
Also, if you get your Brep mostly built, sometimes using RhinoRepairBrep (C++) or Brep.Repair (RhinoCommon) can file in missing or fix incorrect component information.
Thanks for the references.
I was able to create a brep by using the SampleCsFaceWithHole.cs as a reference, but the results are still inconsistent. The brep comes out invalid sometimes (with the same raw data). Something in there seems to be randomized, I am not sure what is going on.
As a fallback, I try to create the breps using built in RhinoCommon methods, and I put them in a finite loop to try and create a valid brep. And that seems to improve reliability because while its trying in a loop it randomly creates a valid brep maybe on the 7th or 8th iteration. But sometimes even this fails after exhausting the maximum number of attempts and then I just give up and tell the user that brep creation failed. Also, when I am try to use the built in methods, the brep.MergeBreps method throws access violation exceptions despite all the supplied breps being valid.
Also, I am using the brep.Repair(tolerance) method and I am finding that often this method returns true and the brep remains invalid after that. That seems to be the wrong behavior according to what I see in documentation. Also often this method takes forever to finish and crashes Rhino (throws access violation exception).
After using the repair method, and putting in fallback creation methods and putting them in a loop to make multiple attempts, the best I could achieve is getting mostly accurate brep most of the time. I guess I will have to settle for this performance for now. If there is anything that I can do to improve this, please let me know.
I am building a real time geometry exchange platform to communicate geometry (in real time) between Rhino, GH, Dynamo and Revit running either on the same machine or on a remote machine. Its linked here: ThePipe
I went looking into the source data that was causing problems, which was from Dynamo and found that this was a known bug in Dynamo and that it was giving me false weights for nurbs curves. I updated to latest version of Dynamo and it is working correctly now.
I also realized that I was not merging the breps (with Brep.MergeBreps funtion) in the right order, i.e. it works without failing if I sort my breps in a way that the consecutive breps have a shared edge.
So the issues were the source data from a buggy version of Dynamo and bad usage of Brep.MergeBreps… my bad. Thanks for the references and help though!