Wheel tracks

[TanDeeJay]

As I've been driving rovers around the Mun, i thought it would be really cool if it was possible to have a mod that recorded wheel tracks. 

It should display all past wheel tracks when close enough to see them.

Of course if it can record wheel tracks, why not foot prints and takeoff/landing blast rings, which of course takeoff and landing would obliterate any tracks within the blast radius

  cheers,

John

Edited September 30, 2018 by TanDeeJay
Fixed auto corrected spelling of mun

[Vexillar]

Hi @TanDeeJay

This has been suggested a few times.  Yes, it would be great for visuals and immersion. 

But... the issue is that it is pretty difficult to implement - not so much from the coding side, but more to do with object management and memory use.  If you imagine that each footprint or metre of track is represented by an object placed on the surface, you'll start to see how tricky this could be, especially as we know about scene change / surface object jumpiness, terrain resolution height differences, ground tiling and a thousand other problems that would come up.

Maybe one day... who knows?

[linuxgurugamer]

11 hours ago, TanDeeJay said:

 

As I've been driving rovers around the Mum

 

You’ve been driving rovers around your Mum? What does she say about that?

 

Edited September 30, 2018 by linuxgurugamer

[TanDeeJay]

9 hours ago, linuxgurugamer said:

You’ve been driving rovers around your Mum? What does she say about that?

 

Argh stupid autocorrect... Fixed

[TanDeeJay]

10 hours ago, Vexillar said:

Hi @TanDeeJay

This has been suggested a few times.  Yes, it would be great for visuals and immersion. 

But... the issue is that it is pretty difficult to implement - not so much from the coding side, but more to do with object management and memory use.  If you imagine that each footprint or metre of track is represented by an object placed on the surface, you'll start to see how tricky this could be, especially as we know about scene change / surface object jumpiness, terrain resolution height differences, ground tiling and a thousand other problems that would come up.

Maybe one day... who knows?

I guess it is a case of havig a database with the right index. Games like WOW have databases full of local textures, but I suppose they are highly optimised and contain static data. A database of wheel tracks would be constantly being updated and therefore not necessarily stored in an efficient manner for querying

[JH4C]

2 hours ago, TanDeeJay said:

I guess it is a case of havig a database with the right index. Games like WOW have databases full of local textures, but I suppose they are highly optimised and contain static data. A database of wheel tracks would be constantly being updated and therefore not necessarily stored in an efficient manner for querying

WoW is a good example to compare against. I'm not sure/can't remember if your tracks are visible to anyone but yourself, but even if they are they're not persistent in anyone's game or on the server; there tends to be both a time and a distance, meaning that if you stand around for long enough you'll see them disappear, and if you walk far enough then your original tracks will also disappear, and these work in combination.

Tracks on an airless world don't have any way to easily handwave their evaporation in the same way as those in WoW would, or other bodies with atmospheres. If you want proper realism in this then you'll be keeping track of every step taken or X measure of distance transported across any and all bodies... That's gonna snowball very quickly, especially as any such data is currently and would probably continue to be stored in plain text, to allow it to be referenced by external entities.

[Mecripp]

18 minutes ago, JH4C said:

WoW is a good example to compare against. I'm not sure/can't remember if your tracks are visible to anyone but yourself, but even if they are they're not persistent in anyone's game or on the server; there tends to be both a time and a distance, meaning that if you stand around for long enough you'll see them disappear, and if you walk far enough then your original tracks will also disappear, and these work in combination.

Tracks on an airless world don't have any way to easily handwave their evaporation in the same way as those in WoW would, or other bodies with atmospheres. If you want proper realism in this then you'll be keeping track of every step taken or X measure of distance transported across any and all bodies... That's gonna snowball very quickly, especially as any such data is currently and would probably continue to be stored in plain text, to allow it to be referenced by external entities.

WOW is a good example ?????   Not really its on a server you login to a server that is keep data and sending it back KSP is just run on your PC  which doesn't really have the same power has there servers.

[Mecripp]

On ‎9‎/‎29‎/‎2018 at 8:34 PM, TanDeeJay said:

As I've been driving rovers around the Mun, i thought it would be really cool if it was possible to have a mod that recorded wheel tracks. 

It should display all past wheel tracks when close enough to see them.

Of course if it can record wheel tracks, why not foot prints and takeoff/landing blast rings, which of course takeoff and landing would obliterate any tracks within the blast radius

  cheers,

John

