[1.0.x] [V1.9f] Kerbal Foundries wheels, anti-grav repulsors and tracks

[Joshwoo70]

Just now, Shadowmage said:

PhysX is a physics engine and independent of what video card is installed in the computer; in fact most of it (the phsyics anyhow) runs on the CPU.

Unity / KSP -already- use PhysX, and as far as I'm aware there are no problems with people using AMD/ATI or Intel gfx (aside from the Intel stuff is always underpowered).

okay

[lo-fi]

15 minutes ago, Shadowmage said:

Calculating the sprung mass is... difficult... with arbitrary vehicle setups.

That was the conclusion I came to.  However, if I can make the joint based suspension work, the physics engine will do all that for us, and we can take the load data from the joint(s) This is all calculated correctly for joints by the physics engine, and probably better than we can manage! The suspension limit may still need some manipulation of rigidbody.position, but this is hardly taxing. I'll keep working on it.

[ComatoseJedi]

On 5/2/2016 at 0:59 PM, Gaalidas said:

For instance: I have been watching a LOT (I mean a -insert expletive here- load) of Space Engineers content on YouTube lately and they are plagued by the barely-manageable wheel physics that we are now dealing with here such as the extreme slipping and sliding (drifting anyone?)

I play Space Engineers regularly and can vouch for the wheel issue on the stock game. With that said, Keen software has done something that Squad hasn't. And that's opening the source code for the game to the public to facilitate mod development. So the wheel issue becomes a non issue when someone has written an ingame script to stabilize the wheels and give them better function than stock.

I probably need clarification on the issues with KSP/Unity 5, but the wheels behaving like they are isn't really a game issue, but a game engine issue? And would having an open source game help with making the wheels work?

[Shadowmage]

Open source only helps if:
1.) People are interested in contributing
2.) The -right- people are interested in contributing; those with the skills and knowledge to make improvements.  Random Joe may want to help, and have the best intentions in the world, but if he doesn't know what he's doing the likelyhood of him fixing things is close to zero.

However yes; the problem is not really an issue with KSP; it is an issue with the game engine (Unity) and their physics library (PhysX).  Squad/KSP have merely done the best they could when they were handed a plate full of excrement (well, they -could- have done a custom implementation... but again... skills+knowledge are needed to do it properly, which those at squad may or may not possess).

[ComatoseJedi]

27 minutes ago, Shadowmage said:

However yes; the problem is not really an issue with KSP; it is an issue with the game engine (Unity) and their physics library (PhysX).

Thanks for clarifying that up for me. And I do agree with the points you made on open source. While you did hint at the problems you were having on your thread with the landing gears, I really didn't know exactly why the wheels were misbehaving. Now it's up to learning physics to get your wheel fix working (may the Kerban Gods have mercy on your soul)

 

[damerell]

3 hours ago, Shadowmage said:

Still not sure how this would work for wheels used as bumpers though; e.g. the vehicle is on the ground supported by 4 wheels but has another set on the front end being pressed into a wall; obviously the two being pressed into the wall aren't 'supporting' any weight, but they -would- exert a force to resist the compression.

Shurely the direction the force is being exerted in tells us that. If the suspension faces down, it's resisting gravity; if it faces outwards, it's not; in between a bit of trig sorts it out?

[lo-fi]

Don't call me Shurley

[TiktaalikDreaming]

6 hours ago, Shadowmage said:

Open source only helps if:
1.) People are interested in contributing
2.) The -right- people are interested in contributing; those with the skills and knowledge to make improvements.  Random Joe may want to help, and have the best intentions in the world, but if he doesn't know what he's doing the likelyhood of him fixing things is close to zero.

However yes; the problem is not really an issue with KSP; it is an issue with the game engine (Unity) and their physics library (PhysX).  Squad/KSP have merely done the best they could when they were handed a plate full of excrement (well, they -could- have done a custom implementation... but again... skills+knowledge are needed to do it properly, which those at squad may or may not possess).

