|
11-14-2006, 01:50 AM,
|
|
|
rookie1
Member
|
Posts: 231
Threads: 32
Joined: Nov 2006
|
|
|
Ideas on track format
Just throwing out random ideas,
1. Does the track format support non-closed tracks, i.e. not a circle? If not at the moment, is it possible to support this kind of track in future?
2. Selectable option to race in forward or backward direction of the track.
3. Selectable option for day time or night time racing.
With these features, it will be possibe to re-create the downhill or uphill battles in Akina mountain pass as in Initial-D. :lol: What we need next is the AE86. :wink:
|
|
|
|
11-14-2006, 06:26 AM,
|
|
|
thelusiv
Administrator
|
Posts: 2,346
Threads: 223
Joined: Jun 2005
|
|
Re: Ideas on track format
rookie1 Wrote:1. Does the track format support non-closed tracks, i.e. not a circle? If not at the moment, is it possible to support this kind of track in future? I think it's possible, however it hasn't been tried. There isn't yet a way to specify an "end point" on a track so if we had a track like this, timing would not work correctly.
rookie1 Wrote:2. Selectable option to race in forward or backward direction of the track. This is not supported yet, but could probably be added without much difficulty. a new "backwards" starting point and set of "backwords" checkpoints would have to be added to the format.
rookie1 Wrote:3. Selectable option for day time or night time racing. We have a weather system that supports day/night. However most of the tracks in the new track system have a skybox which covers this so it has fallen into disuse.
rookie1 Wrote:With these features, it will be possibe to re-create the downhill or uphill battles in Akina mountain pass as in Initial-D. :lol: What we need next is the AE86. :wink: Somebody would have to make an Akina mountain pass track...btw, the TL is sort of like an AE86, it's based on a Toyota Levin (AE85). Obviously this will not quite do...but it's not that far off either 
|
|
|
|
02-21-2008, 08:43 AM,
|
|
|
aegidian
Junior Member
|
Posts: 18
Threads: 2
Joined: Feb 2008
|
|
|
Further suggestion:
Would it be possible (if it's not already) to add support for a number of different layouts per track? I'm thinking of circuits like Brands Hatch, Oulton Park and Pembrey where one might have the option of racing the Indy, GP or rally circuits.
|
|
|
|
02-25-2008, 10:18 PM,
|
|
|
thelusiv
Administrator
|
Posts: 2,346
Threads: 223
Joined: Jun 2005
|
|
Re: Some thoughts i've been having on tracks
zimluura Wrote:Trees: an artist could model 2-3 evergreens, and then 2-3 deciduous varieties. perhaps with lods. then those could be used to populate every track.
* 1 ram footprint per tree type in track
* work done to improve visuals on 1 tree would carry across all tracks.
* applying scale and rotation for each instance should make them look less identical Back in ye olde 2005-2006, when we were using XML-defined tracks from Vamos, and had to generate all our own landscapes and scenery, we did just this. I took a ton of photos of trees myself and edited them into 3D models and textures for VDrift. (Note: it is incredibly difficult to take a picture of a tree without also taking a picture of something behind it, and incredibly time consuming to edit out shit behind trees.) When we started using fully modeled tracks we ditched it. Look through the media gallery and you'll see some old screen shots of it. I think it looked pretty good; that said, it is nice to be able to have modeled trees in the tracks, because that means less work for us, and the trees can be tweaked a lot easier (I remember we ran into some problems with trees not quite going where we wanted, sometimes we'd get trees that were supposed to be close to the track instead winding up on the track, etc.).
zimluura Wrote:Destructable environments: tire walls that get busted up maybe, This is a lot of work, I think, and something not terribly high on our priority list. Lots of people have suggested it over the years and I agree it would be very nice and quite realistic...but we have bigger problems we need to fix that matter more, I think. Of course anyone is welcome to write a patch...
We might start to work on movable objects on the track when we get so much done with VDrift that we get bored and feel the need to add something new. So that would be a year or more from now. Unless someone else showed up who wanted to work on it.
zimluura Wrote:Meshes in the Sky.
the skybox is the big thing that stands out graphics wise. even if it wasn't pixelated it would still probably stand out. i'd rather see a dynamic sky, even if it's always a cloudless day (though i think weather effects and celestial bodies would be easier to do in a dynamic sky). i once got a neat horizon effect by rendering a grey cyllinder, with opaque vertexes at the base horizon line and transparent vertexes at the top (iirc it would blend in with the clear-to-color function) VDrift actually already has a complete weather system, including night and day. Again look through the gallery and you'll find the screenshots. I think that it's based on a domed sky. I think it's off right now, since most of the modeled tracks have their own sky boxes, and they just cover up the sky and weather effects. We used to even have a moon at night...
zimluura Wrote:also a heightmap for surrounding hills. something that translates with car movement, but is never checked for collision. without collision it could easily be an irregular heightmap to save poly-count. It would be difficult to match up a heightmap ground with the modeled landscape around it. In the past VDrift used heightmap for all the ground, including the track. I spent a few hours at one point trying to properly model the track and surrounding landscape surface of Road Atlanta, using terrain maps I found for the area of the track mated up with satellite images. It was a huge pain in the ass. It didn't look all that bad, but it was quite difficult to predict what the landscape would look like after tweaking the heightmap image; it required a lot of trial and error type activity. Modeling in Blender or something is much easier. Texturing heightmaps is even more of a pain.
Your idea to use heightmaps to generate far-away landscape isn't bad though, especially if we had some way to auto-generate the landscape around the edges of the track. All that said, a well-modeled track wouldn't even need any more landscape rendered than what's in the track, so this is a really low priority type feature. Once again, something that someone should work on a patch for.
|
|
|
|
02-25-2008, 11:23 PM,
|
|
|
zimluura
Senior Member
|
Posts: 286
Threads: 22
Joined: Oct 2007
|
|
|
just to clarify: the trees and destructable environments were supposed to look like sub-entry of the "shared object library" heading.
so for the trees i was thinking still have them be 3d modeled. just not storing the mesh inside the track data. just have a position (+rotation & scale) for the tree listed in the track file and the tree just gets drawn from the shared object library. still gives the option for making special case trees that have their meshes defined in the track file. tire walls, chain link fences, crowds and other stuff *could* be done this way too, though with varying needs for parameters passed when declaring an instance in the track definition.
was thinking allot about how doing 3 lod models for 8 trees is allot of work, but doing them for all the trees in the nurburgring sounds completely insurmountable. and then ontop of that, in 3 years when videocards are 5 times as powerful it wouldn't be that bad to model a single higher level of detail for each tree. and then wham, every track has another level of pretty for its trees. but it's theoretical to me ie; could be that it'll take 20 indigenous and 20 deciduous to get things properly differentiated, and that's a tall work order.
dynamic sky: i saw some shots of it in the album, thought it looked really cool. was hoping it hadn't been totally abandoned. hadn't thought too much about modeling the distant hills in with the rest of the track stuff, but that does make perfect sense. only problem i can see is that micro vs. macro in the same 3d modeler scene has, in my experience, been sorta tricky. that said i haven't been using blender for very long, and most of my experience is from truespace.
|
|
|
|
02-27-2008, 01:02 AM,
|
|
|
thelusiv
Administrator
|
Posts: 2,346
Threads: 223
Joined: Jun 2005
|
|
zimluura Wrote:just to clarify: the trees and destructable environments were supposed to look like sub-entry of the "shared object library" heading. Shared object library isn't a bad idea, it's not much different from what we have now except it would get objects for tracks from somewhere besides the track objects.
Maybe we should try to get support for objects on the track that can be moved by the cars, and work from there. For instance, the cones don't move when you run over them. AutoX mode would be a lot better with movable cones. Once that's done, it wouldn't be hard to move from there to stacks of tires. For now, we can just put a flag in list.txt for the track objects to tell which objects are movable.
If someone who knows C++ dedicated a weekend to this I bet it would be done pretty easily - the support for model loading is already done, and trimesh-trimesh collisions are already done for cars and track objects marked as collidable. Most important would be to add support for collisions between the track objects and other track objects.
zimluura Wrote:so for the trees i was thinking still have them be 3d modeled. just not storing the mesh inside the track data. just have a position (+rotation & scale) for the tree listed in the track file and the tree just gets drawn from the shared object library. still gives the option for making special case trees that have their meshes defined in the track file. tire walls, chain link fences, crowds and other stuff *could* be done this way too, though with varying needs for parameters passed when declaring an instance in the track definition. We could have a shared object library right now, if someone simply made the tracks know how to look in a different place for their objects, and set up the tracks' list.txt to include those objects. It really wouldn't be that hard...
zimluura Wrote:was thinking allot about how doing 3 lod models for 8 trees is allot of work, but doing them for all the trees in the nurburgring sounds completely insurmountable. and then ontop of that, in 3 years when videocards are 5 times as powerful it wouldn't be that bad to model a single higher level of detail for each tree. and then wham, every track has another level of pretty for its trees. but it's theoretical to me ie; could be that it'll take 20 indigenous and 20 deciduous to get things properly differentiated, and that's a tall work order. We didn't have quite 8 trees but this is exactly what it did, LOD based on distance away from viewer. they also sorta faded in instead of just appearing out of nowhere so they were less jarring when you first see them drawn. You can download one of our older releases to see this in action. I just checked, and the release you want is 2005-11-03.
zimluura Wrote:dynamic sky: i saw some shots of it in the album, thought it looked really cool. was hoping it hadn't been totally abandoned. hadn't thought too much about modeling the distant hills in with the rest of the track stuff, but that does make perfect sense. only problem i can see is that micro vs. macro in the same 3d modeler scene has, in my experience, been sorta tricky. that said i haven't been using blender for very long, and most of my experience is from truespace. Yep, it's still there...as far as I know. Have you checked that it works with the new scenegraph code, Joe?
joevenzon Wrote:In fact, I *think* that if you model the hills in blender but mark them as "skybox" they should look as if they are infinitely far off (they would move with the camera, just like a skybox). That would be an interesting effect.
|
|
|
|
Just kidding...