Forums

Full Version: Nashville Street Circuit (WIP thread)
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
I think it's Trafo bug. Trafo doesn't like records in replay with small dlong changes in positions. Rpy2lp doesn't have such problems.
Just collecting the ideas together.


(10-14-2021, 04:47 PM)samsepi0l Wrote: [ -> ]What we need to do is develop a newer tool to pull location and speed from rpy files.


(10-15-2021, 05:07 AM)Pavel 69 Wrote: [ -> ]If it's impossible to use Trafo for ICR2 then another way could be making basic track in N3 format and then record replay in N3 and try Rpy2Lp to generate lp.


(10-15-2021, 05:23 AM)samsepi0l Wrote: [ -> ]One option here is that I could record a lap through the pitlane (bypassing the chicane) and then cut and paste the data together
With cutting together the lap parts, only the chicane and the following short part must be done manually.


(10-15-2021, 05:23 AM)samsepi0l Wrote: [ -> ]I'm starting to wonder if it may have been a better idea to just keep the chicane the way it was back in the original nashville.  I know it's not as accurate, but this does solve a lot of problems.  With a game this old there are going to be short-comings that need to be worked around. 
Quote:The player pit is at DLONG 59578188 and DLAT 428250 according to the nash.txt file.

I started building out a tool using your replay file, and I see that the car starts at a "replay DLONG" of 232727 so I think the conversion factor is 256 which would get you to the regular DLONG of 59578112 (which is practically the same location as what we see in the nash.txt file).

The "replay DLAT" is 1672 which translates to 428032. And this is a match for the player pit DLAT of 428250.

That's all the time I have for research today, but this is encouraging.

This is super exciting, I love reverse-engineering.

Personally I'm not so worried about not having accurate speed information nearly so much as not having good position information.  I always make videos of me driving so I can just watch the videos if I need to tweak the speeds.  Sometimes I get faster on a track after I've made LPs so I tweak speeds in certain areas while positions stay consistent.

When I made LPs for Pavel's meadowlands road course his location data was so good all I needed to do was make the LPs brake later and get through the corners faster.
Theoretically the best way to get accurate speed from replay is probably to convert the DLONG and DLAT to the X and Y coordinates using the SG/TRK information, like what TRK23D does to figure out all the X, Y points of the track. This would be a bit of work to engineer but not impossible.

If samsepi0l is comfortable not worrying too much about speed, I think we should focus on extracting DLONG and DLAT from the replay files, maybe calculate some approximate speeds knowing that they will need to be manually corrected for the corners and where the track isn't parallel to centerline.
(10-16-2021, 03:21 AM)checkpoint10 Wrote: [ -> ]If samsepi0l is comfortable not worrying too much about speed, I think we should focus on extracting DLONG and DLAT from the replay files, maybe calculate some approximate speeds knowing that they will need to be manually corrected for the corners and where the track isn't parallel to centerline.

I doubt we would go through this much trouble just to make LPs for 1 track- but if we get far enough to get good location data I feel I should be able to do what I need to get speed data by other means. For the sake of just getting through Nashville maybe we just figure out a better way to get location data. We can worry about improving it later. Ultimately I think we all agree a tool like this that could potentially replace trafo- would be a complete gamechanger.

I mean look at NooRok's converter and how that was a gamechanger for track editing- and next we now know how to decompile 3DO's to 3D! Now imagine a better LP tool.
Does elevation changes have an effect on the track length? If yes, DLONG and DLAT is enough to get good accuracy (only the banking would be ignored). If not, then it would be probably impossible, because we would need the slope angle for each sector. In that case XYZ needed for maximum accuracy.

I made the speed correction formula for corners many years ago. Tonight I made the extension for lateral movement.

v=w*(r-dir*p[0])/(r*cos((atn((p[0]-p[-1])/10,91)+atn((p[1]-p[0])/10,91))/2))
where
v: radial speed at the racing line, needed for the LP file
w: speed data made by trafo20
r: corner radius in feet, 1 for straight
dir: direction -1 for right corner, +1 for left corner, 0 for straight
p: position data made by trafo20, index 0 for current record, index -1 for previous record, index 1 for following record


I haven't tested it yet. It's already late. Maybe tomorrow, if not somebody try it earlier. (Different time zones are sometimes cool Happy )
(10-16-2021, 05:28 AM)Dennis Wrote: [ -> ]Does elevation changes have an effect on the track length? If yes, DLONG and DLAT is enough to get good accuracy (only the banking would be ignored). If not, then it would be probably impossible, because we would need the slope angle for each sector. In that case XYZ needed for maximum accuracy.

I may be wrong, but as I recall, I think the track length that you get from TRK23D includes elevation changes, because they can be different from what you get from adding up all the DLONGs directly from the .SG file.