I happen to think that for KSP, there's a pretty strong community that includes many people that have pretty solid skill sets in physics and often programming as well.  BUT, making things open source creates a collection of other problems as well, with moderating code updates and so on.  They'd want to be pretty careful, because the KSP community includes those useful people, but isn't composed entirely of them.  What KSP does have is a requirement for mods to be open source (essentially), so they can pick over the work done by the community for useful bits. 

I personally think they'd be better off publishing their source (at least for a few modules), without necessarily allowing anything but comments from the peanut gallery.  Because the comments from the peanut gallery could contain useful info.  And might be a lot easier to sort through.

Also, there's a couple of issues.  Wheels are nVidea's fault, pure and simple.  Unity inherits the physx friction weirdness, and KSP inherits Unity's friction weirdness.  Tracks are a different thing, as @Shadowmage and co are trying to invent a way of having tracks work using physx/Unity components.  A lot of that boils down to nvidea's fault as well, but less directly.  :-)

[lo-fi]

I'm making some progress, learning a lot about configurable joints as I go. This might actually be workable... sorry for the lack of detail, it would take ages to explain!

[ComatoseJedi]

6 hours ago, TiktaalikDreaming said:

Wheels are nVidea's fault, pure and simple.

That does bring in a major factor of suckiness.

And I do agree with your view on open sourcing. It's just that when you do run into a problem, like Shadowmage has in the past with stock, you have to -hack- your way around it instead of tweaking a few things and adjust it to make the code work for you, not against you. But, as you said, it runs into another myriad of problems with keeping the code up to date and people with good intentions not knowing what they are doing. That's why I leave all this modding and coding to the learned professionals and -try- to be helpful in other areas, like cheerleading. GO TEAM WHEELS  

[Tr1gg3r]

just popping in to see how y'all getting on, hope you manage to work it all out.......fingers crossed. look forward to seeing what you lot come up with for 1.1+  etc. 

Best o Luck - TEAM WHEELS \o/

[Neutrinovore]

On ‎5‎/‎7‎/‎2016 at 6:40 PM, lo-fi said:

I'm making some progress, learning a lot about configurable joints as I go. This might actually be workable... sorry for the lack of detail, it would take ages to explain!

Yes, no need to take time to explain, take time to FIX!!  Lol! 

Something that irks me about this whole issue, meaning Squad's inability to reproduce 'in-game' a relatively simple physical object - the wheel.  While I realize that there are a great many things that need to be simulated in the code, things that you've talked about such as suspension variables like shock and rebound and damping and... other stuff.  Anyway, while I'm certainly no computer coder or programmer, I get that it's not just "oh, well, a wheel is simple, it should be easy to simulate in a completely virtual way".  However, my point is that there are at least a few other games out there that use the Unity engine, although admittedly I don't know how many use Unity 5 yet, but anyway, there are a few games out there THAT HAVE WHEELS IN THEM that use Unity, and maybe I'm just not paying attention, but I don't hear any great wailing and gnashing of teeth about how crappy the wheels in THOSE games are.

I guess what I'm saying is that I just don't get why Squad seems to have such difficulty doing things that other games manage with no apparent problems.  Wheels.  AIR, for felgerkarb's sake, how many flight sim games are there out there that accurately simulate aerodynamic forces on an aircraft, but Squad's atmosphere settings seem to be set permanently on 'custard'!

Grrr.  Sorry, again, rant over, but I'm becoming increasingly disenfranchised by KSP's inability to do anything that it's supposed to do even COMPETENTLY, let alone WELL.

'Nuff said, for now at least.  Keep on keepin' on, lo-fi, you're 'good people' in my books. 

[TiktaalikDreaming]

50 minutes ago, Neutrinovore said:

Yes, no need to take time to explain, take time to FIX!!  Lol! 

