I have a question about the use of the FACEAREA Attribute of Dynamic Components. It seems to works as advertised in simple cases … but it does not seem to be able to work with Components that have been created using the “Copies” and “Copy” facilities. If past experience is any indicator … I am probably not using it (the FACEAREA attribute) properly … hence my appeal to the forum for some expert advice.
Attached is the .SKP of a simple Dynamic Component that illustrates my issue(s). There are two results illustrated here that surprised me:
At the “upper level” … in the “Complete Assembly” component … I was expecting to be able to use FACEAREA to get the area of all of the faces with the selected material. Instead, it returns “0” … presumably because the faces with material applied are one level down. Is there a way to “call” FACEAREA to get it to “look at” the “included” components?
The second issue is that “one level down” … in the “Panel” component … I was expecting “FACEAREA” to return the area requested in each instance of the Panel component. But it ALWAYS returns the area selected/requested of the first instance … even when one of the other instances is selected. As before … am I using the FACEAREA component properly?
Also … please understand, this simple Dynamic Component is only an example. I am keenly aware that the Report facility could be used to extract the information (in this case areas) that I have asked about. I cannot use a report … that is of no interest. I need to be able to use the areas of specific faces of the various “subcomponents” as arguments in a variety of additional calculations within the larger Dynamic Component.
So there you have it. Any help will be appreciated.
Pretty sure its not a usage problem, I know some DC attributes don’t count copies in generate report. For my DCs I just use the quantity (in this case your face area) and multiply by the number of copies to get an accurate number.
No there is not. You will need to figure out a way to do the math at the top level. A Parent components can’t see it’s Child components, although redrawing the DC twice can allow them to see down.
Is there any way to create an array … similar to the use of the Copies (and Copy) facility … that does NOT generate this second level of “Child” components?
If not, then this means the Copies attribute is useful ONLY for drawing stuff within a Dynamic Component. And thus, they (Copies et al) are of limited utility .. because the upper level (the Parent) knows NOTHING about the lower level (Child) … i.e. where it is, the geometry, the materials, etc. … unless it (the Parent) somehow keeps track of all of this info for itself.
At the most abstract level, I am trying to create a Dynamic Component that generates several types of geometry that are only related to (and dependent on) the top level … and are based on various arguments that the user inputs into the DC.
And then, the purpose of the Dynamic Component is to build/draw all this various geometry … and then calculate various interactions (positions, areas, overlap areas, intersections, etc.) of this lower level geometry that was created by the Dynamic Component itself.
And when I say it this way … it begins to sound more like a SketchUp Extension … than a Dynamic Component.
Hey. You need to work the math from the top down. Figure out all the size, position, etc calculations and keep them in the top level. Then pass each value all the way down to the children. Perhaps using conditional arguments for the hidden attribute could help. You can also pass conditional arguments based on the copy number, eg IF(copy=3, X=30, X=0). I use a basic Ruby script to clean up after ‘setting’ the DC by deleting any hidden elements and keep my file size down. You can always swap (right click menu) the modified DC with a fresh one if changes are required down the road. @pcmoor is the expert on this stuff, perhaps you have some advice Philip?
To update the facearea calculation, the DC must have a scaler, this case the lenx line. This creates a new definition, hence no need to make unique, scale definition and update. The downside is that it fills the file with definitions after changes, so need to purge after use.
For DC internal copies, there needs to be a buffer component (an extra level, a common solution to other issues like rotation) otherwise there is cross talk.
The native report writer (despite requests) does not report changes in internal copies, some have then exploded the DC to get results.
The OpenCutList does handle all visible geometry. It can now report DC attributes as well.
However hidden DCs is the better approach. say 10, that can be swap to a twenty DC, thirty… as required.
suggest @egodsey , Ernest you PM your project so can help
edit: The facearea is updated to each internal DC and can be accessed, but to total them all is not possible. @boris.beaulant This maybe a OCL request? now export to excel and sum there
This might be outside the scope of @egodsey’s original question. But OpenCutList can calculate the area of top faces if its contents consist solely of groups.
I’m not sure this is a feature that would create more problems than it solves. Not all columns necessarily contain numbers. And to take it to its logical conclusion, we might not need to limit ourselves to simply calculating the sum.
