Different surfaces?

[slowDan]

I've been playing around trying to get the squeal sound to stop when the car moves off the track and onto grass. I haven't quite succeeded yet, but I have managed to figure out a way to make the squeal stop when the car turns upside down. Which is a start!

I've noticed though, that there seems to be no way to figure out what sort of surface the wheel is on, apart from checking if its on a Bezier patch rather than a model. (The only other thing I can think of is finding the bump and resistance parameters from the track model?) This obviously makes it tricky to play a different sound for grass and gravel for example. Are there any plans to add another way of flagging these kind of changes, or have I missed something?

[joevenzon]

I've noticed though, that there seems to be no way to figure out what sort of surface the wheel is on, apart from checking if its on a Bezier patch rather than a model. (The only other thing I can think of is finding the bump and resistance parameters from the track model?) This obviously makes it tricky to play a different sound for grass and gravel for example. Are there any plans to add another way of flagging these kind of changes, or have I missed something?

I've got issue 1 and issue 24 open which rely on a way to determine the driving surface. What I was thinking is, if it's a bezier patch, assume it's asphalt, otherwise if it's a collision with models, check the TRACK_OBJECT object to get the material type. Currently the TRACK_OBJECT doesn't have a material type, but this can be added by adding a flag for each track object in its list.txt file that defines the surface type (the listedit tool makes this easy enough). So, you are pretty much on the right track.

[slowDan]

I've got my little bit of code sorted for stopping the squeal sounds when the wheels leave the ground. I've diffed and saved the resulting files here. Let me know if I've done anything wrong, I'm not entirely sure what I'm up to! :lol:

Its a fairly simple integer array added to the car (one for each wheel). If the wheel collision check fails it sets the flag. When the sounds update if the flag is on the gain is set to 0.0. I made the flag an int so that if and when material types get added the int can represent the material the wheel is currently on.

[joevenzon]

Cool, I appreciate the work. I made the changes in SVN R2404. The only things I did differently were that 1) I put the surface type inside the CARCONTACTPROPERTIES in cardynamics.h and used that to remember what surface the wheel was last on instead of the int array in car.h and 2) I made the CAR::GetTireSquealAmount function return zero if the wheel isn't on the road, because this feeds the sound as well as the "tire smoke" particle generation. Please test it out and make sure that I transcribed things correctly.

If you're interested in extending this to different driving surfaces:
1) add more types to carsurfacetype.h
2) add a SURFACE::CARSURFACETYPE variable to the TRACK_OBJECT class
3) do up a test track with different surface tags and make the track loading code read it (I can provide more detail / help with this)
4) have GAME::UpdateCarCollisions pass the surface from the track object to the car's SetWheelContactProperties function
5) add sound sources for tires squealing on different surfaces to car.h
6) make sure the sounds get loaded in game.cpp and car.cpp (there's a sound for driving on dirt from the TORCS project that we could probably use)
7) make CAR::UpdateSounds use the new sounds depending on the driving surface

PM me if you're interested and I'll set you up with SVN access.

[slowDan]

Glad to help out. I'll give it a proper test as soon as I can.

If you're interested in extending this to different driving surfaces:

I'll give it a go. Might take a little while but I'll get around to it soon!

[joevenzon]

I'll give it a go. Might take a little while but I'll get around to it soon!

I updated the "rouen" track with a new parameter for surface type and marked up the grass objects with the grass surface type, so it's ready as a test track. No rush; there's not really a schedule or anything.

[alex25]

I updated the "rouen" track with a new parameter for surface type and marked up the grass objects with the grass surface type, so it's ready as a test track. No rush; there's not really a schedule or anything.

hmm, at this rate we won't be able to keep track of all those parameters. i think this is the right time to do a bit of restructuring. now that we are we introducing support for surfaces, can we move the friction coefficients, drag, bump wavelength and amplitude (did i miss anything?) to a per surface value in a separate file (something along the lines of coefficients.txt (response, physics?) which will look something like:

Code:

[surface] [index]
{
  coeff_1
  coeff_2
  .
  .
  .
  coeff_n
}
[next_surface]
{
}
etc.

that will probably simplify things quite a bit. or at least i think so.

--alex--

[joevenzon]

a per surface value in a separate file (something along the lines of coefficients.txt (response, physics?)

Would this file be per track or for the whole game? I can see pros and cons either way, but I'm kind of leaning toward the one file for the whole game approach.

[alex25]

Would this file be per track or for the whole game? I can see pros and cons either way, but I'm kind of leaning toward the one file for the whole game approach.

i would go with a per track file. it would be easy enough to copy the file between tracks and this way you would have a lot more flexibility. some tracks are bumpier, more slippery, etc. than others.

--alex--

[FFuser]

What about a global game file that is loaded first and then (if it exists) the track file. If entries with the same name exists in the latter just override them.

Then you don't have to copy the file 50 times and apply change 50 times but you have the full flexibility.

Of course this is a little harder to implement...

[slowDan]

That sounds like the way to go to me. Someone is always going to come up with a new surface to drive on but it would be handy to have the basics covered.

[alex25]

What about a global game file that is loaded first and then (if it exists) the track file. If entries with the same name exists in the latter just override them.

for any one track there could exist more than one grass or asphalt surface. how would you handle that in a general way? my favourite is neurburgring where i ended up defining quite a few surfaces for the track itself (different bumpiness, friction coefficients, etc.) not to mention the side roads, pit lanes, escape lanes and so on. every track that i worked on has multiple materials for any type of surface. personally i think that by putting everything into one file we would lose a lot of flexibility when it comes to making tracks. tracks are just as different from each other as are cars. an engine file for an F1 car won't be really useful to a fiat 500. a "road" surface for a F1 circuit is completely different from a "road" surface for dirt racing for example (even though we don't have any dirt tracks yet) or even a regular road.

--alex--

[FFuser]

What about a global game file that is loaded first and then (if it exists) the track file. If entries with the same name exists in the latter just override them.

for any one track there could exist more than one grass or asphalt surface. how would you handle that in a general way?....

--alex--

I don't know what current system is, but it seems that my system is the best of the 2 worlds (one global file, or one file per track). Of course I don't know anything about the format.

[joevenzon]

How about this:
* the objects/list.txt file calls out a surface type id for each object (like "road" or "grass-01" or whatever)
* there is a global file that defines parameters for some basic surfaces as some basic IDs (like "grass")
* each track can optionally define its own list of parameters, and any surface IDs that overlap with the global file get overwritten

[FFuser]

How about this:
* the objects/list.txt file calls out a surface type id for each object (like "road" or "grass-01" or whatever)
* there is a global file that defines parameters for some basic surfaces as some basic IDs (like "grass")
* each track can optionally define its own list of parameters, and any surface IDs that overlap with the global file get overwritten

Thats more or less what I had in mind...

So seems ok for me