Shadowmage

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

Recommended Posts

Have been spending a bit of time on figuring out frictionless colliders and have made a little bit of (very confusing) progress.  But despite the confusion I think I may have found a way to allow for zero-suspension wheel setups.

It is a tiny bit hacky, so I am going to need to do a -ton- more investigation to make sure it doesn't interfere with other.  Basically it requires adjusting the physics material of the terrain and any other static/prefab objects a bit (for some reason both the sliding collider -and- the terrain have to be setup properly; unity docs lead me to believe only the settings on a specific object effect its own collision response, but testing tells me that the settings on the collided-into-object -also- come into play).  But, it -looks- like I should be able to do said hack without too much interference with 'standard' friction.  Not sure how this would handle with part-part based collisions (e.g. driving a rover across an aircraft carrier deck), but I may be able to apply the same 'hacks' to the part colliders as well. 

The hack in question is setting the physics material of the collider to have a friction combine model of 'multiply', which allows the zero-friction in the bump-stop colliders to multiply out to an actual zero-friction collision, but should not effect the friction of other standard colliders (as when they muliply their non-zero value with the terrains non-zero value, it will still result in friction).  As a final touch on the hackery, I can monitor when the specific collider is no longer being collided with and reset it to its previous state (so any changes from the wheels would be temporary, only in effect when the wheels were in contact with the surface).

 

This is actually far bigger news than it would seem, as having zero-suspension wheels, and being able to retrieve force information for them, will allow for many, many, new wheel uses and setups.

  • Locked Suspension at specific heights, -with- usable motor, steering, brakes, etc.
  • Rocker-Bogey setups (as the rocker/bogey -is- the suspension, these require a different model setup/etc)
  • Zero-suspension 'castor' type wheels. (either free-castor, or directional/steerable)
  • Proper simulation of mecanum type wheels without suspension.
  • Allowing users to zero out ride height on any wheel.
  • Landing legs can lock and adjust suspension without reverting to the default friction model
  • Probably a bunch more stuff that I had previously discounted as impossible.
  • Bottoming out the suspension will no longer cause the wheel to 'stick'; bump stop colliders no longer interfere with lat/long motion, and only stop over-compression (as is there intended purpose)

 

More testing is required, and then proper integration of the changes.  Might make it into this weekends update, or might come as a secondary 'dev testing' version a bit later.  We'll see how much testing I can do on it and how stable the system feels....

Edit:  This may also help with the implementation of the spring tuning system (or rather, the removal of) as I no longer need to 'worry' about overcompression/hitting the bump stop.  As long as the wheel friction still works when riding on the bump stop, I can simply let the user worry about configuring the suspension appropriately for the load.  Wheels can them come with specific pre-set spring stiffness, combined with the scaling support and the existing 'springRating' adjustment to allow some minor adjustment in spring stiffness, and I think that is a system that I would be okay with.  It mostly removes the 'penalties' for improper setup, which was previously a non-functional wheel, but is now just a wheel with terrible spring force/low ride height.


Edit:

Cruising along at 25m/s with zero-suspension on the wheels (using collision data to determine 'spring force' to use for friction calcs).  Note the horizontal accel as displayed by KER; the -0.2 m/s is quite appropriate for air-drag and rolling resistance at that speed.  The vehicle is actually riding on the bump-stop colliders, and everything is still working as it should (motor, steering, friction).  Good stuff...

QrBJDz1.png

As long as I don't run into any show-stopping incompatibilities with stock functions or other mods, I think this may be a very workable solution to quite a few of the previously unhandled edge cases.

Edited by Shadowmage

Share this post


Link to post
Share on other sites
2 hours ago, Shadowmage said:

The hack in question is setting the physics material of the collider to have a friction combine model of 'multiply', which allows the zero-friction in the bump-stop colliders to multiply out to an actual zero-friction collision, but should not effect the friction of other standard colliders

Genius! Love your work Shadowmage, you get things done.

