Tanks - tracked vehicles driving and handling

[Strike_NOR 898]

This is actually so easy to reproduce that I managed this on my first recording attempt :)

 

 

Please read my other post to see if this is what's going on.

 

 

[oukej 2910]

We're investigating it. Thanks a lot for both repros (dirt hump and the low walls/statue pedestal)!

[R3vo 2654]

9 minutes ago, oukej said:

We're investigating it. Thanks a lot for both repros (dirt hump and the low walls/statue pedestal)!

 

You're welcome. I hope it helps solving those issues ;)

[x3kj 1247]

"explosive contact" behaviour is a key problem in physics modelling. In a force based system you need to create forces so that penetrating objects reject each other until they are no longer penetrating each other (or only ever so slightly). The "rejection force" is usally calculated by some spring factor * the distance of the penetration ± damping forces. Means, there will always be a tiny amount of "sinking into the ground" because at 0 penetration force is 0. This method works ok if objects come to rest or collide normally. Works bad if objects suddenly penetrate by a large amount (e.g. wheel suddenly 10cm in the "ground" due to ray cast falling onto another collision object, or two objects moving at very fast speeds and colliding, with collision speeds too fast for simulation step to resolve it properly)  -> Huge forces, and unphysical behaviour. 

 

One possible solution could be to limit the maximum suspension force per tire generated by physics contacts via a vehicle based config parameter. So whenever contact forces are extreme, they get capped to a certain configurable limit ->  this means the vehicle (or object) will slowly rise out of the ground whenever there are high penetration values, instead of beeing catapulted. How fast the vehicle will raise out of the penetrating object depends on the force cap. Initial starting point for experimentation (per tire) could for example be: 4x vehicle weight/ tire amount.

IIrc physx does not calculate penetration distance, but instead always forces the tire to sit on the surface and then calculated the suspension force from the tire distance offset (in suspension direction) between the current and the last simulation step. Unless i'm missing something (brain in sleep mode already),  a limiter on suspension force per tire should still work in this situation however. The only issue would be if suspension travel exceeds maximum permissiable limit. With the wheel beeing forced into the "nonpenetrating position" it means it will never clip into the ground. So if the force is also limited, the wheel would have to clip through the body - as there is no other way. And i dont think physx would like this either (possibly a crash as result or something ).

 

that said, in these sidescraping situations... IRL the track or the landscape piece would give way... It's not just the game that doesnt like this kind of driving ;)

 

On 21.11.2017 at 9:14 AM, Strike_NOR said:

 

I must admit though, that while being incredibly frustrating at times, you also get some hilarious results as @dslyecxi so elegantly captured last summer :) 

 

Also this one had me in tears:

 

 

This is not fault of Arma directly... RHS and CUP decided to add the tank barrel into the physx collision models of their tanks. Since turret turning is not part of the force considerations (yet?), they turn no matter what. IRL the turret would stop turning when it hits something and turret drive potentially break. Not in Arma.  Which leads to many potential "explosive contact" situations where vehicles get stuck or are launched. When they swing the turret around very fast and hit something with the barrel, it's like some hammer of god hit something with near infinite force.. Except that their tank is not anchored like static objects , and since actio=reactio they fly when a static object or the ground itself (definitely infinite resistance force) is struck.

Vanilla doesnt have tank barrels in the physx lod (they had at some point in alpha or beta).

[lex__1 422]

Spoiler

4 hours ago, Strike_NOR said:

 

I am going to make a "guesstimation" here and try to propose what may be going wrong.

 

The way it appears to me, ArmA's wheels "snap" to surface. Meaning that if suspension of a given wheel is not fully extended, it is "snapped" to the surface (sticky). If the vehicle moves over a hill, and the front wheels extend their suspension to maximum extension, then the wheels do not extend further, but they still "seek" to snap to the surface of something.

 

This method always works fine when there is a sudden increase in distance from vehicle hull to ground, because the wheel will simply "detach" from the surface, however it seems this has a really adverse effect when the opposite happens - when the distance suddenly decreases.

 

