Shadowmage

[1.4.2] Kerbal Foundries -- Continued - Tracks, Wheels, and Gear (04-10-18)

Recommended Posts

@TiktaalikDreaming  On the note of Substance Painter and its use for non-PBR stuff -- it actually works quite well after some minor adjustments to workflow. 

Most of the built in materials work with it to some extent, though the downloadable content is iffy.  Most of the same effects that make it great for PBR workflow, also work fine for legacy gloss/spec setup -- the geometry based generation tools such as 'edge damage' and 'dust' all still function fine.

This was a 10-minute texture job on these tracks hardware, in legacy diffuse/bump/spec setup.  Spent more time figuring out the changes between the workflows.... and yes the dust level is a bit high...

HS6n6xe.png

 

My new conclusion would be that Substance Painter is worth it even for legacy texturing.  Wish I would have found this tool years ago... (though I wouldn't have been willing to pay for it at the time).  I'm not aware of any free alternative programs with the same model-painting based setup, but they might well be worth looking into if cost was an issue.  At least download the free 30-day demo and give it a try :)

 

 

Share this post


Link to post
Share on other sites

My post was meant to be a light hearted joke :) But I do like your reply. I vaguely remember some numerical analysis from uni. I rather liked it at the time.

I think I see where the slip appears. I wonder if it might be possible to correct the slip though. Yes the simulation is poor, which results in the slip. But would it not be possible to reduce the slip? The idea would be something like this. Initially no slip. Simulation takes place. If no slip then no reduction in slip. If slip is less than x then set slip to zero. If slip is greater than x let slip remain unchanged. The thought would be that unless we have significant slip set the slip back to zero. My thought is that once slip begins then it rapidly increases. If we set x to be a reasonable value we might be able to make sure we retain full control despite the simulation
telling us that slip has happened. This might give the impression that we have more grip in that slip only occurs if for example we yank the steering-wheel. Does this make sense? More importantly might it provide a solution to the 'tires/tracks are not grippy enough' problem? It is simple and avoids the need to manipulate the simulation itself or increase the frequency at which the simulation runs.

Although my suggestion would dampen the slip, I do not mean to dampen the simulation in the sense that I do not mean to change the spring/mass/dampener model. Just manipulate when we accept that slip occurs.
The result would seem like a mockery of all the good work done with physics simulation. What is important though is what appears to be happening in game from the players point of view when trying to move and control a craft with wheels/tracks.

Edited by Apaseall

Share this post


Link to post
Share on other sites

@Apaseall :)  No worries, I'm always up for a discussion on ways to fix some of the areas the simulation is lacking.  Your approach would more than likely work if I had access to the accumulated physics forces for a frame, and could manipulate them prior to them being applied to the rigid body(ies).  Notably, right now, I can't simply 'set slip to zero' -- I have no knowledge of how much 'force' it will take to accomplish that, nor if it would even have the desired outcome once Unity's unreliable joint system gets involved..

The relevant information that is available at the simulation are:

  • Current position, surface normal/tangent, and world velocity of the wheel collider hit position -- the contact patch
  • Current/previous spring (and damper) output forces, calculated from wheel hit  --  this becomes the 'down-force' used in friction.
  • Independent X and Z slip ratios, calculated from world velocity and wheel rpm
  • Input states for motor-torque and brake-torque
  • Other info under control of the simulation, like wheel rpm, wheel radius, wheel mass, spring coeff and damper ratio, friction curve, tire friction coeff (always 1.0, but available...), surface friction coeff(always 1.0, but available..), a few other sundry config settings...

The only output that should realistically be done is to apply a force to the rigidbody for the suspension and friction forces.  I already cheat a bit and also apply a 'holding' force to prevent the slow sliding movements that would otherwise occur on hills (basically an implementation of static friction).

The simulation is purely reactive; as the wheel collider is forced downward by gravity, the simulated spring reacts by outputting more upward force, this spring value is also used to drive the friction simulation (down-force, carried weight, etc).  This is why 'zero length' suspension does not work -- if there is no spring compression, there is no 'down-force' in the simulation, and nothing to derive friction from.

 

It currently has no knowledge of total vessel mass, number of wheels or arrangement, or really anything outside of the single wheel collider -- they each operate as an independent entity. In the long-term, I would like to investigate possibilities to include vessel related information such as mass, total number of wheels, those in contact and their total downforces, etc.  With that information I could more accurately predict the proper output forces that wouldn't overshoot or explode, or do other kerbal-stuff.  Likely I would end up doing some 'simple' single-rigidbody calculations from that data to allow feedback into an RK integrator... hmm...  might actually be onto something there :)  (nothing I have time for in the immediate future... but perhaps some day).

 

 

