Walking .FRM frames alignement: aaarghhh.

S

Sirren67

Look, Ma! Two Heads!
Question for Wild_Qwerty or whom ever who knows:
I'm making the walk .frm for a two legged critter. I added a whole animation with the first aa frame at the end and beginning of the chain. It jumped and looked slidy (the bot feet slided on the ground). I reopened the .frm and used the del scripts to get rid of the standard aa frames. The animation jumped even worse, even if the animation was less slidy.
Remade the frm with the walk script, opened it manually and got rid of the last frame. It jumps like mad.
The point is: I don't know if it's me, but I got the feeling that the walk script doesn't align frames in a straight line... It's more a rounded curved line... No surprise that the animation jumps even with aa frame at the end. I also noticed that in a given .frm not all orientations jump in the same way: east/west tend to be steadier, whilst sout east/west tend to jump the most. When I made Andy's walk .frm I simply placed manually all the frames. This critter will have three or four walk animations, and this makes a *lot* of frames... Am I using the scripts the wrong way? Any leads?
Thanks in advance.
 
I will post it here ;) Let's keep "technical" problems with making FRMs in one thread ;)

Movement animations are very tricky. To get my test animation into correct direction of movement (without any "twisting" or "jumping") I must:
- SE direction -> rotate view of -12,5,
- E direction -> rotate view of 57,5,
- NE direction -> rotate view of 57,5,
- NW direction -> rotate view of 69,5 (strange situation: difference of angle between SE and SW is 65),
- W direction -> rotate view of 55,5 (different angle than E),
- SW direction -> rotate view of 55.
and still on long "distance of movement" effect of "twisting" is little visible ;)

I've used animation which is moving "forward":
nonameee8.gif

and of course no "walking" scripts with Autocutting option on (and I'm not fully satisfied with the effect ;) ). When I'm using Autocut option on the last stage on making FRM animation looks tragic.

And I don't tested Sirren67 method yet ;)
 
I'm not sure if this is usefull. But it might help with a bit of luck, for the record I think this hex it the correct sie, but it was quite hard to measure the distances so it could be incorrect.

The hex measurements is in pixels.
hexsize8pksk8.gif
 
For movement in a straight line (blue color) responsible is First Frame Offset.
imagelq4.jpg

When you're changing At Y into "-" (-1, -4, etc.) animation is "twisting" to the north. If "+" (2, 6, etc.) to the south (green lines).

If you click on the button "Offset Wizard" Frame Animator will automatically adjust it.
snap028eo9.jpg
 
Hi there Gentlemen.
I managed to put together a working walk animation. Wild_Qwerty, your walking11.fas *does* work as is.
The process:
1) I made the aa animation. I didn't center manually my frames on an hex this time. I edited frames offsets at X = 0 and Y = 0 and goodnight. Let the engine handle the frames.
2) I prepared the walking animation. It's 9 frames long, with frames number 1, 5, 9 being standard aa frames. The model walks on the spot.
I centered the first frames with the frames offset button , saved the project and automated it with the walking11 script. After my ab .frm was ready I realized that I had autocut on, but I decided to give the .frm a look.
If compared to original critters this ab animation has a quality rate of approximately 97%. It's a bit slidy, but it's probably due to the fact that the frame chain is two frames shorter than it should. I'll try and add 2 frames and see what happens. (Can somebody confirm or deny this?)
I really, really hope this new critter isn't simply a lucky shot. I'm positive that when they made the original games they had a somewhat simple method to concatenate aa / ab animations. They had a *ton* of critters to do, after all...
Should anyone try this method, please let me know about the results.
Cheers.
 
just remeber that with running FRMs the movement is approximately double and the frames per second is increased.
 
Sirren67 said:
I'm positive that when they made the original games they had a somewhat simple method to concatenate aa / ab animations. They had a *ton* of critters to do, after all...
Click to expand...
Of course they had. Critters probably were centered by one, the same point, not by frame size (like in Frame Animator). Every critter was rendered in the same view, so everything looks perfect. That's why you can't find any formula for it.