Share this post


Link to post
Share on other sites

Kerala foundries is not working even when I have done everything right I installed the latest version of KF and the wheel API also deleted the plugins for KF and nothing happens!;.;

Share this post


Link to post
Share on other sites
16 minutes ago, Jz03 said:

Kerala foundries is not working even when I have done everything right I installed the latest version of KF and the wheel API also deleted the plugins for KF and nothing happens!;.;

That is because it is not installed correctly.  Those are the old installation instructions from when it was in dev testing and will not work with the recent releases.  Kerbal Foundries has been brought back with a new thread and its own releases.

Remove any existing KSPWheel and KerbalFoundries folders, and grab the current release from the new Kerbal Foundries thread:

(or directly from github: https://github.com/shadowmage45/KerbalFoundries2/releases )

Share this post


Link to post
Share on other sites

Okay I get confused a lot sorry shadowmage

Edited by Jz03

Share this post


Link to post
Share on other sites
14 hours ago, Shadowmage said:
  • Locked Suspension at specific heights, -with- usable motor, steering, brakes, etc.
  • Rocker-Bogey setups (as the rocker/bogey -is- the suspension, these require a different model setup/etc)
  • Zero-suspension 'castor' type wheels. (either free-castor, or directional/steerable)
  • Proper simulation of mecanum type wheels without suspension.
  • Allowing users to zero out ride height on any wheel.
  • Landing legs can lock and adjust suspension without reverting to the default friction model
  • Probably a bunch more stuff that I had previously discounted as impossible.
  • Bottoming out the suspension will no longer cause the wheel to 'stick'; bump stop colliders no longer interfere with lat/long motion, and only stop over-compression (as is there intended purpose)

Excellent news and developments especially as it all concerns things I've tried to do within the existing and KF old systems without success. Now I just need a non IR way to make the axle pivot( and the constraints system can't do it as is) Already have beam, rocker bogie and trailing axles made, last worked 1.0.5, if you're after some test models.

Share this post


Link to post
Share on other sites
10 hours ago, Jz03 said:

Okay I get confused a lot sorry shadowmage

No need to apologize, just wanted to make sure you got the proper instructions so you could get things working properly.  I know how frustrating it can be to follow what appear to be the instructions and have them not work (was dealing with that with some features in Unity just last night...).

 

30 minutes ago, SpannerMonkey(smce) said:

Excellent news and developments especially as it all concerns things I've tried to do within the existing and KF old systems without success. Now I just need a non IR way to make the axle pivot( and the constraints system can't do it as is) Already have beam, rocker bogie and trailing axles made, last worked 1.0.5, if you're after some test models.

Sure, feel free to send them my way.  I'm not really sure how to actually implement the rocker-bogey setup myself; in order to function properly it really needs to have several jointed rigidbodies that allow free rotation, which currently means using IR.  Its on the list of things to look into figuring out, but that list is quite long at the moment :)

Share this post


Link to post
Share on other sites

those news @Shadowmage sounds almost too good to be true, keep up the great work! :)

One question, I was wondering would it be possible to somehow integrate behaviour of deployable wheels (i.e. landing gear) with your wheels code, i.e. to have motor-powered landing gear that is not active (no ec usage) and doesn't steer while stowed but works normally with your KSP wheel code when deployed (I'm thinking especially about electric motor usage for those)?

cheers, rio

Share this post


Link to post
Share on other sites
9 minutes ago, riocrokite said:

those news @Shadowmage sounds almost too good to be true, keep up the great work! :)

One question, I was wondering would it be possible to somehow integrate behaviour of deployable wheels (i.e. landing gear) with your wheels code, i.e. to have motor-powered landing gear that is not active (no ec usage) and doesn't steer while stowed but works normally with your KSP wheel code when deployed (I'm thinking especially about electric motor usage for those)?

cheers, rio

