Forums

Full Version: Thoughts on the track system
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
A few days ago Joe & I were chatting and he said something about the track system needing a lot of work. I agree and here are some things I'd like to see in VDrift track system if/when it gets revised.* support for intersections with other roads* support for loading modeled rails/fences from a file* the ability to move the rails out to not conform to the track in some places
Other things I'd like to see:* Support for custom terrain landscaping around the track (to easily create banked turns, built up shoulders, or a recessed road that cuts through a hill)* Support for roadways that don't sit on the terrain (for things like bridges)* Dirt roads (for rally racing)
joevenzon Wrote:* Support for custom terrain landscaping around the track (to easily create banked turns, built up shoulders, or a recessed road that cuts through a hill)
The more I think about this, the more I think that it would be best to have modeled tracks and maybe also terrains. This would give us total freedom in respect to environments. This way would also probably require the most work to make a track, but I think it might be the way most other games do it, which hints at the possibility of importing other games' tracks.
I think you're right (about other games using modelled tracks). The only problems I can see with that are:1) no dynamic LOD -- really kills the terrain detail and distance you can have2) i'm not sure how to do collision detection with a polygonal road in a way that wouldn't leave the road unplayably bumpy
Hmmm, I think this is an area where we can steal from TORCS. :wink: They have a pretty good track system and a good many tracks too. If we make our system like theirs we can use their tracks. They have a track editor too. I'm not sure how good it is, I've never used it...where their track editor lives.
ah, i dunnoi'll look at it more, and maybe we can borrow some ideasbut at first glance, their tracks seem to have some features over vamos tracks, but also seem worse in some areasplus, i don't want to just steal code, because then i'll be in the same boat as with vamos, where i'm stuck with a system that has shortcomings and i'll need to rewrite it anyway to add the features we want
Hi,I am the author of top10, a go-kart racing game. Unsurprisingly, I am going through the same kind of problems. Together with the artist in our small team, we have decided to change from a polygon-mesh approach to an approach where we use splines to describe the center of the road. Models will only be used for decorations and other objects (tyres...).The reason for abandonning the polygon-based approach is that it's too heavy. Adding chicanes, getting a track of the correct length are some of the tasks that are difficult.I am currently working on our track editor. It's based on Qt4. Depending on what design decisions you take, it might be worth cooperating on this.
Sure, cooperation sounds like a good idea. We currently use the Vamos track format, which uses splines to define the track, but you specify the splines in a textual format that is kind of odd to work with and isn't all that flexible. The 2d track is then projected onto a 3d bezier surface that is derived from a low-res heightmap. We can't do things like square edges or intersecting tracks at the moment. We also can't have tracks that tunnel into terrain or rise above the terrain (since it's all projected onto the same surface as the terrain). I haven't done much brainstorming yet about a new format, but I think we've identified all of the features we want. Having a track editor would be great; I don't have the time to do one, so if we cooperate it'd be awesome to be able to use your editor.
Does this page describe Vamos' track format acurately?It does not mention splines (constant-radius curves and straights are used instead), and there is no mention of the heightmap. Are these features specific to vdrift?
Yep, that page describes the vamos format. I should have been more specific. You are correct, the vamos track format just does straights and constant radius curves... but it internally generates the curves with simple two point splines, which is why I mentioned splines. VDrift uses the vamos track format without modification -- except the heightmap surface, which is VDrift-only.Also, the collision code currently only handles the ground and the edge of the track (the track wall).
Sorry. I don't know techniques about that engines, but I have a idea. In the real life a track is just a place where the car must go. We can use the same interpretation. We can draw a imaginary line representating the way of the track. That imaginary line is not just only imaginary, the engine can interpret it but don't need to show it to the player (only the track creator can see it).Now, that imaginary line can show the way of a road. What is a road in real life? A road is a modification in the terrain. We can make the engine handle that kind of things. Just "droping" a road above some terrain (just as when we put a carpet on the floor). The engine too can "drop" some other model things same as tree, houses, wires, etc. The colision detection can be done simply. In the terrain is the same as the terrain form. Mathematic calculations about the side or edges of the terrain and we can determine if it just is colisioning.So, a less poligon terrain will result in a less work for the colision detection.Trees and other things can be considered just cubic prism for colision detection (we only have 6 sides for check and 8 vertices).Colision in the road is same, because the road will be droped in the terrain. We can simply the work for the colision detection just caching the track (where the road is droped it can be fusioned with terrain). We can simply that work too determining distances between vertices and we can skip the near ones (and only check colision with the most importants). So we can too just cache a colision map.Friction factor about a kind of terrain is easy to determine, using the material. So the ground is a material grass and earth and the road is concrete or some other. We can make a material list too so the road creator can choose. The engine must handle that too.Anyway we can "drop" water. The water just will low the friction and will produce a "splash" effect when the car just touch it.Handling the things in that manner we can have a very versatile physics engine. (We can drop oil in the road too Tongue).What do you think about that?
That's almost exactly how it's currently done.The problem is mainly that the road isn't constructed in a way that allows for a lot of flexibility.(edit) That is, it's difficult to specify what shape the road should have and where it should be. All you can currently do is select either a straightaway or curve, and you have little control over the details of the shape of the road. Hopefully, a new track system would for easier definition of unusual road shapes and surfaces.
Why not build a track system on top of OpenSceneGraph? Now Joe, I know you like to write everything yourself. :wink: But it looks like this is just what we need minus the track itself - basically it would support all our scenery and terrain. It would also provide the interface to the GL "world" as well.See their "about" page for all the details. Here's a few of the more succulent points:[QUOTE BY="openscenegraph.org"]Performance Supports view frustum culling, occlusion culling, small feature culling, Level Of Detail (LOD) nodes, state sorting, vertex arrays and display lists as part of the core scene graph. These together make the OpenSceneGraph one of the highest performance scene graph available. User feedback is that performance matches or surpasses that of much more established scene graphs such as Performer, VTree, Vega Scene Graph and Java3D! The OpenSceneGraph also supports easy customization of the drawing process, such as implementation of Continuous Level of Detail (CLOD) meshes on top of the scene graph (see Virtual Terrain Projection and Demeter).[/QUOTE]So, performance is pretty good, as good as it gets for a system like this. It looks like we'll have to have these features one way or another in our system, whatever it is...we already have some of them and the others would be nice but tough to do (like occlusion culling).[QUOTE BY="openscenegraph.org"]Productivity The core scene graph encapsulates the majority of OpenGL functionality including the latest extensions, provides rendering optimizations such as culling and sorting, and a whole set of add on libraries which make it possible to develop high peformance graphics applications very rapidly. The application developer is freed to concentrate on content and how that content is controlled rather than low level coding.[/QUOTE]So basically, Joe would spend his time working on gameplay improvements rather than shadow drawing bugs and the like.They go on to say how portable it is:[QUOTE BY="openscenegraph.org"]originally developed on IRIX, then ported to Linux, then to Windows, then FreeBSD, Mac OSX, Solaris, HP-UX and even PlayStation2![/QUOTE]I know this idea isn't all so likely to be used since Joe hates adding unnecessary libraries...but I think this might really cut out a ton of the work needed for a good scenery system, again enabling our small developer resources to focus on the track itself.
whoa whoa whoaopen scene graph is a scene graph librarywhich basically duplicates the functionality that's already in the current engineit wouldn't solve any of the problems with tracks, shadows, etc etc
I've been playing with the TORCS track editor recently trying to make a replica of Oulton Park. In a number of respects I think that TORCS has actually got this aspect of racing pretty much right. While the track editor doesn't expose all of the track possibilities yet (you have to put banking information in by hand) the track format does provide everything you need.<p>All track segments have start height and end height. Heights are interpolated (with splines I think), All track segments have a banking angle so you can have straights with banking (useful for ovals...).<p>All track segments have a left field surface (with width options), a left border surface (with width and height options for curbs), the track surface, a right border surface (width/height) and a right field surface (width). Barriers types and heights for the edges are also specified.<p>Curves appear to be elliptical arcs which gives plenty of scope for interesting corners. <p>TORCS takes all this info (in XML) and creates a terrain and track model using the trackgen utility. Terrain heights can be provided as well to allow extra control. The result is an AC3D file which can then be dressed up and tweaked. Objects can be applied from other models and shadows can be baked into the map using accc. <p>Now I know that the Vamos track format is spline-derived so it's not an instantaneous fit. However, it would be very cool if VDrift could at least use some of the TORCS track format for several reasons:<br> a) there are a reasonable number of TORCS tracks already available. <br> b) the TORCS track editor is fairly easy to use and a basic track can be raced on within 20 minutes of firing it up<br> c) if TORCS tracks and VDrift tracks share the same basic track data (even if the final result is a little different) both projects would benefit from the overlap.<p>While the VDrift approach of providing a height-map to control the track heights look really attractive at first, it's difficult to lay out a track with well cambered corners and good sight lines. This has made this game much harder to play. <p>Cheers,<br>Toby Haynes
Pages: 1 2