Some of this might be...mitigated in the short term by simply adjusting the current friction curve.  Here is what the current curve looks like (Dry, 'standard' tire friction curve)...

image009.jpg

What happens in the current simulation is that between one frame and the next (on even gentle of maneuvers) you'll go from a slip ratio of 0 to 0.3+. The simulation is so granular from the time-stepping that most of the time you completely bypass the peak friction.

So, if you were up for a bit of investigation, you could try tweaking the friction curves on the parts to something that takes the above knowledge into mind.  Have the curve keep the steep lead in, but more of a plateau at the top before the taper off.  If interested, let me know and I'll dig up the details on field names and/or provide a sample patch to play with.

Share this post


Link to post
Share on other sites

If I read what you wrote correctly, the actual total mass of the vehicle is not used at all?

Looking at the graph above and understanding that the peak is missed most of the time, I can see why a problem might exist for Dry.
I concur that if the slip ratio tends to be large most of the time, then the friction coefficient would be much lower than anticipated.
In other words, if things worked such that the slip ratio increased in minute steps, one would approach and experience the maximum.
If that were to happen I assume that the maximum would prohibit or degrade the progression of increasing slip?
By avoiding the maximum I would assume that slip ratio would not be retarded as expected and thus increase much more rapidly then anticipated.
Would that be a fair understanding of what the effect of a large time step would be?

I am not playing as we speak.
That is because I have a broken game due to an update for another mod going a bit wrong.

I do have two vehicles I am using. One has a vastly scaled up set of wheels. The other a more reasonably up scaled set of tracks.
I could use this break from playing my main progression to provide time for investigation of the effect of changing the friction curve shape.
I have 168 mods going atm.
If you don't mind me using all them and the consequently complex craft, I am willing to give it a go.
LOL the only down side is that I have spent a lot of time trying to cope with the current system with modest success, namely avoiding spinning out at increasingly higher speeds.

Edited by Apaseall

Share this post


Link to post
Share on other sites
2 minutes ago, Apaseall said:

I am not playing as we speak.

That is because I have a broken game due to an update for another mod going a bit wrong.

Nothing* prevents you from copying KSP to a second directory without all the mods.

*except hard disk space, I suppose

Share this post


Link to post
Share on other sites
10 minutes ago, 0111narwhalz said:

Nothing* prevents you from copying KSP to a second directory without all the mods.

*except hard disk space, I suppose

True. The reason why I mention it is that I already have experience of driving those vehicles. Plus I have spent some effort in trying to avoid 'spinning out'. Thus I have a 'feel' for those craft.
If I were to make new craft then I would not know what to expect. If I were to remove some mods then either the craft would break, or they would have reduced mass.
I am able to make use of symlinks to avoid some of the disk space issues, but you are quite right that I am very limited on space right now.
That is because for OS and KSP I use high speed SSD's due to playing on a laptop. Yes a laptop. If I were to use a standard HD I probably would top myself during the loading time wait let alone between frame updates during play.
Yes I know KSP is supposed to be all about 'in memory' but that is not totally true from how the game feels and runs.
Your game play experience may vary :)

Oh and what I mean about not playing because of a broken mod, is that I am not unable to play. Just that what I was playing was learning how to use parts from that mod. I don't have any game play lined up that I can do whilst I wait for the issue to be fixed.
Plus the issue 'should' have no impact on any aspect of testing for wheels/tracks.

Edited by Apaseall

Share this post


Link to post
Share on other sites
2 minutes ago, Apaseall said:

True. The reason why I mention it is that I already have experience of driving those vehicles. Plus I have spent some effort in trying to avoid 'spinning out'. Thus I have a 'feel' for those craft.

I see. Hypothetically you could reduce the complexity by replacing some of the modded parts with fuel or ore ballast tanks of roughly equivalent mass. Doing so might even reveal unexpected mod interaction weirdness, or odd flexion in key points that changes vehicle geometry.

Share this post


Link to post
Share on other sites
2 minutes ago, 0111narwhalz said:

I see. Hypothetically you could reduce the complexity by replacing some of the modded parts with fuel or ore ballast tanks of roughly equivalent mass. Doing so might even reveal unexpected mod interaction weirdness, or odd flexion in key points that changes vehicle geometry.

