Jump to content

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


lo-fi

What to work on next?  

1,282 members have voted

  1. 1. What to work on next?

    • More wheels
      123
    • More tracks
      453
    • Rover bodies
      241
    • Landing gear
      137
    • Landing legs
      108
    • Something completely different
      193


Recommended Posts

So, for anyone who is interested in testing or contributing to the development of the replacement Wheel Collider component/module/code, I have set up a github repository with the current WIP implementation:

https://github.com/shadowmage45/KSPWheel

It currently is only geared towards setup and testing in the Unity Editor, and the repo thus far consists mostly of a Unity Project with a few example/test vehicles.  It is semi-function in its current state as far as suspension and basic friction model go, but there is still a lot to be done.

Development of a KSP PartModule will come after the basic physics stuff has been worked out (friction, suspension, etc); I might actually leave that up to individual mods to implement (as everyone's preferred model rigging is different, as is their required feature-set).

The goal for this week is to get the default spring/damper model in place and functioning properly under all circumstances.  It is currently mostly there but needs a bit of... attention.  Will also be looking into a 'dynamic' spring/damper model where it can be easily auto-adjusted for the vehicle mass (e.g. just input 'stiffness' and 'damping ratio' and it will be auto-scaled for the current vehicle; not exactly realistic, but needed for KSP type setups).

Next week will be cleaning up the default dynamic friction model.  After that will be static friction and adherence (likely the most difficult to figure out).

 

If anyone out there is familiar with Unity physics (and/or physics in general) and wants to contribute... by all means, do so :)  I'm open to regular PRs, or if you feel you would like to contribute more regularly I am willing to add a few more people as collaborators to the project (push access).

The aim of this project is to create a replacement low-level Wheel Collider component that -just works-.  Due to familiarity it will likely very closely resemble the U4 WheelCollider component when finished (at least externally), though it may have some additional internal features or customization options as well (such as switching of spring or friction models).

 

Looking forward to collaborating with you guys and seeing Kerbal Foundries continued for the latest KSP versions.  Has always been one of the first part-mods that I install on my games and I won't even start my next career game without it :)

Link to comment
Share on other sites

I never thought the original post would be resumed again... considering it is a pretty hefty topic as it was when we closed it.  Anyway... despite my plans and ideas and whatnot, it is obvious i don't have the time to actively work on this and likely won't in the near future.  Don't forget about me, though, when assigning any permissions and whatnot.  Summer comes relatively soon and i may yet have some time to look into this mod again.

One thing I have been doing is a bit of research considering how the wheels are implemented in this and other Unity-based games.  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?) but they also have a lot of adjustable settings on the fly without having to reinitialize things and whatnot.  I don't know if that's as much of a problem in the new engine, but I remember a while back we had to give up changing certain values when the flight scene was loaded due to limitations in the engine... unless that was squad-side in which case I am totally wrong... and it wouldn't be the first time either.

Nothing has really come out of this research other than the fact that is sucks for everyone, cross-game-platform even.  On the up side, for the SE players anyway, a lot of the innovations in KSP vehicles are starting to filter into SE builds as more KSP players are picking up the other title as well.  I'm still waiting for someone to make an SE version of that crazy Kethane rig lo-fi showed off in the early days of KF.

Anyway... looking forward to see if you guys can make it work.  I'd be interested to know if anyone has actually managed to make any of the modules load up in the game and if any of the features at all are still functioning.  The only thing I can think of that could still work okay would be the basic rendering of the GUI menu since they left a lot of the old GUI API still accessible, but I doubt the activation icon still functions properly.

 

I really like the idea of auto-adjustments by the way...

That was one of my long term goals when I set up the GUI to be able to handle adjustment sliders and whatnot.  I wanted those to, in the end, become more of a debug option and have the wheels actually grab their settings from a craft-based module (vessel modules I think they were called) which would determine if the craft is even in need of such a module (if not it would kill itself... suicidal modules?  Depression in module AI when its purpose is determined to be null?  I know the feeling...) and, if so, would then calculate all the necessary variables and make them available to each wheel to then include in its individual computations based on its position on the craft and how much of a load it is being asked to carry.  I also wanted to find some way to have the wheels be able to adjust their suspension to keep the craft either as level with the ground as possible or as level with with upright vector as possible (and also apply this to legs) and, possibly, provide IR-style bookmark points for suspension height and such to help with fixed-height ramps for back or side-loading cargo bays (or drop-down bays even).  It's a long list of improvements to the craft control scheme that would all rely on some way of auto-adjusting dynamic variables while in the flight scene without re initializing anything.

