Make the rugged rover wheels work upside down

[THX1138]

I thought I had a smart idea to make a rover that would still work after flipping over but it doesn't function because the wheels don't detect the surface when upside down. I made a video to demonstrate the problem:

[thereaverofdarkness]

I had the same idea but I never got around to testing it.

[r4pt0r]

the whole wheel/ground-contact/friction relationship needs a good look from the devs in my opinion. you raise a point I never knew was a problem.

[Wjolcz]

The wheels seem to have some oddities. As far as the landing gear doesn't need to work no matter what it's angle to the ground is, it would be nice if we could do this with rover wheels. I once posted this as suggestion, but it didn't get popular enough. It's nothing game breaking, but would be cool to have.

[Murph]

The way standard Unity wheels work, this is impossible. In physics terms, there is no wheel, just a stick pointing in one direction, and the ground has to be perpendicular to and at the correct end of it. The shape isn't round, nothing rolls, the physics model has very little in common with what you would recognise as a wheel. The stick can be telescopic and spring loaded, for suspension (which doesn't really work properly unless the load on the suspension is precisely correct for its settings). It essentially abstracts away the entire concept of a wheel to just a contact point with some parameters to simulate the behaviour of a wheel in terms of forwards/backwards friction and sideways friction.

So, it's very likely a huge amount of effort, most likely requires abandoning Unity's wheels, and literally re-inventing the wheel. Of course, it's possible to fully simulate a round wheel which rotates, but that would be a massive computational task (i.e. high potential for lag), in comparison to the highly simplified and restricted model currently used.

[THX1138]

The way standard Unity wheels work, this is impossible. In physics terms, there is no wheel, just a stick pointing in one direction, and the ground has to be perpendicular to and at the correct end of it.

Okay, what if you model it as two sticks pointing in opposite directions or maybe four sticks at right angles, just to be sure?

[Murph]

Okay, what if you model it as two sticks pointing in opposite directions or maybe four sticks at right angles, just to be sure?

Then you have scrapped Unity's wheels, and re-invented the wheel (and it's another one that has very little relationship to real wheels, just a different highly simplified one, this time with zero support from Unity). If those sticks are implemented the same way that Unity does it, most of the problems still exist if you're not close to perfectly perpendicular with one of them, but the overall physics of the wheel simulation got a lot more complicated (paging the lag monster…).

Frankly, wheels play such a minor role in a space exploration simulation game, that I don't see the cost:benefit. The wheels we have are good enough for normal usage. A broader range of landing gear would be nice, using the existing perfectly functional and simple Unity not-really-wheels, but that's all we really need. I do get that some people want to do stuff with wheels that's impossible right now, but those things are pretty much outside the scope of the game.

[klgraham1013]

Wheels play a pretty large part in my space exploration simulation game. Exploratory rovers. Supply transfer down on bases. Construction vehicles. I use wheels quite extensively.

[Murph]

Wheels play a pretty large part in my space exploration simulation game. Exploratory rovers. Supply transfer down on bases. Construction vehicles. I use wheels quite extensively.

Sure, but the existing Unity not-really-wheels work just fine for that for most people. A more complex wheel simulation isn't really needed for any of those.

[THX1138]

There's nothing just fine about a rover on it's back or side that can't move or right itself. Don't act like "most people" haven't had their rovers fall over and become useless so they need to keep reloading saves. Moving ~40 meters per day like Curiosity isn't an option either.

[moronwrocket]

Has anyone tried using the AIRBRAKES to right a rover? I haven't unlocked the tech yet.

[Murph]

There's nothing just fine about a rover on it's back or side that can't move or right itself. Don't act like "most people" haven't had their rovers fall over and become useless so they need to keep reloading saves. Moving ~40 meters per day like Curiosity isn't an option either.

Nope, I do not see the small benefit here being worth the fairly huge cost. Driving fast in low gravity environments, over very rough terrain (which is the typical circumstances for flipping a rover) is not realistic. The Apollo lunar rover design speed was 8mph, with an unofficial lunar land speed record of 11.2mph. 8mph is approx 3.5m/s.

I strongly oppose spending development time on replacing the Unity wheel module. Unity wheels have their flaws, but can be made to perform perfectly well for all reasonable purposes which are currently in scope for KSP. There are far more important and useful things for Squad's limited development resources.

Driving like a maniac in low gravity is out of scope, in my opinion, so up to the mod community if someone wants to implement a far more complicated (and therefore very likely far more laggy) wheel physics module, or implement GTA-Mun.

[thereaverofdarkness]