Yup. Sounds like hard work though. Or more work than I think I can be bothered to do. Hence my asking if I could use my present craft 'as is'. I am feeling a tad lazy today lol.

Share this post


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

In other words, if things worked such that the slip ratio increased in minute steps, one would approach and experience the maximum.

While I think you are understanding the problem, what you propose would be physically un-realistic -- resulting in way more slide before the friction went up to maximum.  The reason the friction curve looks like it is... is because that is what happens in a real tire.  You want that steep lead-in; it is what provides the 'slip stopping' power -- no steep lead in, and there will be way more slipping occuring before you reach the peak at the end of the graph.

Initial there is no velocity difference between the tire and the wheel (no slip); there is also no friction.  (Dynamic) Friction is only generated by slipping, which is what the simulation...simulates...

As velocity is added to the wheel (e.g. through motor torque), it begins to spin, and the slip ratio increases.  In real life, this happens gradually and smoothly (infinitely small time-steps).  The 'minute steps' up to maximum friction are fully present in the plotted graph above, if approached slowly enough.

This is what happens currently in the simulation with the discrete time-steps (numbers merely for discussion, likely not physically accurate):

Frame 1 = 0RPM, 0 slip ratio, 0 velocity, torque input = 100%
Frame2 = 10RPM, 0.4 slip ratio, 1.0m/s velocity, torque input = 100%
Frame3 = 18RPM, 0.8 slip ratio, 2.0m/s velocity, torque input = 100%

Between frame 1 and frame 2, it completely blows past the peak output point on the friction curve.
 

What needs to happen is this -- smaller time-steps:

Frame 1 =  0RPM, 0 slip ratio, 0 velocity, torque input = 100%
Frame 1.1 1RPM, 0.05 slip ratio, 0.1m/s
Frame 1.2 2RPM, 0.08 slip ratio, 0.2m/s
Frame 1.3 4RPM, 0.10 slip ratio, 0.3m/s
XXXX
Frame 2 = 20RPM, 0.08 slip ratio, 2m/s  (note speed difference at frame 2 compared to example-1 -- not bypassing the peak actually results in -much- better grip)

Which is why I proposed a 'table-top' style of friction curve to mitigate this problem.  Won't fix it entirely, but might 'hide' some of the issues.  Something like this (but more curvy...)

4BMNr6I.png

Still not a very realistic solution, from a 'doing things properly' perspective... but it might actually result in a better 'feel' for the simulation.

(I just don't have time to play with stuff that actively goes against the simulation... so feel free... let me know what think... if it is 'the best thing ever'... I'll take a look at it for inclusion in a future release)

 

10 hours ago, Apaseall said:

Hence my asking if I could use my present craft 'as is'. I am feeling a tad lazy today lol.

You can use whatever you want for your personal testing.  Got a craft you like?  Go for it...

But if you are intending to send a craft file for -me- to use for testing/verification -- please make it KF+stock only.  I don't have time to be chasing down mods and doing game setup stuff just to test something.


Edit: Hmm... apparently this is all moot at the moment.  The current plugin only exposes the friction curve to the API, it does not include any provision for loading from config file or patching....   So I'll be adding that function in sometime this week :)  (you'll see the 'new release available' post when its ready...)

More edits -- current curve, as plotted in Unity:

Xnfla3T.png


Proposed change to 'table-top' curve --

AUsoaLm.png

Edited by Shadowmage

Share this post


Link to post
Share on other sites

I was trying to describe that in the case of large steps, the friction experienced went from zero step0, up an amount step1, then in step2 was past the maximum, step3 less than step2. I was trying to say that grip was increasing from step0 to step1, but was missing max grip when it arrived at step2.
If the steps were smaller we would experience grip increasing, and hopefully achieving maximum (if the steps were such that one of them landed on the maximum).

In the first case, large steps, we would quickly go from zero velocity with zero slip to a velocity with some grip.
In the second case, small steps, we would go from zero velocity and zero slip, through increasing velocity and increasing grip. This would appear in game to the player as one feel of control. After a certain velocity grip would decrease. This would feel like a different control.
I know I mixed slip ratio with velocity. My mind just seems to scream that way.

I agree with the steep slope from zero. That was not what I was talking about. I was talking about zero, then a small amount, then missing the maximum, which if plotted would result in a completely different graph.
Yes using a more plateaued graph would enable the opportunity to miss the maximum, but a close hit would still result in a value close to the maximum.

