@unknownuser said:

Are you using the COPIES feature to create the copies?

Sometimes. I'd prefer to use a direct count of the component, if possible.

When I do use the COPIES function, the component I want to count is embedded a few levels in. So I might have:

First Level: Main DC
Second Level: Component to copy
Third Level: Component to count (say 10 copies of this component for every Second Level component)

I suppose I could use the COPIES function on the second level, and multiply by the copies of the Third Level component.

Thanks, all. This is exactly what I needed.

Hi David -

I've noticed that sometimes, if the very first time a formula is assessed, the result is zero, I get an error. I don't know if this could be the issue here.

If n=1, does the formula return zero?

My work around is to write a formula that never returns zero, and then let the DC evaluate it. Once it has accepted a non-zero value, I can edit the formula to allow a zero value, and it seems to work fine. (An example of when this comes up is a RotX, RotY, or RotZ value that is set by a user input box; I initially get an error if the value in the box is zero, but if I start with a non-zero value in the user input box when I create the formula in the RotY attribute, it works fine, even if I set it back to zero.)

I don't know if this is related to what you're doing here, but it may be worth a shot if you have the result of the formula set to zero when n=1.

On a second reading... it seems like you want to use the built-in COPIES attribute.

So if the LenZ of the Component is at or below a certain value (min height of a course), then the number of copies of the coarse is 0.

Otherwise, the value of COPIES is equal to (something like) the LenZ of the component divided by the height of a single coarse.

Found this model on the 3d Warehouse:

http://sketchup.google.com/3dwarehouse/details?mid=8a97a7ff65d55ffc8095ba2080357053

@unknownuser said:

@wo3dan said:

Is there a correct way for SU to handle flipped components with rotations in DC attributes, better than my (miserable) workaround?

Unfortunately, no. Rotations completely reset the current transformation before applying new ones, so it destroys your flip status. This bug has been recorded for a future fix. So the only workaround is to create a new component where the geometry (or a subcomponent) is flipped.

I have run into this quote often, its very frustrating. If I could have negative rotations, I could have much lighter models for the stuff that I am doing.

I think your best bet for getting something quoted commercially is to look up professional model builders and get some quotes. For each job that I quote, I try to get as accurate of a description as possible from the client, and then I send a written quote.

Each model and component is different, and will require a quote... Let me know if you need some numbers. If its not something that I can do, I can direct you to the right people.

👍 Will you keep us posted on this forum?

Thank you, Jim, it worked like a charm. Been trying to get that fixed for a week now.

@unknownuser said:

Rebuild the DC so there is no naked geometry. I turned the "post" into a subcomponent that sets its LENZ to the parent LENZ. (Naked geometry in DCs is particularly dumb. When in doubt, make everything a subcomponent instead of faces and edges.)

What about when you make cutout DC's? Then you need "naked" edges to make the cut.

Here's another broke example. It's a simple 4x4 Post with a single formula for the Z height. For me, it just snaps back to 48" no matter how I scale it.

broke2.skp

I dont know if it is the same thing, but I made some dynamic windows. I needed 3 different versions e.g casement sliding and awning. the windows did not need animation just sizing and costs attached. I made the first DC and basically copied and changed attributes to suit. This works fine when I need all sliding on the job but when I need a combination of several I find that the code reverts back to the original DC file i copied originally. I ended up redoing all 3 versions of windows from scratch, as no matter what I did I could never gethem to work (in the same model anyway)

@unknownuser said:

I think it is not available, but it would be nice to have an option to display a DC attribute in a regular text(label) inside the component.

It would be good for a level tags and room\area tags.

Already on my list... 😒

Assuming it's in inches, make the initial circle 1" diameter and then 'scale' it about its 'center' in both X/Y by the actual inch value the user has inputted [or as it is calculated from the rectangular part's dimensions ?] - so if it needs to be 12" diameter then 'scale' it x12 ?

