Erosion multiplayer suggestion

[totorox]

JLV said he can't activate erosion in multiplayer, for synch problems. And I heard next MXvsATV will be like a sim with erosion system.(leechers;)
So what about another erosion system, like a morphing from a 0 bump track mesh to a 100% bumpy mesh ? So only the % state must be synched. So just a displacement map could be ok. Or a duplicated mesh from original track, modified to be bumpy state, and a morphing between them. It's not as real as the original system but i think doable.

[jlv]

My guess is MVA will just let it get out of sync. It is possible to synchronize it if you're willing to accept the extra bandwidth and complexity. I tend to think this is a feature that sounds better than it really is. 5 laps with 10 riders will barely change the track at all. It would make more sense to have 1st and 2nd moto versions of the same track.

[JohnnyMac]

Honestly Ive never even tried your erosion system jlv, but what if...you keep track of all the erosion that *would* happen for first race (dont apply it), and then apply all that erosion data for the second moto, before race, while track is loading?

Im sure its easier said then done, but just a thought.

[DJ99X]

Ever since the decal system was implemented, there has been a flaw with the erosion feature, as you can no longer update the track's shading without the game having to update all the textures for the track, which cannot be done effectively in real time. So, when you use erosion now, all the holes appear invisible, until you update the shading in editor. Thus, the erosion feature is useless now, and thats in single player.

Your idea would be good though johnny mac, but I would imagine it would be a fair bit of work. The server would have to send everyone a new terrain, which could take too long depending on everyone's internet speed.

[jlv]

That's fixable. I could put the shading in a separate texture to avoid invalidating the terrain textures. My main concern is that it adds a lot of complexity for something that's going to be hard to even notice if it's done realistically.

[Voutare]

I think having a 'lap' terrain system would be pretty boss.

Have them terrainlap1 terrainlap2, and they would get progressively more rough and rutted as the race goes on, but I'm not sure how you could manage to change a terrain on the fly while your riding it.

[totorox]

If you can't do a morphing, a displacement layer progressively (lap based) applyed by ajusting effect percentage could not be a good solution ?
Or after each pilot passage (path based or a low resolution grid (for synch) pass to modify this effect layer (square 2x2 meter with soft border to do soft transition (like painting brush on photoshop with transparency layer).
Like that , even if synch is not perfect, final state (100%) will be always the same, and modders can control how final state will be.
Not as real of your original erosion, but could be more fine and details made by moders like 'ornieres' (long holes made by tyres:x). and if nobody's passed on a part, it will be clean. You can play with erosion speed too, for sand parts or mud, stones, etc.

[Redbull]

Well i was messing around with erosion the other day and the area it takes away is too much it should only be able 2 tire widths or less imo. Also you should only be able to make ruts up to the axles or hubs. What if the maps had a dynamic lighting so the shadows would cast on the ruts cause they are very hard to see.

[yzmxer608]

You can get skinnier ruts if you have a higher res disp map. I think if you used a high res disp with POV-Ray PNG (mxs supports POV-Ray right) and a higher erosion rate (like 20) it would be cool for sand and mud tracks.

[DJ99X]

16-bit grayscale images are used in the game. It could adjust the maps height just as well as pov-ray can.

[yzmxer608]

Pov ray's have way more height definition though. That would get rid of the random jaggies on small ruts and berms. I guess it's not absolutely needed, but I think it could make parts of the track look better.

[DJ99X]

But this game uses floating point values for its colour. Pure white is (1.00000 1.00000 1.00000). I think thats how many decimal values the game can use, so the game can produce pretty precise height changes

[yzmxer608]

Ah I didn't know that. Pretty cool thing, thanks for letting me know .

[jlv]

Internally this game stores the heights as single precision floating point. On disk it's 16 bits ranging from the lowest point to the highest point on the track.

Floating point precision is a little complicated. Basically, every time the number doubles your precision is reduced by half. So for a number between 1 and 2, your precision is 1/8388608. Between 2 and 4, it's 1/4194304. 4-8 is 1/2097152 and so on.

[DJ99X]

Wow, that does sound complicated