I did not anticipate that you would be providing a config file(s) for the friction curve. To be honest I thought the friction curve was in a config file already. Shows you just how lazy I am, that I never even bothered to examine the files. I thought you would be providing a couple of different .dll files for me to try out.
I do like the idea that such curves will now become part of a config file, as I feel sure this will be a good way of 'tuning for user game play feel'.

As I tried to  convey before, I respect the work and dedication to using and generating correct simulation. I was trying to point out that an additional fudge might be worth adding to accommodate 'game feel'. I hope you do or did not take offense by my suggestion that whilst being pure is wonderful, being able to use a wheel in game is more enjoyable. Yes I know if I took the time to sit down and look at speeds/masses involved I would totally agree with the realism. But I am talking about this being a game and enjoying being able to put wheels on something. Then drive it away without it spinning out of control at a whiff of turn. One is realistic, the other is playing a game for fun. I do enjoy the realism and challenges of KSP. It is one of the things that keeps me coming back for more. But if there is a possibility of a little blurring between realism and game play, in order to make things a little easier, I am afraid I will take a little less realism for more fun, over realism and hours of tweaking, everyday.

Thus I keep suggesting ways of increasing grip. I don't want to remove slipping. That would rub me up the wrong way. I am very full of appreciating for folks that spend so much time making beautiful looking and realistic mods. If I can help, by commenting, to bring the enjoyment to more people, then great. In this case, a little less slidding around would suit me fine, and I hope others will enjoy that as much as I think I will.
Ok I ramble. Sorry.

Share this post


Link to post
Share on other sites

More playing with model updates.  Testing out my re-skinning on a set of tracks, and also testing out the possibility of doing legacy textures by simply disabling metallic reflections (but still using the std. shader).  The rigging works... the texturing setup... kind of.

Metals enabled:

wIwAchZ.png

No metals:

Izw0nJB.png

Side-by-side

qoOqy2B.png

 

It is apparent that the specular reflections from the standard shader are still present even in non-metal mode (which is good, they should be), but it is also not a very good swap-in for the stock legacy shaders.

 

Share this post


Link to post
Share on other sites

@Apaseall I'm enjoying the conversation :)

On 10/10/2018 at 12:23 AM, Apaseall said:

If I read what you wrote correctly, the actual total mass of the vehicle is not used at all? 

Correct -- I designed the wheel collider system entirely in the Unity editor, where I don't have access to any of the KSP classes (source files), so there is no such thing as a 'Vessel', or a 'Part', etc.  These wheel colliders actually work far, far, better in the Unity Editor as compared to KSP; but tests revealed this was almost entirely due to the joints used to link different parts together -- joints cause all sorts of instabilities in the simulation (as the joints are, basically, just another spring-damper system that holds the parts together).

That is not to say that having more information couldn't make the simulation better (it can), but I wanted to start from a 'realism' perspective before jumping into hacky-land.  In real world physics, an individual wheels suspension knows absolutely nothing about the other wheels on the vehicle, or how much the vehicle weighs -- they for the most part, function entirely independently (anti-roll bars excluded).

But also... knowing the vessel mass by itself does me little good.  I also need to know the distribution of mass (moment of inertia? inertia tensors for the various axis? idk the term for it...), so that I could effectively 'predict' how the vessel would react to specific forces being applied.  Which is all fine in theory for a single-rigidbody setup; but again the Unity joints and 'each part is a rigidbody' setup completely remove any potential for that simulation to be entirely accurate.  It -might- still be a viable addition to the simulation, and I'm thinking that the additional information I could get out of it would likely be close enough to work in all but the most noodley of craft designs (sim would assume joints are rigid, so if someone was 'abusing' the terrible joints.... it would play havok with that part of the sim).  Something to investigate for the future when I have time and feel like learning some new physics concepts (rigidbody dynamics).

 

21 hours ago, Apaseall said:

I did not anticipate that you would be providing a config file(s) for the friction curve. To be honest I thought the friction curve was in a config file already. Shows you just how lazy I am, that I never even bothered to examine the files. I thought you would be providing a couple of different .dll files for me to try out.
I do like the idea that such curves will now become part of a config file, as I feel sure this will be a good way of 'tuning for user game play feel'.

