[1.8.x] KSPWheel - Physics Based Alternate Wheel Collider [API Only]

[SpannerMonkey(smce)]

On 12/12/2016 at 7:01 PM, Shadowmage said:

I may get back to them personally at some time in the future

Just got to say thanks for the work you've done so far and what you've managed to achieve given the starting point,  i can fully appreciate not wanting to give up your life for it, and best of luck with your less brain melting endeavors

If anyone does pick this up and want to do something with it perhaps using KF parts, I've made a few and still have raw assets of some of the KF models if they're needed

[Shadowmage]

44 minutes ago, damerell said:

You mentioned that you intended to relicence this under a Free licence. Is that still on the agenda, please?

Yes.  I was waiting a bit to see if anyone else wanted to contribute to development of the PartModules and/or to see if I could wrap things up in my other mods to a point where I could focus on cleaning/finishing up the PartModules myself.  None of that is really related to the license per-se, other than that I was hoping to have things mostly finished and usable before opening it up to forks/etc.

But as I don't see myself being able to get back to the modules much before early January, I might as well update the license sooner rather than later.  Will likely update the source to GPL this weekend, along with a recompile+release for KSP 1.2.2.  At least that way it can be packaged/redist by other mods if needed.

If you do want to contribute to wheel-collider or part-module development any help would be very appreciated.  I'm much more open to feature-set and implementation when I don't have to do all the work;  as long as the submitted code works and it achieves the desired effect I will likely accept nearly anything.  Would also like to keep the forks and distributions to a minimum if possible, so will give thorough consideration to all submissions; as long as a feature is useful and doesn't get in the way of other existing features there is no reason to not accept it.  PRs work of course, or if you wanted to get a bit more involved I could even give dev access to the existing repository  (feel free to send a PM if you would like to discuss things further).

 

1 minute ago, SpannerMonkey(smce) said:

Just got to say thanks for the work you've done so far and what you've managed to achieve given the starting point,  i can fully appreciate not wanting to give up your life for it, and best of luck with your less brain melting endeavors

If anyone does pick this up and want to do something with it perhaps using KF parts, I've made a few and still have raw assets of some of the KF models if they're needed

Thanks for the support, been a bit of a bumpy road   

I haven't yet given up or moved on, but certainly will need a bit of time before I can focus on the wheels.  I really wasn't anticipating Lo-fi stepping down, and so wasn't expecting to have much work to do on this project after I got the wheel-collider working.  Got in a bit over my head when the news dropped as I wasn't prepared to pick up lead development on another mod, I had just stepped into a big cleanup and polish pass on SSTU which was taking up most of my time and attention.

I don't intend to let KerbalFoundries die off either though;  I already have Lo-fi's permission to continue the mod under the KerbalFoundries branding, and would really like to get that mod back on its feet before too much longer.  I don't (currently) have any of the raw model assets though, so may take you up on that offer.  I mostly have things working with the existing models, but some could use updates for feature changes in the base KSP code (e.g. no longer need a 'bounds' collider).

The good news is that the current code is fairly stable (code wise, not necessarily physics wise) and usable on a wide variety of models and should be a good starting point for future development.  Could potentially only take a few (long) days of work to get the modules and configs into a much more user friendly and polished state. I'm hoping to be able to get back to the modules and configs after the holidays (if nobody else picks it up before then); work on my other mods should be wrapped up by then, and I don't have any other immediate development plans so should be able to spend (up to) a couple months working on wheel related stuff (collider/physics, modules/features/ui, KF-features e.g. dust/repulsors, possibly even some new models).  Will also look into opening up a proper KerbalFoundries-continued thread once I have the configs and features for those parts working as they should.

 

 

 

[damerell]

Thank you. I won't make any promises, since I'm lazy and have chronic health problems, but I'd like to take a look at it if I can.

[Shadowmage]

Updated release is available:

https://github.com/shadowmage45/KSPWheel/releases/tag/0.9.0.6