When a tank traverses it's hull sideways, the roadwheels will hit some curb/stone/object and immediately, due to wheel/terrain "snap" it compresses the suspension in a nanosecond. This means that the force is happening at light-speed, transferring to the hull, and then launching the tank (this is ground control to major Tom, there's something really wrong).

 

To me, this seems to be the reason. There is no "inertia" in arma suspension. In real life, the wheels are heavy, suspension is heavy and so if you try to compress the suspension, it will happen over time, not instantly. Sometimes it actually seems that ARMA 3 does not have physical suspension, only visual. Meaning that the 3D geometry model that acts with the surface is not really using suspension, but it's only animated for visual appeal. I may be wrong here, but that's how it feels some times.

 

 

I found a video that strikingly resembles this theory of no "arma shocks". It's made by someone in algodoo, and shows a three-wheeled vehicle with suspension, and one without. Just look at the one without suspension as it hits a tiny "bump", and think about what you see in ArmA :)

 

At 0:09 the first vehicle with suspension hits the small bump, look what happens to the second one immediately when it hits the bump:

 

 

This is very much resembling what we see in arma. Now imagine that you "spawned" the vehicle without suspension so that the wheels where clipping through the object, but standing on the surface. The result? If the vehicle wheels are designed to "snap" to the surface, they will instantaneously travel the height of that object in virtually an instant. Leading to X amount of m over no time.

 

 

A quick example of what this would look like. If a tank in arma, stands beside a curb that is 10 cm tall (0.1 meters). Imagine you traverse the track sideways so that the wheel "snaps" to the top of the curb as soon as it touches it. Let's say the time it takes for the wheel to perform this snap takes 0.01 seconds. 10 milliseconds.

 

Then the speed becomes 10cm x 100 milliseconds = 10m/s.

 

10 m/s = 36 km/h which would definitely launch the vehicle upwards in a small jump, if it does not properly absorb/dampen the shock.

 

Now what if the distance increases? Well the speed increases substantially. I don't know how many "ticks per second" the arma simulation runs at, but we can assume this is a constant. So then varying object height should vary the results.

 

Poles seem to fling things to infinity and beyond, while small stuff seems to make vehicles jump.

 

Have a look at this Quad ATV vs box. Although provoked by "moving the box", it seems highly related.

 

 

Seems again that the game is trying to check if the vehicle should be ontop, or next to the object it is "half-way" clipping through. It suddenly decides "oh, you are trying to be on top of the crate" and transports the front up there in a single "simulation tick" then we have Liftoff!

 

Like I said, I'm not 100% sure what's going on here, as I have not made any AddOns in O2 or tried to make vehicles in ArmA, but it does look to me that the problem that is causing this has to do with suspension, and wheels snapping to terrain/objects. The wheels should "transition" from the previous surface height, to the new object height over time, not in an instant. That would soften the effect some, and secondly the shocks should compress fast enough so that the force is not translated to the hull of the vehicle, subsequently launching it into space.

 

I'm just adding my take on it and hoping it may lead the devs to the clue of what is going on.

 

 

PhysX? More like SpaceX :)

 

Suspension of wheels in a game work, and doesn't make problems. A problem in another - Interaction of surfaces of textures. Diverse surfaces interact, under certain conditions allow to be stopped and get in themselves.
When surfaces were crossed, in a certain quiet state - nothing occurs.
When one structure tries to move (in other structure) - there is a pushing out. The light structure (with bigger degree of freedom of movement) is pushed out outside, from structure with smaller degree of freedom. If structures aren't released quickly, one structures can sustain damage, or collapse.
As it occurs - I will show in this video.

 

[oukej 2910]

12 hours ago, x3kj said:

One possible solution could be to limit the maximum suspension force per tire generated by physics contacts via a vehicle based config parameter.

Actually there are 2 new global properties in PhysXParams class since 16-11-2017, EXE rev. 143597 (game) - VehicleSuspMaxLinAcceleration & VehicleSuspMaxAngAcceleration. These are intended as a safeguard against suspension induced orbital launches. However the issues in the recent repros do not come directly from suspension. Probably more of a wheel collision or bad geometry collision.

