Hey guys, nothing further to report yet beyond the work week has started and so progress will slow down a little bit. Also I am going to attempt to reduce the loading times of track terrain / quad tree / reference points greatly by computing what is needed and saving a file so those don't need to be computed each time.
I do have a few questions, if anyone actually following the project knows, about gathering information from LiveForSpeed.
1) Is there a place where the width of the car is stored/kept, or where I can get this value from? (I found the wheelbase value in the car_info.bin files, but I need the width)
2) Is there a place to find the limiter RPM value for each car?
3) Is there a place to find the optimum shift RPM value? (I did find max torque/power)
bonus) Is it possible to get information from the Steering Wheel position as it is not provided by OutGauge from what I saw.
I can (and will if needed) create approximations, but it would be great to know them if possible.
I do have a few questions, if anyone actually following the project knows, about gathering information from LiveForSpeed.
1) Is there a place where the width of the car is stored/kept, or where I can get this value from? (I found the wheelbase value in the car_info.bin files, but I need the width)
2) Is there a place to find the limiter RPM value for each car?
3) Is there a place to find the optimum shift RPM value? (I did find max torque/power)
bonus) Is it possible to get information from the Steering Wheel position as it is not provided by OutGauge from what I saw.
I can (and will if needed) create approximations, but it would be great to know them if possible.
dawesdust_12, that would have been my thought if it was the Vec (3 ints). But it is the Vector (3 floats) and those are usually either 1 unit = 1 meter, or described. I do believe I'm getting the correct values by dividing by the gravity constant, at least they seem to match my expectations.
What I am having a problem with, and this might be elsewhere in my code, is if I set the car forwardDirection based on the Heading of this packet, it seems to travel in unexpected ways. To solve this I've simply continued using the position/heading of the MCI packet, which was working. But it makes me wonder if something I did in the above is wrong. I will investigate more at a far later date and try to post any differences.
For now, back to work.
What I am having a problem with, and this might be elsewhere in my code, is if I set the car forwardDirection based on the Heading of this packet, it seems to travel in unexpected ways. To solve this I've simply continued using the position/heading of the MCI packet, which was working. But it makes me wonder if something I did in the above is wrong. I will investigate more at a far later date and try to post any differences.
For now, back to work.
Okay another quick update for the day. Here is the Physical Sensor for the driver, it is not hooked up to anything beyond making sure the values make some sense. A few of them might still be a little off for certain situations.
View of PhysicalSensor
This has visualization has quite a bit of information stored in it. First the small green circle. This represents the forces the players FEELS. Meaning it is opposite to the actual forces. (Turn the car right and it FEELS like you get pulled right) (Hit the throttle and if FEELS like you get pushed back). I'm still not sure how accurate the number/scale is, but the large circle is supposed to represent 1 full G. From the screen shot it seems a little off since the dot is not 58% to the right edge and 25% to the bottom. But otherwise this is working as expected.
The next part of the visualization is the red line which indicates the linear velocity of the car, from the cars perspective. So moving the car forward will make this line go straight up, if the car is moving sideways it will point that direction. If the car is going 100mph (will eventually make that a variable speed depending on car), the line will extend to the outer green circle. Since the velocity won't always be in the exact direction the car is pointing you can use it to monitor the slipAngle as well, as shown better here.
Physical Sensor Slipping
The final part is the pink line that always reaches the outer circle, and I'm not yet sure I've got a grasp on that in terms of "in car space". But it may not matter it is telling a story, and it might be telling it backwards at the moment. However, it represents the angular velocity of the car along the UP axis. Think of it like a steering wheel, when there is no rotation it will point straight up. If the car is rotating, the faster it rotates the more the line will continue around the circle.
I have captured the information from the gauges, but I have yet to make a CarSensor, and when I do I will create another visualization based on Speed, RPM, Fuel. Also actual throttle/brake/clutch/shift positions (vs what the AI will be saying, since there will be a delay of some sort).
Speaking of, does anyone know how to get the steering information from LFS? I would have thought it'd be included in with OutGauge along with the pedal positions, but it was not included, this would be a nice-to-have, although in all seriousness the important parts about the CarSensor will be the information from speedometer, tachometer and fuel gauge.
-----
EDIT:
Added a rough visualization of the speedometer, tachometer and current gear selection. The tach is the red line, going from 9 o'clock to 12 o'clock and the green line is the speedometer going from 12 o'clock to 6 o'clock.
CarSensor Visualization
View of PhysicalSensor
This has visualization has quite a bit of information stored in it. First the small green circle. This represents the forces the players FEELS. Meaning it is opposite to the actual forces. (Turn the car right and it FEELS like you get pulled right) (Hit the throttle and if FEELS like you get pushed back). I'm still not sure how accurate the number/scale is, but the large circle is supposed to represent 1 full G. From the screen shot it seems a little off since the dot is not 58% to the right edge and 25% to the bottom. But otherwise this is working as expected.
The next part of the visualization is the red line which indicates the linear velocity of the car, from the cars perspective. So moving the car forward will make this line go straight up, if the car is moving sideways it will point that direction. If the car is going 100mph (will eventually make that a variable speed depending on car), the line will extend to the outer green circle. Since the velocity won't always be in the exact direction the car is pointing you can use it to monitor the slipAngle as well, as shown better here.
Physical Sensor Slipping
The final part is the pink line that always reaches the outer circle, and I'm not yet sure I've got a grasp on that in terms of "in car space". But it may not matter it is telling a story, and it might be telling it backwards at the moment. However, it represents the angular velocity of the car along the UP axis. Think of it like a steering wheel, when there is no rotation it will point straight up. If the car is rotating, the faster it rotates the more the line will continue around the circle.
I have captured the information from the gauges, but I have yet to make a CarSensor, and when I do I will create another visualization based on Speed, RPM, Fuel. Also actual throttle/brake/clutch/shift positions (vs what the AI will be saying, since there will be a delay of some sort).
Speaking of, does anyone know how to get the steering information from LFS? I would have thought it'd be included in with OutGauge along with the pedal positions, but it was not included, this would be a nice-to-have, although in all seriousness the important parts about the CarSensor will be the information from speedometer, tachometer and fuel gauge.
-----
EDIT:
Added a rough visualization of the speedometer, tachometer and current gear selection. The tach is the red line, going from 9 o'clock to 12 o'clock and the green line is the speedometer going from 12 o'clock to 6 o'clock.
CarSensor Visualization
Last edited by blackbird04217, .
I've solved most of my matter. It seems I was wrong, and not sure how I came to that conclusion, about the input of the lfsHeading/Pitch variables; they are already in Radians, amd don't need to be converted. I guess I assumed based on the lfsAngle used in the MCI update packets.
I still don't have a documented way to know the values from .Accel are in meters/second/second, though I've assumed this for the time being. Can anyone verify that?
The fixed code (in case anyone is interested in using this thread for future) help is:
I still don't have a documented way to know the values from .Accel are in meters/second/second, though I've assumed this for the time being. Can anyone verify that?
The fixed code (in case anyone is interested in using this thread for future) help is:
GameMath::Vector3 LiveForSpeed::ConvertHeadingToForward(const float lfsHeading)
{ //angle 0 = 0* = (0,0,1) lfs = anticlockwise from above (Z)
float angleInRadians = lfsHeading;
GameMath::Vector3 forward(sin(angleInRadians), 0.0f, cos(angleInRadians));
GameMath::Vector3Normalize(&forward, &forward);
return forward;
}
GameMath::Vector3 LiveForSpeed::ConvertPitchToUp(const float lfsPitch)
{ //angle 0 = 0* = (0,1,0) anticlockwise from right (X)
float angleInRadians = lfsPitch;
GameMath::Vector3 up(0.0f, cos(angleInRadians), sin(angleInRadians));
GameMath::Vector3Normalize(&up, &up);
return up;
}
Last edited by blackbird04217, .
Got a little stuck on the PhysicalSensor, if you know a bit about OutSim let me know: In this thread
For now I am going to ignore the PhysicalSensor and move on to the CarSensor so the AI driver can check the speedometer, rpm, etc.
For now I am going to ignore the PhysicalSensor and move on to the CarSensor so the AI driver can check the speedometer, rpm, etc.
OutSimPack Help
You've probably stumbled across my AIRS project thread by now, but now I need some help, and I figured it would be best to isolate it for others. I've searched up and down, and found several posts including the OutSimPack that I am trying to handle. I have many questions that I have yet to find documented anywhere.
Accel I had an assumption based on the lack of documentation that this would provide numbers in terms of acceleration in Gs. So if I got
Accel.x = 0.5; Accel.y = 0.2; Accel.z = 0.0;
it would mean the car is turning to the left and accelerating. Or something along those lines. However, the range is not 1 = 1G of acceleration. I have no idea what the scale is, but I simply divided by 9.81 and it still seems to work, but I'd like to confirm this fact somewhere.
The more important issue is the numbers seem to be in world space, so with the numbers provided above, it could actually mean the car is accelerating very hard and turning a little. I tried to convert this into car space, and have so far had no luck. I'm looking to get the seat of the pants feeling for the ai driver.
Any one have more information on this?
Image of issue
Notice the G force gauge in LFS shows 0.67g forward and 0.01g left. Yet my display shows more left than forward.
Accel I had an assumption based on the lack of documentation that this would provide numbers in terms of acceleration in Gs. So if I got
Accel.x = 0.5; Accel.y = 0.2; Accel.z = 0.0;
it would mean the car is turning to the left and accelerating. Or something along those lines. However, the range is not 1 = 1G of acceleration. I have no idea what the scale is, but I simply divided by 9.81 and it still seems to work, but I'd like to confirm this fact somewhere.
The more important issue is the numbers seem to be in world space, so with the numbers provided above, it could actually mean the car is accelerating very hard and turning a little. I tried to convert this into car space, and have so far had no luck. I'm looking to get the seat of the pants feeling for the ai driver.
Any one have more information on this?
Image of issue
Notice the G force gauge in LFS shows 0.67g forward and 0.01g left. Yet my display shows more left than forward.
const OutSimPack& msg(InterpretAs<OutSimPack>(data, dataLength)); //msg is the OutSimPack
const float kOneGravity(9.81f);
GameMath::Vector3 carDirection(LiveForSpeed::ConvertHeadingToForward(msg.Heading));
GameMath::Vector3 carUp(LiveForSpeed::ConvertPitchToUp(msg.Pitch));
GameMath::Vector3 carRight(carDirection ^ carUp); //Vector Cross Product
//Note the y/z is swapped on purpose. In my 'world' Y is up and Z is forward.
//The drawing code ignores the vertical acceleration, using only forward and right.
GameMath::Vector3 carAcceleration(msg.Accel.x / kOneGravity, msg.Accel.z / kOneGravity, msg.Accel.y / kOneGravity);
GameMath::Vector3 carSpaceAcceleration(carAcceleration * carRight, carAcceleration * carUp, carAcceleration * carDirection);
lfsScanner->SetCarAcceleration(driverCarIndex, carSpaceAcceleration);
GameMath::Vector3 LiveForSpeed::ConvertHeadingToForward(const float lfsHeading)
{ //angle 0 = 0* = (0,0,1) lfs = anticlockwise from above (Z)
float angleInRadians = GameMath::Convert::DegreesToRadians((lfsHeading));
GameMath::Vector3 forward(sin(angleInRadians), 0.0f, cos(angleInRadians));
GameMath::Vector3Normalize(&forward, &forward);
return forward;
}
GameMath::Vector3 LiveForSpeed::ConvertPitchToUp(const float lfsPitch)
{ //angle 0 = 0* = (0,1,0) anticlockwise from right (X)
float angleInRadians = GameMath::Convert::DegreesToRadians((lfsPitch));
GameMath::Vector3 up(0.0f, cos(angleInRadians), sin(angleInRadians));
GameMath::Vector3Normalize(&up, &up);
return up;
}
Last edited by blackbird04217, .
Reason : Added more code that could possibly be relevant.
Well, I had started a post explaining several problems I was running into with an Outsim/Outgauge connection, however, I finally got it working! For one thing, I've been connecting to LFS with running AI drivers and in this situation you don't get Outsim/Outgauge information, and I had forgotten this minor fact. Another was old code that wasn't written well, now fixed.
So today I am working on the PhysicalSensor and CarSensor and depending how long that will take, I will start on the PredictionUnit which will use all the sensors to estimate the speed, slip angle, and other conditions of the car. And also, with that information, predict where the car will be in the near future.
So today I am working on the PhysicalSensor and CarSensor and depending how long that will take, I will start on the PredictionUnit which will use all the sensors to estimate the speed, slip angle, and other conditions of the car. And also, with that information, predict where the car will be in the near future.
de Souza, no questions are ever stupid, and even if they were answered before (I don't think they were) it is worth pointing it out/clarifying for others!
You are correct the three closest sections are what are being used. Each section of the track is about 75 meters long or so. Which means the car can (at the best of times) see ~150 meters in front of it. Which means it will see the markers in front, but not extremely far.
I have been considering to add more sections in front, which could/will reduce performance a bit more, however I think where it is at right now will work great for the current time, from my quick tests it seems a good compromise. This can always be modified in the future.
That is correct, if the terrain is blocking the line of sight (from the position of the drivers eye to the position of the reference point) then the reference point is discarded as it is not visible at that time. (Before doing that more expensive test, I first check if it is even in the drivers field of vision).
As far as focusing on a single object further away, I feel we take a lot of points into consideration when processing the visual information. The AI driver will need to take multiple points into consideration if only because turning the car will make a point far away move, but not necessarily in the direction the car is moving, where-as the closer points will move less due to the turning and more due to the car motion. I'm hoping I can separate the two and make the Visual Sensor predict where the car will be, given the current conditions (speed, turning, etc).
The AI will see the marker on the next lap, but they won't know it exists until it comes to them. That would involve some form of learning algorithm which I am currently planning to steer clear of for complexity reasons.
Nice to hear from you again!
You are correct the three closest sections are what are being used. Each section of the track is about 75 meters long or so. Which means the car can (at the best of times) see ~150 meters in front of it. Which means it will see the markers in front, but not extremely far.
I have been considering to add more sections in front, which could/will reduce performance a bit more, however I think where it is at right now will work great for the current time, from my quick tests it seems a good compromise. This can always be modified in the future.
That is correct, if the terrain is blocking the line of sight (from the position of the drivers eye to the position of the reference point) then the reference point is discarded as it is not visible at that time. (Before doing that more expensive test, I first check if it is even in the drivers field of vision).
As far as focusing on a single object further away, I feel we take a lot of points into consideration when processing the visual information. The AI driver will need to take multiple points into consideration if only because turning the car will make a point far away move, but not necessarily in the direction the car is moving, where-as the closer points will move less due to the turning and more due to the car motion. I'm hoping I can separate the two and make the Visual Sensor predict where the car will be, given the current conditions (speed, turning, etc).
The AI will see the marker on the next lap, but they won't know it exists until it comes to them. That would involve some form of learning algorithm which I am currently planning to steer clear of for complexity reasons.
Nice to hear from you again!
Okay I am happy to announce I have the Visual Sensor gathering the Reference points in view at a happy level of >40 frames per second!
Improved Sensor 1
Improved Sensor 2
Improved Sensor 3
Again the green, yellow, red lines indicate the visibility as noted in my previous post. The blue/green lines across the track separate the track into several sections. The Visual Sensor will gather all reference points from the section the car is in, as well as the previous and next sections. All these reference points are then tested for visibility to determine if they can be seen or not.
The good news, this remains true to the idea that the AI can see ONLY what the player can see. Although it is possible it won't see everything. On a long straight section, like Blackwood, the Visual Sensor will only sense the immediate reference points and not ones further down. This is an acceptable compromise for now.
Now I get to attempt to have the Visual Sensor estimate the speed of the car, and from there "predict" where the car will end up a few moments into the future!!!
Improved Sensor 1
Improved Sensor 2
Improved Sensor 3
Again the green, yellow, red lines indicate the visibility as noted in my previous post. The blue/green lines across the track separate the track into several sections. The Visual Sensor will gather all reference points from the section the car is in, as well as the previous and next sections. All these reference points are then tested for visibility to determine if they can be seen or not.
The good news, this remains true to the idea that the AI can see ONLY what the player can see. Although it is possible it won't see everything. On a long straight section, like Blackwood, the Visual Sensor will only sense the immediate reference points and not ones further down. This is an acceptable compromise for now.
Now I get to attempt to have the Visual Sensor estimate the speed of the car, and from there "predict" where the car will end up a few moments into the future!!!
Last edited by blackbird04217, .
I have the visual sensor working to some degree, a lot faster than it was a few days ago. Currently working on another optimization so that it can truly work in real-time with LFS in the background, essentially running two full games on the same machine!
Not sure if anyone is still interested in the project, I know it takes time between updates, but I think that is changing. At least, I've been making some good progress lately, and hope to get a few of the sensors accomplished. I've now got it so that it will capture the location of all cars on the server, and handle players joining/leaving/pitting/spec etc... Which is not a necessary step currently, but when the AI driver starts driving, that will get it one step closer for someone (you) to race it!
I'm can't wait to try estimating the speed from the visuals provided by the visual sensor. Also, have some screen shots to share with this visual sensor. Enjoy!
Visual Sensor 1
Visual Sensor 2
Visual Sensor 3
In all of those shots only a subset of the LEFT edge is attempting to be located visually, which means the AI can see more than what the story tells. However, it proves the Visual Sensor is working as expected.
Green lines indicate the AI driver can see that cone, no terrain is in the way. A yellow line means the cone is not in the field of vision (behind the driver as he currently has 180* fov). A red line is for the cones that failed to be shown because of the terrain, also shown is the triangle that blocked this vision.
Once I get the optimized version I might try to record a short video of it in 'real-time', however, I am not sure my system can handle LFS, AIRS and Video Capture... Might be challenging.
Not sure if anyone is still interested in the project, I know it takes time between updates, but I think that is changing. At least, I've been making some good progress lately, and hope to get a few of the sensors accomplished. I've now got it so that it will capture the location of all cars on the server, and handle players joining/leaving/pitting/spec etc... Which is not a necessary step currently, but when the AI driver starts driving, that will get it one step closer for someone (you) to race it!
I'm can't wait to try estimating the speed from the visuals provided by the visual sensor. Also, have some screen shots to share with this visual sensor. Enjoy!
Visual Sensor 1
Visual Sensor 2
Visual Sensor 3
In all of those shots only a subset of the LEFT edge is attempting to be located visually, which means the AI can see more than what the story tells. However, it proves the Visual Sensor is working as expected.
Green lines indicate the AI driver can see that cone, no terrain is in the way. A yellow line means the cone is not in the field of vision (behind the driver as he currently has 180* fov). A red line is for the cones that failed to be shown because of the terrain, also shown is the triangle that blocked this vision.
Once I get the optimized version I might try to record a short video of it in 'real-time', however, I am not sure my system can handle LFS, AIRS and Video Capture... Might be challenging.
I got the LineOfSight code working!!! It was a great reward to see the driver trying to watch a single cone as I moved the car around the FE1, and it would be rendered as visible/not correct. Then I tried adding the rest of the cones and the first performance issue from this project has finally risen.
It made the InSim connection TimeOut. So while it works, it is far too slow. I first eliminate any further checks if the cone is behind the driven. Then since I have the terrain organized into a QuadTree, I eliminate all triangles from quads that are not in the LineOfSight, and test the rest until a triangle is hit, resulting the driver can't see the cone.
There are certainly some minor optimizations I can make, but I've made most obvious ones and the QuadTree should eliminate most of the unnecessary tests. I could put it in a separate thread, but that will only help so much- and not nearly enough.
(Note, my machine is a bit older now. It has a 2.4ghz Intel Core 2 Duo, with 2gb ram, running Windows XP). It also has to be running LiveForSpeed. So between running the AIRS project and LFS both cores are already at max, so threading won't help.
I could just let the Visual Sensor 'see' all the cones within the field of view, but that goes against some of the thoughts behind the project by allowing the AI Driver to see more than a player could.
It made the InSim connection TimeOut. So while it works, it is far too slow. I first eliminate any further checks if the cone is behind the driven. Then since I have the terrain organized into a QuadTree, I eliminate all triangles from quads that are not in the LineOfSight, and test the rest until a triangle is hit, resulting the driver can't see the cone.
There are certainly some minor optimizations I can make, but I've made most obvious ones and the QuadTree should eliminate most of the unnecessary tests. I could put it in a separate thread, but that will only help so much- and not nearly enough.
(Note, my machine is a bit older now. It has a 2.4ghz Intel Core 2 Duo, with 2gb ram, running Windows XP). It also has to be running LiveForSpeed. So between running the AIRS project and LFS both cores are already at max, so threading won't help.
I could just let the Visual Sensor 'see' all the cones within the field of view, but that goes against some of the thoughts behind the project by allowing the AI Driver to see more than a player could.
Noodleguitar, sorry I never responded sooner, I meant to and normally I don't ignore responses! I am probably going to avoid genetic/learning algorithms for this project due to complexity and I am attempting to make the AI think and drive how we would in regards to reference points and visual/physical sensors.
At everyone following the thread, I've recently picked the project up again and making progress toward actually developing the Visual Sensor that the ai driver will use to estimate the distance from the reference points (hopefully never using exact positions). My goal is to have the Visual Sensor estimate the velocity of the car, hopefully accurately-ish. Possibly even predict where the car will end up.
So the visual sensor will run and give the driver this information:
refPoint1 (-1, 2)
refPoint2 (2, 5)
refPoint3 (7, 5)
refPoint4 (4, 2)
A moment later the visual sensor will run and give the driver this information:
refPoint1 (NA) (no longer in field of view)
refPoint2 (0, 3)
refPoint3 (5, 3)
refPoint4 (2, 0)
The coordinates are not the position of the reference point, but the distance (or an estimate of the distance as I talked about long ago in this thread) of the reference point from the drivers eye. So taking the distance before, and the distance after we can average all these differences and we should get the average velocity of the car... In this case it is easy to see the eye move (2, 2) closer to each of the reference points.
This will get trickier as the car is turning while moving since reference points far away will tend to move a distance purely based on the rotation of the car, even if the car didn't move forward much. So, I will run with the theory and see how it works when I get there.
I plan to make another video with the visual sensor showing what it can and cannot see.
Thank everyone for their support and someday maybe my ai driver will be driving around a track!
At everyone following the thread, I've recently picked the project up again and making progress toward actually developing the Visual Sensor that the ai driver will use to estimate the distance from the reference points (hopefully never using exact positions). My goal is to have the Visual Sensor estimate the velocity of the car, hopefully accurately-ish. Possibly even predict where the car will end up.
So the visual sensor will run and give the driver this information:
refPoint1 (-1, 2)
refPoint2 (2, 5)
refPoint3 (7, 5)
refPoint4 (4, 2)
A moment later the visual sensor will run and give the driver this information:
refPoint1 (NA) (no longer in field of view)
refPoint2 (0, 3)
refPoint3 (5, 3)
refPoint4 (2, 0)
The coordinates are not the position of the reference point, but the distance (or an estimate of the distance as I talked about long ago in this thread) of the reference point from the drivers eye. So taking the distance before, and the distance after we can average all these differences and we should get the average velocity of the car... In this case it is easy to see the eye move (2, 2) closer to each of the reference points.
This will get trickier as the car is turning while moving since reference points far away will tend to move a distance purely based on the rotation of the car, even if the car didn't move forward much. So, I will run with the theory and see how it works when I get there.
I plan to make another video with the visual sensor showing what it can and cannot see.
Thank everyone for their support and someday maybe my ai driver will be driving around a track!
Dygear; what I got from the SMX in color was actually more than I was expecting but very close to what I was hoping for. There should be enough terrain and features for proper line of sight testing.
Tommy; No it doesn't include direction, braking or speed into the racing line at this time, and for now I think that is okay. It is just the geometrical smoothest curve. I do want to remove the constraint optimization/stabilization that I put on the point masses, I figure adding another stronger spring from one point to another will help keep them approximately the same distance, but for this to work I need to find why the points were able to pop of the track and fix that.
I would also like to work on allowing the line to take into account long straights so corner entry/exit could be compromised slightly from the geometrical line, thus allowing more gains. However, for current purposes I will consider this the line my artificial driver will start with, it does get a lot better than what is seen in the video; letting it run for 3000 iterations is much better than the 300 shown, the movement becomes less pronounce though as the springs become more equalized.
Keling; Yes the white line shown is the line the Live For Speed artificial drivers take. I do wonder if Live For Speed reads the PTH files or not, if it does I could see how my computed racing line is working in comparison. I can say it probably doesn't work very well since the line hits a few big curbs that will upset the car. Still, something I may try at some point, it could be interesting.
Tommy; No it doesn't include direction, braking or speed into the racing line at this time, and for now I think that is okay. It is just the geometrical smoothest curve. I do want to remove the constraint optimization/stabilization that I put on the point masses, I figure adding another stronger spring from one point to another will help keep them approximately the same distance, but for this to work I need to find why the points were able to pop of the track and fix that.
I would also like to work on allowing the line to take into account long straights so corner entry/exit could be compromised slightly from the geometrical line, thus allowing more gains. However, for current purposes I will consider this the line my artificial driver will start with, it does get a lot better than what is seen in the video; letting it run for 3000 iterations is much better than the 300 shown, the movement becomes less pronounce though as the springs become more equalized.
Keling; Yes the white line shown is the line the Live For Speed artificial drivers take. I do wonder if Live For Speed reads the PTH files or not, if it does I could see how my computed racing line is working in comparison. I can say it probably doesn't work very well since the line hits a few big curbs that will upset the car. Still, something I may try at some point, it could be interesting.
You're brilliant. I thought the same but for some reason it didn't click when I thought it... Reading what you said made it click! One moment...
And back with the fix. It seems I do indeed get the track terrain data, and MUCH MORE! Correctly loaded
Edit: It isn't quite ALL the terrain, but it might be enough to work magic. The giant cliff "jump" at the FE1 chicane doesn't appear for me. But I think enough appears to block visuals appropriately, hopefully. Awesome!
And colored... Lighting was "dark" before from the ordering of the triangles in my rendering system. I win check that out! The cliff jump is there well enough! AWESOME.
Just in case someone may have missed it with the discussion that just took place, go check out this post where I linked to a video on youtube of all the computations taking place visually: Artificial Intelligence in Rac ... Computing the Racing Line
And back with the fix. It seems I do indeed get the track terrain data, and MUCH MORE! Correctly loaded
Edit: It isn't quite ALL the terrain, but it might be enough to work magic. The giant cliff "jump" at the FE1 chicane doesn't appear for me. But I think enough appears to block visuals appropriately, hopefully. Awesome!
And colored... Lighting was "dark" before from the ordering of the triangles in my rendering system. I win check that out! The cliff jump is there well enough! AWESOME.
Just in case someone may have missed it with the discussion that just took place, go check out this post where I linked to a video on youtube of all the computations taking place visually: Artificial Intelligence in Rac ... Computing the Racing Line
Last edited by blackbird04217, .
Reason : Updated broken links
Thanks Dawesdust, that actually looks pretty similar to what I have, which would be expected given the SMX is a specified format so the loaders will be the same. You can see my screen shot, perhaps you didn't yet, of what my outcome with the SMX file was. Not quite pretty. I wonder if Dygear has seen them in action and can let me know if my results are expected.
The next step I think I am going to take is making the visual sensor that will eventually be what the artificial driver will see, and judge distances from. A hurdle I have is I would like the terrain of LFS (at the very least) to block the line of sight like it would for us.
I tried loading the SMX file for Fern Bay hoping this would provide a simple mesh for the terrain, however, it does not. Actually I am quite confused what it contained. I loaded the format as specified, and do see a lot (too many drops the framerate without optimizations) of "objects" but they are not very useful from what I can tell. I tried both CW and CCW winding, and I can see what I guess are the pit lane garages, and some grandstands and many other "boxes" many more than I'd expect, flat ones, etc. I am 99.8% sure I loaded the file format correctly, and am displaying it as it should be, but the coloring was way off (too dark).
Does anyone have experience with the contents in the SMX files? And does anyone know a way I could get access to, at the very least generalized terrain data for the tracks (in specific Fern Bay Club at the moment). Is the following screen shot what I should expect (after changing the colors to a brighter 0xFFAAAAAA ARGB)
Fern Bay Simple Meshes Loaded
I tried loading the SMX file for Fern Bay hoping this would provide a simple mesh for the terrain, however, it does not. Actually I am quite confused what it contained. I loaded the format as specified, and do see a lot (too many drops the framerate without optimizations) of "objects" but they are not very useful from what I can tell. I tried both CW and CCW winding, and I can see what I guess are the pit lane garages, and some grandstands and many other "boxes" many more than I'd expect, flat ones, etc. I am 99.8% sure I loaded the file format correctly, and am displaying it as it should be, but the coloring was way off (too dark).
Does anyone have experience with the contents in the SMX files? And does anyone know a way I could get access to, at the very least generalized terrain data for the tracks (in specific Fern Bay Club at the moment). Is the following screen shot what I should expect (after changing the colors to a brighter 0xFFAAAAAA ARGB)
Fern Bay Simple Meshes Loaded
Last edited by blackbird04217, .
Reason : Updated broken links
So this has been out on youtube for about a week without announcement. Here it is finally. A video of how I computed the racing line for Fern Bay Club. I still need to clean up the code from the visualizers and make it perform in much less than visual time. But working with the visualizations provided a very neat way to actually SHOW how I've done this.
With that said, enjoy: (Recommend to watch in 720 to see the lines a bit better).
Artificial Intelligence in Rac ... Computing the Racing Line
With that said, enjoy: (Recommend to watch in 720 to see the lines a bit better).
Artificial Intelligence in Rac ... Computing the Racing Line
Depending how hard it is to change the racing line at that point I may try to do just that. (Remember the drive won't know the world coordinates of places on the racing line, only get to judge/know where it is from the reference points). My racing line does look like it would be faster in some parts, and ye the car width should keep two wheels on the surface at that part, I believe, but there is a BIG curb on that corner that would kill the speed, as it is the line I computed may have the right wheels taking too much curb on two of the corners.
Still a long ways from getting the driver to drive again, but I am happy with the progress. My next plan is to clean up some of the code, slow down and prettify the visualizer for the racing line part, and make a video of the process as well as write up a small paper on how I managed to have data only for the left and right edge of a track, and compute the racing line.
Also I will need to write a lot of the code again without a visualizer, to speed up the processing without the visualization so I am not forced to wait for it as I move forward with the project, but that should be relatively easy compared to what I just accomplished.
Still a long ways from getting the driver to drive again, but I am happy with the progress. My next plan is to clean up some of the code, slow down and prettify the visualizer for the racing line part, and make a video of the process as well as write up a small paper on how I managed to have data only for the left and right edge of a track, and compute the racing line.
Also I will need to write a lot of the code again without a visualizer, to speed up the processing without the visualization so I am not forced to wait for it as I move forward with the project, but that should be relatively easy compared to what I just accomplished.
Last edited by blackbird04217, .
That is actually a brilliant idea. I will certainly use add a quick loader just to see how this line compares with the racing line of FE1 once I get it computed. By the way, the second method is coming along quite amazing. It certainly still has some strange bug where the line bends in on itself, but once I get that figured out, I think this has a bit of promise. Here are a handful of screenshots...
Racingline Computation Screenshot 1
Racingline Computation Screenshot 2
Racingline Computation Screenshot 3
Racingline Computation Screenshot 4
Racingline Computation Screenshot 5
Racingline Computation Screenshot 6
It was showing some serious promise, and then somehow it still managed to get through the track edges... I don't quite understand that, but perhaps fixing the folding problem will avoid the edge problem?
That chicane is a beauty though! The red-line resembling the racing line started at the center line that I computed earlier.
.... Later .....
So I decided to tune the springs to be much softer, but this took 100s of times longer to compute. While letting this compute I started writing a new portion to the algorithm, I am going to constrain each of the nodes to only move left/right from where it originally started, which will be much easier and faster to compute if it is within track bounds. It is less physical since the node won't move around quite like it was prior to. While writing this I let the softer springs continue, which was quite promising. VERY SLOW. These shots are taken over almost 30 minutes or more and nearly 30k iterations. It did still cross the track so I decided to go add the new part of the algorithm. Shots of that will come later....
Racing line screenshot 1
Racing line screenshot 2
Racing line screenshot 3
Racing line screenshot 4
Racing line screenshot 5
Racing line screenshot 6 (off track)
Racing line screenshot 7
Racing line screenshot 8
.... Even Later .....
These are after 8k to 15k iterations, but took no more than 5 minutes and was "decent" after only seconds. I will slow it down in a final video. You can see it hasn't quite reached the edge of the final turn, this might be from the number of iterations, or perhaps just the algorithm has subtle weaknesses. I can say I am amazed with my results, which can be calculated (theoretically) for any track given the left and right edges. :-) Rock on!
The final results!!!!!!!!
Final Computer Racing Line Screenshot 1
Final Computer Racing Line Screenshot 2
Final Computer Racing Line Screenshot 3
Final Computer Racing Line Screenshot 4
Going to make a few adjustments and load up the LFS PTH files racing line as per Dygear's suggestion. That should be neat. ... It is neat: The gray line is the LFS line from the PATH file. It does point out my line has weaknesses and or is over using some curbs. I do know that I was a little too cautious when I created some track edges, and may not have been cautious enough in other places. Fairly similar but also different.
Racing Line Comparison Screenshot 1
Racing Line Comparison Screenshot 2
Racing Line Comparison Screenshot 3
Racing Line Comparison Screenshot 4
Racingline Computation Screenshot 1
Racingline Computation Screenshot 2
Racingline Computation Screenshot 3
Racingline Computation Screenshot 4
Racingline Computation Screenshot 5
Racingline Computation Screenshot 6
It was showing some serious promise, and then somehow it still managed to get through the track edges... I don't quite understand that, but perhaps fixing the folding problem will avoid the edge problem?
That chicane is a beauty though! The red-line resembling the racing line started at the center line that I computed earlier.
.... Later .....
So I decided to tune the springs to be much softer, but this took 100s of times longer to compute. While letting this compute I started writing a new portion to the algorithm, I am going to constrain each of the nodes to only move left/right from where it originally started, which will be much easier and faster to compute if it is within track bounds. It is less physical since the node won't move around quite like it was prior to. While writing this I let the softer springs continue, which was quite promising. VERY SLOW. These shots are taken over almost 30 minutes or more and nearly 30k iterations. It did still cross the track so I decided to go add the new part of the algorithm. Shots of that will come later....
Racing line screenshot 1
Racing line screenshot 2
Racing line screenshot 3
Racing line screenshot 4
Racing line screenshot 5
Racing line screenshot 6 (off track)
Racing line screenshot 7
Racing line screenshot 8
.... Even Later .....
These are after 8k to 15k iterations, but took no more than 5 minutes and was "decent" after only seconds. I will slow it down in a final video. You can see it hasn't quite reached the edge of the final turn, this might be from the number of iterations, or perhaps just the algorithm has subtle weaknesses. I can say I am amazed with my results, which can be calculated (theoretically) for any track given the left and right edges. :-) Rock on!
The final results!!!!!!!!
Final Computer Racing Line Screenshot 1
Final Computer Racing Line Screenshot 2
Final Computer Racing Line Screenshot 3
Final Computer Racing Line Screenshot 4
Going to make a few adjustments and load up the LFS PTH files racing line as per Dygear's suggestion. That should be neat. ... It is neat: The gray line is the LFS line from the PATH file. It does point out my line has weaknesses and or is over using some curbs. I do know that I was a little too cautious when I created some track edges, and may not have been cautious enough in other places. Fairly similar but also different.
Racing Line Comparison Screenshot 1
Racing Line Comparison Screenshot 2
Racing Line Comparison Screenshot 3
Racing Line Comparison Screenshot 4
Last edited by blackbird04217, .
Different iterations of the same algorithm yes.
Racing Line, not quite there...
Racing Line, still not there...
So, my current algorithm is not working. Actually a few things I have made note of from these results is somehow the racing line is pushing itself out of bounds of the track edges... Interestingly I did put code to collide against the edges and keep the nodes of racing line within those bounds... Not working. Hmm.
I need a bigger bag of magic.
Racing Line, still not there...
So, my current algorithm is not working. Actually a few things I have made note of from these results is somehow the racing line is pushing itself out of bounds of the track edges... Interestingly I did put code to collide against the edges and keep the nodes of racing line within those bounds... Not working. Hmm.
I need a bigger bag of magic.
Last edited by blackbird04217, .
Oh yes. Oh yes...
This is a much better way to compute the centerline, much smoother - mostly from having more points, and more flexible. Still not perfect by any means, but I think it forms the center line well enough for me to move onto the next step... Rather than post another temporary video I will throw up a few screen shots of the old problem spot, and wait until the next step is complete for a more complete video.
Screen Shot of Visualizer
Old Problem Spot 1
Old Problem Spot 2
Full FE1 Track
You can see how the centerline no longer doubles back on itself with this new algorithm. Now time to make the center line turn into the racing line!!!!! This step should involve a bit of magic, so I am digging for the bag of pixie dust.
This is a much better way to compute the centerline, much smoother - mostly from having more points, and more flexible. Still not perfect by any means, but I think it forms the center line well enough for me to move onto the next step... Rather than post another temporary video I will throw up a few screen shots of the old problem spot, and wait until the next step is complete for a more complete video.
Screen Shot of Visualizer
Old Problem Spot 1
Old Problem Spot 2
Full FE1 Track
You can see how the centerline no longer doubles back on itself with this new algorithm. Now time to make the center line turn into the racing line!!!!! This step should involve a bit of magic, so I am digging for the bag of pixie dust.
Last edited by blackbird04217, .
Reason : Updated broken links
By my current definition of the algorithm it is fixed, but it by no need actually needs to be fixed. I plan on running optimizations to the "racing line" once it is finally computed, in that if three points are all in a straight line, remove the middle point.
There is no reason this first algorithm couldn't have "some distance" change depending on the angle changes of last few points, I will try to keep this in mind, but at the current time I will leave it fixed and optimize straights once the final data comes, this actually might be crucial for the way I plan to use springs to find the actual racing line.
There is no reason this first algorithm couldn't have "some distance" change depending on the angle changes of last few points, I will try to keep this in mind, but at the current time I will leave it fixed and optimize straights once the final data comes, this actually might be crucial for the way I plan to use springs to find the actual racing line.
That is close to the plan I started implementing last night, with a bit of a difference. I will find the first position exactly as I did with the first algorithm; as you see in the video, and with that I will have the forward direction from that. Using the center position, and moving along the forward direction I will travel "some distance". I will place a temporary position there, and extend both left and right until collisions occur. Which I can then compute the actual track center at that position. I will then get a new forward direction based on the previous position and current position and continue.
The issue I am having here though, is how to know when I've travelled all the way around the track and reached the end again. I suppose a simple radius check will work, as finding a new position "close enough" to the first position would then say the track is completed.
This new algorithm is better in two ways, it will be adjustable roughly how far between each center point is and it should be more accurate, although that will need to be seen. It shouldn't suffer from the same issue anyway.
The issue I am having here though, is how to know when I've travelled all the way around the track and reached the end again. I suppose a simple radius check will work, as finding a new position "close enough" to the first position would then say the track is completed.
This new algorithm is better in two ways, it will be adjustable roughly how far between each center point is and it should be more accurate, although that will need to be seen. It shouldn't suffer from the same issue anyway.
AI Racing Project
Just wanted to try capturing the attention of others that may enjoy my thread on Artificial Intelligence in Racing Simulations, found in the programmers section. A bit off the beaten course, but some of you may still find it interesting. Feel free to subscribe so you can follow the progress, and please leave any comments in that thread.
FGED GREDG RDFGDR GSFDG