Other than that, i wanted to make KF into an extendable project which I am learning more and more about in school right now.  (Technically "right now" is a loose term since the current topics are all on Unit Testing which I am beginning to really hate with a passionThat and doing web-development with Linux which is completely new to me despite my geeky upbringing.)

Anyway... I hope this project sees the light of day before the next big release of some unknown title from an unknown developer blows the world away and sucks us all into it.  I'll be sure to keep an eye on it and pipe up if I see anything useful.

Edited by Gaalidas
Link to comment
Share on other sites

On 4/29/2016 at 3:54 PM, lo-fi said:

Thread re-opened as Gaalidas is AWOL and I couldn't update the OP on the other thread. 1.0.x download link is live, plus info about 1.1 status.

We're back in business! I'd forgotten how gargantuan this thread was. Good to be back :)

 

EDIT: and a small thanks to @sumghai for working his moderator magic!

Yeah... sorry about that.  Seems I overestimated what I could handle with school and real-life stuff going absolutely nuts on me.  I appreciate you wanting to move away from this stuff lo-fi, but we need someone to take command who can handle at least some of the pressure.  I'm still lurking around, but I fully support the closing of my thread and the re-opening of this one.  My thread was going nowhere quickly.

 

 

Edit: As for the project linked above... I had an initial look at the code and I must say I'm impressed so far.  Actually, I only looked at a single file... BUT (You gotta shout those awkward words out with emphasis to get the attention of the sleepy forum lurkers) I like where you're heading with defining objects for the various wheel-related modules instead of sticking everything into the module class.  This should end up with much cleaner code overall.  This is something mod authors for KSP could really use more of.  I used to download sources for just about everything I downloaded to use in KSP to take a look at the magic behind the DLL.  I can't even express the messy and down-right ugly code I would find in those projects.  If you manage to revolutionize the world with your product, but the sources are ugly as -insert expletive here- then you've done a disservice to the world in the long run.

Edited by Gaalidas
I had more to say... deal with it.
Link to comment
Share on other sites

Great things happening here :)

I've had a crazy weekend playing steam engines, getting drunk and misbehaving, so not had time to even look over the code. I'll have a few free evenings this week to get stuck in. Good to see you're still around, Gaalidas!

Link to comment
Share on other sites

I'm at about the "hello world" stage with C#, and have some mods of my own to fix up for 1.1.X, but I've stumbled on a NEED for tracks.  OK, a want for tracks.  There's really stuff all I can do to help, except to say it's appreciated.

Link to comment
Share on other sites

Thank you. It helps, in so much as reminding those of us who are scratching heads over physics models and code ourselves that we're not working in isolation, and there are people eager to see what we produce. A little like writing in to a late night radio presenter just to say "Loved that last track, keep up the good work". Go get stuck in with C# - it's really not that hard to pick up. Took me about 3 months to be able to do something useful, I guess. Steep learning curve, but it's worth sticking at it.

I've just set up GitHub desktop and opened the project to look over the code, @Shadowmage. It's embarrassingly well organised! I'm afraid my efforts are rather amateur by comparison - I'll try and learn from your example as I go along...

I have two ways to attack the friction problem, which are a little different to yours. Firstly, create joints between the ground and the rigidbody of the part and use parameters in that to simulate friction. It may not work at all, but I've got a lot of experience bashing Unity joints about, so it won't take long to try. Secondly, building on top of what you're done, I think as I mentioned before, we can probably use rigidbody.setposition() after some calculation. This may also be useful for setting the suspension hard compression limit.

I'd best get to it, I guess....

Edited by lo-fi
Link to comment
Share on other sites

Good thing you are just getting around to it, as I -just barely- got the Unity project to come through Git unscathed this morning (or at least it appeared to be working).  Code I'm decent at... git... not so much (or maybe its just Unity that doesn't get along with me very well).

Yah, going to be a bit of fun and learning getting the friction stuff figured out.  What is there currently is... a bit of a buggy guess at how to handle it.  The normal tire-friction models don't seem to work well in Unity (or games in general?) as they don't take into account the current velocity in the slip direction and end up applying a massive force even when the slip velocity is near zero; as such all of my attempts at handling friction have been velocity * downForce derived.

I like the idea of joints for simulation of friction.  Is there a way to set them with a spring value of 0 and a damp value to simulate the friction?  I guess the spring might be needed to try and help it keep position properly.... hmmm...  interested to see what you come up with for those :)

At least the spring/damper/target code appears to function about like it should.  Might still be some errors in it, and certainly some cleanup that could be done regarding simulating an actual tire (rather than just a ray), but seems to be working pretty well at the moment in all regards except punch-through (which might need to be solved at the model level with some actual colliders).