Something that irks me about this whole issue, meaning Squad's inability to reproduce 'in-game' a relatively simple physical object - the wheel.  While I realize that there are a great many things that need to be simulated in the code, things that you've talked about such as suspension variables like shock and rebound and damping and... other stuff.  Anyway, while I'm certainly no computer coder or programmer, I get that it's not just "oh, well, a wheel is simple, it should be easy to simulate in a completely virtual way".  However, my point is that there are at least a few other games out there that use the Unity engine, although admittedly I don't know how many use Unity 5 yet, but anyway, there are a few games out there THAT HAVE WHEELS IN THEM that use Unity, and maybe I'm just not paying attention, but I don't hear any great wailing and gnashing of teeth about how crappy the wheels in THOSE games are.

I guess what I'm saying is that I just don't get why Squad seems to have such difficulty doing things that other games manage with no apparent problems.  Wheels.  AIR, for felgerkarb's sake, how many flight sim games are there out there that accurately simulate aerodynamic forces on an aircraft, but Squad's atmosphere settings seem to be set permanently on 'custard'!

Grrr.  Sorry, again, rant over, but I'm becoming increasingly disenfranchised by KSP's inability to do anything that it's supposed to do even COMPETENTLY, let alone WELL.

'Nuff said, for now at least.  Keep on keepin' on, lo-fi, you're 'good people' in my books. 

I feel the following needs inserting here;

Quote

"And the wheel," said the Captain, "What about this wheel thingy? It sounds a terribly interesting project."
"Ah," said the marketing girl, "Well, we're having a little difficulty there."
"Difficulty?" exclaimed Ford. "Difficulty? What do you mean, difficulty? It's the single simplest machine in the entire Universe!"
The marketing girl soured him with a look.
"Alright, Mr. Wiseguy," she said, "if you're so clever, you tell us what colour it should be."

 

[Kenobi McCormick]

6 hours ago, Neutrinovore said:

Yes, no need to take time to explain, take time to FIX!!  Lol! 

Something that irks me about this whole issue, meaning Squad's inability to reproduce 'in-game' a relatively simple physical object - the wheel.  While I realize that there are a great many things that need to be simulated in the code, things that you've talked about such as suspension variables like shock and rebound and damping and... other stuff.  Anyway, while I'm certainly no computer coder or programmer, I get that it's not just "oh, well, a wheel is simple, it should be easy to simulate in a completely virtual way".  However, my point is that there are at least a few other games out there that use the Unity engine, although admittedly I don't know how many use Unity 5 yet, but anyway, there are a few games out there THAT HAVE WHEELS IN THEM that use Unity, and maybe I'm just not paying attention, but I don't hear any great wailing and gnashing of teeth about how crappy the wheels in THOSE games are.

I guess what I'm saying is that I just don't get why Squad seems to have such difficulty doing things that other games manage with no apparent problems.  Wheels.  AIR, for felgerkarb's sake, how many flight sim games are there out there that accurately simulate aerodynamic forces on an aircraft, but Squad's atmosphere settings seem to be set permanently on 'custard'!

Grrr.  Sorry, again, rant over, but I'm becoming increasingly disenfranchised by KSP's inability to do anything that it's supposed to do even COMPETENTLY, let alone WELL.

'Nuff said, for now at least.  Keep on keepin' on, lo-fi, you're 'good people' in my books. 

The Source engine, designed from the ground up to be a first person shooter, handles wheel physics better than KSP! Go play Gmod. There's no special module in that game to handle the interaction between something round and the surface upon which it rolls. The basic physics properties of the surface, of the wheel, handle all of that. How your car handles in Gmod is 90% how you set up the suspension constraints, 5% how you set up the controls, power system, and 5% hoping that you don't get constraint spazz when you run over a small prop left on the ground by the newbie spamming thrusters and soda cans.

 

 

I don't know if Unity supports that sort of level of physics, though.

[lo-fi]

18 hours ago, Kenobi McCormick said:

I don't know if Unity supports that sort of level of physics, though.

I'm afraid not - this is why we have the special construct that it the wheel collider. 

 

On 5/8/2016 at 10:51 AM, TiktaalikDreaming said:

It's the single simplest machine in the entire Universe

IRL yes, but modelling it is surprisingly difficult.

 

On 5/8/2016 at 9:59 AM, Neutrinovore said:

