Dynamic Door Beginners Project

I am working on learning how to create dynamic components and so I have been making this interior door:

DoorRH3.skp (188.2 KB)

I ditched making the RH/LH swing dynamic because it did not seem to be worth the complexity and increased file size.

This door can change between a 6 styles, 2 colors, 7 widths, 3 heights, 5 opening angles and is parametric

I still want to add a frame with a few molding options and user specified jamb width, and some door knob options,

Currently this is using cool door knob by: FreeSpirit -thanks

I do not know what an acceptable file size is for a door unit -currently at 188Kb

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.

-Gully

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.

Thanks, Chris

Then you’re in good company. Geeks are pretty much all we’ve got here.

-Gully

I see that I need to fix the rotation.

It seems that unless “glue to vertical surface” is selected when the component is created it will not auto orient its axis.

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?

Maybe with a Current function?

I’m not familiar with what’s needed for a dynamic door, just guessing from other DC furnitures I’ve had to make.

Thanks for the suggestion

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 have found an example of dynamic cabinets which work correctly so I know now that it is possible just need to figure out how they did it.

Maybe @pcmoor can figure this out :stuck_out_tongue:

I think I found the answer.
It looks like in order for rotz to be relative it needs to be a sub-component of a non-gluing parent.

so for example a cabinet door will rotate in relation to the cabinet that it is a sub-component of.

However it will not work with gluing components because they do something strange to the axis.

The Blue axis is set perpendicular to the gluing plane.

Thanks I finally got that fixed.

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.

Perhaps my file is corrupt?

Well, The door is coming along, It has really been a struggle to figure out how components behave because of the lack of a good manual.

But after many gotcha’s and redo’s here is what I have:

Door Set Int RH 1.skp (273.8 KB)

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…

common custom attributes can be swapped
so alenZ can be made common to both

then make LenZ = alenZ, then should update when swapping,

a point with axis in regards to your doors, The red and green should be to right and back with the blue up so to be consistent with convention

Hmmm, the lenXZ already refer to a custom name variable.

But when I swap a 84" door with a 80" door lenZ does read 84" but the new door is actually still 80"
so to make it fit I have to change lenZ to 88"

I will try it with a simpler trial to see if it is something about my rotation axis giving me problems.

Thank You for the help.

try a right click, redraw after placement and exit to full component, so that sub_components can update… if not can you post the two components?

As reminded by @Wo3Dan in Parts separate when scaled larger - #5 by pcmoor use the generic term parent!.

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.

I think that I found the problem. The Raised Panel dynamic sub-component is causing the problem

-if I swap a door out for that Raised Panel it will redraw correctly but if that Panel is a sub-component of a door it causes the problem.

Either:
DC’s can’t be nested
or something about the panel is off -maybe because I used groups for the panel parts instead of components