Ok. First I'm wanting the wall spacing in the x and z-directions to be the same. I see no reason they should be different. Also I had to pick a "reasonable" time step between frames to make an animation. We know the spokes seen on the wheels go on and off from one frame to the next and they are always in the same place when they appear. It seemed logical to assume this means the tires make one complete revolution between every two frames. As I've posted my LightCycle model before you know both the front and rear tires have a radius of 85 POV-units. To make the circumference of the tires equal to two I scale everything by 1/(85*pi). The grid lines on the game grid in these animations is then spaced every two units and the bikes themselves move 1 unit per frame. All bikes travel paths of the same total length (in these cases 10) and the number of frames is set at that length plus 1 (in these cases 11).


In the above animation you'll note several differences between it and the scene above from the movie.

1) The pivot point on the bike has been moved to the center of the rear wheel. This means no extra wall is drawn before a turn and removed after a turn. It also enables the walls to be able to be placed closer together as the radius of the rear tire is effectively removed from the length of the bike.

2) If you allow bikes to travel on paths defined by half intergers as the blue bike. Note the red bike in this animation ends traveling on the x=11 line and the orange bike next to it is traveling on the x=12 line. The blue bike is traveling on the x=11.5 line and it HAS enough room to travel between the walls UNLIKE the blue bike in the movie. This means two bikes can't get close enough together to cut off a bike the way TRON and RAM do in the movie without one crossing the others wall in the process. This is why you don't see the individual turns in the frames from the movie above. Each bike HAS to make two turns between frames.

3) Another difference is seen by looking at the red bike in the scene from the movie above. Note the pivot point of the bike is AT a turn in the path in the second frame. At this point you have two options that could define a valid forward direction. Is forward defined by the segment of the path behind you or the segment of the path that's about to be taken. In the movie it's taken to be the segment behind you. I've chosen the segment that's about to be taken. Again this is so the walls can be placed closer together. If I chose the other option and had the bikes traveling the exact same paths I'd end up with this anmation.

where to buy abortion pill http://blog.bitimpulse.com/template/default.aspx?abortion-types buy abortion pill online

So what do I have after ALL this. Well, I think I have a constant set of rules that can be used to make animations. If I confine all points on all paths to be defined by integers all I need are non-interesting paths of the same length, with ONE exception. At ANY given moment in the animation the lead points of two paths CAN'T be 1 unit apart and heading toward each other even if both paths turn at that point.

In my animations I'm toying with the idea of defining two classes of players, programs and users. Programs are confined to paths defined only by integers. Users can travel on paths defined by intergers and half integers. Once half intergers are thrown into the mix however the list of exceptions grows. I'm still working on a complete list of those exceptions so I'll save that for another day.

Enjoy,
Carlabortion pills online abortion pill online purchase cytotec abortion

Whoa!

Talk about a strict, through, and specific point-driven mathematical analysis!

You have indeed put serious thought in to this.

Ok, I've got two thoughts playing in my head on this whole thing. Before I get in to it - please forgive my use of more general terms - I'm not up on all my mathematical and 3D plotting terminology so bear with me

One thought I've had consistently and is based solely on getting the cycles where they need to be so that there is totally free pivot possibilities - in other words, the cycles can turn on a digital-dime and are not restricted to predermined pivot lengths. Of course, this would, more than likely, result in the cycles overlapping in the unseen in-between frames, as in the actual TRON film animation illustrated above. But in terms of total and complete freedom of movement, which I think is essential for actual game play, this overlapping cannot be avoided - it can only be hidden between frames.

The other thought is (based more on your mathematical explanations and animated illustrations) that if cycles touch each other at all, even between frames, then they experience a collision and would probably derez. Now working under this premise, absolute freedom of turning may be reduced some, however it would be programmatically more feasible to go this route as it can be dealt with more mathematically (and programmatically) and the programmer would only need enter paths - the "rules" can take care of the rest quite nicely and efficiently. This may me slightly limiting in terms of animating a cycle duel that features several close (to collision) turns in an edge-of-your-seat set of moments. It may not be as limiting as I'm thinking either - since camera angle and rate of speed can play a good role in the edge factor as well.

Ok, the phantom jet wall that, in the film, is that part of the jet wall from it's origin (center of the wheel vertically) to the edge of the tire. As you pointed out, this part of the wall does indeed get redrawn from where it was before the turn, to where it ends up after the turn.