So, it's very likely a huge amount of effort, most likely requires abandoning Unity's wheels, and literally re-inventing the wheel. Of course, it's possible to fully simulate a round wheel which rotates, but that would be a massive computational task (i.e. high potential for lag), in comparison to the highly simplified and restricted model currently used.

You're making it harder than it is. Just make the wheel stick pivot on the axis and always point straight downward.

[THX1138]

Driving like a maniac? I was doing all I could yesterday to stay below 4 m/s going down a Duna slope. I had to keep zig zagging to make the descent as gentle as possible but I also had to be very careful turning, especially because I was on a slope. The brakes were on the whole time. I'm not trying to drive like a maniac.

Is there any reason the line can't pivot like thereaverofdarkness suggests?

[Murph]

Is there any reason the line can't pivot like thereaverofdarkness suggests?

Yes, the Unity wheel module doesn't support that.

[klgraham1013]

Yes, the Unity wheel module doesn't support that.

You are just adamantly against any modification to the Unity engine, aren't you?

[thereaverofdarkness]

Yes, the Unity wheel module doesn't support that.

But if the "wheel were reinvented", then this new wheel would have the desired functionality without requiring any more calculations than the old wheel design.

[Murph]

You are just adamantly against any modification to the Unity engine, aren't you?

Not at all, I'm simply against very poor cost:benefit development. The wheel physics code has to run potentially hundreds of times per second, additional complexity is not something that is desirable in there. I also don't believe that it's even remotely important to change the behaviour of the wheels, as they work just fine for normal purposes; they are perfectly adequate for KSP. There are far better things for Squad to be working on.

Also, remember that once you modify standard Unity behaviour, you own it in terms of support, and progressively lose the benefits of using an standard game engine to start with, upgrades to a newer version of the engine can become harder work, etc.

- - - Updated - - -

But if the "wheel were reinvented", then this new wheel would have the desired functionality without requiring any more calculations than the old wheel design.

Nope. The reason why physics engines use fairly crude approximations for things like wheels is to keep the complexity of the calculations down. Any change to more accurately model the wheel would almost certainly be much more costly in computation, and it's code that has to run every physics frame, for every wheel that is active (i.e. potentially hundreds of times per second, and it's only one small part of the physics simulation).

[klgraham1013]

snip

Welp. I still support the idea.

[Joonatan1998]

It might cause some lag, but usually there aren't that many wheels.

So I support.

I would say every building having 3 upgrade states and (almost) all states having a destroyed state has far lower cost:benefit ration than wheels that work in a way that make sense.

Edited May 5, 2015 by Joonatan1998

[thereaverofdarkness]

Nope. The reason why physics engines use fairly crude approximations for things like wheels is to keep the complexity of the calculations down. Any change to more accurately model the wheel would almost certainly be much more costly in computation, and it's code that has to run every physics frame, for every wheel that is active (i.e. potentially hundreds of times per second, and it's only one small part of the physics simulation).

I just gave an idea that's actually less complex. Instead of the wheel matching its direction to the angle of the thing it's attached to (the current model), it simply always points straight down. That's one LESS calculation to perform. It could be balanced out by only being allowed to point along the wheel's spin axis, and simply choosing the direction closest to straight down that it can. That would be about as complex as the current wheel mechanic.

[Murph]

I just gave an idea that's actually less complex. Instead of the wheel matching its direction to the angle of the thing it's attached to (the current model), it simply always points straight down. That's one LESS calculation to perform. It could be balanced out by only being allowed to point along the wheel's spin axis, and simply choosing the direction closest to straight down that it can. That would be about as complex as the current wheel mechanic.

And when the terrain under a wheel is at a steep angle, it fails. "Down" for a wheel isn't always down according to gravity, that's a new complex thing which needs to be re-calculated every physics frame. Using a fixed "down", based on the orientation of the wheel part completely avoids that complexity.

[THX1138]

What if the wheel we see is actually in the physics four Unity "wheels" at right angles - then the wheels would work in four orientations.

[thereaverofdarkness]

In any case, I think it's something to be looked at, and I don't think it would be that difficult to come up with a working solution. I'm not a programmer so I can't say what will cost the least CPU cycles, but I see many potential strategies to explore. One need only be creative.

[youkofoxy]

fewer cycles would be less operations.

my tire idea of "realistic" would use the mesh collision state, part of KER code for slope angle and make the traction calculations based on COM vectors.

it would use a good processing power. but would approach to what happens in the real world.

especially if you use the biomes as model modifiers.

I find even stranger, save processing power with a lousy tire system. while is spent, processing power, rendering two planets to have only one planet on the screen.