Forums (I/O Tower)
Forums 
  General Discussion 
 Light Cycle: Rules of Engagement


New New Comments | Post No Change | Locked Closed
AuthorComments: FirstPrevious Page: of 4 PagesNextLast
TheReelTodd
Sector Admin

Posts: 0
Re: Light Cycle: Rules of Engagement

on Sunday, February, 06, 2005 6:34 PM
wwwmwww Wrote:...I don't mind at all. I actually like the glow you added to the jet wall...

Actually, the glow was put there only to make it stand out better - didn't show up well without it. It wasn't a creative move, just a functional one

And the reason my AVI file didn't play on your computer is because I forgot the autoplay attribute. Whoops! I fixed that.

In regards to people with dial-up connections being able to see the page LOADED with the large animation files... well, it may take a long time for them to get all that. Oh well. They should be able to read the message text as it will still load regularly. Whether or not they stick around for the animations depends on their curiosity level after reading all this stuff.

And I PM'd you with some stuff you may find useful

Well, I'm about to PM you, so give me a minute if you're reading this right now (time of posting).




 
wwwmwww
User

Posts: 1,230
Re: Light Cycle: Rules of Engagement

on Monday, February, 07, 2005 8:08 AM
Thanks Todd. I got the PM. I'll reply more as I have time, which I have little of during the week.

I'll be back as soon as I can...
Carl


 
wwwmwww
User

Posts: 1,230
Re: Light Cycle: Rules of Engagement

on Sunday, February, 13, 2005 6:00 PM
Wow!!! Take a week off and this is already on page 2. Is it just me or has posting around here sure picked up? By the way, I just noticed this is my 300th post. What do you know... maybe in another 6 months I'll be in the top 25.

Now on to the discussion...

TheReelTodd Wrote:
Ok, as I tried to back track and address some specifics... I realized that you had already illustrated your points so very thoroughly, there really isn't much left for misunderstanding. Again, you've done an excellent job of illustrating your points and reasoning!

Thanks. That's what I was trying to do.

TheReelTodd Wrote:
You have obviously put a lot of thought in to not only animating the light cycles, but HOW they should be animated. And along with that - you've considered various possibilities of how to do so - mainly how the cycles turn and how close they can approach each other or a wall they as they turn.

Yes, my aim is to write the code general enough such that it does a big chung of the work for me. I want a set of rules that make sense and are easy to apply. With that all I should have to do is put in a set of paths that obay the rules and with the proper camera movements I should have an animation. Atleast that's the aim. If it's simple enough it can be reused for more then just making one animation. I have an idea for a turn based game that could be played with it.

TheReelTodd Wrote:
If I were animating light cycles for a cinematic sequence, I'm not exactly sure how I'd go about it. Off the cuff, I may do something very similar to what they did in the film (or what I think they did), which is plan the major elements of the light cycle competition, but not attempt to animate it as an entire animation that is fully filled in from start to finish. If the animation would never be shown to the audience as a complete and in real time account of the events, it is then possible to simply plan the main elements of the dual and base timing on those elements.

I agree. I'm sure that's what was done in the film. However I want something that is a whole real time account of the match. I want to be able to plan out a whole match and place a dozen or so cameras (some moving, some fixed) that film the whole match and make the animaton by taking the first 30 frames from camera 1, the next 125 frames from camera 4, etc. Frame 274 from camera 2 is taken at the same time as frame 274 from all the other cameras. This way the match is watched in real time. Each bike will also have a camera in the cockpit to give you the in-bike view from the level of the game grid.

TheReelTodd Wrote:
For instance, you might see two cycles near each other and head in to the duel. This is a relatively easy part to plan and animate. Then as the two cycles start trying to out maneuver each other, the animator can cheat. That is the animator need only plan around a few quick turns and base timing (and start points for that part of the animation) around those few precise and quick turns. As soon as the camera angle changes, more cheating can take place. By cheating, I'm talking about animating just short and intense portions of the duel based on the planned moves and counter moves for each cycle and having the cycles already be in the perfect positions based on proper timing of events - charting it backward. In other words if you know the cycles will need to come close to collision at a certain point, then you simply start at that point and animate them backward from that point and then forward from that point. When played back linear - it appears to be a close call to the audience.

There's a little more to it than that, since each duel set up is not based on a single turn and counter turn, but more likely to involve several turns and counter turns. But the basic premise (of animating chunks of the duels at a timeabortion pills online abortion pill online purchase cytotec abortion



 
wwwmwww
User