On the programming end, I think this can be dealt with most effectively by adding that part of the jet wall as a separate element of the cycle itself, that is only present during movement. It is a bit sloppy in terms of not being able to have it exist as part of the wall, both in terms of animation objects and code, but it would take care of the pivot point issue and offer movement of the wall as seen in the film.

I present this alternative because it's a personal preference of mine to see the jet wall stay aligned with the rear wheel, rather than separate when a turn occurs. The separation does offer a very clean and neat way to animate the cycle and trail, but doesn't look right visually in my opinion.

Of course, if you were to animate a light cycle sequence playing at 24 fps (or as close to as you can simulate) and have the cycles travel at the speed they are shown traveling in the film (regardless of spoke revolution distance), I'm wondering how often the wheel separation from it's jet wall would be noticeable. Perhaps that should be tested just to see how often it happens, and how noticeable it is.

In a nutshell, I'm more for freedom of movement over establishing a set of predetermined pivot increments, but I think I'm thinking this way more for because I've played online multi-player light cycles and there is a lot one can do in the game to avoid contact when there is total freedom of movement (pivot points are not graphically detectable because they appear to be so very minute). Playing online light cycles does often result in the appearance of two cycles overlapping each other, but only for a very minute fraction of a second (depending on screen refresh rate and ping of the other players vs. your own). Cycles often do overlap with jet walls and survive so long as the overlap is not severe. Therewhere to buy abortion pill http://blog.bitimpulse.com/template/default.aspx?abortion-types buy abortion pill online

wwwmwww Wrote:Thanks Todd. I'll address all your comments with a few more animations when I get a chance, probably not before this weekend though. I just didn't want you thinking I was ignoring you...