Link to comment
Share on other sites

 

21 minutes ago, Shadowmage said:

Yah, going to be a bit of fun and learning getting the friction stuff figured out.  What is there currently is... a bit of a buggy guess at how to handle it.  The normal tire-friction models don't seem to work well in Unity (or games in general?) as they don't take into account the current velocity in the slip direction and end up applying a massive force even when the slip velocity is near zero; as such all of my attempts at handling friction have been velocity * downForce derived.

You can get the current velocity by subtracting the last hit point from the current one, compare to the wheel direction and factor that in, I guess?

21 minutes ago, Shadowmage said:

I like the idea of joints for simulation of friction.  Is there a way to set them with a spring value of 0 and a damp value to simulate the friction?  I guess the spring might be needed to try and help it keep position properly.... hmmm...  interested to see what you come up with for those :)

I think you can do that, yes. You can also use projection to force things back into position if they get moved out of limits, which is handy.

21 minutes ago, Shadowmage said:

At least the spring/damper/target code appears to function about like it should.  Might still be some errors in it, and certainly some cleanup that could be done regarding simulating an actual tire (rather than just a ray), but seems to be working pretty well at the moment in all regards except punch-through (which might need to be solved at the model level with some actual colliders).

Actual colliders won't work, but Unity lets us use wonderful things call sphere casts :)  If they don't cause too much of a performance hit, they will allow us to make a far, far superiour wheel model. Wheels will actually roll over sharp bits of terrain, rather than simply jolt upwards when the ray gets to the point of change. The hit info will be improved as we can get a tangent plane against the terrain, as opposed to a simple position. Something I've been thinking about for some time. If anyone listening in has the skills, an analysis of spherecast vs raycast performance would be most enlightening!

 

EDIT: I'm so, so rusty on this stuff. Struggling to even remember the correct bits of vector math :( 

Edited by lo-fi
Link to comment
Share on other sites

Well, my joint based model is out for friction. It can be made to work very effectively as the suspension spring, though. The advantage, I suppose, would be that punch through is simply not possible, all the wheels calculate their load bearing properly within the physics engine, and we have joint info available. In fact, they make very good repulsors...

Link to comment
Share on other sites

39 minutes ago, lo-fi said:

Well, my joint based model is out for friction. It can be made to work very effectively as the suspension spring, though. The advantage, I suppose, would be that punch through is simply not possible, all the wheels calculate their load bearing properly within the physics engine, and we have joint info available. In fact, they make very good repulsors...

:(

Would still be interested in a joint-based suspension setup; sounds like it might be a bit more robust than the simple raycast/depth based setup.  Feel free to push to the repo in a new branch if you come up with something cool :)

Link to comment
Share on other sites

At the moment, rather than bashing your nice code around, I'm messing about with something very, very simple of my own. They've done something weird with the configurable joints in U5, so I've got that to fight with before anything productive arrives. I mean, who has most of the component in local space, only to define the anchor point in world space? It just doesn't make any sense at all.

I have kind of figured out another potential way to implement friction using the joint drives, so all is not lost yet.... Time spent messing with Unity joints out of idle curiousity was well spent! 

Link to comment
Share on other sites

1 hour ago, lo-fi said:

Further reading on why we need to get this nailed:

http://forum.unity3d.com/threads/wheel-friction-curve-revealed.153340/

Understand the graph, and you'll suddenly understand why rovers flip over so readily in KSP... 

Wow, that explains a lot.  Also, the horrid chain of "someone else's code" explained.  Damn yooo nvidea!

Link to comment
Share on other sites

On 5/3/2016 at 9:05 AM, lo-fi said:

Further reading on why we need to get this nailed:

http://forum.unity3d.com/threads/wheel-friction-curve-revealed.153340/

Understand the graph, and you'll suddenly understand why rovers flip over so readily in KSP... 

Also, it contrasts nicely with how Unity believes it works, http://docs.unity3d.com/Manual/class-WheelCollider.html

 

Link to comment
Share on other sites

On Tuesday, May 03, 2016 at 5:05 PM, lo-fi said:

Further reading on why we need to get this nailed:

http://forum.unity3d.com/threads/wheel-friction-curve-revealed.153340/

Understand the graph, and you'll suddenly understand why rovers flip over so readily in KSP... 

Indeed, those graphs explain a lot of what was seen from the old wheels.  I love the incoherent mess that it makes < 0.5m/s.  Pretty sure they are supposed to look something closer to one side of : ctsrcurve.gif

Anyhow, getting things nearly wrapped up on my mod, so should have more time to dedicate to getting these wheels working this weekend / next week.  Still have a few ideas on how to solve a few of the issues I was facing regarding friction, and will be taking a bit of time to experiment with spherecasts for the suspension checks.