KSP's inability to do anything that it's supposed to do even COMPETENTLY, let alone WELL

Where Squad struggle is making this stuff work in a sandbox game. Any fool can make a 4 wheel vehicle and fudge the wheel collider settings to work for that specific weight and placement, the same as anyone with half a brain can set up some "reasonable" drag figures for a given design of plane, rocket or whatever. In a normal game, these values are static as the design can't be changed. KSP has to calculate them all - and being sandbox, people do some mental things, so the models have to cover all eventualities. Simplifying such complicated models into something that runs real-time on consumer hardware is no mean feat! I've never got the impression any of the team at Squad are areo engineers either, but I could be wrong.

[lo-fi]

OK, my joint based suspension works lovely in U5. Each "Wheel" works like this: an dummy object with a kinematic rigidbody is created and placed at the end of the suspension travel line. A configurable joint is created between the "wheel" and this dummy object with relevant settings to turn it into a linear joint -  suspension is configured here. In FixedUpdate() the position of the dummy object is updated with the hit point of a raycast (we can move onto sphere later), so the suspension always updates against the contact point on the terrain. This makes perfect repulsors, as the dummy object has no link to the ground. This is possible either by linking it to the ground with another joint, or simply manipulating its positions with some calculation. Configurable joints allow you to manipulate the three linear axis spring and damper separately, so we have the option of adding some "slip" in there, or fixing those two joint axis and doing the rest mathematically. Either way, this is looking rather promising  The joint is simply broken if the travel goes over the set travel limit, so it doesn't get stuck to the ground with a "negative" spring.

I'll make it all into a script you can drag onto a GO with all the proper joint configs and whatnot, add some comments and bung in GitHub some time during the week. Our "loading" problem can be solved by measuring compression (raycast distance) against the weight of the vessel to factor into grip calcs.

Progress!!!

[TiktaalikDreaming]

5 minutes ago, lo-fi said:

, so the suspension always updates against the contact point on the terrain.

Progress!!!

THAT sounds lovely.  Because KSP wheels certainly don't behave that way.  :-)

And, I've said this on a few topics.  Take your time.  Yes, people want this, but unlike Squad, they didn't pay you for it.  The only deadlines are your own, and try to remember you're doing this for "fun".  At least I tell myself all that.  ;-)

[damerell]

Re sphere colliders, I was wondering if they will give unexpected results with very large wheels with flat bases such as on some of the bigger track units?

[Shadowmage]

1 hour ago, lo-fi said:

OK, my joint based suspension works lovely in U5. Each "Wheel" works like this: an dummy object with a kinematic rigidbody is created and placed at the end of the suspension travel line. A configurable joint is created between the "wheel" and this dummy object with relevant settings to turn it into a linear joint -  suspension is configured here. In FixedUpdate() the position of the dummy object is updated with the hit point of a raycast (we can move onto sphere later), so the suspension always updates against the contact point on the terrain. This makes perfect repulsors, as the dummy object has no link to the ground. This is possible either by linking it to the ground with another joint, or simply manipulating its positions with some calculation. Configurable joints allow you to manipulate the three linear axis spring and damper separately, so we have the option of adding some "slip" in there, or fixing those two joint axis and doing the rest mathematically. Either way, this is looking rather promising  The joint is simply broken if the travel goes over the set travel limit, so it doesn't get stuck to the ground with a "negative" spring.

I'll make it all into a script you can drag onto a GO with all the proper joint configs and whatnot, add some comments and bung in GitHub some time during the week. Our "loading" problem can be solved by measuring compression (raycast distance) against the weight of the vessel to factor into grip calcs.

Progress!!!

 

Excellent

Will take a look at this as soon as you've got it all in a usable state and see what I can do about working on the friction.  If they expose a load/sprung mass value I might well be able to clean up some of the problems I was experiencing last I played with it.

Putting the finishing touches on my mod and doing the last balance passes for its initial (public/non-beta) release this week, but should have a bit of time to play around with wheel stuff; and as soon as my mod hits the public/released stage I'll have quite a bit more time to devote to the wheels end of things.

