UnConeD

29th May 2002 19:12 UTC

Rollercoaster :)
I was bored this afternoon (studying for exams sucks..) so I decided to do some more AVSing...

It's not done yet and I'll probably start from scratch (it has some weirdnesses), but the main idea is already working. The cool thing is that the track is only specified as a single curve, and that the code calculates the slope and roll for the track itself. The camera doesn't go along well yet though.

cmountford

29th May 2002 22:22 UTC

Awesome!
My first question is: how much time did you spend making that!?! :D

I see what you're talking about that's weird-but it's still insanely cool! I still don't see how it's possible to make it seem like the camera angle changes like in a DM without using a DM. But it's cool all the same.

It's all a confusing mass of equations (the captions help, though). I'll try to tinker with it to see how it works.

UnConeD

29th May 2002 22:28 UTC

Well first I build the curve by putting together small pieces (lines, circles, etc) and doing by best to match them up so they align. Then I use vector math to try and find the plane that the curve is in, and use that to construct the two rails.

Now to get the camera to move around, I basically have to calculate a position along the track for a certain time 't'. To speed up the calculations, I use a little trick: when the rail is being calculated, we store the value closest to 't' in the position (ox,oy,oz) so we avoid calculating that twice.

Next, I compare the current position (oox,ooy,ooz) with the last known position (ox,oy,oz) and calculate the camera angles off them (the two complicated atan2() statements inside onframe). That's what causes the camera to look in the right direction.

This preset took me an afternoon to make (4-5 hours)... most of that was spent creating the track.


The only error I can't get rid of is the fact that it jumps back at a certain position (in the large horizontal curve left) for some reason. I think it's AVS' limited precision kicking in.

Nic01

30th May 2002 00:03 UTC

Whoa, quite a scope... And the preset runs at a measly almost 9 FPS...

All I can say is if possible, make the cam "rolls" around when the track twists...

Prolly you can use the on-top view as another SSC that is much, much simplified, and place in the bottom left corner, make a box surrounding it, and it'll work like a minimap...

The emptiness of the preset... Filling in the background, I must say, is a big challenge... it's already rather low in terms of FPS, so it needs a high-speed, but good background... ouch :mad:

Oh, and UnConeD, you've just added one more thing to anyone's list of "Why I want UnConeD's Intelligence" :rolleyes: :rolleyes:

Wish ya a calm spot in mind =)

UnConeD

30th May 2002 00:25 UTC

Adding a background will be very difficult because the camera angles are 100% calculated off the track... so even a simple starfield would require the calculation of the rollercoaster track.

I've been able to speed it up a lot already and I got rid of the crazy twisting. Now it only twists when I want it to, and I made a new track that is double as large.

I also tried adding a 360° loop, but the camera wouldn't flip around properly. Too bad, it looked cool.

dirkdeftly

30th May 2002 02:37 UTC

Holy six flags!
If you could speed it up a bit (it works on mine at about 20 fps, btw) it'd be great - perhaps you could do something like what you did in All Neon-Like and add stuff like supports, cameras, and stations....
BTW, instead of calculating it all individually, could you draw the tracks and the beams inbetween at the same time? You'd have to change the pattern of the beams, but something like this for the track might work:
(-1,0)
(1,2)
(1,1)
(-1,3)
(-1,2)
(1,4)
(1,3)...

UnConeD

30th May 2002 04:06 UTC

Here's a second version of the Rollercoaster... the track is totally different (longer and more turns), the track banks/rolls automatically (!) and the camera is now fully attached to it. Looks and feels a lot better!

Oh and I added some colours to spice it up a bit.


I tried implementing a variation on your suggestion Atero, but I can't get it to look completely connected. On top of that, AVS is constantly running out of variables: I'm using 'red', 'green' and 'blue' as local variables now :) (their real value is only calculated at the end).

uNDefineD

30th May 2002 12:54 UTC

Wow. That is some amazing stuff. Do you actually work this stuff out on paper?

BTW I thought I'd give it a more "ride" look by adding space elements. I used your cat's eye SSC from cmountford's Sauron's eye as the planet, hope you don't mind. :)

Jaheckelsafar

30th May 2002 17:29 UTC

I'd like to see Rovastar make that in MD. :p

Seriously nice stuff, though there'a a little hiccup when the track restarts. I can't think of any reason for it excexpt maybe when i jumps from 1 to 0. Afterall, everyting does depend on i.

