this is the situation. The most crucial part defining the behaviour of any vehicle is the interaction between the tyres and the ground. Accuracy in the determination of the contact point and local geometry is very important so if the road is modelled as a polygonal mesh the effect would be somewhat like trying to ride on a cobbstone paved street. Now some of the free simulators I've taken a look at seem to take that approach and then later augment the road with some sort of surface description to help out in smoothing the surface but I can only see that as a workaround. The road is therefore described as a set of segments with given (possibly varying) width, curvature, slope and bank. This description is used to calculate pretty (although not entirely) accurate local collision geometry and it can also be used to calculate a mesh. So I have a little script which can export a mesh into a format suitable for importing into Blender. The only problem is now to fill in the rest. This is the problem. Read on if you're interested in my (failed) approach to solving it.
Although I have some idea of how to use Blender, being a programmer I tried a different approach. I sampled the road height at regular intervals to create a heightfield for the road area and then used GRASS, a free GIS program (which I had used before for Aviation) to get it to fill in the blanks sort of with some interpolation method. This is needed in order to fill in missing data areas from sattelite elevation maps so there are specialised tools in GRASS for that. It worked pretty well as you can see in the videos but it just doesn't look like a track and it is also very difficult to align the resulting mesh (which is triangulated by Techne on the fly and with varying level of detail) with the road, make sure that the earth doesn't stick out of it, put additional features like builidings, tyre walls, curbs etc. and texture it properly. This is also evident in the videos. On the other hand I see something like this: http://www.youtube.com/watch?v=zn0nqvr-vuo which only uses 3000 polys and looks a lot better than what I get for the 10000 polys in my track mesh so I think I may need a different approach. On the other hand the technique might be useful in order to create a mesh for the surrounding terrain which can then be further edited in Blender so that's why I'm mentioning it.
I also use a second mesh which I take straight from a satellite elevation and imagery for some area (these are freely available and with great resolution, for the USA at least) to use as a background. There's a problem with hiding the seams between the local scenery and the more distant one but with proper use of occluding geometry such as trees it could work pretty well. This technique should be at least as good as the usual mountain range and sky wallpaper used in most cases. The sky is also taken care of by Techne and is procedurally generated according to sun position and atmospheric conditions. So what I ideally need is a detailed if possible model of the local scenery of the Laguna Seca Raceway or some typical track maybe and for which the road is already there (although it can easily be adjusted and regenerated if necessary). What I'll settle with is anything better than what I already have :). The pysics and gameplay work so well though that it'd be really great if we had some great graphics to match. It would be a game unique not only in the free but also in the proprietary world. At least as far as I know, most motorcycle racers are pretty unrealistic. They have to be if you're to drive a motorcycle with a keyboard or gamepad.
thanks for the offer to help out. Actually what the game most needs right now is a proper track. I mean the scenery as the road is already taken care of at least for one track. I don't mean that you have to do that of course I'm just making this comment since you talked about getting the project started.
Regarding the motorcycle model now which you're interested in trying to model. This would have a couple of uses: one is for external shots during replays and of course for other motorcycles on the track when the game supports multiplayer modes. This requires the whole motorcycle and the rider. The other is for an onboard view. Now assuming that you wouldn't want a bunch of plastic blocking most of your view the parts that will actually be visible from such an onboard camera would probably be the windscreen and part of the nose fairing, part of the instrument panel and maybe part of the top yoke. Its a little hard to be sure at what would be the bare minimum without trying it out and seeing what works best. You can get an idea from the infinity of videos available on YouTube such as this: http://www.youtube.com/watch?v=bKzsCI2o8gA. An even better one although not real-life is this one which seems to show what would be visible from a usuable on-board cam: http://www.youtube.com/watch?v=nGKXxEIOfcM. The instrument panel itself is actually pretty simple on modern race bikes and usually just includes an analogue RPM meter and a digital display. The physics model is based on data measured from a GSXR-1000 K1 bike so it would be best for the graphics to match but you can model anything in the same category if you find it more convenient. You can no doubt find countless reference images online.
I have no particular concerns about polygon count other of course than that it should ideally be kept as low as possible while maintaining decent quality. But there's no reason to keep it very low on the motorcycle given that it'll be in front of your face most of the time. It would probably make more sense to cut back on the scenery polys. You can maybe have a look around at the available games to see what they're doing.
Hello p0ss,
this is the situation. The most crucial part defining the behaviour of any vehicle is the interaction between the tyres and the ground. Accuracy in the determination of the contact point and local geometry is very important so if the road is modelled as a polygonal mesh the effect would be somewhat like trying to ride on a cobbstone paved street. Now some of the free simulators I've taken a look at seem to take that approach and then later augment the road with some sort of surface description to help out in smoothing the surface but I can only see that as a workaround. The road is therefore described as a set of segments with given (possibly varying) width, curvature, slope and bank. This description is used to calculate pretty (although not entirely) accurate local collision geometry and it can also be used to calculate a mesh. So I have a little script which can export a mesh into a format suitable for importing into Blender. The only problem is now to fill in the rest. This is the problem. Read on if you're interested in my (failed) approach to solving it.
Although I have some idea of how to use Blender, being a programmer I tried a different approach. I sampled the road height at regular intervals to create a heightfield for the road area and then used GRASS, a free GIS program (which I had used before for Aviation) to get it to fill in the blanks sort of with some interpolation method. This is needed in order to fill in missing data areas from sattelite elevation maps so there are specialised tools in GRASS for that. It worked pretty well as you can see in the videos but it just doesn't look like a track and it is also very difficult to align the resulting mesh (which is triangulated by Techne on the fly and with varying level of detail) with the road, make sure that the earth doesn't stick out of it, put additional features like builidings, tyre walls, curbs etc. and texture it properly. This is also evident in the videos. On the other hand I see something like this: http://www.youtube.com/watch?v=zn0nqvr-vuo which only uses 3000 polys and looks a lot better than what I get for the 10000 polys in my track mesh so I think I may need a different approach. On the other hand the technique might be useful in order to create a mesh for the surrounding terrain which can then be further edited in Blender so that's why I'm mentioning it.
I also use a second mesh which I take straight from a satellite elevation and imagery for some area (these are freely available and with great resolution, for the USA at least) to use as a background. There's a problem with hiding the seams between the local scenery and the more distant one but with proper use of occluding geometry such as trees it could work pretty well. This technique should be at least as good as the usual mountain range and sky wallpaper used in most cases. The sky is also taken care of by Techne and is procedurally generated according to sun position and atmospheric conditions. So what I ideally need is a detailed if possible model of the local scenery of the Laguna Seca Raceway or some typical track maybe and for which the road is already there (although it can easily be adjusted and regenerated if necessary). What I'll settle with is anything better than what I already have :). The pysics and gameplay work so well though that it'd be really great if we had some great graphics to match. It would be a game unique not only in the free but also in the proprietary world. At least as far as I know, most motorcycle racers are pretty unrealistic. They have to be if you're to drive a motorcycle with a keyboard or gamepad.
Hello John,
thanks for the offer to help out. Actually what the game most needs right now is a proper track. I mean the scenery as the road is already taken care of at least for one track. I don't mean that you have to do that of course I'm just making this comment since you talked about getting the project started.
Regarding the motorcycle model now which you're interested in trying to model. This would have a couple of uses: one is for external shots during replays and of course for other motorcycles on the track when the game supports multiplayer modes. This requires the whole motorcycle and the rider. The other is for an onboard view. Now assuming that you wouldn't want a bunch of plastic blocking most of your view the parts that will actually be visible from such an onboard camera would probably be the windscreen and part of the nose fairing, part of the instrument panel and maybe part of the top yoke. Its a little hard to be sure at what would be the bare minimum without trying it out and seeing what works best. You can get an idea from the infinity of videos available on YouTube such as this: http://www.youtube.com/watch?v=bKzsCI2o8gA. An even better one although not real-life is this one which seems to show what would be visible from a usuable on-board cam: http://www.youtube.com/watch?v=nGKXxEIOfcM. The instrument panel itself is actually pretty simple on modern race bikes and usually just includes an analogue RPM meter and a digital display. The physics model is based on data measured from a GSXR-1000 K1 bike so it would be best for the graphics to match but you can model anything in the same category if you find it more convenient. You can no doubt find countless reference images online.
I have no particular concerns about polygon count other of course than that it should ideally be kept as low as possible while maintaining decent quality. But there's no reason to keep it very low on the motorcycle given that it'll be in front of your face most of the time. It would probably make more sense to cut back on the scenery polys. You can maybe have a look around at the available games to see what they're doing.
Anyway, let me know what you think.