Posts: 1,230
Re: Light Cycle: Rules of Engagement

on Sunday, February, 13, 2005 6:41 PM
TheReelTodd Wrote:
And the cycle placement in quick turns should generally be hidden between frames (whenever possible) so that it doesn't look like the cycle jumped positions (i.e. was up here in the up move, then way over there in the turn back move).

I agree this looks good for a quick turn. I was thinking about maybe there shoud be a rule that the bike itself isn't drawn on segments of the path that are shorter then the bike itself to avoid the "jumping" effect. Note if you were to draw the bike going up in the segment it would appear to have already gone past the point of the second turn. Atleast the front wheel would have. However the problem with the rule is seen when asking what happens when there are a bunch of short segments in a row? Again the staircase pattern is an example but not the only one. Plus just how many turns should be allowed to take place between any two frames. Personally I think two should be the max. What are your thoughts?

Carl



 
TheReelTodd
Sector Admin

Posts: 0
Re: Light Cycle: Rules of Engagement

on Sunday, February, 13, 2005 7:24 PM
wwwmwww Wrote:Good question. Anyone else want to offer their thoughts?

It would be cool if other people joined in this discussion, but I'm not sure of the likelihood of that. We've both been very long-winded and there's been a lot of technical talk and high-level mathematical examples. I must admit, I have to work a little myself to follow the match talk. I get it (the general points of it), but I'm not even close to being able to talk with that kind of mathematical articulation. Funny thing is, I think visually in terms of space and 3D and I sometimes have a little trouble verbalizing what I'm seeing in my mind as I try to describe what's in there. But it seems you've followed my points well enough, as I have yours. But this discussion has gone pretty deep in to these possibilities and I'm not sure how many people will take the time to get in to it. That's ok if they don't though. I'm enjoying it a lot personally And I’m sure EVERYONE will enjoy the eventual polished animations that result

And yes, there's been a LOT more activity here at The Sector lately! Threads can end up buried pretty quick these days!

In to the discussion - very good points addressed, Carl.

Your game idea sounds really cool, but I'm going to stick to the mechanics of light cycle animation for now.

wwwmwww Wrote:However I want something that is a whole real time account of the match. I want to be able to plan out a whole match and place a dozen or so cameras (some moving, some fixed) that film the whole match and make the animation by taking the first 30 frames from camera 1, the next 125 frames from camera 4, etc. Frame 274 from camera 2 is taken at the same time as frame 274 from all the other cameras. This way the match is watched in real time. Each bike will also have a camera in the cockpit to give you the in-bike view from the level of the game grid.

I kind of thought you were aiming at that. Well, there's no debating how cool it could be. Following an entire competition from A to Z would be very cool. I was just thinking it would require a lot more work since all the in-between stuff would also need to be planned, plotted, and animated. By "in-between stuff" I'm referring to the parts where the camera's focus is on two cycles (in a math with more than two cycles), the other cycles, even while out of camera, would still need to be planned, plotted, and animated - even though it may not be seen by the audience.

However, since you are working toward programming a system that would allow you to simply plot the cycle paths and then choose camera shots later, this everything is animated methodology could open up some really cool possibilities. Since ALL the cycles will indeed be animated regardless of where the focus of the camera is, it may be possible to have camera focus on two cycles dueling while two other cycles are also seen dueling far off in the background. I don't think I need to spell out how cool shots like that would look! I wouldn't be surprised if you were already thinking about shots like that.

In answer to maintaining the jet wall connected to the rear tire:
wwwmwww Wrote:I guess one approach might be to render a frame where the bike is half a tire radius ahead and another frame where the bike is half a tire radius behind its position in each normal frame. Then as I'm putting the animation together if tire separation is seen in that frame pick a substitute from the two backups that were also rendered. The bike's apparent speed might seem to have an odd jump at that point but I sort of doubt it'd be noticeable. That's one possible fix anyways.

Ok, I was about to propose a dual animation scenario for this, but as I re-read the above quote, I think you're already stating what I was thinking. My idea was going to be animating the sequence twice, the second a



 
TheReelTodd
Sector Admin

Posts: 0
Re: Light Cycle: Rules of Engagement

on Sunday, February, 13, 2005 7:42 PM
wwwmwww Wrote:I was thinking about maybe there shoud be a rule that the bike itself isn't drawn on segments of the path that are shorter then the bike itself to avoid the "jumping" effect.