Good news on this front -- I did add in the code for this last night, and you can grab a .dll with the functions enabled from the dev branch on the KSPWheel repo -- (d/l link for dll --  https://github.com/shadowmage45/KSPWheel/raw/dev/GameData/KSPWheel/Plugin/KSPWheel.dll ).  More good news is that the new curve does increase effective friction -- so much that I was unable to spin out in a standard 4-wheeled vehicle no matter how I tried.  Drift a bit at high-speeds.. sure.  Tip over if CG was too high.. yep... more-so than before.  So perhaps the new curve was a bit 'too far'.... but was a good initial testing point.

I didn't implement it as a full 'float curve' setup, but rather it has the chance to input values for the three important points of the simulation (extremum, asymptote, and tail).  An example of the patch/config I was using for testing is below.  Replace the .dll in your KSPWheel folder with the one from the link above, and drop the patch in your GameData folder somewhere, and it'll patch all KSPWheel using parts with the new curve.

 

@PART[*]:HAS[@MODULE[KSPWheelBase]]
{
	@MODULE[KSPWheelBase]
	{
		//point = 'time' along the curve  (the x coordinate)
		//value = value at that time in the curve (the y coordinate)
		
		//there is no starting slip point or value, it is always 0, 0
		%asSlipPoint = 0.06
		%asSlipVal = 1
		%exSlipPoint = 0.35
		%exSlipVal = 1
		//there is no 'tail slip point' -- it is always 1.0
		%tailSlipVal = 1
	}
}

 

Edited by Shadowmage

Share this post


Link to post
Share on other sites

Glad you are enjoying it :)
In the real world, the wheel with own mass/spring/damper would still experience mass from the body in total, be it split evenly or unevenly between the other wheels. In that respect I was surprised that the body mass was not taken into account at all. My thoughts would be that more body mass would produce more grip.

CoM is something that I am familiar with in KSP in terms of designing aircraft. That then is something that is available. I have no idea how mods pick that up, but I am thinking that there are a number of mods that work in the editor part of KSP in order to visually display CoM.
AutoPilot mods may also pick up interesting stuff like the rotation about the axis along with forces in those directions too.
I mention these things as if you are interested in picking up that sort of info then those sorts of mods might be a good source of erm source code. :)

I have downloaded the .dll and put a .cfg in the KSWheel folder with the code from above. I will switch over the .dlls soon but I have just loaded my main game in order to have look at something else for a bit.
As in I may have received a fix for the issue that stopped me from playing.
Do not fear, I merely want to check if the fix works, I will play with my game at a later time.

Share this post


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

sim would assume joints are rigid, so if someone was 'abusing' the terrible joints.... it would play havok with that part of the sim

My suspension designs rely upon Infernal Robotics freemoving joints. I assume this would only serve to complicate things for my usecase?

Share this post


Link to post
Share on other sites
5 minutes ago, Apaseall said:

In the real world, the wheel with own mass/spring/damper would still experience mass from the body in total, be it split evenly or unevenly between the other wheels. In that respect I was surprised that the body mass was not taken into account at all. My thoughts would be that more body mass would produce more grip.

The wheel doesn't know how much the car weighs.  The wheel knows how much 'down force' is being exerted on it in its current configuration/orientation.  Which is the same information the simulated wheel colliders have available to them (the 'spring force' needed to keep the vehicle up, is the exact same 'down force' exerted by the vehicle onto the suspension system).

6 minutes ago, Apaseall said:

Do not fear, I merely want to check if the fix works, I will play with my game at a later time.

No worries -- entirely optional.  Even if you don't get around to testing it, the ability to specify it through config will exist in future versions for anyone to play with or customize.

Share this post


Link to post
Share on other sites
3 minutes ago, Shadowmage said:

The wheel doesn't know how much the car weighs.  The wheel knows how much 'down force' is being exerted on it in its current configuration/orientation.  Which is the same information the simulated wheel colliders have available to them (the 'spring force' needed to keep the vehicle up, is the exact same 'down force' exerted by the vehicle onto the suspension system).

No worries -- entirely optional.  Even if you don't get around to testing it, the ability to specify it through config will exist in future versions for anyone to play with or customize.

Well yes, the force due to gravity acting on the mass of the body is distributed over the wheels which indeed experience it as a force downward. More mass in the car, more downward force experienced by the wheel. The wheel would have some equal but opposite force, otherwise it would move lol. In a tyre that would be air in the inner tube and spring. So yes I think we are talking the same thing but with different words. So how do you determine the spring force that is being provided by the wheel if you do not know the mass acting upon the wheel?
Food time. Write more when I have something to say lol.

Share this post


Link to post
Share on other sites
10 minutes ago, Apaseall said:

So how do you determine the spring force that is being provided by the wheel if you do not know the mass acting upon the wheel?

