[Plugin]$ Keyframe Animation
-
@thomthom said:
Living in one of the most expensive countries in the world (a cinema ticket here is about 15$) I can't charge a price that fits the poorest - then there'd be no return value at all.
OK, how about this then; you make the plugin and I collect the money?
-
You getting into Hungarian mafia business now?
You'll be asking me for "protection"? -
It was just a gentle "offer".
(Now let's stay on topic...) -
I think $19 is fair considering it has a trial period and it's open licence on private use. Also any future upgrades are bundled in. Compared to tgi3d it's peanuts. I know there's more in tgi3d but so far RP has offered his plugins free. Time to reward his efforts.
@ Csaba
On topic enough?
-
-
@thomthom said:
The complexity of a plugin can not be determined unless you've seen the code for it. A plugin may appear very simple to the user, but be doing very complex things under the hood.
Sure, but your missing the point.
Just for the record, I think the UK is now catching up on Norway
Open licence on private use? Sorry I didn't see that.
Fair enough then! 
-
This looks really great -- I can do almost all of that with Dynamic components (except export) in Sketchup Pro but for Free version users who want that functionality this plugin is truly a bargain at roughly $480 less.
Best,
Jason. -
I'm sure it is Jason
-
This is a great plugin. Animation in SU is something that is so weak and this plugin will definitely help fill the gap in a big way. I see some great ways to use this plugin. Nice job!
-
OK, attached are two illustrations. The illustration labeled "with", has Keyframe Animation 1.0 loaded. The illustration labeled "without" does not have Keyframe Animation 1.0 loaded. As shown in the two illustrations, Keyframe Animation greys out the bottom half of the context menu for workplane.
I am not smart enough to know why, I just discovered it.
Any help would be nice.
-
I installed Work Plane v2.3 to see what would happen. The menu isn't grayed out for me.
As I recall, the cause for grayed out menus was due to plugins that create UI::Command objects inside of context-menu handlers. If that is happening, it is not due to Keyframe Animation, because it does not create any UI::Command objects, and it doesn't even have any context-menus.
Is this bug reproducible? If you remove KFA does it go away? If you reinstall KFA, does it come back?
-
@regular polygon said:
I installed Work Plane v2.3 to see what would happen. The menu isn't grayed out for me.
[attachment=0:1cscrbxh]<!-- ia0 -->workplane_context_menu.png<!-- ia0 -->[/attachment:1cscrbxh]
As I recall, the cause for grayed out menus was due to plugins that create UI::Command objects inside of context-menu handlers. If that is happening, it is not due to Keyframe Animation, because it does not create any UI::Command objects, and it doesn't even have any context-menus.
Is this bug reproducible? If you remove KFA does it go away? If you reinstall KFA, does it come back?
The two illustrations show KFA installed, the "with" illustration and KFA not installed the "without" illustration. There is no model, no other activity except, open Sketchup, make a workplane, and context menu select the workplane to arrive at the two illustrations. And yes this is repeatable.
Ken
-
I think this can occur if a user has an unusual high number of installed plugins. Possibly SketchUp has a limit to how many menu items it can manage.
-
@thomthom said:
I think this can occur if a user has an unusual high number of installed plugins. Possibly SketchUp has a limit to how many menu items it can manage.
Well, Thomthom, that would be me.
-
So far, I think only some of Fredo's older plugins has been identified to leak UI::Command objects. If you updated all off these, and can verify that the number of Command objects isn't growing (using the utility in the threads that discussed this) then I think you may have run into a SketchUp limit that plugin authors can't do anything about. Until Google can address this I think the only thing you can do is be a bit more selective on the plugins you have enabled.
-
Very interesting.
That's an improvement. A toolbar would make me buy it.
The trouble with those "scene governed animation" is that nothing can be linked. So one has to move every bits and pieces every time.
I wish sub-groups will work in a future version. So a hand would follow the arm movement, added to it's own, for instance. -
@mariocha said:
Very interesting.
That's an improvement. A toolbar would make me buy it.Thanks for your feedback.
@unknownuser said:
The trouble with those "scene governed animation" is that nothing can be linked. So one has to move every bits and pieces every time.
I wish sub-groups will work in a future version. So a hand would follow the arm movement, added to it's own, for instance.I am not sure I follow you.
This plugin supports nested animated groups. So, if the hand is a subgroup of the arm, it will move with the arm. You can add additional movement to the hand also. Just open the arm group for editing, position the hand group, close the arm group, and save the component positions.You don't have to stop there. The hand group could have finger subgroups. The nesting can be arbitrarily deep.
-
Oh, I try that, did not work. The arm went bezerk.
I will make a more serious attempt.
This is indeed interesting. -
Ok, I finaly got it.
I was thinking one had to record the position of the inner group right after it was moved, i.e. while editing the main group. !! Wrong idea !!
So I succeded once I recorded all the positions while no group was being edited.
Maybe this could be indicated in the User Manual.
Thanks. -
Thanks for your persistence, mariocha. That is a good point. The group can't be open for editing when you record all the positions. When a group is open, all the positions are measured relative to the group's origin, not the model's origin, which screws everything up.
I updated the script so it warns the user, if a group or component is in edit mode, and prevents this mistake from happening. The update is version 1.0.3.
Advertisement