I played an online game (Rogue Spear) for years against a buddy of mine and every time he would kill me in the game he would stand over me and squat over and over. It looked like he was humping my dead body and as evil as that may sound it was quite funny cause he would get killed most of the time by the other players still alive in the game while he was degrading my games body? I wasn't very good at the game but I played with people that were and it became more of a game to them to see who could 1. Kill and hump me and 2. Make it around the whole map of the game and hump me again! I know I know kinda sad but we were kids and we thought it was funny but any way it became so wide spread on the server we were playing on almost everyone was wanting in on it. So I changed my screen name to humpmetwice so anyone who wanted to hump me could easily find my games dead body lying helplessly somewhere in the game and have their way with it. The name stuck plus you never have a problem registering anything with someone else already having your name!

@unknownuser said:

If their axis is not aligned to the parent's axis though, it is also going to require computing x,y,z values. Rotating the parent will change their rotation AND their location.

Chris, I missed this as it was just about when I made my last post. I'm not too concerned about the location of the children moving. I am more concerned about keeping the child on the same rotX,rotY,rotZ rotation as the top level model axis; by this I mean rotX,Y,Z all = 0

So I have two big issue with my setup right now.

First is that this only works if my parent is a top level component/group. If someone places it inside of a group then I lose my bearings. If I know they need it inside a group I can setup a DC group that itself would pass information. So there would be a grandparent/parent/child setup. But I don't want to have to rely on this.

My second problem is that my child can handle rotations on any axis, but it has trouble with more than one. So I'm ok if I change rotX, or rotY, but not rotX & rotY.

I have attached a file with two instances of my component. One is top level one is inside of the group. So if you select all and rotate, only one will fix itself. And you have to use the interact tool or right click to REDRAW() for it to update.

OK, I take that back. This is where things get odd. I base my calcualtsion off what I think the parents rotX,Y,Z are based on, and the odd things is a "REDRAW" by clicking on the interact while the parent is nested in a grandparent, doesn't give the same results as when I REDERAW when I have gone into the grandparent.

rotation problem.skp

Thanks for trying Jim... Just out of curiosity, how were you able to export any attributes from the DC?

Thanks a lot! I guess its true, sometimes the most simple solution is the correct one?

@whit said:

I may be going about this all wrong, but I'm trying to make something very specific.
What I want is: to generate copies of a component which land in the model on the same plane as the original and equally spaced apart. I see how to do the stretch function, but I need individual copies, in AutoCad it is the array function. Can you point me in the right direction?

I think what you want is to add 'Position' attributes X and Y and define them based on the 'Copy' variable.

Attached is an example that creates columns and rows of a fixed size solar panel by scaling the frame that wraps around it. X and Y for each copy of the panel are defined as follows:

X=solar_array!frameThick+(rowXLenX)
Y=solar_array!frameThick+(rowYLenY)

'rowX' and 'rowY' are custom attributes of the panel, defined as follows (note use of 'Copy'):

rowX=FLOOR(Copy/solar_array!numY)
rowY=Copy-(rowX*solar_array!numY)

'numY' (and 'numX', which is not used here for positioning) are computed at the top level of the component hierarchy, along with the exact dimensions of the surrounding frame, based on the number of panels that will fit within the re-scaled frame (by dragging its edges):

LenX=CEILING((current("LenX")-(2frameThick))/sun_power305_single_crystalline!LenX)sun_power305_single_crystalline!LenX+(2frameThick)
LenY=CEILING((current("LenY")-(2frameThick))/sun_power305_single_crystalline!LenY)sun_power305_single_crystalline!LenY+(2frameThick)

And some code to make sure the minimum size contains one panel (not zero!).

I now frequently use DCs like this instead of move/copy; there are advantages.

Solar array will scale in two dimensions by replicating a single panel as needed.

Good luck with that. I'm about to start digging into DC's through ruby, so I'll probably be asking questions about some of this in the near future.

Glad you got it worked out, and thanks for sharing the solution here. Sorry no one was able to dig in and help find it, but glad you got it in the end!

Chris