But yeah.... the wheel problem needs to be solved; the old U4 colliders had their issues (e.g. friction/tipping), but the U5 ones just don't work at all for these situations (and even if the did they have some silly limitations regarding orientation).

If needs-be, I'll dig into other physics libraries and figure out how its done on a low-level basis (bullet, havok, phsyx if I can find source).  Might at least give me some ideas on how to solve the outstanding issues with the current custom implementation.

 

Edit: Have subbed into the Physx codebase; so will be exploring how they have the current wheel collider implemented in their native code and see what I can do to bring some of the (good) parts of that into c#/script land.

Edited by Shadowmage
Link to comment
Share on other sites

Oh my G0d Lo-Fi, Squad's wheels are so g0dd@m messed up, you need to set up the Red Bull I.V., down a bottle of no-doze, and GET US SOME DECENT WHEELS STAT, A.S.A.P., PLEASE FOR KRAKEN'S SAKE!!!

Sigh, calming down...

Okay, the preceding... rant, flip-out, nervous breakdown, whatever... was an only partially humorous plea, because the stock wheels are so freaking USELESS!  They're WORSE than useless, I don't even know why Squad bothers to put them in the game, I cannot find or create any combination of parts that actually functions as a "rover" that uses the stock wheels!  They either don't work at all, meaning the thing just sits there on the runway, immobile, with the wheels doing NOTHING, or if I can actually get the thing to move it does so at one of two speeds:  Glacial, acceleration (and I use that word VERY loosely here) can only be measured accurately with a CALENDAR, or 'So Much Torque and Wheel Slip' that it would be better to replace the word 'Rover' in a description of the vehicle with the phrase 'Drift-O-Matic Crash-O-Tron'.  And turning?  Fuggeddaboudit!  Again, either wheel-slippage-city, or the good-ol' Squad control method of 'try to turn when moving faster than about 3 m/s and automatically catapult your rover into the air because the wheels dig into the ground sideways, immediately followed by landing upside down creating very much lots of explosions'.

Yes, I know that they've added all kinds of tweakables to the wheels so that we can supposedly 'tune' them to work better, but to me all that illustrates is that they KNOW the wheels are F'd up, but here, let's just put a Band-Aid on that severed artery, maybe nobody will notice.  They shouldn't NEED to have their 'traction' and/or 'friction' adjusted, they should just WORK!

Bah... I just got up to do some stuff for about 10 minutes, and I'm calm now.  Just had to get that off my chest.  Anyway, since wheels obviously confound Squad all to heck, I just figured I'd get on here to encourage Lo-Fi & Co. here at Kerbal Foundries to redouble their efforts so that I (we, the players) can create a vehicle that actually moves on the ground, as opposed to having to create VTOLs and whatnot for exploring the surface of a planet or moon.

So, anyway, for what that's worth.  :)  Keep on keepin' on, folks.

:D 

 

Link to comment
Share on other sites

On Tuesday, May 03, 2016 at 3:06 PM, lo-fi said:

Well, my joint based model is out for friction. It can be made to work very effectively as the suspension spring, though. The advantage, I suppose, would be that punch through is simply not possible, all the wheels calculate their load bearing properly within the physics engine, and we have joint info available. In fact, they make very good repulsors...

Well, looking through the PhysX code explains quite a bit of what we are seeing regarding the behaviour of the U5 wheel colliders.  A large portion of the code is 'optimized' for simple 4-wheeled vehicles; entire classes and code-paths dedicated to the over-simplified 4-wheeled-vehicle setup.  It looks as if arbitrary use of wheel colliders was implemented more as an afterthought, and in many spots is unfinished (littered with TODO notes...).

However I've found how they handle static friction (sticky friction they call it) and will possibly be able to bash together something in the near future.  Their implementation relies on timers, examining movement speed in a direction vs a threshold, and basically force-repositioning the rigidbody along a local axis if it should have had static friction applied.

Punch through also seems to be handled in a similar seemingly-hacky manner; they basically examine the movement of the vehicle/wheel during the last update, do a raycast along that vector, and if anything -should- have stopped the vehicle they reposition it manually.

Now... I could be a bit off on a few of these points, my C++ skills are quite rusty... but what I'm seeing in the code explains a ton of what we see in-game/in-editor.  Hopefully I'll be able to put together a decent c# implementation of some of the valid concepts, and find ways to clean up some of the others.

Link to comment
Share on other sites

Couple resources for general research into physx vehicle/wheel physics models:

http://docs.nvidia.com/gameworks/content/gameworkslibrary/physx/guide/Manual/RigidBodyDynamics.html

