1. Summary
  2. Files
  3. Support
  4. Report Spam
  5. Create account
  6. Log in

keyframes implemented

Talk about ideas and the code.

keyframes implemented

Postby erin10 » Mon Nov 08, 2010 4:25 pm

The keyframes for the final stage are implemented. When the character reaches the finish line (defined by play_length) the time stops, of course, but the character goes on moving and brakes hard. When it stops moving, the mode changes to game_over, und the character is controlled by one of the following keyframes:
wonrace_keyframe: event, the race was successful
lostrace_keyframe: event, not successful
finish_keyframe: training, neutral keyframe

The keyframes are set in "course.dim" because they depend on the course. The existing courses are not appropriate, they lack an empty terrain behind the finish line. In this case no keyframes are used even if you define the frames, e.g. [lostrace_keyframe] tux_sad.lst. If the keyframes shall be used you have to enter [use_keyframe] 1. Default is 0.

There's another option. If there's enough space for the braking area the character needn't brake as hard as if the area is narrow or if the speed is very high. You can adjust the braking force with [finish_brake] xxx. Default is 20. With a lower value the character brakes softer.

At the moment I've prepared 3 courses for finish keyframes: Bunny Hill, Twisty Slope and Bumpy Ride. All bitmaps got 20 additional pixels at the end. For example the bunny_hill bitmaps:
height: 240 --> 260
width: still 90
course_length: 480 * (260 / 240)
playlength: still 470 (same value, same challenges)

@ CPicon
BTW: In the meantime I had a more intense view on samuel. There are some very nice parts, e.g. the moustache. Each whisker a sphere but on lowest level! Or the brim of the hat. First a wondered that the fellow was able to walk with one fin. You've only removed the entire right leg - ready. Good ideas and good work!
erin10
 
Posts: 90
Joined: Sun May 23, 2010 9:18 am

Re: keyframes implemented

Postby cpicon92 » Mon Nov 08, 2010 5:52 pm

The pace you get stuff done at is truly impressive.
The keyframe system appears to work nicely. The keyframes themselves aren't blowing me away, though. I understand it's quite difficult to make them, since they are text files, but the way the characters spin around 180 without moving a muscle is quite disconcerting. Perhaps instead of making them spin around, the camera could spin around them.

First a wondered that the fellow was able to walk with one fin. You've only removed the entire right leg

About that. If you look at the following pictures:
http://upload.wikimedia.org/wikipedia/commons/7/74/Europ%C3%A4ischer_Seehund.jpg
http://upload.wikimedia.org/wikipedia/commons/d/df/Elephant_Seals_(2).jpg
You see that seals don't have legs. They have teardrop shaped bodies with flippers at the end. I tried to represent this in the Samuel character. Unfortunately this doesn't translate well to the animations. Seals never stand up and walk the way penguins do. In this video you can see one sliding:
http://www.youtube.com/watch?v=kETuQblI4tg
All of this seems to make specifying animations on a per-character basis necessary. This is especially evident when you look at the sad animation for Samuel, his feet get contorted.

That said, these animations still look much better than having the character stop in midair. I will work on elongating the courses as soon as I've finished with character creation.
cpicon92
Site Admin
 
Posts: 89
Joined: Mon Apr 19, 2010 12:51 pm

Re: keyframes implemented

Postby erin10 » Tue Nov 09, 2010 11:33 am

The pace you get stuff done at is truly impressive.

For me, I've set a time limit. The rewrite must be ready for a release this year. Nothing happened for a lot of months, that's too long time. Soon or never !!!

The keyframes themselves aren't blowing me away.

I admit that the frames are not good. But I can't present new code without a little demonstration. Is it a problem? We needn't use keyframes as long as we don't have satisfactory frames.

... the way the characters spin around 180 without moving a muscle is quite disconcerting

Maybe there are other ways. A track like a bow, for example. But the problem of the standig-up aninmation still exists. See commercial Tuxracer where this phase is simply skipped. And the camera spin around the character? That's almost unrealizable. The algorithm for calculating the view position (and direction) is extremely expensive in Tuxracer.
No, There's no alternative to braking, standing up and spinning around. Perhaps it will take less effort to write an special tool (similar to the char tool) than editing the keyframe file. I'll deliberate the situation.

You see that seals don't have legs...

I'm afraid this is a misunderstanding. Of course, I do know what a seal looks like, and I know how they move. As I said, graphics, characters, motion rules etc. are not my affair. I only was impressed that the CODE works "with one leg" and that's possible to shape hairs by defining ellipsoids.

All of this seems to make specifying animations on a per-character basis necessary.

Agree. That will influence the code, but first we must exactly specify:
What shall happen when the character is steering left or right? Which joints, which rotations, which angles?
What shall happen in case of braking, flying etc? When we have an complete list of those actions, for each possible character, the procedure can be normalized. "Normalized" doesn't mean that all characters are animated in the same way, it means that there is a port with normalized parameters that allow to control the animations individually. At the moment the function is strongly focused on Tux with his given body.
erin10
 
Posts: 90
Joined: Sun May 23, 2010 9:18 am

Re: keyframes implemented

Postby erin10 » Wed Nov 10, 2010 10:45 am

