Dynamic components double action
-
I want to get both sections of a bifold door to move together using dynamic attributes.
Is this possible?
The hinged section is simple - it's the second section that needs to pivot and slide that I'm not sure about.
-
-
Sorry - I wasn't clear enough.
This is the movement I am after.Right bifold section rotates 80 degrees
Left bifold section rotates 80 degrees and slides over
-
Hi Garry,
Attached is one of the simplest ways to create the bi-fold doors. I used nested doors and modified axes which minimizes the math involved in the functions.
It can be done using a flat (not nested) component hierarchy if needed.
-
Here's the "flat" version where the doors are siblings rather than parent-child.
It's a bit more complex, but it's only trig. Some of the attributes in this model may not strictly be required - I was experimenting with some things.
-
-
Thanks Jim,
I think I get it.
It appears that the Left Door has its new origin on the right hand side of the right door
And the Right Door has its new origin on the left hand side of the left door.What is a bit wierd is I set the angle to 93 degrees but RotZ only gets to 86.5
-
@garry k said:
Thanks Jim,
I think I get it.
It appears that the Left Door has its new origin on the right hand side of the right door
And the Right Door has its new origin on the left hand side of the left door.What is a bit wierd is I set the angle to 93 degrees but RotZ only gets to 86.5
Aha - a bug. I originally was going to run the animation from 0 to 100 percent. In the RotZ of the Doors I then divide by 100.
The RotZ of the Right door should be simply: Parent!t
-
That works - thanks.
The devils in the details - this is where I am going.
The pivot point is 35 mm from the edge of the door and on the center line.
The doors have a 3 mm separation (gap) when opened and are 3 mm behind the half jamb and the door is 3 mm away from the drywall edge.When the door is open there is a bit of a separation between the doors ~3 mm.
-
Again, this is easy if you are OK with nested components. The attached animation took about 5 minutes.
If your plugin requires a flat hierarchy, it's going to more complex. After some hours I am still unable to recreate the attached animation using a flat hierarchy. I got close, but could not get the hinge right.
From the detail in your images, I assumed you would want a believable hinge on the doors. I have attached the flat version also.
-
Jim - thanks a million
I can do nested - it makes more sense based on the complexity of the flat model.
Simpler is better.I may need to ask you for some understanding - other than that - many thanks.
-
Just for interest sake (academia)
I'm guessing the solution for the flat model lies in the fact that the second doors x must be based on the pivot point radius to x which is offset from the actual x.
So - for a given rot value - x needs to be computed
perhaps a vector solution based on rot would work - I'm just talking out loud here - perhaps totally wet.
-
@garry k said:
I'm guessing the solution for the flat model lies in the fact that the second doors x must be based on the pivot point radius to x which is offset from the actual x.
Exactly. However, I had a moment at work today and the answer turned out simpler than I initially estimated. I realized that the x and y offsets you mention need to swap values as the door goes from 0 to 90 degrees. See the X and Y position attributes of the Right door in the attached model.
So basically, this is an example of making one component follow another in a rotational animation at some (x, y) offset.
Which is better the flat or nested hierarchy? Person choice, I guess. I would tend toward the flat because it creates a more natural organization of the components. For example, which makes more sense:
A Frame has 2 doors, which each have hinges and knobs, or
A Frame has one door, which has 1/2 a hinge, which has 1/2 hinge, which has the other door.I think a flat hierarchy will also make the component easier to work with both manually and in code.
(Note - I somehow got the scale of the right door off.)
-
Jim that's got it.
I simplified the math through substitution which reduces the number of variables.
More importantly both right and left doors now reference parent directly. So now if a user renames a component the code doesn't break.
-
One other thing to note. If you want to leave the axis unchanged for the Door component then you need to change the math and take into account the relative X and Y values of the sibling. Unfortunately you need to reference the sibling.
Right
X =10.656250 * cos(-(RotZ)) - 0.870886 * sin(-(RotZ)) + Left!X
Y =10.656250 * sin(-(RotZ)) - 0.870886 * cos(-(RotZ)) + Left!YYou can copy and flip for the door to open the other way. However, you can just change the axis and set the X and Y values for the Left Half instead of the Right Half.
Notice that all you do is negate the X and Y values (because the door slides the other way. You still reference the sibling (in this case the Right Half) if the parent axis is not set set the same as the Right Half axis.
Left
X =-10.656250 * cos(-(RotZ)) - 0.870886 * sin(-(RotZ)) + Right!X
Y =-10.656250 * sin(-(RotZ)) - 0.870886 * cos(-(RotZ)) + Right!Y -
I have now coded the dynamic attributes into my plugin for bifold doors.
There was a gotcha that I wasn't expecting. It took me a lot longer to understand what was going on.I started out just calling the script over and over to create up to 4 doors which handles a double bifold. Three problems, code was starting to get messy, execution was starting to take more time and memory and storage was increasing too much.
So I now create 1 door create a second instance then flip it. Then take the bifold (2 doors) and instance it and flip them. This caused havoc. As soon as I tried (in code) to change the axes of the second door the door no longer behaved as expected. Turns out that Rotz on the flipped door changed from 0 to -180 and all I did was flip the door.
Of course if you flip the door in the editor the rotz stays at 0.
flip the sibling
tr = Geom::Transformation.scaling(sibling.bounds.center, -1, 1, 1)
sibling.transform!(tr)If I change axes after flipping door then the door moved to an unexpected place. If I change the axes before flipping the door the axes gets flipped as well causing the door to move over.
The solution I came up with was to create a parent container to hold the door. Flip the door. Since the parent's rotz stays at 0 I could reference the grand parents angle.
Creating another level of nested containers effectively insulates the animate coding from the effects of flipping the door.
Advertisement