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