[R3vo 2654]

@oukej What exactly does the maxSpeed property do? The T-100 can still go over 150kmph downhills so I guess it's not related to the real vehicle speed, is it?

 

Quote

Tweaked: The maxSpeed properties were adjusted for all tracked vehicles 

 

[lex__1 422]

9 minutes ago, R3vo said:

What exactly does the maxSpeed property do? The T-100 can still go over 150kmph downhills so I guess it's not related to the real vehicle speed, is it?

Tweaked: The maxSpeed properties were adjusted for all tracked vehicles 

This is not related to the speed of the slope. It is connected with a sudden jump on an even surface, in collisions with obstacles.

[R3vo 2654]

3 minutes ago, lex__1 said:

This is not related to the speed of the slope. It is connected with a sudden jump on an even surface, in collisions with obstacles.

 

I guessed so.  Thanks.

[oukej 2910]

51 minutes ago, R3vo said:

@oukej What exactly does the maxSpeed property do? The T-100 can still go over 150kmph downhills so I guess it's not related to the real vehicle speed, is it?

Same as it has been used on cars - it sets the limiter speed +~10%. But it won't apply brakes for you, so if you roll down a hill you can go as fast as the vehicle damping forces allow you.

[x3kj 1247]

On 23.11.2017 at 12:46 PM, oukej said:

Actually there are 2 new global properties in PhysXParams class since 16-11-2017, EXE rev. 143597 (game) - VehicleSuspMaxLinAcceleration & VehicleSuspMaxAngAcceleration. These are intended as a safeguard against suspension induced orbital launches. However the issues in the recent repros do not come directly from suspension. Probably more of a wheel collision or bad geometry collision.

Intended as safeguard, but do they cover every possibility? After all, the force on the wheel translates through the suspension. And like i said - if physx operates in the way i remember (tire always posed on top of the closest raycast hit), and you limit vehicle suspension forces (or acceleration - same result), then what happens if the new wheel pose would overstep maxcompression limit of the suspension? That would be one boundary condition to much.

Since there is imprecision and fluctuation in the calculations,  a physx car tire beeing positioned extremely close to a curb for example (with distance between wheel and curb approaching zero) - sidescraping basically, there could be a chance that the raycast may instead hit the top of the curb, rather than the road.  I haven't payed any attention, but do wheels properly cause lateral forces to prevent a tire close to a curb getting closer? And if so under what conditions is the force created? Maybe there needs to be a larger safety boundary. So when you drive and very slowly get closer to the curb, the lateral force from the collision needs to happen earlier, so that the raycast will always have a bit of buffer distance to not "glitch" on to the curb and cause sudden force spikes.

I'm just stabbing in the dark here, its been too long since i looked at physx (also i looked mostly at the clutch thing...).

[oukej 2910]

1 hour ago, x3kj said:

And like i said - if physx operates in the way i remember (tire always posed on top of the closest raycast hit)