I fully understand that these conversations and experiments may take some time to process through (especially when you'll more than likely be responding with additional animations).

Take your time and if there is not another post in this thread for a while, I'll completely understand why

Let's just have fun with it - no time frame necessary.

This thread may be a slow moving one that is expanded upon over a longer duration. And that's just fine by me

Ironic that the subject matter of this slow thread is actually the nature of high speed light cycles!

TheReelTodd Wrote:The other thought is (based more on your mathematical explanations and animated illustrations) that if cycles touch each other at all, even between frames, then they experience a collision and would probably derez.

If bikes crash and derez even for contact between frames I think the closest any two walls could come to each other in general is a full bike length away which is about twice as far way as I currently have them (not counting the blue bike). This is just too far away in my opinion to look right. So these ponts of "contact" need to be hidden between frames.

TheReelTodd Wrote:Now working under this premise, absolute freedom of turning may be reduced some, however it would be programmatically more feasible to go this route as it can be dealt with more mathematically (and programmatically) and the programmer would only need enter paths - the "rules" can take care of the rest quite nicely and efficiently.

All I enter into my POV-Ray code are the paths. There is no checking for contact as is obvious. I do have a second piece of code that can generate non intersecting paths. The code needed to check for contact in real time would only really be useful in a real time game where the paths were being entered by the players also in real time. For my purposes its easy enough to weed out good non-intersecting paths from by other program off line. If I get to the point I need real time checking for contact all you say is true. It's just not need for animations.

TheReelTodd Wrote:This may me slightly limiting in terms of animating a cycle duel that features several close (to collision) turns in an edge-of-your-seat set of moments. It may not be as limiting as I'm thinking either - since camera angle and rate of speed can play a good role in the edge factor as well.

Agreed. At 24 frames per second all this will look much better in that regard.

TheReelTodd Wrote:I present this alternative because it's a personal preference of mine to see the jet wall stay aligned with the rear wheel, rather than separate when a turn occurs. The separation does offer a very clean and neat way to animate the cycle and trail, but doesn't look right visually in my opinion.

There are THREE ways this could be done.
(1) The pivot point (green dot) could be moved to the rear of the rear tire as it seems to be in the film. With the paths I'm using in these tests you get this animation.


(2) Again as in the film the pivot point (green dot) is at the rear of the rear tire. However now I've defined the forward direction AT a turn to be the direction along the next segment of the path. Not a continuation of the current segment.


(3) Leave the pivot point (green dot) centered on the rear wheel just adjust the frame spacing such that the pivot point is NEVER show directly at a turn in frame. Have it atleast the wheel radius minus half the wall width ahead of a turn and the tire will never be seen seperated from the jet wall. Note without the green dots and being able to see the action between frames this animation is almost identical to #2 above. It would have been had I left out the "minus half wall width part above" but believe me the code is quite a bit different and had I rendered frames between these they would have been different. Just noticed the very last frame is different as the pivot point can't be advanced past the end of the path that's been entered.


Of these options I like #3 best but note even with that option the underlying grid spacing would have to be wider then I started with to avoid contact. To me the one frame where part of the rear wheel is disjoint from the jet wall is worth it to have as tight a grid spacing as I can get. That one frame will only be on screen 1/24 of a second and you'll really have to be looking to see it and to be honest even when I do see it, it doesn't bother me. It just seems the logical way the bike would have to turn to leave a wall with 90 degree turns in its wake. Note even when the wheel IS disjoint from the wall, the part of the wheel sticking out isn't making contact with the game grid so it makes sense that it wouldn't leave a wall there. Think of a bicycle tire with wet paint on its tires. Roll the tire along a path with a 90 degree bend in it. What do you need to do with the tire at the point where the bend is?

TheReelTodd Wrote:Of course, if you were to animate a light cycle sequence playing at 24 fps (or as close to as you can simulate) and have the cycles travel at the speed they are shown traveling in the film (regardless of spoke revolution distance), I'm wondering how often the wheel separation from it's jet wall would be noticeable. Perhaps that should be tested just to see how often it happens, and how noticeable it is.

Looks like I skipped this paragraph above. Check out the one animation done at 0.04 seconds per frame above. The way I'm currently doing it with fixing the path to the underlying grid and starting the light cycle at the beging of the path and advancing the pivot point 1 unit per frame means that at every turn the pivot point will be placed directly on top of the turn. In other words this separation occurs at every turn. However I do believe it's much less noticeable. Depending on camera positioning even if the separation does always occur it won't always be noticeable. Here is another animation at 0.04 seconds per frame from another angle.

Wow!



Once again, Carl, you've put together a spectacular and very well thought out concept and illustration of the "rules".

I just read through it and wanted to pop in a quick video of how the cycles actually look at 24 fps (because the GIF animations only play at about 10 fps on my machine regardless of their frame timing increments).



I'm not sure if the GIF animations play at their proper speed on your computer, but hopefully this AVI animation will play at the correct speed for everyone regardless of video card or (general) hardware.

The AVI file has been set to run at 24 fps (which is actually 23.98 fps on the timeline because of computer timing vs. TV and film timing).

Before I could post the AVI file though... you're STILL adding to the discussion

Ok, first wanted to pop in the AVI of your work in all it's 24 fps glory

Now, have to re-read and continue the discussion...

Ok, in response to the possibility of in-between frames - in short, I don't think that looks right at all.

To me the fact that light cycles moved at 90 degree angles (with no in-between increments) was part of the whole you can do things in computer games that you can't do in reality kind of thing. In other words, the 90 degree turns being instant is just cool in that respect. To me anyway

In terms of how would a light cycle pull off a very quick turn, I'll offer that it would look like this:

Frame by frame:


In real time:


I hope you don't mind me taking a still of your light cycle and re-animating it, Carl I'm not even close to being able to animate things like this in any 3D app.

Anyway - I believe that is how a quick turn would be dealt with in terms of animating it.

Of course, what I did may break "the rules of engagement" in the sense that I did it manually, but I generally stuck to movement increments of one movement per grid and kept that consistent... aside from the fact that I don't know if the two turns in one frame thing was kept to a constant length. Eyeballing it - it looks very close, but I don't care to measure the pixels (too lazy after doing the animation ).

In-between frames where the cycles are seen at angles other than 90 degrees wouldn't look right to me at all in m y opinion.

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).

My two cents


EDIT: Ok - eyeballing the two turns again reveals that I did indeed move the cycle about 25% further in that one frame. Oh well. I don't think it looked off because of it though.

TheReelTodd Wrote:To me the fact that light cycles moved at 90 degree angles (with no in-between increments) was part of the whole you can do things in computer games that you can't do in reality kind of thing. In other words, the 90 degree turns being instant is just cool in that respect. To me anyway

In that we are in 100% agreement. I just didn't want to rule it out until after I'd animated it. I heard that voice in my head that said it won't look right before I did it but till its done I'm never sure if that's my lazy side talking or not.

TheReelTodd Wrote:I hope you don't mind me taking a still of your light cycle and re-animating it, Carl I'm not even close to being able to animate things like this in any 3D app.

I don't mind at all. I actually like the glow you added to the jet wall. I wish I knew an easy way to do that in POV-Ray. It could be done with media but would slow things down alot. Just how much I might have to find out.

I'll reply more later. I'm getting off now to watch the Super Bowl

Later,
Carl