Deployable gear -- yep, as long as I'm understanding your question correctly.  KSPWheels fully support stock-style deployable landing gear.  Disabled while stowed, enabled when deployed.  Including steering and motor only active when deployed.

https://github.com/shadowmage45/KSPWheel/blob/master/VSProject/KSPWheel/PartModules/KSPWheelDeployment.cs

https://github.com/shadowmage45/KSPWheel/blob/master/GameDataDisabled/Stock/Stock-gear.cfg.disabled

Share this post


Link to post
Share on other sites

 

17 hours ago, Shadowmage said:
  • Probably a bunch more stuff that I had previously discounted as impossible.

This is my entire experience reading this thread. And why I'm so utterly captivated by it.

Thank you for continuing to work these "miracles." :wink:

Share this post


Link to post
Share on other sites

Just want to confirm that it works absolutely fine with FAR now.

47avVZo.png

Since it's the first time I have been able to test them with planes properly, I have to say the physics are wonderful. Absolutely game changing. My first landings were catastrophic, but they always felt like "oh, okay, I have the springs too stiff, I have to change it" or "oh, I have the brakes too strong on the front wheel, I have to tone it down", not the crazy weirdness that is stock wheels. Once properly adjusted, the wheels worked perfectly, exactly as expected of wheels. Definitely the best wheels I've ever seen in KSP.

Let me make clear that, for the functionality they have now, I am already completely satisfied with them. But in the interest of completeness, there are still some minor problems (I have only tested the small and medium ALG for now): FAR doesn't voxelize the actual gears when they are deployed, only the wheel "containers". This makes it so that it's indifferent to FAR if they're deployed or not, and they don't grant the expected extra drag when deployed. Furthermore, even after retracted, they seem to keep making noise (as when they are rolling).

I will completely understand if these very minor issues are unadressed, and bring them up only in appreciation of the author's work. Thanks, Shadowmage!

 

Edit: Also, for some reason, even though ALG starts deployed, the landing gear action group starts inactivated, in such a manner that you have to press "G" twice to retract the landing gear. A very minor inconvenience at most, of course.

Edited by TGSAP

Share this post


Link to post
Share on other sites
21 hours ago, Shadowmage said:

Updated release is available:

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

Fixes FAR problems, a few ALG symmetry cleanups, drag-cubes on scaled wheels, new spring model, and a few other minor updates.  See the link for downloads and full change-log.

Wow, Nice job man! Thx for the FAR effort! Much appreciated! Going to test it out ASAP

Share this post


Link to post
Share on other sites

As I've said before the fact that alg is working again is amazing, and without complaining at all I would like to mention a feature that was in the original mod that was just a simple button in the wheel options that auto aligned the wheel it self to the ground, which toke the guess work out of that element of building spaceplanes.

I don't know how difficult that would be to do in your plugin but i thought i mention it.

Again amazing work, I will continue to sacrifice kerbals in your honor
 

Share this post


Link to post
Share on other sites

I think you could replicate the functionality by simply inverting the rotation of the part and applying it to the wheel. Specifically, the "roll" axis in local space.

Share this post


Link to post
Share on other sites
19 hours ago, 0111narwhalz said:

I think you could replicate the functionality by simply inverting the rotation of the part and applying it to the wheel. Specifically, the "roll" axis in local space.

Its a fair bit more complicated than that.

The wheel only moves on one axis; the part can be rolled on two axis.  There is also different coordinate systems (local spaces); the part uses one coordinate system, and the wheel uses a second one that may or may not be the same (and most often is not).

So you need to get the difference between the wheel and the ground direction on only the axis in which the wheel can move.  This involves calculating the direction to the ground in world space, converting that into local space, doing some trig to find the x/y/z difference on the plane denoted by the axis, calculate the angle from that x/y/z diff, and then rotate the wheel by that amount or up to its maximum allowed.

(This is basically doing the same thing that tracking solar panels do, rotating on a single axis to face a target, only the target in this case is the ground instead of the sun).


