[1.8.x] Kerbal Foundries -- Continued - Tracks, Wheels, and Gear

[Apaseall]

3 minutes ago, 0111narwhalz said:

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.

I am trying to understand where or what deals with the body mass, and I thought from your last post that it was unity doing that, rather than this mod directly.

Yes I understand that an iteration takes place in order to try to reach an equilibrium since this is a complex system.

Edited October 12, 2018 by Apaseall

[0111narwhalz]

1 minute ago, Apaseall said:

I am trying to understand where or what deals with the body mass, and I thought from your last post that it was unity doing that, rather than this mod directly.

The only thing the collider cares about is forces between its root and its raycast target. You can test this yourself by building a "spring" with parts and laying it on its side, and introducing a wheel collider to it. The collider will spread the "spring," even though there's no force due to mass involved. (You can even do it in space if you want.) In the usual case, gravity does provide a force (namely, that of the vessel's weight), but the wheel collider doesn't care about where the force comes from. If the collider suddenly disappeared, your spring would collapse and your car would fall to the ground. The collider produces a force which opposes this tendency, in a way related to the extent of its compression.

[Shadowmage]

7 hours ago, Apaseall said:

I am trying to understand where or what deals with the body mass, and I thought from your last post that it was unity doing that, rather than this mod directly.

Yes I understand that an iteration takes place in order to try to reach an equilibrium since this is a complex system.

Yes, Unity handles all things 'physics' related -- including adding forces to the rigidbody to simulate gravity  (rather KSP specifies the gravity amount, and Unity applies/integrates it).  All things are specified as 'forces' -- a vector denoting a location and the amount of the force to be applied (or you can apply a torque to the rigidbody directly, but that is just two forces on opposite sides, in opposite directions).  The thrust forces for engines and RCS are also applied in this manner -- just another force acting upon the body.

In fact, you are not even allowed to simply 'move' the rigidbody manually -- doing so completely tanks the Unity physics simulation.  If you want to move something, you need to calculate and apply the proper force to it.  You can't just 'stop' a rigidbody in place, but need to find the proper force to apply to it to make it stop under the constraints of the physics system.

[Apaseall]

I keep a learn'n all the time!

[Apaseall]

First bit of feedback for you.
I have 6 KF Large Wheels on my wagon. Scale 2.5. Friction Multiplier 4.0 on rear two pairs, 1.0 on the front.
I have two drive modes:
1. Propulsion provided by wheels, front wheels limited steering, rear wheels large steering.
2. External propulsion, front wheels steering the same as 1. Rear wheels locked.

Low speed driving aka mode 1.
It is difficult to definitely state that more grip is experienced.
Possibly.

High speed driving aka mode 2.
Oh boy, yes there is much more grip.
The wheels disintegrate before they slip, so no slip seen at all.

Previously mode 2 would require little taps of direction change.
Tap a bit, wait for steering to come back to forward.
Tap again.

I think that because I am only trying to steer a tiny bit at high speed, that the grip remains high enough.
At low speed grip is lost due to the excessive amount of steering being requested.
Sounds and feels good to me.

As to how you want to tweak the curve for a more balanced experience, well I would suggest that you tend to have more grip, i.e. overly grippy.
Players will still need to watch their speed and request for steering.
For example I have the front wheels with tiny steering values, as I was having great problems trying to steer without spinning out.

Talking of spinning out, have you noticed that a spin will turn you by 180 degrees and bring you to rest?
 

[Shadowmage]

4 minutes ago, Apaseall said:

Talking of spinning out, have you noticed that a spin will turn you by 180 degrees and bring you to rest?

That would be because of the mass-distribution in your vehicle.  I'm guessing its tail heavy?  (or there is otherwise added friction on the front wheels, causing more drag, which makes them want to become the 'rear').  Also, having SAS enabled will cause added friction on the front wheels, because KSP's default 'drive forward' is the same as 'pitch down'.  Try disabling SAS if you have/had it enabled.

For best handling you want something with a neutral COG in regards to the wheels, e.g. like a mid-engine car IRL.  Bonus if you can add extra down-force to the rear wheels through spoilers/etc.

