Hello, and can I be of service?

[aegidian]

Hi folks.

I've been developing cars and tracks for Jonas Echterhoff's Redline, but I'm tiring of the limits of that game and I'm thinking that I might convert some of my work for use here - and maybe go on and do some hacking on the code too.

Y'all can see some of my work here: http://redline.aegidian.org and here http://www.ambrosiasw.com/forums/index.p...pic=110562

I've mostly worked in Wings3d (exported to Wavefront .obj format) rather than Blender, so I expect I'll have to hack together my own Obj_2_Joe.py cnversion script - but looking at the format that doesn't seem too difficult.

Anyhoo, if there's any special requests from the list of cars/tracks at redline.aegidian.org then I'll consider them for my experiments here at vdrift.

Good to meet ya.

[thelusiv]

Welcome!

You can probably import your .obj files into Blender just for the purpose of exporting to .joe. I haven't tried this but I'm pretty sure that's a commonly used format and Blender should support it.

Your cars look pretty nice, we'd love to have some in VDrift.

You should look over our documentation on our Wiki to find out how to import/export cars. Please let us know if you have any questions.

It might be fun to have the oval circuit in VDrift, we currently have nothing like that. The Radical you did would probably be a lot of fun, and most of the other cars you did would be interesting to play with, for instance the '61 F1 cars. We already have a Mini Cooper but I'm not sure if it's slightly different from yours.

[aegidian]

Thanks for the welcome.

For the moment then my basic plan will be to convert the 1961 BRM P48/57 car and the Pembrey circuit to VDrift. And try to create whatever tools necessary to achieve this.

With that I'm still struggling with getting scons installed properly in order to build the track editor - has anyone done this for the Mac (built a working version of the track editor that is).

[joevenzon]

Hello!

The blender .obj importer is excellent, so you should have no trouble doing wings3d->blender->vdrift.

Track development isn't very streamlined right now. Here's the current process:
http://wiki.vdrift.net/Creating_tracks

By the way, the track editor is just a big hack at the moment. There's an effort to write a new one, but it has (to my knowledge) stalled out. If you're interested in programming that's one area where we could use some help ASAP. Info:
http://code.google.com/p/vdrift/issues/detail?id=50

[thelusiv]

Yeah the new track editor (Python based) is stalled right now. I'm not sure that anyone has ever tried setting up the old one on a Mac, but you might get some help from the folks who use OS X here on the forums (abs1nth, cologne, cotharyus, and more).

[abs1nth]

I'm not sure that anyone has ever tried setting up the old one on a Mac

i didn't but i seem to remember that a quick look revealed that it definitely had endian issues.

getting the new one to work would probably be better...

[aegidian]

So, what's needed is work on the Python based version of the track editor with some x-platform interface - okay. I'll think over the options, check out the code and have a look.

No miracles guaranteed, but I have had some experience with this stuff. See http://oolite.aegidian.org

[joevenzon]

I think the only endian issues would be related to the .joe model loading, but since that's been solved for vdrift it shouldn't be too hard to make it work for the track editor as well.

The joepack program, though, probably has some endian issues, although it's not really required to model a track, it just speeds things up by putting all of the .joe files into one big file.

aegidian, do you run a PPC or intel mac?

[aegidian]

I think the only endian issues would be related to the .joe model loading, but since that's been solved for vdrift it shouldn't be too hard to make it work for the track editor as well.

The joepack program, though, probably has some endian issues, although it's not really required to model a track, it just speeds things up by putting all of the .joe files into one big file.

aegidian, do you run a PPC or intel mac?

I have both available to me, but mostly a 2x2.4Gz Intel iMac.

Can prolly fix endian issues w/o too much difficulty.

[thelusiv]

That sounds great! Please do try whatever you like to fix it; you may want to try copying some source files from the VDrift sources as Joe suggested since many of the endian issues have been resolved there, but those changes did not make it into the track editor. model.cpp and model.h can probably be copied verbatim. Again feel free to post any questions or problems you run into, we'll do our best to help you with them.

[TF]

Sweet! I played your brands hatch map a lot. It was probably my favorite track for redline.

[cotharyus]

Yea, as most of the guys here know, I've been begging for a good track editor for some time. Of course, I'm behind on cars ATM, but I'll catch up soon. Anything you need tested on Intel Macs let me know. I generally try to maintain a recent SVN build on my website for the game - if we get a working track editor, I'll keep a copy of that too.

