bullet dynamics

[NaN]

I compared the values to the first patch(closed track). The first row is correct(== last row of the first patch). It is the third row that is wrong. It should be somewhere between 213-211 for the z value.

[alex25]

but obviously the racing line doesn't represent the actual surface vdrift sees:

everything is red but the car still sinks in.

--alex--

[NaN]

The racing line is created from the corners of the patch. If the inner points are wrong(like for the rouen track) the car will sink. There must be a bug in their calculation. Is it also the last patch where the f1 sinks?

[alex25]

it just happens that at rouen it is the last patch. in general they are all over the place (the interlagos one was the third one for example). and there is more than one patch that could be bad (there is plenty of them at suzuka, and monaco, etc.) how could we represent the inner points to visualize the bad patches?

--alex--

[NaN]

That is a bit more complicated as the surface doesn't have to match them. We need the interpolated values there.

[alex25]

i've fixed the bezier surface for rouen in svn. also, instead of just using the corners to draw the road patch it would be nice to use the interpolated values as well to draw the surface vdrift actually sees. is it possible?

[NaN]

OMG, hacking in real time. This is a quick and dirty draw mesh through patch control points implementation. You will see buggy patches if they are visible from the bottom. You can adjust the trackoffset to a height you like.

Bug example:


Code:

Code:

void ROADPATCH::AddRacinglineScenenode(SCENENODE & node, ROADPATCH * nextpatch,
        TEXTUREPTR racingline_texture, std::ostream & error_output)
{
    if (!nextpatch)
        return;

    //Create racing line scenenode
    keyed_container <DRAWABLE>::handle drawhandle = node.GetDrawlist().normal_blend.insert(DRAWABLE());
    DRAWABLE & draw = node.GetDrawlist().normal_blend.get(drawhandle);

    draw.SetDiffuseMap(racingline_texture);
    draw.SetLit(false);
    draw.SetPartialTransparency(true);
    draw.SetColor(1, 1, 1, 0.5);
    draw.SetBlur(false);
    draw.SetCull(true, false);
    draw.SetVertArray(&racingline_vertexarray);
    
    float vcorners[3*16];
    float uvs[2*16];
    int bfaces[2*3*9];
    
    // vertices/uvs
    float trackoffset = 2;
    for(int y = 0, vi = 0, ui = 0; y < 4; y++)
    {
        for(int x = 0; x < 4; x++)
        {
            MATHVECTOR <float, 3> v = patch.GetPoint(x,y);
            v.Set(v[2],v[0],v[1]);
            vcorners[vi++] = v[0];
            vcorners[vi++] = v[1];
            vcorners[vi++] = v[2] + trackoffset;
            uvs[ui++] = x;
            uvs[ui++] = y;
        }
    }
    
    // faces
    int n = 3;
    int m = 4;
    for(int i = 0; i < n; i++)
    {
        for(int j = 0; j < n; j++)
        {
            bfaces[6*(i*n+j)+0] = (i+1)*m+j+1;
            bfaces[6*(i*n+j)+1] = (i+1)*m+j;
            bfaces[6*(i*n+j)+2] = i*m+j;
            bfaces[6*(i*n+j)+3] = i*m+j+1;
            bfaces[6*(i*n+j)+4] = (i+1)*m+j+1;
            bfaces[6*(i*n+j)+5] = i*m+j;
        }
    }
    
    racingline_vertexarray.SetFaces(bfaces, 2*3*9);
    racingline_vertexarray.SetVertices(vcorners, 3*16);
    racingline_vertexarray.SetTexCoordSets(1);
    racingline_vertexarray.SetTexCoords(0, uvs, 2*16);
}

I'll try to write down the interpolated version tomorrow.

[alex25]

awesome job, but it looks like it highlights the next good patch and not the bad one:


--alex--

[NaN]

highlights the next good patch

The code simply draws the patches with 0.5 transparency. The highlighted section means there is some overlap(something wrong with the patches).

To visualize the patch segments:

Change uv-code to:

Code:

uvs[ui++] = y/3.0;
uvs[ui++] = x/3.0;

Use this racingline.png:

In game:

[alex25]

i wonder if we can integrate this functionality in the track editor and then we can see right away which patch is bad. additionally, it would be nice to have the ability to delete just one patch and then redo it, instead of having to re-trace the whole track. that would really speed up things.

--alex--

[alex25]

so i think i pretty much fixed all the tracks (with the excpetion of ring2007). turns out, i didn't need to retrace the track, instead i could just load then into the track editor and save them right away and that would fix the bezier patches. not sure what happened the first time around. anyway, the only track this didn't work for is ring2007 (which was created with the latest version of the track editor). ring2007 uses quite extensively 3 and 4-vertex selection mode and i wonder if this confuses the collision routine (if it actually matters at all).

--alex--

[NaN]

if we can integrate this functionality in the track editor

I had a look at the track editor code. I think it should be possible. Just need to find the time to do it.

[alex25]

it's not that important. i thought the patches in the editor were wrong but it's most likely the bug happened when it wrote them out.

[alex25]

if i try to change the bump amplitude for any of the track textures (corresponding to the bezier surface) nothing happens. actually it looks like none of the surface coefficients are being used. is that supposed to be so? removing the bezier surface makes the surfaces behave as i would want them.

[NaN]

Oops, I had no idea that we have surface data for the road surfaces. I think there has been some talk about using track geometry surface data for this. I'll have a look.