Really, its the same as rockets -- weight in the front, drag in the rear (but note, that moving the COM to the front adds 'drag' through friction to the front wheels...hence the mid-engine/balanced COM statement above).

 

8 minutes ago, Apaseall said:

Previously mode 2 would require little taps of direction change.
Tap a bit, wait for steering to come back to forward.

I guess another part of why I rarely saw issues with the old friction setup is that I don't often use the keyboard for steering -- analogue inputs (e.g. joysticks) remove the need for 'tap-tap-wait-tap'; just give the input amount you desire and hold it.

10 minutes ago, Apaseall said:

Friction Multiplier 4.0

Please remove any friction multipliers when doing testing for feedback purposes.   Use of that setting is unsupported due to its tendency to cause instability/jittering.

[Apaseall]

Lol game crashed. Probably unrelated. Most likely it is telling me to do something else for a while. Lol.

No wonder you never had issues with steering.
Using a joystick!
I wonder how many folks using this mod also use a joystick?

When I play again I will turn the friction multipliers off.
Easy to do as each pair is its own wheel group etc.

As for the weight, well CoM is fairly close the the middle by eye of the craft.
I am using space plane parts for the structure.
Hence I am tending to make it a bit like a plane with no wings.
Huge wheels.
I really need to link a pic.
When a Kerbal goes EVA you have to zoom in to see them.
Thank goodness I found some insanely long ladders.

I have a cargo tail, with a tiny (in comparision) rover inside.
To get the tail ramp to meet the ground I have to mess with the springs!
There is that much ground clearance.
Even so I still manage to bottom out the suspension now and then.
Did I mention it weighs over 386 T, and that was after I cut it down from 410!
I went in to see if I could stop the wheels from disintegrating and noticed I was over my weight limit.
Over 108m/s causes the wheels to vanish, would you believe.
LOL. Go big or go home. MOAR!!!!
LOL.

[Shadowmage]

Because Substance Painter relies so much on AO baking for its texuring process, and animated parts don't by default give good AO from standard baking methods, I've had to resort to some.... interesting... techniques to get usable AO maps for these parts.

For this wheel I essentially took the geometry that was around the wheel, found the closest edge/vertex, and spun it around to create a cylinder-ish shape.  I then expanded that shape out to be at the average of the surrounding geometries distance from the wheel to create a 'baking rig' -- the idea is that it should give the average AO to the  part that it would experience while spinning.  It won't be entirely correct for any given point... but it won't be entirely wrong either.  I'm likely not the first person to have stumbled onto this process, but neither have I ran across anything like it during my reading up on AO techniques.

 

I've decided that I'm going to adjust my workflow a bit to try and avoid the burn-out that I inevitably run into when I dive into huge projects;  rather than do all of the models in batched steps, I'm going to work on one (or one group of similar) model at a time.  I've already done the first stage/pass on (nearly) all of the models (import into blender, basic clean-up), which was one of the larger time-consuming steps, so from this point out I should be able to 'finish' 3-4 models/week at the least.  As the work progresses and parts are finished they will be available on the /dev branch of the repository, but I don't think I'll be packing up any releases until it is all done;  this may delay the 1.5 versions temporarily, but the 1.4 versions will continue to work after KSPWheel is updated/recompiled.

 

At this point in time I am strongly considering making Textures Unlimited a full-time dependency, where the new textures and shaders would become the default.  If I do this, I will provide an optional patch that will disable the use of the advanced shaders, so that those who are still stuck on DX9 or don't want the changes for whatever reason can still use the mod.  Also, please note that several of the updated models have had major UV-layout changes that will prevent their original textures from working.  In these cases I will make sure to provide a legacy shader compatible set of textures in one fashion or another (won't be the original tex, but won't be metallic either).

[Apaseall]

Here (hopefully) is a link to some pictures: https://imgur.com/gallery/EsiH8m2