Updates the license on the source to GPL, removes stock part duplicating configs, and reworks KF configs to not duplicate the parts but to patch existing parts in-place.

[SmashBrown]

Awesome, is there a new thread for KF or are you not planning to pick that up again? Sorry if I have missed something here.

[Shadowmage]

36 minutes ago, SmashBrown said:

Awesome, is there a new thread for KF or are you not planning to pick that up again? Sorry if I have missed something here.

 

On Thursday, December 15, 2016 at 6:32 PM, Shadowmage said:

 

 Will also look into opening up a proper KerbalFoundries-continued thread once I have the configs and features for those parts working as they should.

TL:DR -- yes, but not until sometime after the holidays.

[SmashBrown]

6 minutes ago, Shadowmage said:

 

TL:DR -- yes, but not until sometime after the holidays.

You brilliant man you. I have sent some bacon in the post.

[SmashBrown]

They work!!! I have my beautiful tracks back!!! YAY!!!! My mod pack is now complete and I can begin a career.

[akron]

So much win in this thread. Thank you @Shadowmage for your work on this. I am also looking forward to a potentially working rocker-bogie system, although I'd be willing to try and simplify it into a two-part assembly if needed.

 

If anyone is working on wheels for their mod using this, would you be willing to post a screenshot on how you are doing the rigging, for a dummy like myself? I was going to wait and work on wheels later, but maybe I can get started a little sooner. Perhaps if I can figure it out I can help test, or at least provide some models for others to test.

[Stone Blue]

@Shadowmage Sorry if this has already been discussed, ( I freely admit I havent taken the time to read too far back in the thread ), but does KSPWheels affect/turn off autostrutting of wheels, at all?.. If not, could it DO so?

Reason I bring it up, is I guess Infernal Robotocs seems to be having issues with autostrutting of wheels...

I guess if you're inclined to investigate, this post, and maybe a few previous, would be ones to read:
 

 

[Shadowmage]

2 minutes ago, Stone Blue said:

@Shadowmage Sorry if this has already been discussed, ( I freely admit I havent taken the time to read too far back in the thread ), but does KSPWheels affect/turn off autostrutting of wheels, at all?.. If not, could it DO so?

Reason I bring it up, is I guess Infernal Robotocs seems to be having issues with autostrutting of wheels...

I guess if you're inclined to investigate, this post, and maybe a few previous, would be ones to read:
 

KSPWheel does not touch AutoStruts -- I have found them to not be needed under most circumstances, and best left for players to enable when they are needed.   (No it does not be change the stock wheels autostrutting -- I am not a SQUAD dev, and cannot change stock code or behaviour;  this will need to wait for the stock-conversion patch to be finished, at which point the stock parts will use KSPWheel and not need autostruts).

 

[Shadowmage]

On Monday, December 19, 2016 at 11:02 AM, akron said:

So much win in this thread. Thank you @Shadowmage for your work on this. I am also looking forward to a potentially working rocker-bogie system, although I'd be willing to try and simplify it into a two-part assembly if needed.

 

If anyone is working on wheels for their mod using this, would you be willing to post a screenshot on how you are doing the rigging, for a dummy like myself? I was going to wait and work on wheels later, but maybe I can get started a little sooner. Perhaps if I can figure it out I can help test, or at least provide some models for others to test.

Thanks for the support

 

As far as model rigging goes -- any of the old wheel tutorials geared for Unity 4 wheel colliders will work (so KSP 1.0 or earlier).  However the modules are capable of using old U4 rigging or new U5 rigging, merely some config fields that need to be setup appropriately, so really any of the wheel rigging tuts will work (but the older ones are easier to understand and easier to setup)

Basically the hierarchy should go:

