Forums

This menu is done, plus loading and saving script settings. Saving track metadata into the .blend file is done. Loading metadata is very close...

The plan is to hook those buttons up to pop-up dialogs that perform various functions.

I added the file to the vdrift-art repository (r157) with the other Blender scripts.

I had to do a few things that seemed a bit kludgy in some cases. Hopefully the improvements they are making to the Python API in the Blender 2.5x line will help with this.

Looks good. Too bad there is no way to create nurb surfaces from python, as a more direct way to create/edit the road patches.

This is still coming along alright...so far, I have been writing it as a single module full of functions, rather than classes, because I wasn't sure the best way to structure it. Now I have a pretty good idea, but I'm going to continue hacking in this fashion until I have a basic version of all the functionality needed. After that I'll refactor it all, and integrate it more closely with vdrift.py.

In vdrift-art r159, I have begun implementing the export function and added a way to add/edit/delete start points. The idea here is to create camera objects, place them at the desired start points, then tell the script the ids of the objects. Later, I hope to set the script up to also manipulate the camera objects themselves when defining start points, rather than just remember the id.

So to finish this up I need to do the following (in this order):

• Track Objects - add default properties
  
• Road Segments - not sure how to tackle this one...
  
• Lap Sequences
  
• Export
  
• Import
  

A few questions:

• What is the "start orientation-w" parameter in track.txt? I understand the other start-related parameters...not sure how to get that one.
  
• What other track.txt parameters are available? I have noticed "vertical tracking skyboxes", didn't know that was there.
  
• What is the best way to generate roads.trk from a given road mesh object?
  
• Is there a limit to the number of vertices wide a road can be? The old track editor only allows the width to be 2, 3, or 4. Is 4 the limit or could it be more? (BTB makes its roads 5 vertices wide).
  
• Am I correct that a Lap Sequence is defined by two points, which make a line segment, and timing starts/stops when this segment is crossed by the vehicle?
  

I could probably just read code to figure these out, but I want to make sure to avoid any deprecated functionality which hasn't been removed, and get some context about where these things might be headed in the future.

Quote:What is the "start orientation-w" parameter in track.txt?

Orientation is stored as a quaternion. I've added support for euler angles: "start orientation n = x, y, z. Should be more readable.

Quote:Is there a limit to the number of vertices wide a road can be?

The marked vertices are used as control points for the 4x4 bezier patch. You always have to return 16 points per patch. Most of the time you will be interpolating the inner control points from the 4, 6 points marked.

Here are some of my experiments. Haven't looked into them for months. Not sure how usable they are.
Create road from spline curve: http://pastebin.com/WFg5Q0kn
Export the created track: http://pastebin.com/FDqHDNRg

thelusiv Wrote:What other track.txt parameters are available? I have noticed "vertical tracking skyboxes", didn't know that was there.