Let's stop this discussion. I've thought about additional help tools. Keyframes might be possible (in time). Animations are too complex to handle them in a passable time span, that must be done later. And now I'm going to deal with a keyframe tool. I'll be back in one or two weeks, with new keyframes or with the admission that it hadn't worked.
erin10
 
Posts: 90
Joined: Sun May 23, 2010 9:18 am

Re: keyframes implemented

Postby cpicon92 » Wed Nov 10, 2010 3:08 pm

Okay. If you think that's the right thing to do, it works well for me. I'm so busy with school right now, I wouldn't mind a two-week break from this kind of thing. I'll try to make another character in the mean time, though.
cpicon92
Site Admin
 
Posts: 89
Joined: Mon Apr 19, 2010 12:51 pm

Re: keyframes implemented

Postby erin10 » Thu Nov 18, 2010 3:18 pm

Try the latest revision. See documentation "tools_keytab.rtf".

As suggested the keyframes are created on per-character basis now. The keyframe entries in course.dim are obsolete, in this file you only have to specify if the course is suitable for keyframes. Though different characters may have same keyframes, each characer folder contains a complete set of frames. That's a bit redundant, but only a bit. A keyframe takes less space than a small icon, for example.

I think all keyframes must be reworked.
erin10
 
Posts: 90
Joined: Sun May 23, 2010 9:18 am

Re: keyframes implemented

Postby cpicon92 » Sat Nov 20, 2010 9:30 pm

Firstly, sorry for not replying sooner. My school work has been taking up literally all of my time.
Now I must say that this tool is absolutely amazing. I'm truely impressed this time around, and I think that this will allow for a much better game experience for the end user. It's going to take some time to learn how to use it, though.
When is the proposed release for this version, because, if possible, I would like to have finished all the characters and keyframes by then. This tool will allow me to do that easily enough, I hope. I'm currently working on another character, too.
The documentation is quite useful, too. I'll try to convert it into a wiki page, as well, because openoffice uses too much ram on my computer.

EDIT: After working with this more, I can't seem to find a way to edit the keyframes used for paddling in-game. Where are they?
cpicon92
Site Admin
 
Posts: 89
Joined: Mon Apr 19, 2010 12:51 pm

Re: keyframes implemented

Postby erin10 » Sun Nov 21, 2010 10:42 am

It's going to take some time to learn how to use it, though.

Working on 3D models is not trivial, so a tool should be as intuitive as possible. There are some potential improvements (mouse actions, icons ...) but it doesn't make sense to realize them in a built-in tool. The tools blow up the code considerably, and it becomes difficult to keep track on the code.

When is the proposed release for this version, because, if possible, I would like to have finished all the characters and keyframes by then.

My suggestion was: end of the year, but don't be pressed for time. On the other hand, I don't think that all work must be done for the first release of the new generation. Anytime we should put the "cap on the pot" and retain some work for following versions. 2 or 3 characters and some nice keyframes (nice, not perfect) should be enough for the time being.

I'm going to do the last steps for this release: display of the course authors, player registration, perhaps highscore list etc. In my opionion, it's not important to present a perfect game, but the community must see that work is going on.

After working with this more, I can't seem to find a way to edit the keyframes used for paddling in-game. Where are they?

The in-game animations don't use keyframes with their static frames and linear interpolation. Animations are another affair, and that will be the third part of the character tools. There's no customizable interface for defining animations yet, and I can't code it in acceptable time. No, at the moment we must keep the existing animations.

If someone would help with the game code, I could focus my work on tools. Remember that we need an efficient course editor, too.
erin10
 
Posts: 90
Joined: Sun May 23, 2010 9:18 am

Re: keyframes implemented

Postby cpicon92 » Mon Nov 22, 2010 5:04 pm

I agree with everything you've said. I'll do my best to get the stuff done by the end of the year. I've got a vacation starting about 15 days before the end, so I should be able to get a lot of work done during that time.
By the way, there are two "last steps" which I think we might want to add on. The first being a course "progress bar," as you can see on the right here http://extremetuxracer.com/screenshots/040/3.jpg.
The second is Windows/Mac support. If I remember correctly, the current codebase doesn't compile properly under Windows, and nobody has tried it under OS X. A large portion of our user-base uses these OSs.
cpicon92
Site Admin
 
Posts: 89
Joined: Mon Apr 19, 2010 12:51 pm

Re: keyframes implemented

Postby erin10 » Tue Nov 23, 2010 10:02 am

I've got a vacation starting about 15 days before the end, so I should be able to get a lot of work done during that time.

Nice. January next year we can decide if we shall publish the rewrite as the next ETR release.

The first being a course "progress bar,"

That should be no problem at all though I can't promise that it will look like the bar of current ETR. You know, it's still impossible for me to use code from ETR.

The second is Windows/Mac support.

This task is beyond my possibilities. I'm not familiar with OS X and I don't have acces to a Mac. We reach a point where we are dependent from additional help. The same with Windows. BTW: It would be very helpful to have a windows version of the alpha. We need as many testers as possible, I'm waiting for suggestions, bug reports etc. I'm sure to be able to fix most bugs but I'm NOT able to detect all bugs.
erin10
 
Posts: 90
Joined: Sun May 23, 2010 9:18 am

Next

Return to Developer Discussion

Who is online

Users browsing this forum: No registered users and 0 guests

cron