Root 
|-WheelCollider (y+ = up, z+=forward) -- positioned at the top of its travel  (can be offset in config for alternate riggings / positioning)
|-Suspension Transform (y+ = up, z+=forward) -- positioned at the top of its travel  (can be offset in config for alternate riggings / positioning)
  |--Steering Transform (y+ = up, z+=forward) -- positioned in the 'neutral' steering angle
    |--Wheel Mesh (x+ = rotation axis) -- y/z orientation doesn't matter, it just spins around x axis

The important parts are that the wheel collider is -not- parented under the suspension or steering transforms.  It can be animated, but should not be a child of the suspension/steering.  The order/parenting of the steering and suspension can be swapped if needed.

Old-style 'bounds' colliders are not needed, but can be used and are supported (either use a 'bounds' collider, or setup the groundOffset in the config properly).

If needed I could provide a .blend file that has a couple pre-rigged landing gear models in it that should clear up any last points of confusion.

[TOMMY (JEB 2.0)]

How do i get kf weels to work with kspweel?

[SpannerMonkey(smce)]

32 minutes ago, TOMMY (JEB 2.0) said:

How do i get kf weels to work with kspweel?

You need a copy of the MM patches for KF wheels, that originally came with the KSP Wheels download

[Shadowmage]

2 hours ago, TOMMY (JEB 2.0) said:

How do i get kf weels to work with kspweel?

1.) Keep in mind that the patches are intended for testing of the wheel physics and are not intended for general use, and certainly not intended to be used in actual gameplay (e.g. if you want to 'play' with it, don't bother installing things now, check back later when it is ready for general use).  They may break your save, existing vessels, or craft files.  The parts WILL be changing in future releases, and it WILL be save-breaking when it does.   If you are not okay with any of that, stop now.

2.) Download and install the KSPWheel distribution linked above ( https://github.com/shadowmage45/KSPWheel/releases/tag/0.9.0.6 ).

3.) Install the last KerbalFoundries 1.0.5 release (1.9.x.g I think).  Delete the plugin from KerbalFoundries, none of it is used or needed (all replaced through the patches).

