When Dynamic Components first came out (version 7 I think), I spent a couple of weeks trying to figure out how they work, using a six-panel door as an experimental subject. The project came out well enough, and I used it for all the doors in the house I was modeling at the time (my current residence). I came to the conclusion, though, that it would have been faster, easier, and more compact to simply make a separate standard component for each of the three sizes I used, and I haven’t used them much since then. Still, to the extent that my door might be of use to you, here it is, along with a demo.
Thanks Gully, appreciate the tip.
I suspected as much when i saw that dynamic components where not fully implemented for doors.
I guess it would really help if components could be built on the fly from sub-assemblies in the library instead of having to have all the options hidden also if copies could contain a unique xyz and Len coordinates instead of just a repeating array.
But anyway I am a bit of a geek and this is a entertainment for me.
Well unless I am missing something it seems that the axis system needs a major improvement.
If I make the door Glue to a surface it changes its axis
This makes it impossible to have a gluing component with a Rot behavior. It also makes it very hard to use coordinates of any sub-component.
Then if you do not glue it and rotate the door manually the RotZ seems to use an absolute angle instead of a relative angle. So it has to be manually edited depending on whatever the door angle is.
Is there a function which will return the current axis angle of a component or someway that RotXYZ can be made relative to the current angle?
RotZ does not reflect the correct orientation of the DC it only reflects user input
so if I use =CURRENT(“RotZ”) it always returns a zero unless I change the value within the component
In other words -If I rotate an object manually it just reads Rotz=0.
Based on the lack of any components which exhibit this property I am guessing it is a dead end trying to use rotz except for extremely simple cases where the component always faces the same direction.
I noticed that but the first time I tried to set it to the green axis it rotated 2 directions -I think I was trying to make onclick set the the green axis without actually adding the green RotY axis
Anyway, now I do not seem to be able to save any Rotxyz behaviors.
Everything else in the component saves but when I open it in a new drawing rotxyz are missing.
Still a decent file size but had to give up on variable casing, knobs and more door style options to keep the size reasonable. I suppose it may be possible to do a few more style variations without adding any hidden geometry or too much extra size maybe a few kb of code.
I still need to work on the user front end some more.
It seems like the more efficient way to handle a variety of door styles would be to swap components from the library
instead of having one door with many style options as I have currently.
Or maybe keeping minor variations as I do in this component and then major variations like for example going to a six panel style would be swapped out.
I have experimented with this but it seems that the swapped component will come in at its original LenXYZ attributes instead of adopting the attributes of the parent.
Is there a way to make a swapped component automatically take on the LenXYZ of its parent?
I have tried LenX=Parent!LenX but when it is swapped that line turns red and does not work…
As the title in the attribute dialog of the component will change to the default when swapping, any direct references to the original will also be broken. Just one error will stop the update, however a search should reveal a red # =… somewhere
I tested it with two simple squares of different sizes and it does work by doing a redraw but this door set DC does not.
DC’s seem to be fairly sensitive to how they are made and since I do not know much about them I have not constructed this door in the most logical straight sequence. Or it could be the glueing plane which is causing the problem. Or maybe because the doors contain dynamic sub-components.
Here is the file I am working on: DoorSwap.skp (1.8 MB)
I am starting to think that in order to get doors that know how to be doors I will have to learn Ruby.
Thanks,
Yes I have experimented with using parent but have not implemented it yet.