A little demo.

Argh · Post by **Argh** » 16 Jun 2007, 17:18

Here's the second demo.

I've smoothed out the ramping for the angle-calculation, so it's actually returning good values, when it sees changes on the axis. Could still be improved, of course, for this particular vehicle, it feels too bouncy- and I need to probably steal a four-wheeled thing, or make one real quicklike, to do a demo of that variant. I'll probably just (gasp) steal a Wesel.

Nemo · Post by **Nemo** » 16 Jun 2007, 17:24

Might just be me, but I don't see anything happening in that video except a bunch of sheep driving in a line...

Perhaps a bumpier map would be good?

Edit: oh, nevermind. If you look in the back left corner of the pack you can see them bouncing a bit.

Argh · Post by **Argh** » 16 Jun 2007, 17:31

Er, yeah, I wanted to keep it subtle- as it is, at scale, those MegaSheep are bouncing a meter or more with every large bump.

Lemme see if I can find a better map for this.

Nemo · Post by **Nemo** » 16 Jun 2007, 17:35

This is a tech demo - screw subtlety, we want flash-bang whizbomb awesome dramatic stuff!

rattle · Post by **rattle** » 16 Jun 2007, 18:12

Hm... I can't see anything either.

Argh · Post by **Argh** » 16 Jun 2007, 19:42

Here's a third demo, with a little more obviousness and oomph.

I also found out that by using damping the way I'm doing it now, I've actually significantly lowered my CPU usage once again.

The only thing this approach can't do, which Zpock's script does really well, is determine where the height of the ground is, and make sure that the wheels don't ever clip. I can probably get that to work, though, by giving the wheels a ceiling and floor value that are different, and compensating with speed changes, to keep the whole thing smooth.

It'll now quit bumping around any time the vehicle is going down a totally-smooth slope, on flats, and in water, and smooths out quickly. The only other remaining problem, besides the wheel traverse distance, is making the gradation of upwards motion slightly smoother, so that we're not seeing it hit the top level of bump-jump except under unusual circumstances.

knorke · Post by **knorke** » 16 Jun 2007, 19:46

try another video capture program, the video is too laggy to see subtile things like bouncing suspension.
This one can record at 1.0 speed with quite good fps and spring even stays somewhat playable:
http://www.planetgamecam.com/?locid=download

Maybe also chose another unit? Megasheep seems not really made for this.
Something like http://www.army.cz/images/id_5001_6000/5796/piranha.jpg
or
http://www.amphibiousvehicle.net/amphi/ ... 8sbII.jpeg <- (how cool is that?)

rattle · Post by **rattle** » 16 Jun 2007, 20:21

Looks like your mega sheep have a hiccup.

Argh · Post by **Argh** » 16 Jun 2007, 20:50

Yeah, I need to compensate for the springs properly. Almost done with that, and hmm, it saved me another step. Interesting.

Argh · Post by **Argh** » 16 Jun 2007, 22:03

Here's the fourth cut.

Now that we can all see that something's actually happening here

I have put in some stuff to smooth things out a little, and took care of the "hiccups" by altering the method whereby the wheels respond to the bumps. It's still exaggerated, just so that it's clear what's happening, so don't get me wrong, I don't want things just flopping around. Adapting it to hovercraft is super-trivial, and then it's mainly just a matter setting max values and tweaking speeds, depending on the mass of the objects you'd want to portray, and you can lower / speed up the simulation very easily, using two values that are #defines.

I'm estimating, because there are various factors involved, but at this point, it's roughly 3000% faster than Zpock's script. Not bad, for six hours of work. It's not nearly as perfect of a simulation, mind you, and I don't claim that. However, the objective I wanted here was to see objects feel like they have mass and inertia that reacted to a change of vector- working in a suspension with springs is just icing, since I mainly intend this to get used with hovercraft. I think that that part works acceptably, at this point.

As for the whole tracks thing... I know nobody's going to listen to me, but here's my opinion- just move the body, not the treads, and keep it extremely subtle. IRL, tanks are so massive that you rarely actually see them bounce much, and trying to simulate indepedent suspensions on multiple bogies, when they're usually only a couple of pixels high on the screen, and will move less than a pixel under any less than extreme conditions seems like a complete waste of time, to me. Just my $.02, of course- it's the kind of thing that makes a heck of a demo, but is completely worthless in a final game, and I'd just fake it, if I thought players really cared, by occasionally slipping in a "bumpy" track animation that showed a bump circulating along the lower portion. Big time investment for small value received, though.

Zpock · Post by **Zpock** » 16 Jun 2007, 22:15

Argh wrote:IRL, tanks are so massive that you rarely actually see them bounce much,

http://www.youtube.com/watch?v=MMa9MhSS ... ed&search=

Argh · Post by **Argh** » 16 Jun 2007, 22:29