I think the closes your going to get is this mod 

 

[TanDeeJay]

All the local terrain and ground clutter, I believe is stored locally, and depending on your quality settings, the game engine renders what you see. But thinking about this, if your driving your rover at a mild 50m/s across the Mun that's 50 * number of wheels of data points per second that it needs to record. Assuming your recording 1 data point per linear meter per wheel... Which is going to add up very quickly.

I'll have a look at persistent trails. Thanks for that. 

[Thygrrr]

On 9/30/2018 at 2:12 PM, Vexillar said:

with object management and memory use.  If you imagine that each footprint or metre of track is represented by an object placed on the surface, you'll start to see how tricky this could be, especially as we know about scene change / surface object jumpiness, terrain resolution height differences, ground tiling and a thousand other problems that would come up.

I won't write this mod, but Unity 5 and up have a very decent TrailRenderer Component that is suitable for exactly this, and it would be just one Gameobject per wheel.

It would, however, be somewhat nonpersistent, i.e. there is a max length and time you could have, but it could be hundreds of meters if not some kilometers long.

As a nonphysical object, its overhead on the overall performance would be quite negligible.

Edited October 3, 2018 by Thygrrr

[Vexillar]

1 hour ago, Thygrrr said:

As a nonphysical object, its overhead on the overall performance would be quite negligible.

Bingo!  Nice one @Thygrrr Now all we need is a good modder...  

[Shadowmage]

2 hours ago, Thygrrr said:

I won't write this mod, but Unity 5 and up have a very decent TrailRenderer Component that is suitable for exactly this, and it would be just one Gameobject per wheel.

It would, however, be somewhat nonpersistent, i.e. there is a max length and time you could have, but it could be hundreds of meters if not some kilometers long.

As a nonphysical object, its overhead on the overall performance would be quite negligible.

While most of what you write is true, I don't think the TrailRenderer will work correctly for this use-case.  Notably, it renders the trail as a camera-facing billboard effect, rather than allowing the trail to be aligned to the plane of the surface.

(other than that issue, it seems to be almost exactly what would be needed)

The gist of why it would work is that it does not attempt to create any sort of 'database of tracks', but simply draws tracks at runtime based on movement (where the track data is simply an array of vertices that live inside of a single game-object; one object, one mesh, one renderer = not too bad for performance).  These are non-persistent -- if you went to the space center and returned to your vessel, the previous tracks would be gone.  This is the most common way to handle such 'decals' in games -- non-persistent; cache the data in memory only and dump it when the scene/models are unloaded -- it never hits the disk.

[Manwith Noname]

It has been done...

 

Edited October 3, 2018 by Manwith Noname

[TanDeeJay]

 ah ha! That is totally awesome!  Now I just have to figure out how to install it.

 

 

[Thygrrr]

On 10/3/2018 at 8:29 PM, Shadowmage said:

While most of what you write is true, I don't think the TrailRenderer will work correctly for this use-case.  Notably, it renders the trail as a camera-facing billboard effect, rather than allowing the trail to be aligned to the plane of the surface.

(other than that issue, it seems to be almost exactly what would be needed)

The documentation is outdated in that paragraph;  much like a LineRenderer Component , Trail Renderers can be anchored in the world (or whatever transform you parent them to).

Quote

Alignment

Set to View to make the Trail face the camera, or Local to align it based on the orientation of its Transform component.

As ou can choose your own material and thus shaders, you have very fine grained control over how these "particles" could look and orient themselves. Both do require some understanding of the KSP / Unity rendering path though, and I wonder how well it would work if every wheel had a trail, and trail generation would need to pause as soon as the wheel left the ground, etc.

Edited October 7, 2018 by Thygrrr

[Shadowmage]

59 minutes ago, Thygrrr said:

The documentation is outdated in that paragraph;  much like a LineRenderer Component , Trail Renderers can be anchored in the world (or whatever transform you parent them to).

As ou can choose your own material and thus shaders, you have very fine grained control over how these "particles" could look and orient themselves. Both do require some understanding of the KSP / Unity rendering path though, and I wonder how well it would work if every wheel had a trail, and trail generation would need to pause as soon as the wheel left the ground, etc.

Yay for outdated Unity documentation

Hmm... knowing that.... I might do some experiments wrt KerbalFoundries/KSPWheel, to see if I can use that component for some wheel-tracks as a built-in (alongside the existing dust effects and sounds; might as well get the whole package...).