I stuck as hell with this f***ing (:mrgreen:) Frames Offset in movement animations. I can't find any "method" for First Frame Offset (I've checked the original ones - almost every direction in every armour animation has different X and Y coordinates - but they're "powered" by the same animations). And this is the most important thing - from it depends how looks movement. When character is moving one hex - used are first four frames (I think), when he's moving two hexes - whole set of frames is used. Little changes in First Frame Offset and character is "sliding" instead of moving, animation is slowly "twisting", there's no good "passage" between first AA frame and AB animation (and vice versa). Problem almost doesn't exist with E and W direction (they're walking on straight line).

I can't work with animations which are moving "on the spot" (I prefer those than moving "forward" - it's better to control and adjust lights, shadows on the ground for each direction or adjust angle of view for renders - NE, SE, SW, NW). Frame Animator's scripts don't work like they should. Maybe I'm making something wrong, I don't know. I tried different ways - result is always the same. Ok, this isn't such big problem I can play around it and adjust the lights and new trajectory of moving "forward" for different orientation, but... there's no "formula" for NE, SE, SW, NW direction. There's no 60 degreess angle between each orientation. I've maded "almost" ideal AB animation, but without shadows (it's better to control right direction of the movement, by checking how feet are "moving" ;) ), but when I've added them, everything was changed :?
 
Hi Continuum.
I made a test animation for Beyond Good and Evil mod lately. I used the same method I described in this post and got good results (I used the walking.fas). Mind you, aa/ab alignement is not 100% perfect but it does work. This time I managed to make shadows which aren't as small as the original ones, but they have the correct orientation and practically don't get in the way. Yes, as I alredy said and you're pointing out shadows play an important role in animation .FRM centering. Did you try to *only* center the aa and ab animations by only setting x and y frames offset to zero? Critters aren't really centered on hexes, but I think the result is good. Please let me know.
Cheers.
 
Yes, I centered frames in X=0 and Y=0, but I must know one thing: what X and Y coordinates do you have in First Frame Offset in your movement animations? Is there only X=0 and Y=0 for each direction?
 
To tell the truth I simply didn't set them. I opened the last test ab I made and apparently the different first frame offsets were set on X=0 and Y=0 automatically. And yes, that makes zero for each directions.
 
Ok, I centered everything in X=0 and Y=0 (Frames Offset in AA, AB and First Frame Offset in AB).

I can confirm that centering Frames Offset in X=0 and Y=0 is good solution. But First Frame Offset (X=0 and Y=0) isn't good. When I moved character one hex - everything is looking fine, but more than that - not. I also tested this method with original animations - result is the same.

But I don't know how everything is working in your animations maded in this way ;)

I think FO2 engine is using First Frame Offset to determine how many frames is used when character is moving one, two and more hexes or to get ideal concatenate between AA and AB without any "sliding" (X values). I wrote above what's happen when you're changing Y values.
 
For adjusting the position of where the FRM starts you need to use the Frames Offset, but this should be set to x= 0 and y= 0 for every FRM except AA which is centered.

If you adjust the first Frame Offset of any of the other FRMs (like AB for example) it wont take effect, I think I left that adjustment in the scripts and couldnt be bothered removing it because it had no effect.

The FO2 engine automaticaly aligns the first frame of a enw FRM with the position of the last frame of the previous FRM. So the engine overides the Frame Offset of frame 0 for each FRM.

So you migth as well set frame 0 to have an offset of x = 0 and y = 0.

So it's possible that Frame Animator will look different to who the FRM moves in game because Frame Animator will show the frame offset for frame 0.

I still recomend that you guys both delete the frame animator scripts from your computers and just render the critter moving forward rather than on the spot. If you give me the rendered images I can have a go converting them into FRMs if you want.

For new critters you probably wont notice a small error in its movement, but with the new armours that will be overlapping the original critters it could cause a problem if it doesnt line up correctly.

Maybe Lisac2k could answer how he made the girl critter.

I've grave dig a post up here later by Jochua on the correct orietations.
 
Wild_Qwerty, your scripts do work. As far as I'm concerned I'm getting good results with the method I described above -not to mention the fact that I'm having huge troubles in having the critter to *actually* walk in Anim8or... My main concern now is to make good walking animations... That's still my weak spot...
 
Okay thats cool :) I found this post by Jochua (the guy who made frame animator)

Jochua said:
'Offsets' in the project-file is an internal performance of the FrameAnimator. It is absolute offsets of the BMP-frames. Be not guided by them. The real offsets, which are written in a FRM-file, calculate dynamically and depend on the current options: autocutting and background colour.
Click to expand...
 
So critter .FRMs should be always made with autocutting off, and then automated with the autocat.fas? And what about the background color? If I remember correctly Fo2 engine considers fucsia to be clear, along with pure 255 blue. But what's the deal?
 
Yes, Autocutting should always be off.

not sure on the background colour part, but as long as the frame animator makes it transparent you should be okay, I think that converts it to the right colour.
 
You must log in or register to reply here.
Back
Top