so, ill try to make it simple. first off i dont have that much of expierence on computers so i cant tell would this be really hard on computer or what, but my idea is that....
there would be couple inches of loose gravel on the rallycross track, so bacicly it would be modelled and physiced to respond to how you move on it and how much do you for exapmle press gas. this would solve many things, wed get croovy marks on the road, particles and really good looking gravel. so heres an example, you go to a turn and go trough it sideways with a rwd. then you see that it leaves groowy marks to where its rear tyres has gone depending how fast and grippy the tire has rolled, so the gravel could move around and shape the way you drive on it. i really dont know how this well would it work or how hard its on your comp(im afraid that it will be too hard for your pc) but who knows, maybe in the future

Deformable surfaces have been suggested before, and would be nice. Making it actually look right isn't so hard if you go with the shaders option. Not possible in the current LFS engine, but likely to be in a later one.

The problem (as mentioned in the other thread which I'm too lazy to search for) comes with making it affect the car's handling. You need to change the surface layer of the track to model the bumps and grooves. And even though it's invisible, making it work in a way that's believable and realistic (and wouldn't cause issues with the physics system) is a pain.

Wouldn't be able to do it with the current DX8 engine, but Parallax-mapping with DX9 and above could be used pretty easily (as it's just a case of altering grey values on a bitmap texture) to make a beautiful deformable surface without the need for excessive numbers of polygons to get the detail or the need to manipulate the mesh itself.

The contact mesh would need to be altered though, otherwise it's pretty but also jsut aesthetic. Sega Rally did a pretty good job of the deformable surfaces affecting handling, but since it's an arcade game it's hard to tell if it's accurate enough to be used in a proper simulation.

Just have something in the collision detection that uses heightAboveMesh + extraDeterminedFromHeightmap instead of just the height of the wheel above the bare polygons. It'd use a few extra CPU cycles, but they'd be well spent.

I doubt you could use a simple heightmap for this though. To cover an entire track in reasonable resolution it'd have to be absolutely huge. More reasonable would probably be to record all tire/ground interaction for a given track sector, not unlike what LFS does with skidmarks currently, and then just re-apply the forces the track surface has been under as you drive past. You can still use a height map for the actual calculations/visual effects of course, but you'd regenerate one or two smaller maps as you move around instead of using one huge one covering the entire track.

I just worked it out.

Assuming a pixel density of 2cm/pixel gives roughly a 512x512 bitmap for a 10m wide (about the widest you'd need), 10m long section of track. A 4km track would need 400 of these (or a bitmap 400 times as long). In 4bit colour (16 shades of grey) that's 1.6GB to store the bitmap.


Not implausible in a few years though.

Also consider that you need more parameters than "height" in order to do a proper surface simulation. Things like density and moisture of the surface can also play a huge part, so you'd need some bits for that stuff as well.

Is there nothing in the DX or graphic driver APIs that would reduce the need for storing very similar or identical pixels/bitmaps/meshes/etc in such a resource intensive way? Like cloning of some sort, based on some parameters specific to that (group of) pixels/etc

(I have no idea, never even looked at graphics programming, don't shoot the noob )

Quote from wien :

Also consider that you need more parameters than "height" in order to do a proper surface simulation. Things like density and moisture of the surface can also play a huge part, so you'd need some bits for that stuff as well.

Things like that wouldn't need so high a pixel desity though and they wouldn't need to be kept in the same bitmap - things like moisture could get away with maybe 0.5m/pixel, temperature even larger. You'd need a higher precision in the value for each pixel for temperature though.

Quote from NotAnIllusion :

Is there nothing in the DX or graphic driver APIs that would reduce the need for storing very similar or identical pixels/bitmaps/meshes/etc in such a resource intensive way? Like cloning of some sort, based on some parameters specific to that (group of) pixels/etc

(I have no idea, never even looked at graphics programming, don't shoot the noob )

Well there's different types of texture compression, but when you also need to process the texture on the CPU I'm not sure how well they'd work. Either way they can't perform magic. You need unique data for the entire surface of the track however you look at it, so the dataset will be huge.

But of course, there are lots of ways you could do this. The one I mentioned is one way. I'm sure actual smart people (like Scawen) could come up with something better. In general though its a memory/CPU tradeoff. You can save memory by using clever data structures, compression and algorithms, but this will usually require more CPU to compensate. Striking the right balance is critical.

Jeez, now I want to sit down and give this a try... Probably need an actual sim first though.

Quote from Crashgate3 :

Things like that wouldn't need so high a pixel desity though and they wouldn't need to be kept in the same bitmap

Good point. Some of this data doesn't require nearly the same resolution. It's still more data than just height though.

Quote from wien :

More reasonable would probably be to record all tire/ground interaction for a given track sector, not unlike what LFS does with skidmarks currently, and then just re-apply the forces the track surface has been under as you drive past. You can still use a height map for the actual calculations/visual effects of course, but you'd regenerate one or two smaller maps as you move around instead of using one huge one covering the entire track.

i doubt that this is feasible in any way for a race longer than say 3 laps as the requirements of calculating the effects of say 20 cars with 4 wheels each for 30 laps over and over again would quickly baloon into something thats just not doable
and since those have to be applied in the correct order of time its impossible to parallelise too

also i rather doubt that the amount of data to store wheel position wheel forces and wheel rotation lap after lap will be any less than for a detailed height map if you look at races of realistic length and number of drivers



also theres a far more fundamental problem which is that lfs' tyres arent three dimensional (currently lets see what the new tyre model brings to the table)
essentially the current physical model of the tyre is a one dimensional line from the wheel hub to the bottom part of the tyre (bottom in car coordinates btw) which is very evident when you slowly drive towards a steep curb or do a wheelie and the tyre just disappears into the ground
eg as in this video http://www.youtube.com/watch?v=AdvBtFTqths

this is mostly the reason why lfs has trouble with steep inclines (eg the infamous bl chicane exit curb) and also why its impossible to go around corners initial d style by dropping the inside wheels into a ditch

Quote from wien :

Jeez, now I want to sit down and give this a try... Probably need an actual sim first though.

rigs of rods has recently gone open source and has tyres that are a lot more 3d than those in lfs

Quote from Shotglass :

i doubt that this is feasible in any way for a race longer than say 3 laps as the requirements of calculating the effects of say 20 cars with 4 wheels each for 30 laps over and over again would quickly baloon into something thats just not doable
and since those have to be applied in the correct order of time its impossible to parallelise too

All good points. You'd obviously have to fade out older "tracks" as the race progresses. Possibly combine the old ones into larger and more sparsely sampled tracks as the simulation runs. It won't be anywhere near 100% accurate of course, but it may be good enough. Storing 50+ laps and playing them back as you go is obviously unreasonable.

And while you're right that it'd be hard to parallelise the data generation itself, you could very easily throw the whole process off to another core. Also, by tiling "upcoming" track sectors you could easily have many cores working simultaneously to generate the data you will need in the near future.

Quote from Shotglass :

also i rather doubt that the amount of data to store wheel position wheel forces and wheel rotation lap after lap will be any less than for a detailed height map if you look at races of realistic length and number of drivers

Oh it'd be a huge chunk of data, no doubt about it, but my initial gut feel is that it'd still be cheaper than a giant texture containing the required data. Especially across the longer tracks. You can always reduce the sample frequency of the tyre-tracks and interpolate if it becomes a problem as well.

Hard to say either way without experimenting though. Anyone know how the Sega Rally game did this? They even did it on the consoles, so they'd have to do a huge amount of streaming in and out of memory if they used a monolithic texture.

Quote from Shotglass :

also theres a far more fundamental problem which is that lfs' tyres arent three dimensional (currently lets see what the new tyre model brings to the table)

I don't see that as a problem to be honest. As I imagine it you'd store simple point samples with load information and probably wheel speed/angle. Based on that it should be possible to reasonably approximate what the tyre was doing at the time. At least come close enough. Or am I forgetting something crucial?

Quote from Shotglass :

rigs of rods has recently gone open source and has tyres that are a lot more 3d than those in lfs

Yeah, that could be interesting to look into I guess. Never actually looked at that code. It's Not Invented Here though (Oh the horror!)

Quote from wien :

They even did it on the consoles, so they'd have to do a huge amount of streaming in and out of memory if they used a monolithic texture.

keep in mind that consoles usually have a shared ram achitecture between the cpu and gpu with ram thats magnitudes faster than what you have on pcs

Quote :

Or am I forgetting something crucial?

oh yes... one dimensional single contact tyres cant simulate grooves in the driving surface

Quote from Shotglass :

keep in mind that consoles usually have a shared ram achitecture between the cpu and gpu with ram thats magnitudes faster than what you have on pcs

Oh sure, what I was worrying about was grand total lack of space. You'd have to stream to/from disk. Some Xboxes don't even have disks, which is why I was wondering how Sega did it...

Quote from Shotglass :

oh yes... one dimensional single contact tyres cant simulate grooves in the driving surface

Well the shape of the tyre is known, so as long as you have a one dimensional load sample and tyre angle, you can easily deduce how much of the surface to displace, width of the groove etc.

EDIT: Wait, did I misunderstand your point? Did you mean the tyres can't react properly to the ruts in the surface? That's a very good point I completely missed, which is par for the course for me .

Quote from wien :

Did you mean the tyres can't react properly to the ruts in the surface?

exactly

the ruts would be similar to the old blackwood chicane curb
youd expect it to slingshot you round the corner initial d style but what it actually does is turn you belly up

Ah, then we're on the same page. With the current LFS tyre model that wouldn't work very well, no. Adding this stuff would probably require a major overhaul of the model anyway though, so I don't know how relevant it would be. But yeah, it's something that would have to be fixed.

It will be exciting to see if the new tyre model will deliver any improvements here.

Quote from wien :

...which is why I was wondering how Sega did it...

According to this video (~4:10) they use "a 6 cm polygon mesh". So they're actually deforming the track mesh itself instead of overlaying a texture then, but same general idea I guess. Seems like they're using relatively short tracks though, so that probably helps a bit. Still surprised they can fit it all in the Xbox' memory (not having done any math on it to get an actual number).

Quote from wien :

According to this video (~4:10) they use "a 6 cm polygon mesh". So they're actually deforming the track mesh itself instead of overlaying a texture then, but same general idea I guess. Seems like they're using relatively short tracks though, so that probably helps a bit. Still surprised they can fit it all in the Xbox' memory (not having done any math on it to get an actual number).

judging by the looks of it it seems like its a simple 1 bit deformation (ie theres no difference in the depth of these grooves)
so assuming the track is 6m wide thats 100 bit across and at a length of 5km that works out as ~60kb worth of information

now if you gave all these nodes an accuracy of 16 bit (ie 65000 different levels of deformation) youd still be under one megabyte worth of data

or if the nordschleife were covered in mud and 10m wide and you wanted a 64 bit 1cm mesh youd still only need about 160mb

Quote from Shotglass :

also theres a far more fundamental problem which is that lfs' tyres arent three dimensional (currently lets see what the new tyre model brings to the table)
essentially the current physical model of the tyre is a one dimensional line from the wheel hub to the bottom part of the tyre (bottom in car coordinates btw) which is very evident when you slowly drive towards a steep curb or do a wheelie and the tyre just disappears into the ground
eg as in this video http://www.youtube.com/watch?v=AdvBtFTqths

I'm only aware of one game that uses more than a simple line collision for wheel collision detection and positioning. I had the exact same bug when pulling wheelies on the bikes in the game I'm working on but this was easily fixed by changing the maths that position the wheel after the line collision position has been obtained. I just needed to rethink the correct vector and it looks like LFS is doing the exact same mistake we used to.

Well, that's it then. No fancy tricks required. 16 bit per vertex should be enough to store both height, density and moisture I reckon. Those parameters combined with global variables like temperature should give you a huge variation in possible conditions.

Guess I got thrown off by the 1.6GB estimate earlier in the thread, though that was obviously a much denser mesh/texture.

You'd need more info than this per vertex of course, but that could easily be deduced from a lower res polygon mesh and then applying the height as an offset from that as you render the thing. This is easy to do using stream out in a geometry shader or using DX11 tessellation, but it probably wouldn't be too bad to do it on the CPU either on lesser hardware.

Quote from Bob Smith :

I'm only aware of one game that uses more than a simple line collision for wheel collision detection and positioning.

well theres x motor racing a whole bunch of off road sims and ror which uses neither the line nor the 3d wheel model

Quote from wien :

Guess I got thrown off by the 1.6GB estimate earlier in the thread, though that was obviously a much denser mesh/texture.

nah it was just calculated by someone whos obviously unable to deal with something as complicated as a calculator

on a related topic my calculations were all wrong as well
so the 1 bit mesh for the 6m wide 5000m track would take ~1mb
if you up those nodes to 16 bit accuracy youd get ~16mb

as for the nordschleife... well that works out as 15.6gb

Quote from Shotglass :

or if the nordschleife were covered in mud and 10m wide and you wanted a 64 bit 1cm mesh youd still only need about 160mb

Hmm, you sure about this one? I just did the math, and I'm getting 15.5 GB (1000 * 100 vertices pr. meter * 20810 metres * 8 bytes.)

EDIT: Foiled.

EDIT2: But to take a relevant example then. Aston GP (?) at 8.8km, 10 meters wide with a 5cm mesh and 16 bit per vertex would result in a 67MB dataset. Hardly unreasonable. The gravel tracks in LFS are obviously shorter, but the same model could probably be used for weather effects on tarmac as well.

i wish there was loose gravel layed out in a rally stage

If you want a compromise between cpu and memory why not using culing method? While driving part of the track data will be loaded (like it's done now) as well as deformation data. So even if you need a huge file containing the data, it wouldn't take a lot of space in memory.

The norschleif example is a bit silly imo.

Another approach would be to have only spaced points of deformation with a radius of action. So with the 3D coordination you just need to join a radius value wich is will result in a gain of space taken by all this data. I recognize that the calculation of the deformation itself will be more complicated because, to be effective, each tyres should have a radius of action too.