+- Forums (https://www.vdrift.net/Forum)
+-- Forum: Community (https://www.vdrift.net/Forum/forumdisplay.php?fid=3)
+--- Forum: Cars & Tracks (https://www.vdrift.net/Forum/forumdisplay.php?fid=11)
+--- Thread: roadway tracing (/showthread.php?tid=283)
roadway tracing - alex25 - 07-25-2006
can somebody explain to me what is th epoint of actually tracing the roadway when designing/converting a new track? as i mentioned in a different thread, i am having problems with the pau circuit (but i've seen this on other tracks as well) because there are stretches of road where the car suddenly starts bouncing around and i get this message at the console:
Quote:Detected NaN in elevation 1 0
Not contacting with NaN surface
just for the fun of it i deleted the roads.txt file and, lo and behold, there are no more problems (i lost the timing info, but that's a different issue). my current theory is that there is some bad interaction between the texture position and the traced roadway resulting in the elevation becoming infinite in some places.
the question is: do we still need roads.txt? looks like if i make the textures collidable, the car will drive just as well without a traced road, so why even have that in the first place.
the second question would be: why was drivebale deprecated? to me there is a huge difference between a drivable texture like a road and a collidable one like a wall. collidable is a subset of drivable but the two are not equivalent.
if we get rid of roads.txt track conversion will be a lot easier (i've spent enough time tracing those tracks). do we lose anything (other than timing information which will have to be put in differently, maybe just by designating two squares on the track) by eliminating roads.txt?
btw, i've started looking at the code to see if i can answer the question myself, but any help would be appreciated. thanks.
--alex--
- alex25 - 07-25-2006
i replaced roads.trk and track.txt for the pau circuit with the files from http://caliban.lbl.gov/vdrift/tracks/pau/ and now i get the lap timing info and no more weird bounces. so it looks like there is no need to trace the roadway. am i missing something?
--alex--
- thelusiv - 07-25-2006
If you don't trace the track, the track will not be smooth, it will be slightly more 'jagged' or have more square edges. Also I think the 'outside objects' collision detection routine will be used more, as it is when the car is not on a roadway, so this could cause a performance decrease.
My theory about the bumpiness is that sometimes, if you use the "auto-select the next 25 roadway pieces" feature in the track editor, it sometimes chooses the same set of points but reverses them. Then it continues. This creates a "bump". I haven't thoroughly tested my theory...but you could if you like. Just go around and select the track pieces one by one, use the single auto find function and observe it as you go. If you auto grab a track segment, but you don't see the next square of track light up, press backspace to delete it and do it manually. If this causes all the bumps to be gone then we'll know that is the problem...
If so, it's possible to make the track editor at least refuse to go on instead of picking the same two vertices it previously did but swapped.
- alex25 - 07-25-2006
thelusiv Wrote:My theory about the bumpiness is that sometimes, if you use the "auto-select the next 25 roadway pieces" feature in the track editor, it sometimes chooses the same set of points but reverses them. Then it continues. This creates a "bump". I haven't thoroughly tested my theory...but you could if you like. Just go around and select the track pieces one by one, use the single auto find function and observe it as you go. If you auto grab a track segment, but you don't see the next square of track light up, press backspace to delete it and do it manually. If this causes all the bumps to be gone then we'll know that is the problem...
i traced manually one of the corners where i see this bumpiness and, indeed, there is a difference between the two tracks in two places (there are two places around this corner where i see the bumpiness, one at the entrance and one on exit). i put the files at http://caliban.lbl.gov/vdrift/tracks/pau/ as roads.trk-old (the version that's in svn) and roads.trk-new. roads.trk.diff is the diff file (in unified format). unfortunately i don't understand the format, each 4 vertex rectangle has 16 entries and in both cases only one group of 4 is different while the other 3 are the same. can somebody shed some light on this format? i wonder if this helps.
unfortunately, this is not it. looks like the extra entries are some kind of interpolation. if i select some more rectangles at the beginning and the end of the track segment there is no difference (except for the extra rectangles) between the manually selected track and the old one (which might or might not have been selected automatically). maybe the interpolation is wrong.
--alex--
- alex25 - 07-25-2006
thelusiv Wrote:My theory about the bumpiness is that sometimes, if you use the "auto-select the next 25 roadway pieces" feature in the track editor, it sometimes chooses the same set of points but reverses them. Then it continues. This creates a "bump". I haven't thoroughly tested my theory...
i've retraced the pau track using mostly manual point selection (a few times i used the auto-select next segment, but i never used the auto-select the next 25 segments). the bumpiness is still there, pretty much in the same places so your theory is not correct. what's even more disturbing is that the new roads.trk is different from the old one in quite a few places even though the same points were selected.
--alex--
- joevenzon - 07-26-2006
If you don't use roads.trk, then you just get the basic ray-triangle intersection to find the roadway. This doesn't work very well on roads that aren't flat, because you're driving on triangles instead of a smooth surface. If you use roads.trk, you're actually driving on a sweet ass bezier patch that is totally continuous and smooth... which is pretty necessary on roads that aren't completely flat if you're going fast. However, my ray/bezier collision code seems to have some lingering bugs, and they cause the bumps you described. It may soon be time to audit the code and try to find what's causing the bug (I did this before and fixed ONE bug that was causing the bumps, but this second bug remains).
The extra entries are for each control point of the bezier patch. Each patch has a 4 x 4 control point grid that is automagically generated from the points you selected as well as the previous and next patch.
I'll refer you to the Racer developer guy for further info:
http://www.racer.nl/tech/splines.htm
(his solution is a bit funky, I think -- but I shouldn't talk, as my code is still kind of buggy)
Oh yeah, the driveable thing was deprecated because the code now lets you drive on anything that you can collide with and collide with anything you can drive on. Originally this wasn't so.
- alex25 - 07-26-2006
joevenzon Wrote:However, my ray/bezier collision code seems to have some lingering bugs, and they cause the bumps you described. It may soon be time to audit the code and try to find what's causing the bug (I did this before and fixed ONE bug that was causing the bumps, but this second bug remains).
i think i found one of the sources of the bumpiness, IntersectQuadrilateralF() was trying to take the square root of a negative number and everything fell to pieces after that.
this patch:
Code:
--- src/utility.cpp (revision 1162)
+++ src/utility.cpp (working copy)
@@ -1143,6 +1143,7 @@
- (beta * (alpha_11 - (1.0))) - (1.0);
float C = alpha;
float D = (B * B) - ((4.0) * A * C);
+ if (D < 0) return false;
float Q = (-0.5) * (B + ((B < (0.0) ? (-1.0) : (1.0))
* std::sqrt(D)));
u = Q / A;
@@ -1250,6 +1251,7 @@
- (beta * (alpha_11 - (1.0))) - (1.0);
double C = alpha;
double D = (B * B) - ((4.0) * A * C);
+ if (D < 0) return false;
double Q = (-0.5) * (B + ((B < (0.0) ? (-1.0) : (1.0))
* std::sqrt(D)));
u = Q / A;i am running vdrift right not with fpe exceptions enabled so i get a core dump every time we raise an exception. this makes it pretty easy to find the problems. i can commit this to svn if you think it is correct.
--alex--
- joevenzon - 07-26-2006
Looks good, commit!
Nice work!
- alex25 - 07-26-2006
joevenzon Wrote:Looks good, commit!
done.
--alex--
- joevenzon - 08-02-2006
I'm still getting a few bumps in some areas. I'm not 100% sure, but I think they may be due to collisions between the car's chassis and the track, which causes the car's body to be moved up off of the track slightly (which is because the collision response code sucks, but that's another story).