Bone morph dials script
Moderators: Víctor Paredes, Belgarath, slowtiger
-
- Posts: 279
- Joined: Thu Mar 30, 2006 6:12 pm
- Location: Verona, New Jersey
- Víctor Paredes
- Site Admin
- Posts: 5765
- Joined: Wed Jan 26, 2005 12:18 am
- Location: Barcelona/Chile
- Contact:
This works great! I did have to "relink" the scripts.
The one thing I need to play around with and experiment with is the location of the controlling layer. I would like to be able to use this WITH other "systems" so it doesn't take over complete control. This is FANTASTIC and has amazing potential. I just need to do more experimenting to see how it will fit into my current workflow.
-vern
The one thing I need to play around with and experiment with is the location of the controlling layer. I would like to be able to use this WITH other "systems" so it doesn't take over complete control. This is FANTASTIC and has amazing potential. I just need to do more experimenting to see how it will fit into my current workflow.
-vern
-
- Posts: 279
- Joined: Thu Mar 30, 2006 6:12 pm
- Location: Verona, New Jersey
Yeah, Vern is right. I keep all my embedded scripts in a separate directory to my anme files, so you will have to relink them. The controlling layer needs to have "rt_gen_morph_weights.lua" embedded and the controlled layer(s) need "rt_apply_morph_weights.lua". What was the lua error message you got, by the way?slice11217 wrote:I downloaded the file but alas, it didn't work for me. I got a lua error message and the bones appeared to be absolutely disconnected from the vector layers.
And yeah, I don't mind that I didn't get feedback straight away. We're all busy and besides, it's given me a chance to get back to my nudge scripts.
Oh and Vern, I could have sworn that it used to play nicer with an existing bone rig than it does now. At one stage I had a bone for the head that I could rotate around and all the morphing happened relative to whatever the current head position was. I think it was because I used to apply the resulting delta morph to fPos instead of fAnimPos(moho.frame), but that had strange results when you didn't have a parent skeleton. I don't use bones much in the conventional way, so any input you could give would be very valuable.
Yep, you at least need to put the "rt_bake_morph_dials_script.lua" in one of the menu directories, then it should work.slice11217 wrote:OK, so when I loaded in the embedded "gen" lua file this is what I got for an error message:
and when I scrub the timeline I get this:
I noticed that there are scripts for the menu and tools, do those need to be installed first before running the embedded script?
I haven't really tried it out yet. i just know when using "fPos" the controlling layer MUST be under the other layers.Rudiger wrote:slice11217 wrote:
Oh and Vern, I could have sworn that it used to play nicer with an existing bone rig than it does now. At one stage I had a bone for the head that I could rotate around and all the morphing happened relative to whatever the current head position was. I think it was because I used to apply the resulting delta morph to fPos instead of fAnimPos(moho.frame), but that had strange results when you didn't have a parent skeleton. I don't use bones much in the conventional way, so any input you could give would be very valuable.
-------------------
I finally got that whole thing explained in detail by Mike. Here's what happens...
All the layers are updated "in order" from top to bottom. A controlling layer ABOVE a controlled layer tells the layer to do something but doesn't create a key frame (fPos). This is only a temporary change to that layer. Then when the CONTROLLED layer does its thing it just "over rides" whatever the previous layer told it to do. The change was only temporary. So you must put in keys if you want the changes to "stick" if you are controlling a layer with a layer higher in the order.
I ended up "duplicating" the keys with the script I was working on. Instead of putting in keys on every frame (which would be the default) I added and removed keys based on the controlling layer. This could be done easily with your script. Each bone key would place a vector motion key on the effected vector layers. If the key is deleted from the bone layer then the keys are removed from the vector layer. Would keep the file smaller.
The main problem I have is that a ton of key frames can really bloat AS files. Makes them huge... I mean freaking huge. Key frames probably take up the most space in an AS file in proportion to the code for a layer.. especially point motion keys. Using bone fPos is much more efficient since vector point motion requires a lot more info in the file for storage than a bone key.
That is another HUGE bonus of this script. All of the point motion isn't stored in key frames, it is stored in compact tiny bone keys . (Imagine if my physics scripts were actually key framed. I have a TON of motion in those things and the files HAVE NO KEY FRAMES! NONE! Just one key frame for one bone on frame 1. ) Without all of those keys and huge bloated files there is less chance of having a file get corrupted during a save... although I don't really worry about that so much. It did happen to me just last week though.
Of course the bonus of having keys in the vector layer is that the file or animation still works even if you don't have the script (like your baking the actions).
-vern
Thanks Vern, that is very helpful. It would also be great if we could come up with some sort of a flow-chart type explanation that describes exactly how the final position of a point is determined following a particular event.
1. Wait on event
2. Set point.fPos to point.fAnimPos(moho.frame)
3. Check for ParentSkeleton. If exists, multiply point.fPos by combined BoneMatrix.
4. Check for embedded layer script. If exists, run it (may or may not affect point.fPos).
The above is just what I'm guessing happens, but I would need to do more experiments to make sure.
1. Wait on event
2. Set point.fPos to point.fAnimPos(moho.frame)
3. Check for ParentSkeleton. If exists, multiply point.fPos by combined BoneMatrix.
4. Check for embedded layer script. If exists, run it (may or may not affect point.fPos).
The above is just what I'm guessing happens, but I would need to do more experiments to make sure.
-
- Posts: 279
- Joined: Thu Mar 30, 2006 6:12 pm
- Location: Verona, New Jersey
Yeah, that was bound to happen. When you're aware of all the operations that happen for each frame it's a miracle that it could ever work in real time at all. My only suggestion would be to disable the real-time effect and bake in the keys on every frame instead. You will get perfect playback and you will also be able to morph more than just the point positions.kefen109 wrote:I tried the scripts and It is wonderful.
thats the script that I waited for that software.
But If you make more points the software crush.it is hard to play the timeline.
what could we do for this?
Hi y'all,
Wow I seem to have missed out on some interesting stuff, too busy
This looks amazing Rudiger!
I will have to bend time to get to have a go with this, cool stuff.
Edit: had a little go but I'm just not getting it yet. Dang. Is it meant to give immediate feedback like the old array script, or does it not display results until baked?
I am obviously missing something here.
Wow I seem to have missed out on some interesting stuff, too busy
This looks amazing Rudiger!
I will have to bend time to get to have a go with this, cool stuff.
Edit: had a little go but I'm just not getting it yet. Dang. Is it meant to give immediate feedback like the old array script, or does it not display results until baked?
I am obviously missing something here.