I like the fact that it still works nomatter what you change n to. (though it looses too much of it's effect when under 250). You can kind of speed tailor it.

UnConeD

30th May 2002 17:49 UTC

I've been trying to get rid of that annoying hiccup, but it's there for good... it's because of the curve-smoothing. In my current version it's much less noticable though.

The version sitting on my harddrive has trippy colours, stars and can go in both directions, but of course it's much, much slower. Synchronizing a second scope with the track is almost as intensive as adding a second layer of track.

ssj2gohan1018

30th May 2002 20:40 UTC

lol it goes 13fps on my comp than again i have a geforce2 mx200 it so should go faster but thats cool i had no idea of the things you do with math (not i know very well you know the guys in quake THERE ALL A BUNCHA MATH!!!!!!!!!can you imagian trying to make a 3000+ polygon model from raw math wow think about trying it in avs lol that wouldent be possabale)

Nic01

31st May 2002 00:05 UTC

Ooh, much better, and now it's 17 FPS!

After all the other requested good stuffs are added, I don't know how good the preset will be... heck, it already rocks!

dirkdeftly

31st May 2002 02:39 UTC

Hmm...that shouldn't be happening at all. I think it might by a bit easier explained like this:
a=1-a;
x=if(a,-x,x);
y=if(a,y+2,y-1);
This might even fix the hiccup, if the track is the only thing that uses i. But if your camera position is using i...then this flups it up further.

*thinks*

*observes the track design*
It seems like you're using the equivalent of this algorithm:
a=1-a;
x=if(a,-x,x);
y=if(a,y+3,y-1);
Where do you calculate the track design itself?


Anyway, I noticed that when the track goes below the screen the lines taper out. I fixed this by adding .2 to y3 at the end instead of .1
--Wait a minute, if you do .2, it runs into a piece of track...NEVERMIND...
However, it'd be great if you could fix that bug...maybe you could set it so that when yo do set y to 0 when you're flying by the track, the colors turn off temporarily. That way you could make a very low-level flyby (don't add anything to y3)

*continues random experimentation*

uNDefineD

31st May 2002 07:18 UTC

Jaheckelsafar: I don't think even EL-VIS could make that in MD. :D I downloaded it the other day and it has nothing over AVS, except for that stereo 3D thing, which I have no use for. Still okay though.

UnConeD

31st May 2002 12:30 UTC

Atero, If you're referring to the pattern on the rails, you're a bit off... remember that the track twists and turns in every direction, so anything that involves x and y specifically wouldn't work.
First, I calculate a zig-zag pattern using hi=-hi and I multiply the vector that defines the roll/banking for a point on curve by hi (pc=hi*.04/sqrt(red+sqr(by)), this is also a normalisation routine). On top of that, I store the last 2 positions in (gx,gy) and (lx,ly), and then alternate between those two and the current position (mx,my) using hp (hp=(hp+1)%3):

x=if(hp-1,if(hp-2,mx,gx),lx);
y=if(hp-1,if(hp-2,my,gy),ly);

I don't think you quite realise the mathematical complexity of this preset though. The hiccup at the end is not easy to fix.

dirkdeftly

31st May 2002 20:22 UTC

Okay...lemme think.
I assume that hp is the incrementation of i as the track moves on. You could simply reduce it's incrementation to attach it, but that still wouldn't be quite what I was talking about.

And why don't you just patch the hiccup? I realize that a patch in this case could make it incredibly slow, but you could just calculate where it's happening (camera-wise) and then make specific steps over that section to smooth it out.

UnConeD

1st June 2002 00:12 UTC

Actually hp is simply a counter (0,1,2,3,0,1,2,3,...). There are if's that choose a specific situation depending on what value hp has. It has no direct relationship with the value of i.

To make the code anything close to managably fast, I had to skip quite a few corners. For example, the camera position is calculated along with the track: whenever 'i' is close to the current position of the camera 'u', we save this position as a nice approximation of the camera's position.
However because of the discrete nature of the curve (a bunch of points, not a smooth one), the camera has to be exactly on one point. I tried using linear interpolation to get around this, but it introduces ugly skips and irregularities in the camera angles: remember that they depend 100% on the correctness of the camera's current and last 2 positions.

As you see, it's a very fragile construction. You'll notice this, that if you start messing in the preset, because it'll soon develop weird behaviours. The hiccup is a side-effect, but I've managed to minimize it mostly.
It's a bit like the 'ugly-edges syndrome' on 3d dynamic movements: the only thing you can do is use some visual tricks. Just like increasing the grid-size, increasing 'n' would help a lot, but would add an unacceptable slowdown.

dirkdeftly

1st June 2002 02:03 UTC

Hmm...I don't think we're understanding each other very well. However, there is one upside to the disconnection problem. You can make it more sound responsive without making it look wierd. Try changing the y3=y2*cz-x1*sz+.1; to y3=y2*cz-x1*sz+.15+v/25;.

Also, is it plausable to increase T by the y-camera movement (a gravitational effect)? I've tried doing this by adding some of ox to t every frame, but the problem is I don't know if ox is centered at the middle of the coaster or on the ground (below the very bottom of the coaster somewhere). I would assume it would work because of the t=if(above(t,1),t-1,t); line, that would work without disrupting things. But it does't. Which means I'm doing something wrong. Or I'm doing something stupid. In either case, it's a suggestion

UnConeD

1st June 2002 02:39 UTC

I guess my explanation wasn't very clear... second try:

Without all the banking and rails, the track is a single curve. To display it in AVS, it's rendered as a series of line segments between dots. That's every-day stuff for any Superscoper.

Now, because the camera always follows the rail, I 'catch' the next camera position when calculating the current points. When the camera position 'u' is close to the point-position 'i', I copy the point's coordinates into the new camera's coordinates. This is done not only for speed reasons, but because the curve-code is too long for 'onframe' sections.
This has the side effect that the camera is always centered on one of those superscope-points and that it moves at exactly one-superscope-point-per-second (1/n).

Now, the camera's angles are calculated off the current position, and the last two positions. However, if the camera is moving at less than one-superscope-point-per-second, then you cannot guarantee that the current point and the last 2 positions will be 3 different points. And if they aren't, the banking and rotation formula's will divide by zero or calculate angles between 2 identical points. That doesn't work out and this will make the camera do very whacky things.

But, you say, why not just interpolate between the two nearest points! Then the camera could move at any speed and it would still look good. That works nicely for the camera movement, but not for the camera angles and rotation. If I use linear interpolation, the smoothness of the curve is lost and it actually becomes a series of line-segments, even internally. This would mean that the camera would rotate in sharp jumps. Just imagine a camera moving along a 12-dot circle and looking along that circle, and compare it to e.g. moving along a 12-sided polygon with a higher dot-resolution. At every corner, the camera's rotation would jump in the direction of the center.

I really think you underestimate the complexity of the rollercoaster problem: given a curve f(x,y,z) through space, define a track that moves along that curve mainly in a horizontal plane and rolls/banks in curves in a realistic and smooth matter. It's harder than you might think: it requires first and second order derivatives and some tricky trigonometry and vector math. Work it out on paper if you don't believe me :).
And the fact that it's AVS doesn't help much either...

dirkdeftly

1st June 2002 03:15 UTC

Well, first of all, the camera already jumps around a bit, not just the hiccup, but at the beginning of the second section, and the beginnings of both sections before the first helix, the camera jolts a bit.
Now that I'm done nitpicking, why CAN'T you interpolate between two points? The camera jumping would be at most, say, 15 degrees, and that's in the helixes anyway. My point is, most of the time it's not going to be very noticable. And you might even want the camera jolts; a rollercoaster isn't really that smooth of a ride, now is it? And, no offense to you, which is more important, giving it the same effect as a roller coaster, or making it look pretty?
Wait a minute...I was just making it look pretty too, wasn't i :p. Nevermind... :D *shuffles offstage*
*should probably back off anyway as it's a work in progress*

Anyway, it *looks* to me, from a code-viewers standpoint, that hi is the forward/backward movement of the points, and hp is the left and right movement, and where hp=0,1 it's on the left (or right) and when hp=2,3 it's on the right (or left). It should only take some minor tweakage to get things to get it 'attached' correctly. What I've tried so far hasn't worked, but I'll keep at it (even after you tell me i'm being stupid and i'm wrong :p)

And in any case...that oscilloscopeyism still makes it look cool ;)