As I stated, I don't see this as a 'necessary' feature.  Would be nice?  Sure.  Necessary to proper functioning?  No, not at all.  (in fact, the angle of the wheels on those models has zero impact on the simulation, it is purely visual, the wheel-collider is aligned to the suspension strut and not the wheel).

As such I can put it on the long list of 'would-be-nice' features, but it is a very long (and constantly growing list); so the best chances to get this in earlier rather than later, if it is a feature that is really wanted, is for someone else to write it up and submit a PR.

 

Edit:

Untested prototype code for in-editor wheel-ground alignment, using the current suspension mechanics (see KF thread for proposed new mechanics).  Probably at least one thing inverted in there with the angles:

            Transform cr = carriageTransform;//the wheel, to be aligned
            Vector3 target = Vector3.up + carriageTransform.position;//one unit above the transform, in world-space in the editor
            Vector3 localTarget = cr.InverseTransformPoint(target);//one unit above the transform, as seen in local space
            //rotating around the local Z axis, so we only care about the x and y offsets
            float xOff = localTarget.x;
            float yOff = localTarget.y;
            //erm.. feed this into Mathf.Atan2 as a slope, to get the returned angle
            //check the returned angle versus current angle and max angle
            //set to maximum of max angle or dest angle
            float angle = Mathf.Atan2(yOff, xOff) * Mathf.Rad2Deg;
            float dest = Mathf.Clamp(wheelRotation + angle, -wheelRotationMax, wheelRotationMax);
            wheelRotation = dest;
            carriageTransform.localRotation = wheelDefaultRotation;
            carriageTransform.Rotate(0, 0, wheelRotation, Space.Self);


(Just posting to show that it is not nearly as easy as 'just point it at the ground' or 'just use the inverse of the part rotation')

Edited by Shadowmage

Share this post


Link to post
Share on other sites

Unless @Grease1991 just means making sure the wheel is straight and level in the hangar? I never actually used adjustable landing gear, but I can see how that might be useful. Attach the part with the wheel strut at whatever angle you like, and have the actual wheel bit then align itself with the cardinal axes in model space.

I don't know how important that would be anymore, since you can switch the rotation gizmo to absolute coordinates and turn on angle snap, although this will align the part as a whole, not just the wheel.

Edited by allmhuran

Share this post


Link to post
Share on other sites
5 hours ago, allmhuran said:

Unless @Grease1991 just means making sure the wheel is straight and level in the hangar?

yea thats what i meant, As in you could place the landing gear at any reasonable angle and adjust the strut angle, then you just hit the button and it would align the wheel up and down to the hanger. 

but I don't know anything about code so like i mentioned before it's a minor thing that would be nice to have again. not a major issue by any means.

 

Share this post


Link to post
Share on other sites

is there ANY chance at all for a revival of say... the engines + wheels from modular multiwheels?

Share this post


Link to post
Share on other sites
6 minutes ago, Hellbrand said:

is there ANY chance at all for a revival of say... the engines + wheels from modular multiwheels?

Zero chance.  That mod was never released under any sort of permissive licensing, so -cannot- be updated by anyone else.  Period.

In fact the author explicitly forbids re-use of the models and art.  Can't get any more of a 'No' than that....

Share this post


Link to post
Share on other sites

Got some questions about the damage model.  I've noticed that on very large craft, sometimes the stress of just being dropped onto the runway can break the wheels even though the load after they settle is well within the limit (presumably something similar could happen on landing).  Looking at the log messages it appears that the peak loading can be several times the normal loading (saw it exceed 100 briefly).

I took a look at the damage model and it looks like the damage you receive (by which I mean addition to stressTime) is proportional to (load - maxLoad).  Doesn't that mean that larger wheels on larger craft will break much quicker than smaller wheels/smaller craft?  It looks like the speed contribution to stressTime is a proportion (as opposed to your actual speed), maybe it would make sense to do the same thing for stress damage?