Through the equation for the spring output -- up/down force = compression distance * spring stiffness ( +/- movement speed * damper ratio * critical damping function).

Basically the simulation says 'the spring is compressed X amount, so it is putting out Y force', and then uses Y for both the spring force and down-force (in opposite directions of course).  The good old fashioned newtonian equal-but-opposite simplicity at work :)

Share this post


Link to post
Share on other sites

I think that you no need to worry much about shiny/metalic textures. It may be a bit off in comparison to current stock parts, but that may be changed on next KSP release. At least Stayputnik is changed to be more shiny in future:

Despite being a bit too shiny(that also depend on someone personal taste), new textures looks very nice to me.

 

Share this post


Link to post
Share on other sites
On 10/4/2018 at 2:55 PM, TiktaalikDreaming said:

Yeah, that's my take on it.  Not super useful for classic KSP texturing, but by golly it looks to do great things if you're doing PBR renders and so on.  So very very tempting, but hard to justify that cost.  Maybe some time when my wife's not reviewing the credit card purchases so closely. ;)

Make sure you set some money aside :) What I can tell you is no matter what kind of texturing you do, once you've used Substance Painter you'll never ever go back to doing it in Photoshop and then testing and then fixing and testing again, repeat ad nauseum. You texture right on the model in real time and can see the results in real time in an excellent HDR renderer. It's French made (Quebecois actually) and that means it has a somewhat quirky UI and workflow, but as usual with French UIs once you do get it, it's quite efficient. And since it has a zillion procedural effects, grunges and things become stupid easy to do. The example I showed to @Shadowmage that made him disappear from the forums for three days after immediately jumping into SP was this one, a mech model I was working on:

H0NU64Y.jpg

Share this post


Link to post
Share on other sites
1 hour ago, vossiewulf said:

once you've used Substance Painter you'll never ever go back to doing it in Photoshop and then testing and then fixing and testing again, repeat ad nauseum. You texture right on the model in real time and can see the results in real time in an excellent HDR renderer.

This. I really can't stress how much truth there is in that statement.  Just the time saved in workflow alone is immense.

1 hour ago, vossiewulf said:

it has a somewhat quirky UI and workflow, but as usual with French UIs once you do get it, it's quite efficient.

True on both points.  There is a steep initial learning curve, certainly, but before long you don't even notice the UI and just go from working on stuff, to more working on stuff :)

One of the biggest suggestions I would make though would be to customize the mouse inputs to conform with your modeling program as best they can.  Having consistent control schemes for rotating models and such was very beneficial to my  use of SP, and its defaults were very different from anything else I use in my workflow.  So I changed it to be the same as blender for model manipulation and everything seemed much easier to use.

Share this post


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

Through the equation for the spring output -- up/down force = compression distance * spring stiffness ( +/- movement speed * damper ratio * critical damping function).

Basically the simulation says 'the spring is compressed X amount, so it is putting out Y force', and then uses Y for both the spring force and down-force (in opposite directions of course).  The good old fashioned newtonian equal-but-opposite simplicity at work :)

Ok so how do you determine how much the spring is compressed by, I would have thought that the force acting on the spring to compress it would be due to mass from the body and local gravity?

Share this post


Link to post
Share on other sites
2 minutes ago, Apaseall said:

Ok so how do you determine how much the spring is compressed by, I would have thought that the force acting on the spring to compress it would be due to mass from the body and local gravity?

The distance given by a [ray|sphere|capsule]-cast from the "root" of the wheel to the end of its suspension, i.e. by looking at the relative positions of the wheel and either the ground or other parts, whichever comes first.

Share this post


Link to post
Share on other sites
1 minute ago, 0111narwhalz said:

The distance given by a [ray|sphere|capsule]-cast from the "root" of the wheel to the end of its suspension, i.e. by looking at the relative positions of the wheel and either the ground or other parts, whichever comes first.

oh, so unity does the compression, this mod looks at the part and works out what the compression is?
Meaning that this mod does not know about the mass, but looks at the part for the results of unity dealing with the mass * local gravity?

Share this post


Link to post
Share on other sites
5 minutes ago, Apaseall said:

oh, so unity does the compression, this mod looks at the part and works out what the compression is?
Meaning that this mod does not know about the mass, but looks at the part for the results of unity dealing with the mass * local gravity?

It's a feedback loop. The compression drives wheel collider forces, which change the compression, which changes the forces, and so on for as long as the wheel's in contact with something.

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.