UnConeD

1st June 2002 13:39 UTC

I tried implementing linear interpolation. It sucked, was ugly and destroyed the feeling. I don't have the preset anymore, but please take my word for it.

I still think you're missing the point about the track pattern:

'hi' defines the side of the rail... hi = 1 -> left, hi = -1 -> right. Or vice versa. This creates a zigzag pattern.

On top of that, the last 2 positions of rail and the current position are stored in (mx,my) (gx,gy) (lx,ly). Then, the code picks one of those 3 depending on the value of 'hp'. This is what causes the lines to go back and forth along the length of that track: remember that the real value of (px,py,pz) *has* to be the actual curve with no off points, otherwise we get FunkyStuff(tm) with the camera.
Manually adjusting the coordinates makes no sense because there is no common value to make them line up.
There. If that doesn't convince you, you're being stupid and you're wrong :p. I spent up till 5am 2 days ago trying to get it look nice and I still couldn't figure it out. And I know that preset through and through.

Rovastar

1st June 2002 18:03 UTC

Originally posted by Jaheckelsafar
I'd like to see Rovastar make that in MD. :p

uNDefineD

1st June 2002 23:17 UTC

Rovastar, you don't know when to quit, do you. AVS is better. Period.

Although MD is still good. :)

dirkdeftly