More feedback.
I dropped the Friction Multiplier down to 1.0.
Can confirm that more grip is experienced in both mode 1 and 2 driving.
Additional note, in mode 1 I now have a new experience, I can turn the steering sharply whilst accelerating, I obtain the expected slip, and if I continue to accelerate but stop steering, I can see the craft slowly reduce spinning and then pull away in the new direction.
Sort of like if you put the handbrake on, got a slide going then released the handbrake. Resulting in a sliding turn which eventually decreases and you drive off in the new direction.
I say it is an added bonus and makes for fun but enjoyable play.

Tracks.
Can confirm that more grip is very apparent. Most noticeable to me is acceleration from rest without steering. Prior to this change the tracks would almost immediately slip, which looked like the tracks going faster and faster without the vehicle moving.
Now there is a small amount of slipping but the vehicle seems to move much sooner.
Great fun can be had with the sliding turns now, like drifting in a car. Very enjoyable because as I said, grip is restored and so control can be maintained. Before once you started to slip you were almost condemned to a flat spin to a halt before you could steer again.

Many thanks for this improvement.

Edited October 13, 2018 by Apaseall

[Shadowmage]

Think I'm nearly finished with the new textures for the KF-TrackLong, though I'm still undecided about all of the greeble-details on the mounting plate.  Might be a bit much.  Also still playing around with the various wear and weathering levels; mostly the 'rust' effect that I'm undecided on.

[Shadowmage]

One more mostly done....

Front:

Back (prior to fixing the track tex...):

[Shadowmage]

One more 'finished' part model/texture update --

This is at 512x resolution (original was 1024x).

I also spent some time today making a 'legacy' shader that accepts the same texture inputs, but uses legacy blinn-phong calculations for lighting (same as the stock shaders).  Works fairly well in initial testing.  Certainly not the same as having the textures authored for legacy shaders, but gives acceptable results.

Legacy is in foreground, PBR version in background.

[Catatau_27]

4 hours ago, Shadowmage said:

One more 'finished' part model/texture update --

This is at 512x resolution (original was 1024x).

I also spent some time today making a 'legacy' shader that accepts the same texture inputs, but uses legacy blinn-phong calculations for lighting (same as the stock shaders).  Works fairly well in initial testing.  Certainly not the same as having the textures authored for legacy shaders, but gives acceptable results.

Legacy is in foreground, PBR version in background.

Congratulations great work, I have a few questions: 1 - When will these texture updates be available? 2 - Will this mod be updated to 1.4.5 along these new textures? Or will the texture update come independently as a compliment? 3 - If there is an update to 1.4.5 this mod and the textures will work for users who have the 1.4.5 game update? Example: "Mod 1.4.3 working on game 1.4.5" Thanks for the attention =)

[0111narwhalz]

2 minutes ago, Catatau_27 said:

1 - When will these texture updates be available?

When they're ready. ⍩

[JH4C]

14 hours ago, Shadowmage said:

Certainly not the same as having the textures authored for legacy shaders, but gives acceptable results.

Legacy is in foreground, PBR version in background.

As someone who is very unlikely to install TR/TRR, I'd be more than happy with that Legacy look on any new parts packs. The repulsor looks new and shiny enough to reflect its experimental technology status while still fitting the Stock aesthetic that, honestly, I quite like. Nice work!

[Shadowmage]

1 hour ago, JH4C said:

As someone who is very unlikely to install TR/TRR

