Forums

I've made some progress integrating another somewhat older patch. For anyone interested check out: https://github.com/logzero/vdrift

The idea is to interpolate track mesh geometry to get a smooth surface using cubic interpolation for contact position and quadratic interpolation for the normal derived from triangle mesh vertex and normal data.

The code in the fork is already using this interpolation overriding road patch values. When finished this would make road patch interpolation and hopefully road tracing obsolete. A track could be defined as a list of road meshes(segments).

Issues:
At the moment code is used for wheel rays only. Car collision shape and especially car wheel cylinders are still colliding with non-smoothed geometry leading to collision artifacts.
Tracks might have to be checked for broken/skewed normals. I've already run into one on ruudskogen.

I've added some code to visualize triangle control points edges and normals(left front wheel):

NaN Wrote:Car collision shape and especially car wheel cylinders are still colliding with non-smoothed geometry leading to collision artifacts.

Isn't that also an issue with the code in master? (traced splines for wheel ray, plain geometry for collision shape)

Only with damage enabled. The default shape in master is a rounded box without extra wheel shapes.

Edit: The car will bottom out in the worst case(large bump amplitude for example).

I've implemented code to interpolate track mesh geometry for all contacts (contact callback). The contact depth and normal are corrected. It works under ideal conditions and would even make wheel shapes possible instead of rays. But it breaks under testing with vdrift tracks. Atm I don't think it is fixable without writing a custom mesh collision algorithm(bullet is using gjk here), which would be a larger undertaking.

What does it mean? No fracture functionality as it requires complex collision shapes that require smooth contact surfaces...

Testing contact correction, f1 complex collision shape:

I possible hack/workaround could be to stick with the current system but use a large shape margin to keep it from surface. Wheel collision cylinder radius = wheel radius - 0.1 or something. The problem is of course to get the margin right.

Alternatively contact correction could be constrained to road meshes only(right now all mesh contacts are processed). Their vertex normals should be sane enough(don't deviate too much from triangle normal) to be usable.

You could do both: use contact correction for road meshes, AND do a slight offset for the wheel fracture meshes.

Also, how do I turn on your cool visualization mode?

I've pushed the debug drawer into master, enabled damage again. Parameters are -drawaabbs, -drawshapes and -drawcontacts.

Cool! I pushed a fix to make line drawing work with the gl3 renderer.

I was attempting to draw text using TextRenderer as per the TextRenderer Javadoc. I'm using a GLCanvas with a GL3 context. joevenzon, could you tell how you make line drawing work with the gl3 renderer?

VDrift's gl3 renderer is something I wrote that wraps the OpenGL 3.3 API. The OpenGL spec is pretty easy to read, and describes how to do line rasterization:
http://www.opengl.org/registry/doc/glspe...100311.pdf

... but it sounds like you might be talking about something written in Java, which I know nothing about.