Share this post


Link to post
Share on other sites
12 hours ago, blowfish said:

Got some questions about the damage model.  I've noticed that on very large craft, sometimes the stress of just being dropped onto the runway can break the wheels even though the load after they settle is well within the limit (presumably something similar could happen on landing).  Looking at the log messages it appears that the peak loading can be several times the normal loading (saw it exceed 100 briefly).

I took a look at the damage model and it looks like the damage you receive (by which I mean addition to stressTime) is proportional to (load - maxLoad).  Doesn't that mean that larger wheels on larger craft will break much quicker than smaller wheels/smaller craft?  It looks like the speed contribution to stressTime is a proportion (as opposed to your actual speed), maybe it would make sense to do the same thing for stress damage?

Good catch; not sure what I was thinking when I set it up.  Yes, it should be proportional and linear; 2x max load on a small wheel should be the same 'over-stress' as 2x max load on a large wheel.

^^ Would explain what I was seeing with large wheels popping easier than small ones.  I'll likely have to do some re-adjustments of the overall damage model, perhaps adjust the base multiplier a bit.

Have fixed that up and should be available with a release later today.

Share this post


Link to post
Share on other sites

Working through the updated motor efficiency/power use mechanics.

Hit a bit of an alarming point -- where previously I had thought that there was an error in my calculations regarding conversion of kW input/output and torque... well... it was actually correct.  The current power-draw factors for wheels are off by about 1000x .... (they are 1/1000 of what they -should- be, if 1ec/s = 1kw)

A 100% efficient motor with stall torque of 1kN*M will have a stall input power of ~340kw.  That is 340ec/s in KSP terms using common conventions.  The KF-tiny wheels put out 0.63kN*m, which would be 214ec/s..... for the smallest rover wheels.  Makes those batteries and generators seem pathetic, doesn't it?  Certainly not going to be running those rovers on solar panels (which are around 0.2kw per m^2); you would need a giant field of panels for 214kW.

One of the Tesla models has a 270kW/362hp motor rated for 440 N*m of torque (torque at wheel(post-gearing), or at motor shaft(pre-gearing)? doesn't say).  As no motor is ever 100% efficient, we can wager that the peak power draw will be -at least- 270kW; and that is for only 440Nm of output torque (probably closer to 4x that power for the stall-input-power). 

So my calculations, while probably not perfect, are at least close to realistic.  For every real world motor that I feed the stats into my calcs, the output from my calcs is always within 1-2% of the specified stats/charts for that motor -- close enough for video game use....


This brings back the question of definitions of power and use;  what is 1EC as a stored energy unit, what is 1EC/s as energy flow?

The stock TR-2L wheel has a stall-torque of 2kN*m.  However it only has a stall power draw of 3.5ec/s? (commented out 7ec/s).  That only makes sense if 1.) That motor is ~200% efficient, AND 2.) 1EC/s = 100kw

 

USI and NF reactors list output power as being 'kW' and give the respective output as that value in EC/s.  1EC = 1kw

 

If average (terrestrial) solar panels can put out ~0.2kw per square meter....  ( http://www.theecoexperts.co.uk/how-much-electricity-can-i-generate-solar-panels )

The stock static solar panel is 0.3*0.5m = 0.15m^2.  But it puts out 0.3 ec/s?  Should that not be 0.03 ec/s?  What gives?

 

So.. stock solar panels put out 10x more power than they should.  And stock wheels draw 0.005x (1/200th) the amount of power that they should.  IF 1ec/s = 1kw... 

Arrghghhrhhghgh.....  ughhghhh.... the inconsistencies... make my brain hurt....  (and I haven't even looked at power-density of batteries yet...)
 

Either way, the math for the motors is done.  It works.  It gives the expected outputs for given inputs.  Now I just need to 'fix' all the inconsistencies regarding EC with all the other mods and stock......

Edited by Shadowmage

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.