Arma is now using sweep instead of raycast (http://docs.nvidia.com/gameworks/content/gameworkslibrary/physx/guide/Manual/Vehicles.html#wheel-contact-beyond-raycasts)
One of the issues we've been looking at is that there's not much difference between sides of the wheel. If you drift with a car onto a curb (or turn with a tank) - depending on the reject angle/point values set and the length of the suspension travel - the wheels get either blocked by the curb (too high or acute angle) or go onto it fluently. More or less the same as if you drove onto it straight forward. If the properties are set so there's almost always a blocking contact there's usually no violent reaction. But if we go for more blocking contacts we also sacrifice ease of terrain traversal.

A little improvement should go in with the next dev update and we're still looking at the issue.

[lex__1 422]

Today played the mission of "Final Strike".
The game made autosave in a situation where I had to repair the Marshal.
On the flat wheels, the Marshal stood under the crown of a tree.
The accident occurred when the wheels reappeared. The Marshal was restoring his height, and no longer fit under the crown of a tree.
I have replayed this save a few times. The video is the most successful episode. All the others killed the "Marshal", or he turned over, with the wheels up.
In this case, there were no curbs on the wheels.

In principle, can you change this behavior of machines so that they do not explode from objects that should not damage machines?

 

[scotg 204]

5 hours ago, R3vo said:

@oukej What exactly does the maxSpeed property do? The T-100 can still go over 150kmph downhills so I guess it's not related to the real vehicle speed, is it?

 

5 hours ago, lex__1 said:

This is not related to the speed of the slope. It is connected with a sudden jump on an even surface, in collisions with obstacles.

 

4 hours ago, oukej said:

Same as it has been used on cars - it sets the limiter speed +~10%. But it won't apply brakes for you, so if you roll down a hill you can go as fast as the vehicle damping forces allow you.

I haven't noticed any limiting effects from maxSpeed. The only thing I've noticed it do with absolute certainty is for garage comparison purposes. When browsing through all the vehicles, there is a little meter in the bottom-right corner that gives a visual representation of each vehicle's max speed. It appears to be up to the script writer to give "maxSpeed" a value that is consistent with tested results. Since the meter is relatively small and has no numeric rule on it, the value in script can be an approximation. If you have configured a sports car to reach speeds of around 200 kph, and give the value 2000 kph, then the meter will be one of the longest ones in the garage - despite the actual mediocre performance.

If it is intended to be a limiter then it is defective, because I can easilly defeat it with gearbox adjustments and/or MOI.

[oukej 2910]

On 11/24/2017 at 11:10 PM, scotg said:

If it is intended to be a limiter then it is defective, because I can easilly defeat it with gearbox adjustments and/or MOI.

Can you please verify the Dev-branch data? (e.g. T-100 s able to go up to ~74km/h without the maxSpeed property).
The limiter doesn't cap the speed exactly at the value. Depending on physical properties the vehicle may be able to go up to 10% more than the set maxSpeed on flat ground (VR). But not more than that.

[scotg 204]

@oukej My mistake... this wasn't something I've done in dev-branch, but rather in standard mode. Also, the 10% give/take is a factor I didn't count on when making those statements.

If you still want the data, what format did you have in mind? E.G.: Did you want a copy of the config I have and a screenshot of the speed as tested?

[oukej 2910]

On 11/27/2017 at 9:12 PM, scotg said:

If you still want the data, what format did you have in mind? E.G.: Did you want a copy of the config I have and a screenshot of the speed as tested?

No, thanks, I meant verifying the steam data. So everything works ok, right?

[R3vo 2654]

On 27.11.2017 at 2:10 PM, oukej said:

Can you please verify the Dev-branch data? (e.g. T-100 s able to go up to ~74km/h without the maxSpeed property).
The limiter doesn't cap the speed exactly at the value. Depending on physical properties the vehicle may be able to go up to 10% more than the set maxSpeed on flat ground (VR). But not more than that.

But if one compares the Kuma sound to the sound of the other tanks, one can hear that they at very different quality levels. So I presume the other tank's sounds are WIP, right?

[oukej 2910]

1 hour ago, R3vo said:

But if one compares the Kuma sound to the sound of the other tanks, one can hear that they at very different quality levels. So I presume the other tank's sounds are WIP, right?

Yup. All-the-land-vehicles. We're sorry we weren't able to make it for this patch.

[R3vo 2654]

29 minutes ago, oukej said:

Yup. All-the-land-vehicles. We're sorry we weren't able to make it for this patch.

 

No problem, good to know we are getting new sounds. The Kuma already sounds great!

[lex__1 422]

- By all tanks and cars, where there is a rotary tower, there is no sound of turn of a tower. The sound of turn of a tower was gone about two weeks on DEV.

- On DEV, a background sound in the tank when the motor is switched off, the sound is similar to a sound in a huge empty iron barrel).

[Strike_NOR 898]

21 hours ago, oukej said:

Yup. All-the-land-vehicles.

 

Wow, that's really great! If the Kuma sounds are anything to judge by, vehicles are getting a huge quality-boost in the sound department. After the weapon sound upgrade and jets DLC, the land vehicles were kind of left in the dust :)

 

