Thank-you both... since I realized the math may be a bit abstract I created a model to illustrate what is being calculated. The plane at the bottom represents the "filmback/sensor" of the camera. The cone represents the image being projected through the camera "lens" onto the "filmback/sensor" from the idealized "Normal" focal length. The idea is that the closer the lens is to the filmback/sensor (short focal length = the cone gets smaller) the more perspective distortion creeps in -- Conversely if the lens is moved further away from the filmback/sensor(long focal length = the cone gets larger) the less perspective you will see. As you change the size of the desired output image the filmback/sensor size changes to match which makes the lens projection of the focal length no longer match the desired perspective distortion. Ideally there is a balanced placement of the lens from the filmback/sensor which creates "Normal" perspective as we humans generally see it with our naked eyes... but since when you change the filmback/sensor size the focal length is no longer the same, "Normal" perspective is a constantly moving target. This was not as large of an issue in real cameras as the film/sensor size was not very likely to change in any given camera, but since we can and do change those parameters in 3D there needs to be some way to predict "normal" perspective for any given output. This DC has also been modified to create calculations for 35mm equivalent focal lengths -- which could also be desirable, because again the same goal is the point: consistency of output regardless of aspect ratio. I have updated the first post to contain the new version. Best, Jason.

thanks jason- one step further again. and i definitely will stick to DCs! wish you a nice weekend! time to hit the road

@dropout said: And we get it where? See the first post in the thread. Sort of the standard here for plugins and components: The download is usually in the first post--even for updates. I am downloading this one. Fantastic work! Thanks so much. Peter

using Sketchup to insult people...who woulda thought?!? Nice, Jason!

@tig said: You should be able to set custom_attributes to whatever units you want... Change the attribute name to say 'myLenX' etc and see if that helps... Post and example and we'll investigate it further... Hi TIG, The problem is not being able to set the units after custom attribute definition. The problem is that it defaults to text. There are times I have to add a custom attribute to a number of components and it gets to be a pain to have to go in and change the units each and every time from "default: text" to "inches". For instance. I have a dynamic cabinet door that initially had a "Rail_and_Stile" custom attribute that was set to "Parent!Rail_and_Stile" to denote the widths of the Rails and Stiles of the door. I came to a point in time when my overall design dictated that I had to have some doors that had 4 different rail and stile dimensions. One each for the top and bottom rail and one each for the right and left stile. Adding the 4 custom attributes to the door definition was no problem. Each variable was then set to "Parent!Right_Stile", "Parent!Top_Rail", etc. Four new definitions and in each case I had to change the units from "default: text" to "inches". All of which was no problem on the door. The problem came when I had to add those custom attributes to each of the parents: 4 times 15 and in each case the units had to be changed from "default: text" to "inches". It would have been nice to have the ability to set what I wanted the units to default to. Cheers, Mike

@sketchdata said: Looks good, I think you're understanding DCs. Can I ask if you did your attribute "Display Values" in "English"? I noticed some other language on some of the component names. I have a reporting plugin and trying to resolve language issues. Also a thanks, your HTML markup inside the DC attributes helped me realize I need to modify my reporting plugin. Values are displayed in metric units, but inside, in Component Attributes, you can see some names in other language (Romanian). I translated only what I considered the user will see/interact. I was tired and in my head I had only DCs Nice component reporter tool! I would like to keep close with you about that !

You have it right. It's an inconvenience and makes things more complicated than need be. I think I made a suggestion to Google one time about adding a type of global variable to DC's; or possibly making a variable's scope be from the parent down to children of any depth, but not up to parent components.

Thanks for the advice guys! I'll have a look on my lunch break.

Since I am not getting any replies about subroutines, I did restructure again so that I can copy DC and make a few changes to produce a component that maintains distances. The example would work for a garage door ( using ASIN & ACOS for angles ). The calculations were adapted from http://local.wasp.uwa.edu.au/~pbourke/geometry/sphereline/ http://local.wasp.uwa.edu.au/~pbourke/geometry/2circle/ There are some weird bugs in sketchup when using large numbers, in addition to the SQRT problems. skyfish trackroller II.skp

