I was trying to dig into the source codes of Rhino-inside into Github, as still no clear schema map or helping guide for the APIs, I found out that most of Breps conversion nodes and methods are trying whether to convert to Revit geometry and succeed or it throws an error if failed to convert.
Why not return from the methods 2 lists, one with succeeded elements and the other with the failed ones? This way will offer to the APIs more extensibility and flexibility.
@kike will have to answer this, but he is currently out of the office.
One reason the results could came back as one list is it the results make it easy to match up with the indexing of the original list. This is something that Grasshopper likes when processing a complicated array of objects. In GH it is easy to create a cull pattern to split the list of later if required. But that is a complete guess on my part, why it is the way it is.
Thank you for the reply, but it’s quit different what I meant precisely in my question.
Let say you have a collection of BREPs inside Rhino and you want to convert them to (FORMs or DirectShapes) elements into Revit. Simply you select the BREP by picking the geometries and then connect them to DirectShape transforming node. Though I recognized that into the Rhino-Inside APIs codes for this node they are doing a kind of checking to BREPs whether they are solid or Capped and trying to cap the holes before proceeding. But for some reasons and many times is happening. Some peoples are drawing some geometrical forms containing some errors that couldn’t be Capped. So Rhino recognize them as normal geometry while with the sensitivity and restriction of Revit they couldn’t be passed.
So What will happen, is that the Converting node will begin to process the BREPs list till facing an error and can’t convert a disrupted geometry then it’ll throw an exception error and will stop working. finally the result is: a part of elements from this list are converted to Revit while the others are not. after the exception error is happened. then it’ll be hard to filter what it is converted and what is not.
If to compare the same nodes to what is done in Dynamo, they are trying to convert all elements from SAT Although when throwing errors about some. While in GH the process stops at time the error happens. Neither with Dynamo is not a perfect way because it’s no having a filtered result at the end.
Surely, there are some ways to work around it with the programming algorithms for having a filtered list after all, but it’s a long way processing to deal with it and hardly overriding the exception errors if it’s not offered directly from the source code.
My Suggestion about the filtered result output is an amelioration idea to the product for better productivity and flexibility. I can locally branch or fork the source code from Github and work on this idea. The problem that there are still no helping manual from the APIs and I don’t have a clear schema map to the whole Rhino-inside APIs Classes model.
Apart, Still I need also to understand some very basic questions about how the Rhino APIs are working related to each other. There are a little few references about that. I Can’t find the link-relationship into APIs how to pass through Classes (Guid – Rhino.Geometry – Rhino.DocObjects {RhinoObject / ObjRef}?) though they are connected in some way to point on 1 final object at the Screen. As an example What is connection and difference between both Classes (Rhino.Geometry.Brep & Rhino.DocObjects.BrepObject)?
Let say into GH, I select a BREP and I link it to a (python or C# script) that reads at the input an access parameter as BREP how I can collect the Guid from the Brep – (BREP -> Guid)? while in the opposite way from (Guid -> BREP) is easy to do it by using the (rs. coerce).