4.) Report any problems you find to the bug-tracker ( https://github.com/shadowmage45/KSPWheel/issues ).

[ZodiusInfuser]

I've only just found out about this mod. Great work! I'm wondering if this could be used to get my old Mecanum wheels working again (video below). Previously they used Kerbal Foundries, so as you can guess have been out of action for quite some time. They consist of 8 wheel colliders without suspension, with infernal robotics rotating the wheel hub.

Also, since wheels using this plugin do not use autostruts, I wonder if it would be suitable for my other infernal robotics wheels (http://m.imgur.com/4hlVCOy)? Due to IRL commitments, I have yet to get around to updating these to 1.2s wheel physics, so would updating them to this plugin be the better option?

[0111narwhalz]

You know, when you said "for testing of the wheel physics," I don't think you expected people to test this.
Meet the Magnus.

Though it is yet a WIP, the Magnus is my most successful complex suspension mechanism yet. Four repulsors per wheelgroup act as combined springs and shocks. See the annotated image below.

As you might note from the image, the system is protected from the "backflop" of many complex suspension systems by a negative travel limiter. This repulsor is set to a very large (read: maxed) load capacity, which is more than enough to prevent that particular failure mode. It does come at the cost of the crew's personal safety (it's launched Bill and murdered Jeb), but that is a small price to pay for vehicular durability.
The repulsor below the pivot, furthest from the centerline, acts as the primary spring. The entire weight of the vehicle is on these for most of normal operation. It also acts as compression damping.
Just fore of the primary repulsor is the overload spring. It cuts in at the extreme of travel to prevent the Magnus from scraping against the ground. As such, its force is set very high, though not as much as the negative travel limiter.
Above the pivot is the rebound damper. It corresponds to the compression damper directly below it, preventing the wheelgroup from extending with excessive speed.

Due to the unique way in which the Magnus' suspension works, the possibility of sway bars has arisin. These couple the left and right wheelgroups, discouraging excessive body roll. They are powered by conventional weakjoints. Though they are not yet adjustable, plans are in motion to rectify this.

The wheelgroups are connected to the chassis through a parallelogram. Previous applications with a simple single beam were deemed unsatisfactory.

I am using stock colliders for the individual wheels, mainly because I misplaced the patches. Every now and again, the wheelgroups experience violent oscillations and pop the tires. I'm fairly certain this is due to improperly tuned dampers, and not a fundamental flaw of the system. I'm not sure how to go about this, though I think the system is, in effect, a PD controller. I wonder if we could do something about the lack of an integral term...

[Shadowmage]

4 hours ago, ZodiusInfuser said:

I've only just found out about this mod. Great work! I'm wondering if this could be used to get my old Mecanum wheels working again (video below). Previously they used Kerbal Foundries, so as you can guess have been out of action for quite some time. They consist of 8 wheel colliders without suspension, with infernal robotics rotating the wheel hub.

Also, since wheels using this plugin do not use autostruts, I wonder if it would be suitable for my other infernal robotics wheels (http://m.imgur.com/4hlVCOy)? Due to IRL commitments, I have yet to get around to updating these to 1.2s wheel physics, so would updating them to this plugin be the better option?

Should be doable, but probably not with your previous rigging methods.

Notably they won't work with '8 colliders without suspension' -- this wheel system relies on the suspension in order to derive the friction forces.  No suspension = no friction = no wheel simulation.  You can have a wheel without a visible suspension mesh (e.g. repulsor), but the spring-damper-based suspension physics is what drives the rest of the wheel simulation by providing a 'down force' to use in friction calculations.  You can have multiple colliders (e.g. tracks), but each one must have suspension.

However, after doing some research into mecanum wheels, it looks like you could use a standard single wheel collider, with suspension, set at a 45' angle offset from the visible wheel mesh.  You would need one model angled for 'left' and one angled for 'right'.  This would mean they would mostly only work 'right-way-down', as the wheel system is still raycast/spherecast based.

Alternatively you could use the existing 8 wheel colliders (so they will work in any orientation) but give them a rather small suspension range (~0.1m), and offsetting the collider into the wheel hub slightly to compensate for the suspension.  However such small suspension ranges when used with large suspension forces can cause simulation integration problems, and is very much on the 'not recommended' list; they would work but could be jittery/bouncy in some configurations.

[Shadowmage]

9 hours ago, 0111narwhalz said:

You know, when you said "for testing of the wheel physics," I don't think you expected people to test this.
Meet the Magnus.

Though it is yet a WIP, the Magnus is my most successful complex suspension mechanism yet. Four repulsors per wheelgroup act as combined springs and shocks. See the annotated image below.

[...SNIP...]

 

 

Quite an interesting use you found for those repulsors now that they allow vessel->same-vessel force application.
If that thing isn't jittering itself to pieces immediately upon launch, I'de say the physics/integration are decently stable.  If it actually -works- as you are intending it to, then I'de go so far as to say the overall physics system is actually working quite well

 

As to the physics/integration -- I had been investigating alternate integration methods (imp. euler, rk4), and had been stuck on the point that I can't sub-integrate the suspension forces (as I have no access to the rigidbody internals).  I then realized that I can integrated the suspension forces separately from the friction forces;  suspension will use standard Unity integration, single pass basic euler; friction forces though can be put through an RK4 derivative calculation framework for -much- improved accuracy at the cost of some minor calculation overhead (some extra mults/divs/add/subtracts, but no added allocations or raycasts).  Now, since I cannot use RK4/etc on the suspension forces this setup won't be able to fix the jittering caused by suspension, but it should clean up any jittering caused by friction as well as allowing for a much more robust integration of the torque application code (reduced wheel slip on first applying torque or brakes, better response during dynamic handling scenarios, reduce or eliminate overshoot that could cause jittering).  RK4 integration is new to me though, so likely will take a couple weeks to learn the ins and outs and get it implemented properly.  The existing friction integration code will need to be reworked to allow for derivative use; shouldn't be too difficult, but will require cleaning up some assumptions that currently exist in the code (such as delta-time always == Time.fixedDeltaTime).

On the PartModules end of things -- after I get the integration stuff reworked and figured out I should be able to spend a few weeks / month to get them cleaned up.  I have a concept for a 'stock-alike' suspension auto-tuning algorithm that should remove a large majority of the manual setup for wheels (if the auto-setup system is enabled; it will be configurable through the settings menu).  This system will constantly auto-adapt the suspension on a craft to keep the ride height within the config-specified 'valid' range; the trick is going to be getting it to work without interfering with standard dynamic suspension response too much (e.g. how to detect difference between constant over-loaded-compression and a constant hard banking turn, from the perspective of a single wheel?.... without knowledge of the entire craft I don't think it can be done....and wheels cannot be aware of other wheels or the vehicle design, they must be self-contained and vehicle-agnostic).  Shouldn't be a problem on wheels with sufficient travel (as turning would not cause body roll sufficient to leave the 'valid' range), but many of the stock/mod wheels I've seen have very tiny travel ranges where even the slightest turn causes wheels to either over-compress (outside) or nearly leave the ground (inside).

From there that still leaves a few things that need to be figured out -- tuning the friction curves, implementing better steering and motor handling functionality, a proper tracks handling module, and finding solutions to a few collider-related oddities.  Should all be solvable, but may take awhile to get it all sorted out.

Sometime -after- all of that is figured out and working I'll look into opening up a new KF thread and getting everything cleaned up for that mod.  Need the colliders and part-modules to be functional (and easily usable) first though.

Edit:  After a bit more thought on RK4 integration, I realized that it really isn't workable for any of the wheel physics -- every part of the wheel physics relies on variables controlled Unity code that I cannot access -- e.g. in order to use RK4 integration on wheel friction I need to be able to determine the final state of the rigidbody for each derivative, and use that state as the input for some of the other derivatives (as friction relies on things like the local wheel velocity, which are controlled entirely by the rigidbody it is mounted on, which I have no control over).

I might be able to fake it a bit by 'guessing' at what the rigidbody state would be at for mid-point derivatives, but this will be inaccurate on anything but perfectly evenly loaded suspension, and even then it might have problems due to not knowing how Unity actually integrates their physics code (difference in calculations could cause inaccuracies).  Still going to investigate a bit, see how bad 'guessing' at rigidbody state is, and at least try and clean up the friction code (still can't do much on the suspension integration).

Edited December 29, 2016 by Shadowmage

[0111narwhalz]

Would changing the max delta-time in any way affect the simulation quality?

Also, where did those stock MM patches go? Neither of the releases on Github have them, and my archives lack them.

Regarding the Magnus: It actually drives fairly well, considering the potential for krakenbait it illustrates. I don't think I'll be able to finish it in time for the event for which I designed it, but it could happen. Recently, the wheels seem to have gone wonkers, strutting everywhere despite the fact that they're not installed in symmetry and attached by IR rotatrons (which should sever autostruts). So, I swapped the stock wheels for KF ones. The minimal tuning I managed to do got it through stage one of the Kerbal Dakar rally, but it's not really all that fun to drive. It pulls to one side or another and is super draggy. We'll see if I can change that later.

[SpannerMonkey(smce)]

15 minutes ago, 0111narwhalz said:

Also, where did those stock MM patches go?

https://www.dropbox.com/s/gma1b1sgjw3h7z5/KerbalFoundriesPATCH kit.zip?dl=0

[0111narwhalz]

6 minutes ago, SpannerMonkey(smce) said:

[link]

Thanks mate, but I was looking for the ones for the stock wheels.

Edited December 30, 2016 by 0111narwhalz

[Shadowmage]

9 hours ago, 0111narwhalz said:

Would changing the max delta-time in any way affect the simulation quality?

Also, where did those stock MM patches go? Neither of the releases on Github have them, and my archives lack them.

Delta time -- yes, if you can actually get into the KSP back-end and change the time-step, it can greatly increase simulation stability, at the cost of general performance (not physics time in the configs/settings, I do not think that actually adjusts delta time, you need the actual FixedUpdate delta-time manipulation stuff).

Stock patches -- I removed them from the distribution because people were insistent on complaining about UI stuff on the part-modules rather than using them to test the wheel actual physics.  I wouldn't even have the KF configs in there, except there is no other way to get KF parts working, and I need at least -some- wheels to be available for testing of the physics.  ( https://github.com/shadowmage45/KSPWheel/tree/master/GameDataDisabled/Stock )

[0111narwhalz]

On 12/30/2016 at 7:45 AM, Shadowmage said:

Stock patches -- I removed them from the distribution because people were insistent on complaining about UI stuff on the part-modules rather than using them to test the wheel actual physics.

They were complaining about what? That's absurd.

My friend, you've done well if that's the worst they can come up with.

[Shadowmage]

Holiday break is over, and I'm about ready to begin working through fixing up the KSPWheels PartModules / UI stuff.

Have not made much progress on the alternate integration code, mostly because of the limitations that are in place regarding lack of access to Unity physics integration stuff.  Can't do proper advanced integration if I do not have access to the data needed for it.  Will continue giving it some thought and possibly revisit in the future.  Really don't think there is going to be a proper way to do it, at best the implementation would use some 'guessing' as to the interpolated rigidbody state for any midpoint derivatives.

Will be adding a game-options/game-settings toggle to enable/disable 'advanced mode' for the wheels.  This will (mostly) just toggle the suspension auto-tuning on/off.  Advanced mode = wheels have a one time suspension parameter setup (in the editor), and will likely not be adjustable in flight.  Basic mode = only damper ratio and very limited spring multiplier controls available (both editor and flight); actual spring setting auto-adjusted to keep wheels within stable simulation range (0.2 > x < 0.8 compression percent).  Have this mostly implemented so far, needs testing and likely some cleanup.  (Basic mode will function very similar to how stock wheels currently work; Advanced mode will function very similar to how the wheels currently work, allowing to specify a 'load rating', 'damp ratio', and 'ride height')

Second I'll be adding a singular 'Show Wheel Controls' toggle to the main wheel module that will enable/disable all other wheel GUI controls (similar to how stock RCS control toggles work).  This is simply a GUI cleanup step, but badly needed with all of the various wheel controls available.

Next up will be adding in a good 'default' steering curve for standard wheels (not tracks).  For wheels with motors this curve will use the max-motor speed as its 'max', for un-driven motors it will use an rpm value derived from the wheel radius (assuming that larger wheels = higher max speed).  Will still be able to manually specify steering curves on a per-part basis, but this should hopefully give a good default for most parts so that they will not need any manual config work done on them.  Steering inverts will still be setup manually by the user, and configurable in-flight.

Motor handling will be next up on the list.  Figuring out the best way to specify motor input power (torque, kw, ??), how to best handle motor torque output and power input curves, potential for regenerative braking, and some sort of working traction control.

Tracks handling will come next.  This will entail better handling of motor input to tracks, better wheel averaging/consistency code, special handling for setup of tracks suspension parameters, and some special handling for 'tank steering' setups (including capability to specify half-track type steering).

-Might- have an updated release sometime near this weekend with the initial suspension-tuning code updates.  May or may not have some of the other goals working / WIP at the time.  We'll see how it goes.

 

After these features/updates are completed I'll work on opening up a new KF release thread if everything appears to be working properly and reasonably stable.  Once I have a 'new' KF release up and going I'll look into reworking/reintroducing some of the features from the old KF plugin -- notably the dustFX bits of code.  I would expect this is at least a few weeks out, possibly even a month or so, but the goal is to have KF stable and usable with the first actual release (initial testing will still be done here though this thread for the time being).