http://docs.nvidia.com/gameworks/content/gameworkslibrary/physx/guide/Manual/Vehicles.html

http://www.eggert.highpeakpress.com/ME485/Docs/CarSimEd.pdf

The linked .pdf is actually the source/reference that the physx vehicle model is implemented after, so likely the best place to start from a low-level perspective.  Is some pretty heavy reading though (at least for me)... so... going to be some learning involved before I can implement much of it.

Link to comment
Share on other sites

18 hours ago, Neutrinovore said:

Oh my G0d Lo-Fi, Squad's wheels are so g0dd@m messed up

Glad it's not just me that had a "WTF????" moment... 

16 hours ago, Kerenatus said:

 

Yes! The wheels ARE coming back!

 

Yes, yes they are!

15 hours ago, Shadowmage said:

The linked .pdf is actually the source/reference that the physx vehicle model is implemented after, so likely the best place to start from a low-level perspective.  Is some pretty heavy reading though (at least for me)... so... going to be some learning involved before I can implement much of it.

You absolute legend - this is far beyond the lengths I'd have gone to. So my idea about "sticky friction" (lets call it that from now on, shall we?) being implemented by forcing the object to a certain position wasn't far off, and I bet that explains the jittering under 0.5m/s. Recreating this should not be hard :) I'll have a read through over the weekend and see if I can bring any other insights. Interesting that they're geared to simple, 4 wheel vehicles, and probably explains why the tracks go so beserk! Either way, I feel that writing out own colliders - no matter how hard it may be - is absolutely the right way forward, and can probably benefit other Unity games as Gaalidas pointed out. Your generic Unity model + KSP specific wrapper seems all the more pragmatic!

One thing I've been puzzling over, and haven't come up with a good answer for, is how to calculate how much weight each collider is bearing. You can check the mass of attached rigidbodies, count colliders and divide, but this is expensive, and won't take into account other collisions such as a body scraping on the floor. Any thoughts? Maybe some kind of two pass approach, but I still can't get my head around it. Maybe the Nvidia docs will yield some answers....

Again, on behalf of all involved, thanks for the encouragement, and thanks for sticking with us as we tackle this thing!

Link to comment
Share on other sites

3 hours ago, lo-fi said:

 

One thing I've been puzzling over, and haven't come up with a good answer for, is how to calculate how much weight each collider is bearing. You can check the mass of attached rigidbodies, count colliders and divide, but this is expensive, and won't take into account other collisions such as a body scraping on the floor. Any thoughts? Maybe some kind of two pass approach, but I still can't get my head around it. Maybe the Nvidia docs will yield some answers....

Again, on behalf of all involved, thanks for the encouragement, and thanks for sticking with us as we tackle this thing!

Calculating the sprung mass is... difficult... with arbitrary vehicle setups.  My current method is to use the upwards force that the suspension generates; as this exact force is how much that particular wheel is exerting at any moment against the ground; they are one and the same.  Now... converting that force back into a mass becomes much more difficult (or is it?  N -> KG = N * 0.1?).  However I have not thought of a reliable method to get the supported mass by a wheel while it is not being suspended; and even then there are... problems with that implementation such as when the suspension is first stopping downward motion the force will be > than the actual mass would imply, only when the spring has reached 'steady state' would the forces==mass supported.

The actual solution is a bunch of trig to figure out the position of the wheel vs the COM; but this method would not work reliably for KSP vehicles... you know.. the type who like to have wheels on the roof/etc.  So you would have to first know how many wheels were in contact with the ground (not hard, just do the suspension raycast before querying mass; this is actually how physx does it; all wheels do their raycast in a single pass, and all other calculations come afterwards).  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.

I think the suspension-force based method is the only reliable metric of how much force a given wheel is exerting; but it seems to fall short for several necessary calculations -- such as determining how much friction force is needed to bring something to a complete stop; for that you need to know the precise mass that each wheel collider is responsible to ensure there are no over-corrections.  Physx itself has low-level access to the per-update accumulated forces and resultant delta-velocity and delta-angular rotation values directly (as does Unity), but I'm not sure we'll have access to those.

Anyhow.. you can register to get access to the physx source from:  https://developer.nvidia.com/physx-source-github  Pretty short signup, takes them about an hour to approve the account, but a mostly painful process in the end.  Is some interesting reading going through the source (note it is all C++ code, so some background with C/C++ helps when reading it and understanding the various variable/pointer/reference types).

 

Link to comment
Share on other sites

6 minutes ago, Joshwoo69 said:

curious.. what if some people use those not with nvidia's? would't they be left out?

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).

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...