1st June 2002 23:31 UTC

I'm going to stop bothering you about this then...It seems like I'm stringing you out more than your AVSing does

UnConeD

2nd June 2002 00:36 UTC

Haha don't worry Atero... it's fun to discuss this kind of stuff. You seem to know your share of mathematics as well. In any case two minds work better than one, so your suggestions are always very much appreciated, though sometimes a bit off :).

ryan

2nd June 2002 01:46 UTC

I don't think I could do that in MD I mean how could I get it so chunky with such a low frame rate.

Seriously though a nice preset.

Posted by undefined (Arent there enough Un people around here... UnConeD Unchained undefined... :D) - Jaheckelsafar: I don't think even EL-VIS could make that in MD. I downloaded it the other day and it has nothing over AVS, except for that stereo 3D thing, which I have no use for. Still okay though.

UnConeD

2nd June 2002 02:31 UTC

I don't know about the others, but my nickname goes back a few years. Besides, what kind of an idiot are you to name yourself idiot? :p :D

(PS: This is a jest. Discussing people's nicknames in unrelated threads adds nothing to the discussion, and personally it offends me a bit when people go 'UnConeD? What kind of stupid nickname is that???' :rolleyes: )

Oh and please, please, pretty please: STOP DISCUSSING MILKDROP VERSUS AVS!. It's a boring topic anyhow unless texels, polygons and OpenGL turn you on (to anyone who's thinking 'yummy': we *don't* want to hear it).
All the arguments have said. Okay? Thank you for your attention. (yes I'm being egocentric, but this is *my* thread, mwahhahaa! :weird: )

I think I'll go play with Mister Happy somemore... he's lost weight, sobered up a bit and is less rheumatic.

Rovastar

2nd June 2002 03:09 UTC

Originally posted by UnConeD
I think I'll go play with Mister Happy somemore... he's lost weight, sobered up a bit and is less rheumatic.

uNDefineD

2nd June 2002 04:18 UTC

idiot24-7: It's uNDefineD. You gave the respect to UC (and I wrote your name right too), please show me the same. :)

But anyway, I'm not the one who started it. Besides UC, who the hell are you to tell me what to discuss? You might be a damn good AVSer and help to newbies, but even that doesn't make you an evil overlord. :p

I think I'll get back on topic now: Did you like the space elements I threw in?

Jaheckelsafar

2nd June 2002 06:18 UTC

Meh. The occasional jab is still fun.

Go AVS!

<ducks flying heavy object>

Umm... okay. It's over.

<hides in corner>

Illusion

2nd June 2002 14:31 UTC

...but even that doesn't make you an evil overlord

ryan

2nd June 2002 23:35 UTC

I don't know about the others, but my nickname goes back a few years. Besides, what kind of an idiot are you to name yourself idiot?

NoSage

7th June 2002 07:26 UTC

Nice job, roller coaster v2 looks really good. I did something like this a while ago taking a completely different (and much weaker) method to render a track. Every frame the scope created two points in a limited random spot on the screen then a line was drawn from the last set of points to the new set, creating two parallel lines that go everywhere in a faked 3-D look. The problem is that the "track" was random thus never cycling and it moved at 4 fps while rc v2 moves at 28 fps.

UnConeD

7th June 2002 11:55 UTC

I DID IT!

I won't explain, just watch :). (still a few graphical glitches to take care of though)

Oh and I added random onbeat switching between normal, mirror, reverse, mirror reverse and... upside down! :)

ryan

7th June 2002 13:13 UTC

WOW! That is cool.. I really like the colers and the loop =).. Nice work... Now... If I had a faster CPU I might get 20fps.. but 15 isnt bad =)..