Following that point, I think LP files use the DLONG from the .TRK file which may include elevation. I mean they don't use DLONG directly because it's divided into those small "records" but I think it's based on the DLONGs adjusted for elevation. But I haven't done enough to confirm this yet.
Before doing any initial calculations, why not take a simple oval (say papy phoenix) and just drive at a constant speed as best we can (say 100mph) and then take speed measurements to see how close they come to 100mph. If the error is negligible than we may not need to include it in the mathmatical model.

I'm not sure if we know how trafo actually calculated speed. I mean- after all it was Dennis who figured out how to manipulate the speed based on position, but none of us have seen Robert Szikszo's source-code for trafo, so are we sure with how these number were pulled from the replay? Maybe he had an error? Everyone makes mistakes. We know Trafo has bugs. I have nothing but respect for the man- does anyone have a way to contact him and ask?

Dennis- did you go to engineering school? I can really appreciate how you like to model things with math! I went for 7 years, however it seems like the longer I work as an engineer, the more I forget about what I learned in school!
(10-16-2021, 06:27 AM)checkpoint10 Wrote: [ -> ]
(10-16-2021, 05:28 AM)Dennis Wrote: [ -> ]Does elevation changes have an effect on the track length? If yes, DLONG and DLAT is enough to get good accuracy (only the banking would be ignored). If not, then it would be probably impossible, because we would need the slope angle for each sector. In that case XYZ needed for maximum accuracy.

I may be wrong, but as I recall, I think the track length that you get from TRK23D includes elevation changes, because they can be different from what you get from adding up all the DLONGs directly from the .SG file.

Following that point, I think LP files use the DLONG from the .TRK file which may include elevation. I mean they don't use DLONG directly because it's divided into those small "records" but I think it's based on the DLONGs adjusted for elevation. But I haven't done enough to confirm this yet.
This sounds good.

(10-16-2021, 11:26 AM)samsepi0l Wrote: [ -> ]Before doing any initial calculations, why not take a simple oval (say papy phoenix) and just drive at a constant speed as best we can (say 100mph) and then take speed measurements to see how close they come to 100mph.  If the error is negligible than we may not need to include it in the mathmatical model.

I'm not sure if we know how trafo actually calculated speed.  I mean- after all it was Dennis who figured out how to manipulate the speed based on position, but none of us have seen Robert Szikszo's source-code for trafo, so are we sure with how these number were pulled from the replay?  Maybe he had an error?  Everyone makes mistakes.  We know Trafo has bugs.  I have nothing but respect for the man- does anyone have a way to contact him and ask?

Dennis- did you go to engineering school?  I can really appreciate how you like to model things with math!  I went for 7 years, however it seems like the longer I work as an engineer, the more I forget about what I learned in school!
That's what I mean with testing.
1. test - Looking for stupid results.
2. test - Research, if the lateral movement correction is already implemented in trafo20. In that case we don't need it. But we will need it anyway, if we make a new converter.
Test scenario: Driving on a broad straight between the left and right edges in a snake line with constant speed (80 or 100mph), and looking for the result. How we get constant speed back, with or without correction? I will do this on my track, it has a long broad main straight, but Cleveland would be also good.

Thanks for the compliment. I studied cartography and GIS, and working in that field since then. Fun fact, I was at the neighbor campus to kakukri and Szikszó Róbert.
I made also some data converters in the past from or to very weird formats. The challenge was sometimes to create the correct file format (bits and bytes), sometimes to understand the data structure to import data to the right themes. But meanwhile my skills in code writing (I don't know the modern languages) and looking for bits and bytes are a little rusty, but the theory is still present, maybe because I only use FME at my actual workplace.

Update: The formula above needs an adjustments for the corners, but at first comes testing on the straight.
I made the test for the straight. It seems, this won't corrected by trafo20 too. I'm not completely sure, because I can't drive with constant speed with keyboard.

I drove in snake line on a straight. I tried to keep a pace of 48mph. I made 5 runs, to get more data, you can see all in the graph (see attachment). The red line shows the uncorrected speed made by trafo20, the blue line is the corrected speed. The points, where both lines touch each other, are the points, where I changed the direction at the track edge, and drove for a moment parallel to the centerline. As you can see, the red line has between these points a significant dip, which indicates, that the correction isn't implemented in trafo20. Driving across the road means, that the completed longitudinal distance is shorter than the real distance, so if trafo20 calculates the speed on the centerline, it's lower than the real speed. It's the same, as we drive in a corner on the outside line, the speed in trafo20 is lower.

Samsepi0l, could you make also a test? Maybe you can drive more constant also through the corners.

The corrected formula: not necessary
v=w*c/cos((atn((p[0]-p[-1])/(10,91*c))+atn((p[1]-p[0])/(10,91*c)))/2)
where
v: radial speed at the racing line, needed for the LP file
w: speed data made by trafo20
c: radius correction, 1 for straight, (r-dir*p[0])/r for corners
r: corner radius in feet
dir: corner direction, -1 for right corner, +1 for left corner
p: position data made by trafo20, index 0 for current record, index -1 for previous record, index 1 for following record
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29