Phew! It’s been a year of development.Finally what I had in mind is somewhat complete.There is still work to be done but I decided to post it and have anyone who is interested, start playing with it. It should work anywhere…but I did test it only on my own computers(1 desktop and 2 laptops, one with Nvidia and one with AMD cards).
For now only GitHub is active. I’ll update the Gumroad as well.
I have found an issue that goes against the concept I have for the scripts,i.e. that the script will change the timing of the keyframes the user has,but keep the pattern.In other words if the user has keyframes on one fcurve in one frame but does not have a keyframe in that frame position in another fcurve this pattern should be preserved.
And right now the script does that,but only for one object.Basically the script knows the pattern of the keyframes only for one object at a time.
But what happens when we have multiple objects(controllers) that for one reason or another don’t all have keyframes on the same frames that we want to manipulate?Well I expect that this pattern will be modified.I haven’t tested it,since I came to this conclusion while animating in max,because somehow I ended up having keyframes on one object(controller) and no keyframes in another and things worked and I did not wanted to go in an add more keys because of time limitations.
So my asumption is that the “push and pull”, and “nudge” will be fine. But the “come over” and “hold for” scripts will brake that keyframe pattern.
I think the solution is simple -basically bring the variables that store the keyframe data outside the " for object in selected objects" loop. But I guess I have to put time to do that, and test it.So at the moment anyone using the script should be aware of the possible issue.
If you always key all controllers for every keyframeyou have,most likely you won’t have this issue.But if somehow you forgotten then it will brake your pattern.
For “come over” there is a work around and that is to add a keyframe for all objects at the first selected keyframe.Since the script uses the first selected keyframe to calculate the distance to the “current frame”.
Updated the scripts I wanted to redo “Come Over” and “Hold For”.
They now respect the global keyframe position of all selected objects.I will add a gif soon for better explenation.
Note, that selecting only one object will affect only that object’s keyframes and not all objects in the scene…Makes sense but still to say it.You need to select all objects(controllers) to modify the other objects(controllers) timing.
Something I did not expected to happen,but in the end I coded it that way.But now you don’t need to select all the keyframes you want to modify(for the “Hold For”).Just the first and the last in the group of keyframes. Of course selecting all them also works.
I added a gumroad page.If after some time,you end up enjoying the scripts,I added this feature so you can say thank you in a more impactful way.But it’s free anyway.Also I archived the files so people might prefer that method of downloading than going to GitHub. Being a non programmer I know I hated GitHub links.
Started with just a simple exploration.Ended up with add inbetween.
Basically creates a keyframe in halfway point between two keyframes,based on the timeline position.If a keyframe is already selected(or after the creation) and the timeline is on the keyframe you can real time update the value by moving the slider.Thus you could create some kind of a blend towards one or the other value of the frame before and after the created keyframe(or the timeline position).
I could say that this is v0.1 of this script.I have some ideas: like to see if we have 2 keyframes selected. Then instead of modifying the values of these frames…to modify the value of the keyframe at the timeline position based on those two values.
Also when we have 1 keyframe selected…right now it uses the timeline to get the previous or next keyframes.This could lead to interesting effects but I want this to be left to the “if 2 keyframes selected” functionality.Thus make sure that if we have 1 keyframe…it will blend only between it’s previous and next keyframes.
By the way…it’s a bit unclear from the gif I made.But if you don’t have a keyframe selected,you don’t need to be on the halfway point to create it.It will be created automatically there and the timeline(current frame) will be moved automatically to that frame.
UPDATE
today i was trying the inbetween.And found one limitation and that is that if you are editing the key(updating it’s value),or adding a new key(creating the inbetween). It will be created or modified in all fcurves for the object.While when creating this might be your decision.When I was trying to use the script I found that I wanted the script to apply the changes only to one fcurve keyframe,and not all.So I went in and added a condition check to see if the fcurve that will be modified is visible.One has few options from the API - is the fcurve hidden,selected,or locked. So I figured that selected would make sense…but this means that you have to pre-select all the curves you want to modify.Also when creating a new keyframe,usually none of the fcurves are selected. So right now…if you want to edit separate fcurves with the inbetween slider…you will have to hide all the other fcurves.
Note: if you isolate and modify let’s say Xfcurve and then isolate and modify Zcurve(for example).If you then have them both visible or all visible then using the slider will give them all the same proportion.In other words…it will remove any difference like: on Xfcurve the keyframe was closer to previous keyframe,and on Zfcurve the keyframe was closer to next keyframe…If you have them both visible then applying the slider will cause them to get at the same precentage of distance.
I have managed to fix some things that bugged me.Like the fact that the script did not retain the pattern in the y value of keyframes.Like if the Z-fcurve keyframe is more closer to B than X-fcurve keyframe. But unfortunately,to have comfortable control of this blender’s slider widget have to reset back to some value when it is released by the mouse drag.However Blender devs, have not considered to allow users to work with a button or slider’s -press/release states so we can fire commands when we have those states.Thus at the moment development on this is stopped.I made a workaround…which is kind of OK but no doubt the user might find it awkward …so I won’t be posting that as well.I’m looking in to building my own ui using the bgl module and OpenGL.But at the moment I have no idea how to do anything.
Things with the idea of making an custom ui is taking more than I expected and I have no idea how longer will this take. Not because I lack knowledge on how to do it. But the bgl module is not working the way I would expect it to be working. Either I’m not doing something right or the module has issues when you interact with it directly. Otherwise I can do pretty much everything I need in pyOpenGL,so it’snot a matter of me wondering how to do it.
Lately I’ve been working with grease pencil, doing storyboards. Mainly I use Krita but at times I switch to Blender. And I really felt a need to have the scripts from Keyframe Nudge work with Grease Pencil. So…I finally put some time off and reworked the push/pull script and made a blender UI panel for it as well.
Eventually when I manage to have bgl working,I’ll just make a toggle for it, in the panel I plan to work on. And I was thinking that another option is to have the script work for both object keyframes(scale,rotation,translation) and grease pencil keyframes(layer keyframes).So we won’t be switching between the two when we push around keyframes for GP objects.
Anyway here is the Grease Nudge repository link :
Phew…Finally I have it setup and working.
It’s buggy and some of the scripts need to be reworked(because now I have a bit more knowledge of python and blender API).
It’s almost a year now…since I went on this road. And I finally reached what I wanted to do.
Again, buggy as hell at the moment(including it crashes blender)…but it’s nice to see it finally working as I wanted.
Just to Bump the thread.
But also give an update.
I finally managed to complete the addon. At least one stage of it. There are some things to be done in the UI, but for now I will focus only on porting the scripts for GP for the GP mode.
As mentioned in the first post, I found out that the scripts before , worked only with objects in object mode. No doubt they didn’t do much when it came to rigs in Pose mode. But now…I think it should work. I tested it on a simple rig but didn’t had issues in the end.
Will do some video guide on each tool, and post it on youtube. There are some 'don’t do x,y,z ’ as there are things I need to fix in the UI. Also I would like to explain the scripts a bit more.
Unfortunately I have to slow down development. I wasted a lot of time trying to learn this and that, and also used work time for development. This led to a not so good financial situation and I have to dedicate more time for that. Still there will be development, just a bit slow. You can probably say “well it’s not like there was any frequent updates before” ,yeah well I didn’t post updates but I did worked on it.
That’s it for now. I hope the thing works on everyone’s computers.
To be honest I don’t remember.
But I looked at the code…and yeah it’s not a modal operator. The thing is, that you can add any function to VIEW_3D draw handler and you will have something like a modal operator, because it will execute on every rendered frame.
But the problem is that blender does not give you access to mouse or keyboard input from a property in the blender scene data(for example) so you have to make a modal operator to get the mose-XY and events and plug those in custom scene properties. That way you can access the properties inside the draw loop without the draw loop being a modal operator. That’s how I did it. But to be honest I don’t know why it worked. Because in the draw loop the custom scene property works, but outside of it, it didn’t…so go figure.
Another problem is that you have to make some switches to control when to render and look for mouse input or shut it down. Maybe a better way was to make it a modal operator, but I didn’t like something back when I started the UI.
Again to be honest I don’t remember how and why I did things…I was fiddling with the adding the Main draw function to VIEW_3D back in May-June.
Which reminds me…Ton said once on blender Today, that he wants the Python API instead of some other language like C++ or Java, because with Python you cannot crash blender. Um…not true.I crashed it almost daily, most of the times it hanged when some value isn’t there. But I suppose that is because I plug everything in to the draw function, and if something is not the correct type of value it will hang on that function and thus hang all of the draw code for the whole Blender. But that’s something I speculate about, but I’m not sure it is so.
Ok I added Grease Pencil Push\Pull to the Grease.keyframe mode.
Now you can do the Push\Pull to GP keyframes.
Archive in Gumroad updated, Github repository updated. Readme in Github updated.
I fixed some issue with a test file I used to find a way to link files properly. It was giving an error that a specific directory does not exist. I’ve cleared up that file, and it should work. Eventually I should just remove it.
Last two nights I spent some time working on the Nudge script for grease pencils. And now can be executed from the UI. It’s behavior is similar to that of the Keyframe - Nudge script. Except that it follows the logic I have in mind for grease pencils:
It should modify the position of all keyframes in all layers in a GP object that share the same frame number. Thus all keyframes on all layers that are on the same keyframe number as the selected keyframe, will be changed.
Known Issues
I saw that I missed a check for locked layers - the idea there is that you can select which layers of the GP object to be affected by locking a layer.That way the locked layer will be excluded from the move.
I also noticed a small issue with the Grease Push/Pull script. Where if you have more than 1 keyframe selected in one object. Only the keys after the first selected are getting moved.I’ll look in to that soon and figure out what’s going on. The script works fine as long as you do not select more than 1keyframe in the same GP.
Lol, you can totally see that I knew little about blender when i started doing these scripts.
Today I found that you can move a keyframes to timeline position(current frame). Which was the idea behind the ‘come over’ script. Which kind of makes the script obsolete, but it does have a different behavior than the built in function. Since that function works only with selected keyframes, while ‘come over’ works with the selected and everything after it.
But that pie menu gave me some ideas of future scripts.
One would be a modification of ‘nearest second’ but nearest to the timeline marker. I think that would be interesting.
Also the guy who mentioned the shift+s menu in blender.chat, said he wanted the ‘key to cursor’(current frame) function to have an offset. Which gives me an idea about having the ‘come over’ script have an offset. Basically from all the scripts(except the inbetween) only ‘come over’ does not use the value input field. So it would be interesting to link it that way. But I have to make sure that in the UI you can alternate between the mode we have now, and the one with the offset.
It’s not part of the keyframe.nudge addon. I’m not sure should I add it. Also the guy said, and I agree, that for a good workflow he does not want to go to other editors and click buttons or ‘run’ script every time. So I learned a bit, tested a bit, and I made sure that when you install the addon(‘script’), and when activating it it will automatically add it’s operator to the snap pie menu(‘shift+s’) of the Graph Editor.
But there is one more requirement, and that is to restart blender. Only because the graph editor pie menu is inside a startup file called space_graph.py . Which unfortunately will not get re-loaded when you click the refresh addons button or command. So you end up with the old(‘unedited’) version until you restart Blender. After that it should work. And when you deactivate the addon\script it will remove it from the pie menu as well.
To be honest I don’t know how layer animation works…both in blender and maya. I used to animate in 3ds Max and even there I never used it because it almost never worked for me.
Maybe post in the Support>Animation section.