The "vertical tracking syboxes" parameter is a boolean that most of the time should be off. The way skyboxes are drawn is they ignore the camera translation (i.e. you're always the same distance from the skybox no matter where you are). However, with this parameter set true, then the camera is allowed to translate up and down when drawing the skyboxes. A track or two is set up with this in mind.

thelusiv Wrote:What is the best way to generate roads.trk from a given road mesh object?

There's code in the track editor to do this, but basically if you have a road mesh like this (the direction the car goes is to the right, the numbers represent vertices of the mesh, the mesh is just two quads):

1--3--5
| | |
2--4--6

then you would set the corner control points for the bezier patch to be the same as the vertices of the mesh. Here are the control points for a single bezier:
1 5 9 13
2 6 10 14
3 7 11 15
4 8 12 16
So control points 1, 4, 13, and 16 get set to vertices 1, 2, 3, and 4. The direction of the track at control point 1 gets calculated by taking control point 1 from the next quad and control point 1 from the previous quad and taking the distance and then normalizing. Control point 5 gets set to control point 1 plus the direction of the track at control point 1 that you just calculated. You do the same thing with control point 9 and 13. This ensures that there's always a nice continuous curve between the patches. Control points 8 and 12 get the same technique. Control points 2 and 3 get interpolated from 1 and 4. Same with control points 6, 7, 10, 11, 14, 15. This would probably all make more sense if you look at the code.

thelusiv Wrote:Am I correct that a Lap Sequence is defined by two points, which make a line segment, and timing starts/stops when this segment is crossed by the vehicle?

No. A lap sequence is defined by a list of track road/patch indices that the car needs to roll over in order. As you can imagine, this causes problems if a patch is narrow and the care is very fast. Hopefully in the future we'll do something fancier.

NaN Wrote:I've added support for euler angles: "start orientation n = x, y, z. Should be more readable.

Thanks, this will be quite helpful.

NaN Wrote:The marked vertices are used as control points for the 4x4 bezier patch. You always have to return 16 points per patch. Most of the time you will be interpolating the inner control points from the 4, 6 points marked.

That makes sense...somehow, interpolation never occurred to me.

NaN Wrote:Here are some of my experiments. Haven't looked into them for months. Not sure how usable they are.

Is one of these the same as export-trk.py in vdrift-art/tools?

joevenzon Wrote:The "vertical tracking syboxes" parameter is a boolean that most of the time should be off. The way skyboxes are drawn is they ignore the camera translation (i.e. you're always the same distance from the skybox no matter where you are). However, with this parameter set true, then the camera is allowed to translate up and down when drawing the skyboxes. A track or two is set up with this in mind.

OK, I will add a toggle to the tracks script for this. Are there any other seldom used variables which should be included as well?

joevenzon Wrote:There's code in the track editor to do this, but basically if you have a road mesh like this (the direction the car goes is to the right, the numbers represent vertices of the mesh, the mesh is just two quads):

1--3--5
| | |
2--4--6

then you would set the corner control points for the bezier patch to be the same as the vertices of the mesh. Here are the control points for a single bezier:
1 5 9 13
2 6 10 14
3 7 11 15
4 8 12 16
So control points 1, 4, 13, and 16 get set to vertices 1, 2, 3, and 4. The direction of the track at control point 1 gets calculated by taking control point 1 from the next quad and control point 1 from the previous quad and taking the distance and then normalizing. Control point 5 gets set to control point 1 plus the direction of the track at control point 1 that you just calculated. You do the same thing with control point 9 and 13. This ensures that there's always a nice continuous curve between the patches. Control points 8 and 12 get the same technique. Control points 2 and 3 get interpolated from 1 and 4. Same with control points 6, 7, 10, 11, 14, 15. This would probably all make more sense if you look at the code.

Thanks, that makes much more sense now. I have read the code before but I know it's not been touched in a while, I don't think it was well commented, and my linear algebra is fairly rusty (btw, can you recommend a reference?)...with the context you have given me for understanding the system, I will go back and re-read it this weekend, and I may have some further questions.

But to straighten out in my head what you told me, I made a few diagrams in Inkscape:

some track segments:


vertices for the trimesh t:


control points for the Bézier patch bp:

question: are bp04-bp11 correctly placed? or should, for instance, bp04 and bp08 lie directly on the edge t[0,0] - t[0,1]?

in red is the resulting Bézier patch:

note the subtle curving at [bp00,bp04,bp08,bp12] and [bp03,bp07,bp11,bp15]...is that right? again, should it follow those edges exactly?

joevenzon Wrote:No. A lap sequence is defined by a list of track road/patch indices that the car needs to roll over in order. As you can imagine, this causes problems if a patch is narrow and the care is very fast. Hopefully in the future we'll do something fancier.

Hmm, OK, so then I'm not sure I understand the format. For instance, how does this represent road/patch indeces? (from tracks/hungaroring06/track.txt)

Quote:Is one of these the same as export-trk.py in vdrift-art/tools?

No, export-trk.py is meant to be used with import-trk.py due to control point vertices ordering. The experimental scripts are about using a spline to generate a track mesh and to get the patches from an already existing mesh(without having to rely on a certain vertex ordering).

Quote:For instance, how does this represent road/patch indeces?

The lap sequence is the start/finish line. The road pieces are the patches in the trk.

thelusiv Wrote:question: are bp04-bp11 correctly placed? or should, for instance, bp04 and bp08 lie directly on the edge t[0,0] - t[0,1]?

Yes, bp04 through bp11 are correctly placed. bp04 and bp08 should NOT lie on the edge t[0,0] - t[0,1]. The bp11 from this patch should form a line with bp00 and bp04 from the patch to the right.

thelusiv Wrote:Hmm, OK, so then I'm not sure I understand the format. For instance, how does this represent road/patch indeces? (from tracks/hungaroring06/track.txt)

Code:

lap sequence 0 = 0.000000,0.000000,0.000000
lap sequence 1 = 0.000000,569.000000,0.000000

These are stored in the configfile as 3 floats for no good reason. Lap sequence 0 is probably the start/finish line, and is road 0 patch 0, and lap sequence 1 is probably a patch halfway through the track, and is road 0 patch 569. Only the first two floats are used, and they're treated as ints. You can put them as ints in the file if you want, and you might even be able to leave off the third value and have the game still figure it out.

blender 2.54 beta was released.

http://www.blender.org/development/relea...-254-beta/

it says "final feature set, ready for documentation" in the release figure.

does this mean the api is stable yet, or is waiting for a release candidate/final release the best idea?

I'm going to keep waiting before I make this script work in 2.5x. I have played with 2.54 a little and I like it a lot so far. According to this page, however, there are still some major things in the Python API which are likely to change:
http://www.blender.org/documentation/ble...pi_2_54_0/

The code I've written is a bit sloppy and repetitive so far. It is basically a prototype, which I plan to refactor with a better structure later. It would make sense to port it to Blender 2.5x then.

I am working on some new features which I'll have ready soon...