Hi
I have two components a door and a hinge.
When I click on the door I want the door and the hinge to open or animate by rotating around the same axis…
I have made the two parts and made them animate the way I’d like separately.
I now want to combine the two parts that animate into a singe component.
I think I want the door to be the parent component and the hinge to be the child component.
What I think I want is when a user clicks on the door I want the door to animate and the onClick to be passed to the child component i.e. the hinge and have it animate at the same time.
Can someone show me how this is done?
Door_Hinge_Inherit_Click_001.skp (1.1 MB)
Here is the file with the two separate components.
Thanks in advance.
I explained how I would do it in the other thread.
You misunderstood what I said. Model objects cannot inherit attributes, which is what an “OnClick” field is. (I was speaking more about the Ruby implementation “under the hood,” and how the physical component nesting should mimic the class hierarchy. But perhaps I wasn’t clear.)
For cross-ref:
[url]http://forums.sketchup.com/t/cant-select-rotation-points-i-need-to-make-component-dynamic/27255/5[/url]
But back to your question, …
You qualify child or sibling components (by name) from within the DC hierarchy, and can refer to the parent component as “Parent!”.
The contents of the outermost wrapper (clickable) component’s “onClick” attribute can contain a list of animate functions to execute.
=onClick(
ANIMATE("Door!ROTZ",0,-90),
ANIMATE("DoorLeafHinge!ROTZ",0,-90)
)
… or you put the rotating sub-components into a wrapper sub-component and rotate that, and they’ll ride along:
=onClick( ANIMATE("DoorAssembly!ROTZ",0,-90) )
Any other sub-components such as the “FrameLeafHinge” and “DoorFrame” components would (and should) remain stationary.
By the way, have you seen this wikilist ?
… and in the Tutorials section, there is a link to a tutorial right hear on the forums:
Hi Dan
I apologize for being dense but your explanation makes no sense to me.
Both parts do exactly what I want them to do.
I need to tell the child when the parent has been clicked on that it has been clicked on because it is encapsulated by the parent object…
In object orienting programming parlance I’m passing an onClick message from a parent to a child[ren]…at least I want to do that.
I tried something similar to what you wrote above and whilst it rotated the door properly the hinge rotated along with it in the closed position because of the way the hinge operates.
In the hinge component only the two loop portion of the component rotates whilst the three loop stays stationary.
I don’t want the whole hinge to rotate.
I want the three loop portion to stay at the door jam.
In your example I’m not understanding how I get the behavior of the component which is the rotation of a piece of the component instead of rotating the whole component.
I don’t want them to ride along I want them to exhibit their behavior that I endowed them with.
Does that make sense?
I apologize again for being a doofus but I’m not getting what you are saying even a little bit.
obviously I’m missing something very fundamental.
No kidding, … in the other thread I had said:
The pin and the frame leaf which would not rotate, so they’d be wrapped into a component attached to the frame.
Basically you are not listening.
You do NOT tell child sub-components that the parent was clicked.
The parent WHEN CLICKED, tells the child components TO ANIMATE.
I showed above how to do this in the parent.
Since a picture is worth a thousand words, this is a graphic representation of the component hierarchy as it should be.
The “DOOR_ASSEMBLY” sub-component rotates. The “FRAME_ASSEMBLY” sub-component stays stationary.
Hi Dan
Sorry I don’t know what I don’t know because of that I kept trying to map things on to the paradigm I’m familiar with.
In the other thread you told me that SU was object oriented in design.
So I’m thinking I design my component give it the ability to do what I want and then reuse it.
From the handy diagram above it is now abundantly clear that is not going to happen.
So to reiterate what you been trying to tell me is that I have to deconstruct my component and use the pieces to construct another component and animate those pieces to get the functionality I need.
Umm not very object orientated or at least a poor implementation in my mind.
I likely can make that work from my previous experiment the trouble was I kept trying to avoid busting up a perfectly functioning component.
It would make much more sense to me a long time (I was object orient programming before object orienting programming was cool…remember small talk?) object oriented programmer to make one of the function calls like animate or ROTz onClick and be done with it.
If I call this function then you know you have been passed a click from above so do that thing that you do when clicked?
This paradigm means you get no reuse from components at least not the way I am used to reusing components.
In this case you can reuse the whole door but not the hinge component because it is spread across two components the door and the frame.
What if I want to use the door in a different frame?
I can’t just place a door in a new style frame I have to break the frame out of the door or the door out of the frame and then build a new component that has the door and the new style frame…that just feels clumsy and like a huge waste of time.
Anyway thanks again for your help and patience.
Once I get it working I’ll post my results.
It is “under the hood”, and so is Ruby. But not the DOM.
Just forget everything I said, and go buy a book. I’m done with this. (Setting this topic on ignore.)
Why not just split the hinge into two component halves? One half (the static half) becomes part of a Frame assembly, and doesn’t move. The other becomes part of a Door assembly, which is animated and rotates with the door when the OnClick is triggered
2 Likes
Hi John
I could certainly do it that way and that would solve the problem in this instance but I’m trying to learn/ figure out the best way to use SU/ get the job done instead of anyway to get the job done this time.
That approach in my mind creates a problem of re-usability as I said above what happens when I want to reuse the door with the hinge or just the hinge in another design?
Let’s take the case of reusing the door and hinge with a different frame, I need to go get the door with the two loop piece and then go get extract the corresponding parts from the frame.
I lose all the information of the orientation of the rotating hinge parts to the non rotating hinge parts and have to recreate that information.
I still think there is a little/slightly better approach.
I’m going break the hinge into its parts, the two loop, (the three loop and pin) and put them all in the door component.
I will animate the parts I want to rotate in this case the two loop and the door and not animate the three loop and pin pieces of said hinge.
Now when I want to use the hinge again I only need to look in one place to get all the hinge parts for reuse and the placement relative to each other is preserved.
Said another way the hinge parts are not scattered around among the various components…birds of a feather and all that…
I’m only making changes to one component instead of two which is slightly better in my mind but still a huge huge bummer compared to placing a hinge (with its functionality preserved) as a child in a component and going on with my life.
Door_Rotating_On_Hinges_001.skp (1000.5 KB)
For anyone that cares
In an object oriented programming paradigm you would build an object (a hinge) endow it with the functionality that you want (encapsulation) and then you would include it in more complex object.
I would actually give it multiple behaviors I could rotate the two loop or the three loop piece and when I instantiated it I would tell it how I expected it to behave when it received an onClick message e.g. new hinge(rotate_2) or new hinge(rotate_3).
(The way the component interface it is written this could accomplished this by checking a box.)
I would never have to worry about which part rotated and which part remained stationary again.
But I still would have to add the hinge to the part that rotated in order to get the onClick message from my parent as it would be very un-intuitive to click on the frame to open the door but there would be nothing stopping you from building it that way.
If the DCM (which I believe means Dynamic Component Model) was object oriented then I could create the hinge as suggested above and include it in any other object and its functionality would be preserved.
Because SU is written in C++ and Ruby both object orientated computer languages I assumed an OOP paradigm would be followed in the design of the DCM.
I reckon this was a I can get it working quick or I can get it working right decision.
It was real Debbie downer moment when it finally dawned on me what Dan was trying to tell me all along.
No Virginia there is no object oriented Santa Claus when it comes to SU animations.
I was flabbergasting that the DCM did not follow OOP convention.
I can not fathom the reason for this it makes no intuitive sense to me and makes SU animation very weak or at least more work that it needs to be.
My hope in going on about this is that the ancient ones might consider moving in that direction as it seems a shame not to in my puny mind.Door_Rotating_On_Hinges_001.skp (1000.5 KB)
It’s actually pretty easy. Just add an OnClick function to the highest level of the DC. Have the OncCick animate the change in a “placeholder” value (in this case, the “SpinDoor” attribute. Have half the hinge and the door reference that value.
This is the way to do it (not just getting your job done, but the actual solution).
Dynamic components are not, strictly speaking, object oriented programing. They are a unique creature, inheriting functionality from various solutions.
Hi Aaron
I have no doubt that this is the right answer.
From what little I have learned thus far this makes perfect sense.
And I would add makes more sense than calling functions for each component so it is more efficient code wise in my mind.
We are still in agreement here also.
But if it were up to me (it certainly is not) dynamic components would/should still exhibit OOP type behavior.
Right now when you give a component a behavior and you want to reuse it in another component you have to recreate that functionality each time you reuse the component.
What I’m saying is that if you got rid of the door in your example above then your hinge will stop working…there is no encapsulation of hinge behavior and the hinge pieces as an independent entity.
Does that make sense?
Also if DCs had polymorphic behavior you could add to the behavior[s] (see above rotate the three loop and the two loop) and when you instantiate a new one i.e. make a copy you could (by checking a box or other means) tell the new component what behavior to exhibit when it receives an onClick message/event.
Here is where I would beg to disagree with you here about the “inheriting functionality” part…at least the part[s] I can see eh?
I would describe your example (and mine and Dan’s) as a flat model where the scope of animation functionality is all exposed at the same level instead of encapsulated with each component.
The door component doesn’t really contain hinges as they are part of a group you can tell the group what is going on by calling each group member’s function (the way I did it in my example like Dan did it) or you can make each group member aware by updating a attribute/global variable in your example “spindoor”.
Either way when you copy a hinge the functionality is lost.
No disrespect but I think that the ancients should grok this.
Thanks again to everyone for all the help I am very grateful.
Especially Dan it wasn’t my intention to try his patience so.
I’m honestly trying to learn best usage techniques and practices instead of only the answer to my immediate problem…which I’m not trying to discount either…sometimes you just need to get things working and don’t care about the why.