Hello all, I have a piece of conveyor used to divert boxes off of the main line. I have a group of wheels set up as components. The issue I have is if I change the width to anything larger than 18" and then change the divert direction the copied wheels do not change position. Although, it does appear that they do rotate correctly. If I then change the width back to 18" and then to a larger width they copy fine. How can I get them to change position correctly when resizing? Thanks in advance.Divert.skp (1.1 MB)
If you wrap the wheels within another group and apply copies within this environment without the outside mirror factors then can do what you want. This wrapping or isolating technique usually over comes rotation or scaling issues.
some solution.skp (1.4 MB)
this is a rather large file, maybe consider reducing the wheel detail, change some elements to groups, since copies is not economical and creates unique instances that require purging
1 Like
Thanks for the reply. I use copying for a lot of my components. So, I’m concerned about your last paragraph. I was under the impression that copies were only references to the original instance. If I read your message correctly they are not. So, if I need things to repeat dynamically is there a better way to go about than copying?
The first thing I would rationalize the model, level of detail, animation?
If the copied part has no dynamic attributes then there is no problem. When DCs are built with more than one nesting, there is an automatic check that makes new entities unique. This is a necessary requirement when populating a file, you don’t want two components with the same name conflicting with each other. However it is a problem that has not been fixed for DCs if you use the inbuilt “copies” or if you copy a DC with more than one nesting and then change an attribute.
Depending on the case there are various workarounds.
The first is to use groups, they do not leave any residue when deleted or removed. But care must be taken when building such, scaling or rotation then altering during the build will cause serious “out of sync” problems, which unlike components are hard to fix. So make the objects to a known size and position (a rest state) and always return to this state before making any alterations. Other “traps” to be aware of, a normal copy of a group can retain the same properties so must be made unique otherwise and safer build fresh ones.
Another is to use proxies, a shape that resembles and is an obvious simple form that can be replaced when detail is required. The proxy is a one level component that contains all the relevant data that can be passed in the swap. A small script is required to do the redraws if more than a few
To protect DCs from falling victim to the unique update, group the DC then copy
I added an array example for your rollers, that uses groups after the copies attribute, thus no unique component population and any need for purging , animated switch, can change time, angles
wheel array.skp (330.9 KB)
2 Likes
Thanks again for replying and for the great info. I have used proxies and I have created dumbed down versions of most of the components using textures in place of details. This seems to help keep face count low in the overall model. You mentioned a script to force a redraw. Would you mind sharing? Thanks!
Is there a remedy in sight for the copy unique ID slowdown (problem 1) that you’re talking about? I’m pushing the limits of SU DCs every day, and this is one of two things that I can’t get past (problem 2 being that copies of sub-components “reset” when their parent component is redrawn in any way).
In my world of semi-custom products (and probably others’ worlds), the complexity (problem 1) and the flexibility/exceptions (problem 2) are so crucial. Anyone else struggling or have answers??
Redraw script
https://sketchucation.com/forums/viewtopic.php?f=180&t=68489
it maybe handy to assign it to a toolbar
by Aerilius
A drag & drop editor for creating custom toolbars and custom buttons
Thanks for all your help!
As far as SketchUp improving or updating DCs… well we can only hope. But don’t hold your breath
To help to reduce the unique number population:
Use a group to contain the “copies”
post example 2 - group & sub components.skp (48.7 KB)
post example 1 - group & sub group.skp (48.0 KB)
rather than a component.
post example 3. - component & subs .skp (80.2 KB)
Can use a group to contain and shield a nested DC
Consider
post example 4 - all component plus exta nest.skp (150.0 KB)
then place a group before the hole sub, assign attribute through
post example 5 - all component plus exta group.skp (115.4 KB)
You could also consider some ruby tools to help to simplify
If there are hidden elements, then use a script to remove them and alter the option dialog to suit. The ruby code can read an attribute, say “ZZDC” that gives direction on how to change each DC. Latter if required, then reinstate the dynamics with a swap with the DC definition. Other simplifying ideas can be considered, manifold? explode? all to certain parts directed by the code of the “ZZDC” attribute.
Maybe consider that the ruby script take control of the copies? That is feed the DC a value so copies are done after the simplification with the redraw?
Maybe PM me to work through ideas