The tracks are still pretty static parts of that, though, even with the IRL bogies that really do have suspensions (extremely stiff ones, since they're mainly trying to keep the track from slipping off the bogies). Meh, it's your free time, do whatever makes you happy, of course. But tanks are pretty stiff bodies, compared to a dune buggy.

Zpock · Post by **Zpock** » 16 Jun 2007, 22:33

I do partially agree with you. I want to try and see all/most options tough, before judging.

Argh · Post by **Argh** » 16 Jun 2007, 22:54

I totally understand. I think I might make a new tank for NB (assuming I ever release another version) that makes use of this, just for funsies.

Oh, and I just eliminated about 50% of the logic steps of the main animation process, and added another tweakable variable that lets people set a fake inertia up for X and Z rotation. Should be handy, for long/thin things, like the MegaSheep, or wide things with little depth (which I'm having trouble imagining right now, but meh).

Warlord Zsinj · Post by **Warlord Zsinj** » 17 Jun 2007, 00:41

Without any intended offense, it does look a little bit like they have hiccups rather then responding to the terrain below...

AF · Post by AF » 17 Jun 2007, 00:58

I like how when tanks go over a ridge they jump a little, any chance of that?

Argh · Post by **Argh** » 17 Jun 2007, 03:09

it does look a little bit like they have hiccups rather then responding to the terrain below...

Bear in mind, I'm trying to duplicate a vehicle with a bouncy, loose suspension. I can do a super-tight suspension by removing most of the traverse of the front wheels, keeping them much closer to the body, but that wasn't my objective here- Zpock's script showed a fairly loose suspension, and I wanted to figure out how to make the concept practical, because I think it'd make my game look better

If you watched those scenes of a real-world tank, you have seen that real-world vehicles do a lot of bouncing when traveling cross-country. On a flat map, or a map with mainly very smooth slopes, the simulation I wrote will perform accordingly- this doesn't bounce at all on flats, and barely any on gentler terrain. I picked Mars for the majority of the vids, because it's just plain easier to see how bumpy the terrain is, and how the script is responding.

If we want a smoother, less-bumpy ride, then I just turn up two variables for the vehicle's body, and one variable for the wheels. I can't do anything about how bumpy Spring maps actually are- I have a feeling that this is one of the few times most of you have really watched the details as I have. I'll do a video with the MegaSheep, a Strider, and a TriRook, to show you what un-augmented vehicle movement looks like, so that you can get a much better feel for how much vehicles with upRight = 0 are actually rotating just due to Spring's code.

Well, terrain in Spring is actually pretty granular, and has some other problems (iow, what looks like a small height distance, on a flat map, is very similar to a larger distance, on a very tall map). A MegaSheep is only 16 height-pixels on a side- it's not a very large sample area, and it causes some special problems.

I have a sneaking suspicion that Zpock's model is a bit larger than the MegaSheep (it's only 2X2) too, which would help smooth things out a bit. At that size, the only way to make things even smoother is by damping the top level that the body can travel, frankly. Because any change in height is, well, a change in height. After that, it's a matter of how "strong" the "springs" are, how much change they can make in vector, and how quickly that change is damped. Basically, just a matter of tweaking, which has to be done on a per-unit basis based on how the vehicle functions.

And remember, everybody complained when I didn't make it bounce up and down more than would be natural, because they weren't able to see what was happening, because I kept it natural at first. Then everybody said they couldn't see anything, which I thought was funny, because if you compared the unit's behavior with a stock unit moving down the same hill, you'd see the difference right away

Which, of course, I'll be doing with real production code. Because this shouldn't be something you really notice, imo- it should, ideally, be something that if you play a more primitive game, you notice the lack, not the other way around. I don't want my hovertanks or whatever to bounce around like they have rubber bottoms

That said, perhaps adding another detector (I'm only using two) will help for long-axis rotational stuff, and maybe provide a smoother see-saw. I'll try it, now that I know all of my math works properly. It's no biggie, and it'll hardly slow the code up- the GET operations aren't the thing that slowed up Zpock's approach, it was the simulation code that was very slow.

As for jumping a little... that's the one thing I haven't quite figured out a good way to simulate completely adequately yet, because that was where Zpock's trig was actually doing something that's hard to deal with, with simpler methods- looking at the video, it almost looks like he calculated angular momentum, or something, whereas I definitely just want to fake it. I've gotten the tires to stick to the ground, but lift some of the time... lemme go try adding two more detectors and two more math operations, and see if that does the trick. If it does, then I'll post up another video, and maybe start talking about what I wrote, and why it's so much faster, yet produces fairly similar results, visually.

<EDIT> Here we have the script with 4 detectors, and I found an error in a math step (oops!) and corrected it. It certainly seems to have smoothed it out a bit more, so I think that the small additional cost is justified (everything else, so far as I know, is now maximally lean).

<EDIT> Here's a movie with 4 different approaches- upRight = 1 (the Sheep), upRight = 0 (the Archer), upRight = 1 + my funky, primitive first take on this issue (the TriRook's fake upRight script, I forgot I haven't removed that code because I don't need it any more, and how primitive a solution it was, lol), and the Megasheep. I've slowed everything down to a crawl, so that you can really watch the differences- note, especially, how static that Archer looks now!

Just for funsies, and quite frankly, because it's ridiculously easy to apply, now that I know what the model requirements are going to be, and it's mechanically simple, etc., I'm going to go ahead and apply this to the TriRook, which should produce some very dramatic results... hopefully good ones, heh

Argh · Post by **Argh** » 17 Jun 2007, 07:37

Here's the hover version- note that it's really subtle here, because it's a very subtle slope with few bumps.

It worked, with only the most minor modifications needed, on the TriRook. So, now I have a TriRook that finally acts like it was supposed to- terrain-following hovercraft on land, UpRight submarine-ish thing over water. It's pretty kewl. I need to make teeny adjustments to the water-detection code (I have a crazy idea about how to finally, maybe, get the transition just right), but otherwise, it's pretty sweet, and what I was looking for in the first place (hovercraft is the main goal here, although we have some tanks and stuff where this could really come in handy, too).

Warlord Zsinj · Post by **Warlord Zsinj** » 17 Jun 2007, 08:08

Yeah, that latest one looks better. I mean, it's not quite as jaw-dropping as Zpock's, but as you said, it's probably several hundred percent more efficient.

My only concern with the hovercraft version is that if you have quite a large hover, it could look a bit awkward dipping so significantly and frequently, particularly where the terrain below is undulating quite a lot.

rattle · Post by **rattle** » 17 Jun 2007, 09:41

So what did you do? Do you scan the ground slope a couple of times each second and then wiggle the body if it's greater than some threshold?

Spring RTS Engine

A little demo.