Here are a few ideas I think you should investigate (or maybe you already are you sneaky devs):

 

• Road -> tire sounds. In reality, if you think about cars driving by you. The faster they go, the less engine noise you hear and more tire sound you get. I think @LordJarhead with JSRS soundmod does this very well for vehicles as you can hear in this video:
• Various sounds for different surfaces (at least asphalt and gravel/dirt road) Anywhere with gravel makes a whole different noise. Completely offroad tends to be very low noise due to soft terrain, grass etc that silences the tires.
• Audible distance: In the same video, you can very easily get the correct feeling. You you easily think that "this is what it would sound like in real life". That's immersion! It makes you connect to the game better.
• Broken down sound effect: I suggest you take a look at adding engine smoke and damage sounds (typically the broken radiator effect works nice here with sizzling water on metal, making the metal "pop and crackle". This is a very good visual and audible indicator for players that a vehicle has broken down, without having the disappointment of entering it only to find "red engine status".
• As others have pointed out. Maybe a turbo sound effect that can be used for engines. Many, if not most diesels have turbo(s) and these operate on speeds of maybe 120,000 RPM average. The RPM generally increases with increase in exhaust pressure, so it could be a separate sound layer that increases pitch with RPM, but that it follows a different curve than the sound of the engine itself. Maybe, since turbo sounds are rather generic (whine), it could be added as a default config parameter for addon makers to use. Just a simple "Has_turbo = true or false" type thing and then what RPM it fades in/out and what "TurboRPMmax/min" it would operate at (to create varying pitch between vehicles). It could be used for piston engine aircraft as well. Then of course, maybe a second effect when you hit "shift" in vehicles (max throttle).

 

Anyways, just a few thoughts while you are working on the effects anyways :)

 

 

[R3vo 2654]

Quote

 

Tweaked: Improved geometry of Dirt Humps 

 

 

I guess this was made to prevent space exploring missions with tanks when they collide with dirt hump, right?

Edit: Seems like the issue with dirt humps is gone. Good job ;)

Edited December 1, 2017 by R3vo

[x3kj 1247]

If we could get details on what was unfavorable on dirt humps LOD that would be a help for us modders, to know what should be avoided on our terrain models.

On 30.11.2017 at 8:14 AM, Strike_NOR said:

Broken down sound effect: I suggest you take a look at adding engine smoke and damage sounds (typically the broken radiator effect works nice here with sizzling water on metal, making the metal "pop and crackle". This is a very good visual and audible indicator for players that a vehicle has broken down, without having the disappointment of entering it only to find "red engine status".

This would only make sense immediately after a vehicle got the damage while operational, and only if the radiator was actually damaged. It makes no sense and is very gamey if this is permanent, or guaranteed no matter where engine was hit. There are many other reasons for engines becoming disfunctional that do not procude any externally visible effects or noise.

Seeing red engine status immediately after entering already is a simplification.

[Strike_NOR 898]

1 hour ago, x3kj said:

his would only make sense immediately after a vehicle got the damage while operational

 

True true. I think I didn't explain it fully. Just like Thermal Imaging textures fade in/out with heat over time, the sound and smoke effects of a broken down engine could be visible during the same window, so that a cold/dark tank being shot in the engine won't produce noise/smoke because there is no heat, but a warm running engine will as long as it remains hot. There are other things that could go wrong than a broken radiator, like ruptured coolant lines, fuel lines, lubrication etc. They would all contribute to smoke/noise.

 

I believe the advanced flight model has this when you damage the rotor from overstress. Very immersive imho.

 

Also, there could be a better soundeffect when vehicles burn, with this metal clang/clack noise.

 

RHS have implemented beautiful localized smoke effects for damage, but they still sound like a campfire to me :)

 

A yellow state engine could have an audible sound effect over it such as knocking, whining, screeching or grinding noises to help the player understand that the engine is damaged. Just saying that it would be more immersive, doesn't have to draw away from simulation for that matter.