[lo-fi]

5 minutes ago, damerell said:

Re sphere colliders, I was wondering if they will give unexpected results with very large wheels with flat bases such as on some of the bigger track units?

They'll certainly be better than a one dimensional ray  The spherecast works like a "thick ray", and is what the wheel colliders should have been using anyway. I've seen several (though not open source) that used them to improve the simulation. 

1 minute ago, Shadowmage said:

 

Excellent

Will take a look at this as soon as you've got it all in a usable state and see what I can do about working on the friction.  If they expose a load/sprung mass value I might well be able to clean up some of the problems I was experiencing last I played with it.

Putting the finishing touches on my mod and doing the last balance passes for its initial (public/non-beta) release this week, but should have a bit of time to play around with wheel stuff; and as soon as my mod hits the public/released stage I'll have quite a bit more time to devote to the wheels end of things.

Sounds like the timing is fortuitous  I'm playing around trying to see if I can improve things further by using the ConnectedAnchor property, rather than a dummy object. As usual, things are not at all as they first seem.

[Shadowmage]

11 minutes ago, damerell said:

Re sphere colliders, I was wondering if they will give unexpected results with very large wheels with flat bases such as on some of the bigger track units?

My one...concern... with the sphere colliders would be the simulation of tires that are big + skinny (e.g. bicycle, motorcycle, even most car tires); sphere colliders can give incorrect results on the sides of these as it will incorrect detect collisions with objects that lie completely outside of the tire bounds;  -might- be some cleanup that can be done in the raycast code though to exclude these false-positives.

Other than that they will be better in nearly every respect compared to a simple raycast.

The only further improvement that could be made would be to actually project and check collisions between the visual mesh (or a custom/simplified collider); however I'm not sure that Unity has generic 'mesh-cast' functionality, and I -am- sure that it would be terrible for performance for anything but the simplest of meshes.

[lo-fi]

That is a fair point about the skinny wheels, but no reason we can't check to see how far offset from the plane of the wheel the collision point is and correct as appropriate against a "wheelWidth" configurable. It might even be possible to correct for wide wheels using this method too, so long at they're not wider than the diameter. Agreed that making a mesh cast would be a terrible performance hit. Sphere colliders, IIRC, are the best performing of any primitive collider type.

[Neutrinovore]

On ‎5‎/‎8‎/‎2016 at 9:37 AM, Kenobi McCormick said:

The Source engine, designed from the ground up to be a first person shooter, handles wheel physics better than KSP! Go play Gmod. There's no special module in that game to handle the interaction between something round and the surface upon which it rolls. The basic physics properties of the surface, of the wheel, handle all of that. How your car handles in Gmod is 90% how you set up the suspension constraints, 5% how you set up the controls, power system, and 5% hoping that you don't get constraint spazz when you run over a small prop left on the ground by the newbie spamming thrusters and soda cans.

 

 

I don't know if Unity supports that sort of level of physics, though.

Yes, this is my point, I think that Squad FUBAR'd bigtime when they chose Unity.  But it serves no purpose to tell me to "Go play Gmod".  Gmod isn't KSP!

[Vorg]

5 hours ago, damerell said:

Re sphere colliders, I was wondering if they will give unexpected results with very large wheels with flat bases such as on some of the bigger track units?

I don't under stand why spheres are being used for cylinders. It is clearly causing colider issues by hitting part on the vehicle when it really isn't.

[lo-fi]

7 minutes ago, Vorg said:

I don't under stand why spheres are being used for cylinders. It is clearly causing colider issues by hitting part on the vehicle when it really isn't.

......then you have a lot of reading to do.

 

3 hours ago, Neutrinovore said:

Yes, this is my point, I think that Squad FUBAR'd bigtime when they chose Unity.  But it serves no purpose to tell me to "Go play Gmod".  Gmod isn't KSP!

Most of the mods would probably not exist were it not for Unity being so commonly used and understood. I certainly wouldn't have managed were it not for forums full of info.