Yes, I agree.

wwwmwww Wrote:However the problem with the rule is seen when asking what happens when there are a bunch of short segments in a row? Again the staircase pattern is an example but not the only one.

Yep - the staircase would be a problem, as would any occurrence of very quick turns.

wwwmwww Wrote:Plus just how many turns should be allowed to take place between any two frames. Personally I think two should be the max.

Well, yes and no. I see this as a good rule to utilize when making animations, but not a good rule to actually explain as a rule or property of light cycles themselves. I don't think you meant it as a light cycle rule so much as just an animation rule though.

Now on the staircase, I think it may be possible to actually animate that without it looking too funny. It gets done in online multi-player light cycles from time to time - often as a victory dance performed by the winning cyclist for the round. I'm thinking of cheating and recording some moves like this to see how it looks on the frame level. In real time it never looks funny. But that may be because in real time, it's also playing at about 85 fps and not 24 fps. That may be the major difference. But I'm still tempted to record these moves and convert them to 24 fps and see what it looks like when I have the time. It may offer some insight in how to deal with this kind of thing... or it might look odd. We'll have to see.

BTW - I think the TRON 2.0 light cycles actually pivot in the center of the cycle. It's almost never noticed because of the speed in which the game travels and the higher frame rate. It makes sense for the game to be like that as it is played in real time, but I don't think it would be a good approach for animating them like that.
order abortion pill abortion pill buy online where to buy abortion pill



 
wwwmwww
User

Posts: 1,230
Re: Light Cycle: Rules of Engagement

on Monday, February, 14, 2005 10:32 AM
TheReelTodd Wrote:I kind of thought you were aiming at that. Well, there's no debating how cool it could be. Following an entire competition from A to Z would be very cool. I was just thinking it would require a lot more work since all the in-between stuff would also need to be planned, plotted, and animated. By "in-between stuff" I'm referring to the parts where the camera's focus is on two cycles (in a math with more than two cycles), the other cycles, even while out of camera, would still need to be planned, plotted, and animated - even though it may not be seen by the audience.

I view it as a basically a two step process. First is getting good paths for all the cycles to follow. The second would be in placing the camera in the right locations and having them pointed in good directions to capture the action. The second step I expect to actually be the harder of the two. Where as each bike just follows one spline, each camera needs two, one for its position and another for it's look at location. And those splines will be more complex. They will be smooth arcs and not made up of 90 degree segments, well aside from the cameras placed in the bikes themselves.

TheReelTodd Wrote:
However, since you are working toward programming a system that would allow you to simply plot the cycle paths and then choose camera shots later, this everything is animated methodology could open up some really cool possibilities. Since ALL the cycles will indeed be animated regardless of where the focus of the camera is, it may be possible to have camera focus on two cycles dueling while two other cycles are also seen dueling far off in the background. I don't think I need to spell out how cool shots like that would look! I wouldn't be surprised if you were already thinking about shots like that.

Yes, I want to capture as much action in frame as I can. I want zooms from views of the whole game grid showing ALL the action into shots of two bikes racing side-by-side. I want pans as bikes zip past the camera. And shots that show action in both the forgroud and the backgroud as you describe.

TheReelTodd Wrote:
Ok, I was about to propose a dual animation scenario for this, but as I re-read the above quote, I think you're already stating what I was thinking. My idea was going to be animating the sequence twice, the second animation would be started just about a half tire-rotation further in to it to offer slightly different frames, but still very close to the original in terms of spacing. Then this second set of frames could be substituted where wheel-separation or false-collisions are seen in the primary animation frames. Making single frame substitutions in a high-speed animation would most likely not be noticeable. Ok, I'm sure that is exactly what you were proposing. Funny how we're thinking very similar on many of these points. That must be a good sign

Yes, that sounds exactly like what I was thinking of. It should be the simpliest fix.

TheReelTodd Wrote:In my creative video work, I use the 16x9 ratio. That's the size of the new, HDTV sets and also becoming the new standard screen size. My camera has a setting that allows me to shoot at that ratio without using false letterboxing (where the top and bottom of the screen are just covered up with a black bar to simulate wide screen). When I take the video and resize it to a frame size that can be properly displayed on computers, I end up with a resolution of 640x360 which is a ratio of 16x9, or wide screen as it's being called.

Yes, any final animation certainly would have been in wide screen. 640x360 sounds perfect. I can certainly start making my test renders with that ratio/resolution.

Carl