Hello, I think I found where the problem lies: After testing many variations to my formulas, without success, I had the idea of changing the internal units of the component. Being Belgian, I naturally use metric units, so my component was configured with "cm". So I converted all numeric values in inches and reconfigured the component to use same unit. Miraculously, everything works now as expected , even when using the component in a model configured in metric units. I think there's a bug in the function CURRENT("LenX/Y/Z") which should return a value expressed in inches, whatever the choice of internal units. Well, I hope my experience will serve the other! Thank you for your attention, Gerard

DCs are stuck in Imperial for many of their formulas.

yes, i spent some time trying to identify a better solution but currently none exist... so i thought i'd leave this information here in case other folks ran into it...

Yeah, the Bead is not going to scale without distortion. So you might try separating it into individual components, and setting their positions relative to one another. I used 3, but you might be able to get away with only 2 - the bead, and the rest. Note, too that I changed the Axes of the individual components to make the formulas as simple as possible. [image: NNoQ_615.png] beaded stile[jf].skp

the way i approach this is to create 2 end caps and a middle component. then i can calculate the length of the gridbeam constrained to the block size and count the number of middle components to copy. see attached. to use a different size you could adjust the size value noting that the holes will scale accordingly. or re-size each component manual and adjust the holes and positions etc. if the size of each is not a cube, you might need another attribute to handle the different dimension. e.g. if the sign post is 3x3 but the height is 2, the calculation needs to know the height of 2... in my model it assumes all 3 dimensions are the same. to neaten it up i hide the edges on the ends and middle which face each other. i took out the inner geometry as it will overload quickly when lot's of these are used in a model. [image: TOzV_gridbeam.jpg] dynamic gridbeam component

Hi Jim - Thanks for the response. I should have dug around a bit more before posting this question. Laziness, I'm afraid. Up until now, I haven't needed to specify more than one position for copies generated using the COPIES function. I should have known, from the DC stairs I've seen, that you can specify PosX,PosY, and PosZ attributes for copies at the same time (and any other attribute, for that matter).

Pyroluna.. thank you for your response. The hidden / nested components won't purge because the main component is being used in the model. I have also tried using different layers to turn things on and off, but they (meaning various hidden mullions) still show up in the report I generate even though they're not visually shown. The only way I've been able to get around this, is to go into the outliner window and manually delete any nested component that is hidden (or greyed out) then if I run a report, the hidden nested components will not be included in the newly generated report. It's just a manual way of doing something I thought I could/should be able to control automatically. thanks again..

that would work but it would lose a bit of the aesthetic appeal i was looking for so i think im gonna need to rethink the whole idea. thanks alot for clearing it up, thats one headache over.

Like +1

Hm no not exactly. But I've figured out what went wrong. Sort of. It went like this. Everything was fine until I added a custom variable. At that moment (or some other similar actions), either the parent component or the component itself would jump to a different location. I was baffled at first, but discovered that when I changed the user input, thus forcing SU to recalculate the entire component, everything went back into place. So it's quite irritable to work with, but the error will never occur when the user uses the component

@danbig said: Have you made any headway on getting unique control over the component copies? Hi Dan, Yes I have. I've attached the new and improved Drawer Cabinet. Take a look at the Component Options and you'll see a number of things that are programmable. Regarding the drawers, it's programmable with 1 to 4 and each drawer is programmable in size. If you use the Interact tool, you'll see each drawer box is different depending on whether it is a top, bottom, or middle drawer. Specifically the top and bottom clearances change. As you can guess, the copy command wouldn't have worked due to the programmability of each of the drawers. I did use selective hiding instead. Cheers, Mike EDIT: Replaced the DRAWER CAB.SKP file with an updated one. Drawer Cab.skp