Hi all,
we are working with Rhinoceros 7 SDK. We have a brep geometry and we are able to display it in the conduit as a preview. When we try to create the same brep as a Rhinoceros object, RhinoAddBrepObject returns NULL and no object is created. Are there some general check or change we can apply to a brep in order to know what is wrong with it and possibly fix the issue so that it is possible to create the object. If it can help, the brep is the result of a morph (morph method invoked on the original brep).
I was just verifyng topoogy and then geometry by isValid method. Thanks for the suggestion.
Here it is what comes up:
Brep is invalid: brep.m_E[243] edge is not valid.
edge.m_vi[0]=edge.m_vi[1]=154 but edge.IsClosed() is false.
ON_Brep.m_E[243] is invalid.
NOT VALID GEOMETRY
Brep is invalid: ON_Brep.m_T[75].m_bRev3d = true, but closed curve directions are the same.
I found one post from Dale to fix the latter but nothing relevant for the former. Any help?
Also is there any function/method to repair all bugs in a brep including the ones I detected?
instead of trying to fix the errors, I’d try to fix the object creation method. Maybe you can share a file to see what the original object and morphed objects look like?
Original surfaces are valid. After morphing from the flat to the bent surface by means of flowalongsrf, two not valid surfaces are returned.
Since original surfaces are valid I do not know how to fix them for any potential bug. I could repeat the trim but in general I need a way from the sdk to safely handle any type of surface.
can you indicate how the original surfaces were created? Because these already have slight wacky edges. If you look at their edge tolerances, they’re not 0, and using RebuildEdges on them makes them go bad objects too.
I am sorry I was given the surfaces and I cannot say how they were built. In any case I would like to be able to deal with questionable geometries as well, since they can be passed to the plugin routinely.
Maybe there are a few guidelines on how to deal with them. Otherwise I can but fix the input objects repeating the trims…
if you untrim the two surfaces, they contain 2 instead of 1 boundary, and one of the boundary curves has a lenght of 0.000, so I guess there it goes wrong. Maybe this script of @pascal can help you out, at least for this case it fixes the surfaces. RetrimSrf.py (2.6 KB)
Oddly enough the edge tolerances go further out of wack after running the script, but it avoids the bad surfaces after FlowAlongSrf
Thanks a lot! Still I do wonder how Rhinoceros is able to create the objects after flowalongsrf even if they are not perfectly valid. I would be content with this possibility but using addbrepobject does not allow me to do so…