VDrift Tracks Blender script

[thelusiv]

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

Thanks, this will be quite helpful.

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.

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?

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?

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?

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)

Code:

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