Anything that I do will actually use Textures Unlimited for its replacement shaders, which is much better for performance than TR/TRR -- it adds all the shiny, at almost no overhead (and actually much -better- graphics than TR/TRR, if you are into that sort of thing).  The only downside is that it does not really support DX9 (rather Unity doesn't really support DX9), so some functions are unavailable or incorrect when using the older API -- so in order to make full use of it, one needs to use either DX11 or OpenGL mode.

Likely will be using TU either way, as it is the provider of even the legacy shaders.  So in the end -- there will be no performance difference between 'shiny' and 'old' textures -- TU will be present either way, its just a 'pick your preference' thing.

[Shadowmage]

11 hours ago, Catatau_27 said:

Will this mod be updated to 1.4.5 along these new textures?

The mod already works fine in 1.4.5, so I'm not sure what you are referring to?

 

11 hours ago, 0111narwhalz said:

When they're ready. ⍩

Pretty much, exactly that

[JH4C]

7 hours ago, Shadowmage said:

Anything that I do will actually use Textures Unlimited for its replacement shaders, which is much better for performance than TR/TRR -- it adds all the shiny, at almost no overhead (and actually much -better- graphics than TR/TRR, if you are into that sort of thing).  The only downside is that it does not really support DX9 (rather Unity doesn't really support DX9), so some functions are unavailable or incorrect when using the older API -- so in order to make full use of it, one needs to use either DX11 or OpenGL mode.

Likely will be using TU either way, as it is the provider of even the legacy shaders.  So in the end -- there will be no performance difference between 'shiny' and 'old' textures -- TU will be present either way, its just a 'pick your preference' thing.

Ah cool, I was misunderstanding - easy to do with so many similar Texture-named mods  I'm on a Mac so I'm OpenGL, so I shall investigate TU post-haste!

[Shadowmage]

Working on getting TU updated for KSP 1.5 -- nearly finished, need to do testing and documentation.  Once that is finished up and released, I can return to working on updating KF textures and models.

As stock now includes PBR shaders, I will be making the move to use TU and PBR shaders as the default.  If for some reason someone does not want the updated graphics (or can't due to limited hardware)... they are free to download and use the existing KF releases (which will continue to function just fine in KSP 1.5+).  The option will exist to patch the new KF models to use legacy shaders, but I am not going to be writing or include any such patches in the release, and will not be offering any support for it.

This is also going to be the answer to backwards compatibility -- if you require back-compat for any reason -- download and use the older versions of the mod.  The newer versions (for KSP 1.5+) will not be backwards compatible, and no amount of 'find and replace' in your craft files will be able to fix the changes (such as attach-node position, COM, config-balance, and model scale and orientation changes; far more than just a part name).

Hopefully will only be a few weeks until the model/texture revamp is done.  I think I had 5 of ~20 parts in a 'finished' state before KSP1.5 dropped, with the remaining parts (hopefully) only needing a few hours each to finish up.  Once I get a bit further along I'll start uploading it all to the /dev branch for feedback/testing purposes, but won't be packing or publishing any releases until it is all finished.

[Briso]

I have arise problems with wheels Kerbal Foundries. On Kerbal and other planets everything is fine, but in space I start the glitches every 3 seconds. Can someone faced what to do ?

[0111narwhalz]

16 minutes ago, Briso said:

I have arise problems with wheels Kerbal Foundries. On Kerbal and other planets everything is fine, but in space I start the glitches every 3 seconds. Can someone faced what to do ?

Could you elaborate on what the glitch looks like? Screenshots may be helpful as well.

[Briso]

8 hours ago, 0111narwhalz said:

Could you elaborate on what the glitch looks like? Screenshots may be helpful as well.

With wheels 3 fps, without them all normally (in space).

[0111narwhalz]

2 minutes ago, Briso said:

[snip]

With wheels 3 fps, without them all normally (in space).

I see. Have you looked for errors in your KSP.log file or in the ingame console? If you don't find anything obvious, put the log file in a Pastebin or upload it somewhere and I'll take a look at it.

[Briso]

36 minutes ago, 0111narwhalz said:

I see. Have you looked for errors in your KSP.log file or in the ingame console? If you don't find anything obvious, put the log file in a Pastebin or upload it somewhere and I'll take a look at it.

You need a full ksp.log (is it very large) ?

[0111narwhalz]

4 minutes ago, Briso said:

You need a full ksp.log (is it very large) ?

That would be optimal. It is very important that you do not paste it directly into the forums here, as that will cause problems to the forums; instead, put it somewhere else and then link to it.

If possible, please do the absolute minimum of activity to cause the problem. This will minimize the size of the log and make it easier for me to find your problem. Reducing the number of mods (I note that you have several in your toolbar in the video) will also help for this.