YaPoNDeeZzZzz..

7th June 2002 14:08 UTC

dman thats hella tight
thats alot of math too....how high are u in math(like classes example : cal) UnConeD ?
maybe in 10 years i might be on the same level ......

:D

UnConeD

7th June 2002 14:11 UTC

For better speed, try moving them out of the effect list... you lose the motion blur though. Or alternatively, set 'n' to a lower value in the superscope itself. Note that it's not completely 'n'-independent... if you pick 'n' too low, the track will be messed up. The curve smoothing is also affected by 'n'.

By the way some neat tricks:

Find the line that says "by=...":
- change the first minus sign into a plus... now the track banks in the wrong direction, making it look like some sick, twisted rollercoaster :)
- there's a large number here (5000?)... increase for more banking (too much messes up the loop though)

Anyway getting the loop to work was a maaaajor pain in the ass :p. It might seem logical, but it's totally not. The only reason it works is because the loop is aligned on a major axis (x) and is pretty tight.

Jaheckelsafar

7th June 2002 17:04 UTC

Wow, nice loops. The upside down one on threw me for a loop the firt time. (oh, god. I didn't mean the pun. I swear) I dunno about the switching directions though. First time it happened, I thought it was a glitch. I didn't know it had switched, I just thought it was redoing a part of the track because it jumped over the loop when it switched directions.

Still, very cool.

3dino

7th June 2002 19:56 UTC

:D very cool!
need more colors?!
here it is lol!

UnConeD

8th June 2002 13:46 UTC

3dine: the color code is important to hide the invisible lines... your preset doesn't have that. And I still prefer the original :p

dirkdeftly

8th June 2002 20:07 UTC

The only thing I'd change is the direction change...it's awful ;)

UnConeD

8th June 2002 20:11 UTC

The track variations really reduce the boring-factor IMO. Maybe I shouldn't make it onbeat, but rather let it switch every time it completes one/two/n round(s). Because of the way the camera rotation is calculated it also looks incorrect on the actual on-beat frame. Maybe I could add a very short fade out to prevent this.

dirkdeftly

9th June 2002 20:27 UTC

I dunno if this is possible, but you could add a twisting feature to the end of the track sort of like a mobius strip. Or just have the camera rotate around the track when you switch sides. For switching directions, you could simply turn the camera...it'd be great if you could slow it down temporarily, but you say it'd be uglified :( Possibly just move the camera back a bit after you turn it, not depending on the track, then push it forward afterward?
Also, how about a direction reverse without turning around?

UnConeD

9th June 2002 22:24 UTC

A mobius-strip arrangement would be weird: when the camera is upside down, the track needs to bank in the opposite direction. And having the camera freeze and rotate would require the code to be a lot more complex. Remember that the camera angles are calculated in a very weird way (only way to make it go fast) and that I'm close to running out variables.
On top of that, actually making the track twist 180° or 360° isn't possible. To do this, I would need to implement code to rotate the 2 rails around the 'spine' at an arbitrary angle. This would mean a *lot* more multiplications and sines/cosines per point. I avoided this by pushing the rails up and down, and then normalising the offset. This allows it to rotate between -90° and 90°, but not over.

Krash

12th June 2002 11:01 UTC

Can anyone explain why I can see rollercoaster v2 perfectly well, but Neon Coaster doesn't work at all?

- Krash

uNDefineD

12th June 2002 12:43 UTC

UC: I flipped the minus sign to a plus and increased the 6000 in the by= to ~50k-100k and I noticed that the track twists often, like (wait for it) a mobius strip. Oh yeah, the rollercoaster became pretty funky. :)

UnConeD

12th June 2002 16:57 UTC

Yeah sure you can make it twist a lot, but I think Atero meant to include the one-sided property of a mobius strip: after one round, the track flips around and you travel on the other side... at the end it flips back again.