Problem with Dynamic components ??
-
I have been looking at the new option to create dynamic components.
I created the attached frame and restricted the sizes of the two sides to a set width and depth, and the top and bottom are restricted to a set height and depth.
This seems to work but there is a problem when the width of the frame is scaled.
As the width of the frame is scaled, the sides expand whilst scaling (which appears to be normal for SU), but when the mouse is released they return to the fixed width, which is correct.
However, the top and bottom rails are left in the positon they were in when the sides had expanded in width before returning to the controlled size.
The same error occurs with the sides if the height of the frame is scaled.
Am I missing something, or is this a bug/problem in SU.
-
It is not a bug in SU. What is happening is that the length of your struts is scaling by the same amount as the whole frame, but that is not what you want, as part of the width is made up from the sides, which do not scale (remaining fixed at 4cm), so the top and bottom actually need to be slightly longer.
I think the best way to do this is to have their length taken from the frame as a whole, similarly with their positions and for the sides.
I rebuilt your frame to show you what I mean, take a look at the attributes for a guide as to what is going on. I think it should be clear enough when you look at it, but if you or anyone else wants an explanation then just ask.
frame-fixed.skpI used a few other things in there, such as copies (good to keep the number of components down), restricting the scale tool and the parent! reference, which should show you how to use them, too, if you haven't come across them yet.
I would add that it is best to avoid using groups as dynamic components, they don't have axes, so things could go wrong. Watch where your axes are, as well, they were in a strange place in your model, which could also mess things up.
-
James.
Thanks very much, your example and explanation were very useful (I'm sure others will find it so as well.)
One point, your model is made up of four individual components and scaling had the same problem as mine.
However when I created a fifth component made up of the other four it worked as you suggested.I guess this was because as individual components there was no 'parent' so the definition was not having any effect.
I will study your example a bit more and come back with any questions.
Thanks for your input.
-
I'm guessing that he saved it out as a component, which means for you to open it correctly, you would need to save it to your computer, then open SU and File>Import the model. Or just drag it into an open blank model.
If you just open it directly from the forum here, it will lose its outer DC shell because of how he saved it.
Chris
-
Yep Chris, that is exactly what I did
I should have said that I saved it as a component really, sorry about that.
It was a handy misunderstanding, though, as the fact that it worked fine just by being wrapped up shows how useful "parent!" is in attribute references; if I had used "frame!" instead then it would not have worked unless you called the wrapper "frame" as well.
-
Oh james using the old parent! trick! That is indeed interesting to see that in action. And whats more, it would have created dynamically the X,Y,Z attributes in the parent, since they would not have been there. So that cool!
Chris
-
Thanks guys.
Your input has given me a better understanding now.
I'll have a go at making the components I need and see how I get on. -
I think I am getting the hang of this, but in the meantime I have another related (sort of) question which I posted here
Any thoughts would be appreciated.
-
Hi,
I am just looking at DC and working through some examples.
I have looked at the Frame-fixed.skp file in this thread and have the following observation and questions.If I measure the top of the frame it measures 59.1cm.
Then if I make this a component and view the Len X in the attributes box it reads 63.1cm. The top rail also jumps up out of the frame.I am coming accross this in my initial attempts at making DC and it is putting me off.
Can anyone please explain to to correct this and what I am doing wrong.
Many thanks,
Bruce
-
What I'm seeing is that the top bar is floating, an dyou want it to be fit nicely down inside the 2 sides. right?
The answer is that you have the top's Z set to parent!LenZ - 4 . But it doesn't rely on the paren'ts height at all. It depends on the height of the side frame. So Top's "Z" function should read:
Side!LenZ - 4
That will then position is at the top of the side frame, and down 4 inches. In fact, I think all of your "parent!" values should be replaced with pointing to something else. Because the length and height of the parent component will change each time you change your model. Say you add a new beam over the top of everything? Now your parent component has grown super tall and you don't everything to be based on that. I think you should set the one side component to x =0, y =0 and z=0. Then relate everything back to the side component, since it will then always draw itself to the 0,0,0 of the parent component.
Does that solve it?
Chris
-
@chris fullmer said:
What I'm seeing is that the top bar is floating, an dyou want it to be fit nicely down inside the 2 sides. right?
The answer is that you have the top's Z set to parent!LenZ - 4 . But it doesn't rely on the paren'ts height at all. It depends on the height of the side frame. So Top's "Z" function should read:
Side!LenZ - 4
That will then position is at the top of the side frame, and down 4 inches. In fact, I think all of your "parent!" values should be replaced with pointing to something else. Because the length and height of the parent component will change each time you change your model. Say you add a new beam over the top of everything? Now your parent component has grown super tall and you don't everything to be based on that. I think you should set the one side component to x =0, y =0 and z=0. Then relate everything back to the side component, since it will then always draw itself to the 0,0,0 of the parent component.
Does that solve it?
Chris
Thank you Chris,
I now understand why the top rail jumps out of line, and this now make sense.
I can not get may head around the dimensions that are displayed as LenX as being 59.059cm when the dimension is actual 63.1cm. So therefore LenX is actually not the overall dimension but the overall dimension - the side LenX of 4cm, is that correct?
So every component inside a DC has its own reference point that must be strictly adhered too ! is that correct?
I will try and experiment a little further if I get time today.
Many thanks,
Bruce
-
OK, I have tried this again and I am still seeing this anomaly.
The Len X is ok but the LenY is incorrect I can not see how the attributes box for LenY is being calculated. What am I not understanding here.
The LenY reads 126.322 ????
Any help is much appreciated.
Many thanks,
Bruce
-
I have to admit, I'm seeing it too and I can't figure out why. I'll try to see if I can duplicate it when I get a chance,
Chris
-
Just for clarity the Google Team report as follows.
*Thank you for your note. We're aware of this problem, and our engineers
are currently investigating. We hope to have this resolved in an upcoming
release of SketchUp. We appreciate your patience, and thanks for taking
the time to write.Regards,
The Google Team* -
Hey guys, I can explain. This is one of those problems that is halfway between a bug and "working as designed." Ideas for how to make it better are more than welcome!
Here's the idea. Before something is a DC, it's reported width is equal to what is on screen. However, at the moment a positioning formula is added to one of its parts, its reported width can get out of sync with what is one screen. Consider this series of steps:
- I draw a 4-piece frame that is 100cm wide
- I look at it inside the Component Attributes window and its LENX is 100cm. So far so good.
- I add a formula to the right piece where its X=parent!lenx. This moves the piece "outside" the size of the parent, to the far right of the parent component.
- The LENX of the entire frame is STILL reported as 100cm, even though on screen it is wider (100cm plus the width of my piece.)
This may seem weird at first, but consider what would happen if the reported width were always updated to the onscreen width. My frame was 100cm wide, so the right piece moves to 100 cm, so the frame becomes 110 cm wide, so the right piece moves to 110cm, so the frame is 120 cm wide, etc. etc. etc. Every time you redrew your DC, the frames would grow. It's a kind of geometric circular reference.
So the software's behavior is as described above: at the moment you add a formula to a DC, its on screen width gets stored inside the DC, and formulas are driven off of that. If you scale a DC, the internal width is updated and the formulas are fired again.
In the case of this particular frame example, the answer to getting the onscreen and reported widths to line up is to constrain the X and LENX of all of your subparts to be relative to the parent!LENX in such a way that the formulas place all of the parts perfectly inside the reported width.
Does that make sense? I'd be happy to post another example...
Cheers
-
Thanks Scott,
I think I am getting to understand this a little more.
Please see attached, it seems to work as expected
Many thanks,
Bruce
Advertisement