[aegidian]

Working on it, at least in terms of researching what the Track Editor is actually supposed to do...

So far I understand it to create/edit the roads.trk, track.txt, and possibly the objects/list.txt.

roads.txt is a list of 4x4 bezier patches making up the circuit as it's intended to be driven - I presume the 'x' and 'y' coordinates are supplied (in pairs) by the user tracing the map and the 'z' (terrain-height) values from the intersection with the surface of the track model at that point.

That would require an overhead/3d movable rendering of the surface and some point selection - not too hard.

track.txt just defines some simple positions for start positions and some other values for the track (I expect there's more to be added here).

list.txt gives the models and collidablity etc. of every model that makes up the track, I'm not sure what defines their positions or whether these models are moveable or not (like a cone that can be hit and moved, a track marker or hay bale).


I'd be grateful for corrections/expansions of these ideas as I have them thus far.

[thelusiv]

So far I understand it to create/edit the roads.trk, track.txt, and possibly the objects/list.txt.

Spot on.

roads.txt is a list of 4x4 bezier patches making up the circuit as it's intended to be driven - I presume the 'x' and 'y' coordinates are supplied (in pairs) by the user tracing the map and the 'z' (terrain-height) values from the intersection with the surface of the track model at that point.

I'm sure you meant to type roads.trk. Also, I think the Z coordinate for each point is supplied in this file as well, as my file seems to have triples, not pairs. Otherwise I think you understand it well.

By the way, did you see Joe's reply to you on the wiki? http://wiki.vdrift.net/Talk:Track_files_and_formats

That would require an overhead/3d movable rendering of the surface and some point selection - not too hard.

In the new PyGTK track editor, the 3D surface rendering is done. That's about it, however...

track.txt just defines some simple positions for start positions and some other values for the track (I expect there's more to be added here).

Correct. This file is in the VDrift CONFIGFILE format, even though it doesn't have a .config extension (that should get fixed...)

list.txt gives the models and collidablity etc. of every model that makes up the track, I'm not sure what defines their positions or whether these models are moveable or not (like a cone that can be hit and moved, a track marker or hay bale).

Correct again. Right now objects are not movable. The current track editor doesn't actually write this file, listedit does.

[joevenzon]

roads.txt is a list of 4x4 bezier patches making up the circuit as it's intended to be driven - I presume the 'x' and 'y' coordinates are supplied (in pairs) by the user tracing the map and the 'z' (terrain-height) values from the intersection with the surface of the track model at that point.

I'm sure you meant to type roads.trk. Also, I think the Z coordinate for each point is supplied in this file as well, as my file seems to have triples, not pairs. Otherwise I think you understand it well.

Yes, the X, Y, and Z coordinates are all supplied by the user tracing the map. When the user traces the track, they do it by selecting vertices from the existing world geometry. In every track I've seen there is explicit geometry for the left and right edge of the road surface, so this approach seems to work well (makes tracing easy because the cursor snaps to vertices) and allows for some amount of auto-tracing.

list.txt gives the models and collidablity etc. of every model that makes up the track, I'm not sure what defines their positions or whether these models are moveable or not (like a cone that can be hit and moved, a track marker or hay bale).

Correct again. Right now objects are not movable. The current track editor doesn't actually write this file, listedit does.

To elaborate a bit more, right now the blender exporter (if you run the export-all version) generates a list.txt with default properties for each object. The user then has to use listedit to set properties (for example, set all objects with grass textures to be bumpy). In a new track editor I think it'd be ideal for the user to be able to set properties from within the editor, so they never have to use listedit. The way I'd image it would work is that you can select multiple objects in the editor, either by clicking on them or by doing a "select by property" (so you could select all objects with a certain texture, for example), and then do a set property operation on the selected objects.

track.txt just defines some simple positions for start positions and some other values for the track (I expect there's more to be added here).

The lap sequence values here (example from monza):

Code:

lap sequence 0 = 0.000000,0.000000,0.000000
lap sequence 1 = 1.000000,688.000000,0.000000

Mean that for the car to complete a lap it has to pass over road 0 segment 0 and then road 1 segment 688 and then road 0 segment 0 again. The third value is ignored.