Open shadowmage45 opened 7 years ago
Implemented and working. Seems to have no negative impact on kerbals or other parts interaction with the effected colliders. Cannot detect any extra memory allocations from material assignment.
Undergoing final testing and UI cleanup. Ideally one should be able to specify a spring-length of zero in the wheel config and it should from then on rely soley on the bump-stop collider. Need to ensure there are no cases where having a zero for suspension length or spring value would cause incorrect operations (NaNs from div0 operations).
Also with this feature update, all other non-linear suspension mechanics will be removed; this should remove the 'bounce' action at low suspension heights.
Potential NaN sources cleaned up.
Needs testing of a config-specified zero-length wheel setup.
Needs further examination for memory allocation.
NaNs not a problem. Memory allocation not a problem. Zero-spring and Zero-length suspension setups both working, with caveats.
Needs further investigation on ways to disregard collisions with the top and sides of the bump-stop collider -- using data from those collisions gives very inappropriate wheel response.
Further work on this feature has revealed low-level PhysX/Unity problems that will prevent it from working properly in many cases.
The essence of the problem is that given a craft with 4 wheels, in many cases only 2-3 of them may be in contact with the ground at any time, even when the craft is fully at rest. This causes problems with the friction code as it sees the wheels no longer in contact with the ground.
No known solution or even any conceivable workarounds at this time.
Might still consider porting over and using the zero-friction collider code, as it will still allow for removal of the non-linear spring handling. Could be paired with code that explicitly disables the motor (and steering?) when the wheel is overcompressed -- but somehow the friction still needs to be calculated and used.
For momentary over-compression, such as bottoming out from a jump, the above stuff will work acceptably. It really only breaks down when a craft is explicitly set to use zero-length suspension for all of its wheels (and still mostly works at that... but there are... problems...).
Not to be Captain Obvious, but surely a "zero-suspension" part is best modelled as a part with a very short stiff suspension. There would always be some compressibility of the part and the surface.
Ideally, yes. Unity/PhysX are far from ideal though.
However, how do you calculate how stiff the suspension needs to be to make sure that it will -never- completely bottom out? (It needs to be able to support the entire vehicle mass, plus any absorb any excess velocity from gravity/jumps/engines pushing downward/whatever)
Need to ensure that it never bottoms out, as it needs to use the spring/force value to determine the friction; if at any time it bottoms out, some of the weight of the body will be supported by the colliders and not the spring, and then the friction simulation breaks.
That is the root of the problem. Its not that I can't make parts with very short suspension, its that the friction simulation needs the 'down-force' value that can currently only be derived from the spring force, and that down-force value is only correct when the spring is fully supporting the load.
Zero friction collider materials, and handling for zero-length suspension.
Seems like the simplest way is to merely set the materials to Multiply mode and leave them be (along with assigning materials to those colliders that are missing materials).
Investigation needs to include checking what the default settings are on normal part colliders (null?), and what the default settings are for other 'null' materials (runway).
Testing needs to include testing of a kerbal walking around on the ground while the vehicle has set the colliders to Multiply mode, as well as testing how stock wheels interact, and standard part colliders.