the idea is to make skid marks not disapearing after time or race restart like they are now but keep them on track all the time till server gets restarted

and objects such as tyres and cones to be raplaced just after race restart, not after few seconds

i believe that this would add a good reality feeling

though make skid marks switchable on and off becouse this might eat alot of ram

Quote from e.M :

the idea is to make skid marks not disapearing after time or race restart like they are now but keep them on track all the time till server gets restarted

and objects such as tyres and cones to be raplaced just after race restart, not after few seconds

i believe that this would add a good reality feeling

though make skid marks switchable on and off becouse this might eat alot of ram

Lots of a lot of RAM...

But the objects would be nice, even in a on/off basis also, since it would give meaning to the existence of safety/pace cars...

I would like the skid marks to stay the whole Race, maybe I am wrong but they disappear as soon at a threashold of marks are reached

I doubt the RAM would be a big problem - it's more the tons and tons of transparent skidmark layers over each other that would kill render performance.

The dynamic objects are also not really resetted for performance reasons I believe (you could freeze them after they slow down enough to get them out of the physics loop again), but more because they usually serve a purpose of preventing track cutting. If the objects didn't reset then the track would usually be completely open to wanton cutting after lap 1.

The could 'bake' the skid marks into an additional texture layer over the track. And save/reload these textures. Which would add more video memory to the requirements, but it would be consistent, not adding to the rendering time, and not growing in size.

The main problem with rubber that stays on track permanently is the fact that eventually all, or most, of the track will be rubber marks and they wouldn't disappear. Even in real life the rubber marks fade and disappear with use/wear.

I don't think that'd be a sensible solution, tbh. Do you know how huge such a track-spanning texture in adequate resolution would be? Current tracks can be textured easily because it's basically the same textures repeated over and over, but baking those skidmarks into a single texture would result in a staggering amount of data, dwarfing the current texture load easily. Then it would really become a (video) RAM issue.

E: Oops, didn't read all you said. Loading and unloading those textures would get the requirements down to sane dimensions again, but would it really improve anything if you now constantly have to load and unload those textures over and over? Transferring textures between video RAM and normal RAM/HD isn't exactly fast.

I didn't mean loading/unloading on the fly, I was talking more for when you leave a track and come back. So, you were closer with the previous assumption of textures spanning the track, and you are completely correct, it would be large textures - depending on resolution. I didn't exactly mention negative side effects, just a thought. For a track like Fern Bay Club, Aston Cadet/Club and so on I think this would be reasonable, but certainly for tracks like Aston Grand Prix there would be a considerable surface area to cover. The other good thing though, is the memory for the texture could be something like 4bits, or at the highest of 8bits. The skid mark texture really only needs an alpha channel. Which would save considerable amounts of memory - so I do believe this is a plausible idea. Remember it would only span the track portion of the environment, certainly still a large area, no doubt. Also some texture streaming techniques could do this, requiring a bit of work and thought - certainty.

I know it would work on my card, but I am also quite sure it wouldn't work on the low-end cards that LFS supports at this time.

Considering what's possible (and what other games are doing) I always thought the current skid mark model was rather impressive.