I am a long time developer new to SkechUp development. I have been tasked to build a tool to analyze SketchUp files and produce a bill of materials. It seems like an easy task conceptually until you dig in and realize that you don’t really get named 3D volumes in SketchUp, but rather a huge listing of lines and faces that you need to interpret yourself (please correct me if I am wrong).
I am curious if anyone has any recommendations for tagging volumes and then parsing the quantity and sizes using the SDK.
It seems to me that the only real way I could approach this is by requiring the use of Components or maybe Groups to identify the actual volumes themselves (really just a collection of lines/faces). I think that I would open the file, get the list of components, perform some kind of logic to determine the dimensions of the component based on some assumptions I would have to make, and then I can enumerate the number of each “Type” of component (which is really just a component name) and its dimensions.
Does this sound like I am going down the correct path? I appreciate any help that can be offered… It is really a lot to wrap my head around.
I’m no extension developer but I think you might learn something if you have a look at the variety of existing extensions that do this sort of thing. Have a look at the Extension Warehouse.
Correct. In SketchUp, groups and components separate geometry into object contexts. Layers do not and are used for shared display behaviors. Also, geometric primitives need to usually be associated with “Layer0”. The parent group or component can use any other layer.
Yes this sounds all correct. There are some examples using the Ruby API we’ve posted in that category. Search for “Find Group by name” or similar.
Realize that a group is really a special component instance that is hidden from the application’s Component manager, and when edited manually via the GUI is made unique automatically by cloning of the definition (if there is more than 1 instance.)
So both component instances and groups have a component definition, the latter’s has it’s group flag set true. It is the definition that “owns” the geometric entities collection, but each instance and group has it’s own transformation.
Also be aware that definitions have a name property that is separate and distinct from each of it’s instance’s (or group’s) name property.
This all means that, when the object’s are likely to be all the same, they’ll be component instances. When they each differ (ie, are unique) they’ll perhaps be groups. You’ll also find that often (especially with dynamic components,) that many of the child objects will be groups because the DC author did not want piece parts or sub-assemblies to litter the “In Model” component manager as these sub items are not meant to be inserted in the model alone.
You should also learn how Trimble leverages the dynamic components to create reports.
See File (menu) > Generate Report.
Some users export the reports as CSV, and import this into LayOut as tabular BOMs.
Also learn about the Attribute Dictionaries so your extension can attach data to objects.
The Ruby API documentation has much more extensive explanations of the inner workings, whereas the C API doxygen output is extremely terse.
I have taken a look at the various extensions, but I have to somewhat guess how they are accomplishing what they do. They are definitely useful in understanding what can be done though.
@DanRathbun thank you very much for the detailed response! This helps tremendously, and I am glad to see I am mostly on the right path. Time to dig into dynamic components and attribute dictionaries to get an understanding of everything that I have at my disposal.