aiw~thing video (6)

Discussion in 'Track Modding' started by Bink, Feb 13, 2015.

  1. Bink

    Bink Registered

    Joined:
    Nov 20, 2011
    Messages:
    523
    Likes Received:
    2
    Hey Mario,

    Hard to know exactly why some things are done in aiw files unless you have signed a "non-disclosure" agreement with ISI (which I have not).

    Like pre-production work in entertainment, it's useful to do as much work as you can before the show, so you don't have to try to make it or figure it out during the show.

    With rFactor, the more of the environment, limits, and paths you can calculate in devMode and store in a static aiw file... the less you have to do during the real-time race simulation. If you tried to do all this in real-time (like the Mars Rover), your execution time would suffer.

    About your questions:

    (Read somewhere): wp_pathinfo2[3] is elapsed time since last wp, and wp_pathinfo2[4] is time in this sector 'so far'.

    (Guess..) Regarding why the orientation (pitch, yaw, roll in radians) at each path point.. on each wp.. for every drive line:

    Say you have 2 drive lines (fastest and block) that are on intersecting paths on a banked corner:

    -- At a certain waypoint, the Fastest line is pointing a little bit down the banking.
    -- At the same waypoint, the Blocking line could be pointing a little bit up the banking.

    So the car's loading, traction, aero, and a bunch of other things are different for each drive line... at the same waypoint.

    If rF can always know the approximate orientation of each ai path via pre-calculated ori, it saves processing time during the race. The simulation could also use it to mimic a real driver that can actually see the track.... software for the ai cars can 'look-ahead' at the ori, and 'know' when to brake for a corner, or speed up when the path is going to straighten out.

    It also 'knows' ahead of time how much the car weighs, how many micro liters per radian of crank-shaft rotation that the fuel usage is.... and bunch of other stuff in files for the various mods.

    Probably some pretty compelling reasons for independent ori for each line, or it would not have been a newly added set of parameters to each wp block in rf2 aiw files.
     
  2. Radar

    Radar Registered

    Joined:
    Oct 20, 2010
    Messages:
    687
    Likes Received:
    60
    Hi Bink, any more updates on when we may see this tool?
     
  3. WiZPER

    WiZPER Member

    Joined:
    Oct 5, 2010
    Messages:
    1,521
    Likes Received:
    186
    Listening in... :)
     
  4. Bink

    Bink Registered

    Joined:
    Nov 20, 2011
    Messages:
    523
    Likes Received:
    2
    G'day Radar... Hvordan gar det, WiZPER?...

    Long Version:

    Spent the last two months re-writing / re-structuring the "Learn" functions. They are in the machine learning 'ai' struct of the script (fastSplineSt). The methods used previously weren't always accurate... particularly on corner sequences where the track gradually tightens or loosens.

    An extreme example of these variable radius spiraling corners (like Shanghai turns 1 & 2 ... and turns 12 & 13) are about 270 degrees per pair. The old 'learning' functions didn't have a way to 'recognize' variable radius corners as such. The new methods can now handle them up to ~ 460 degrees. [With anything more than about 460 degrees, there is not enough space to get the track to come out of the inner spiral, so it is a less likely track design.] Now the 'learnFast' functions can 'recognize' these situations and store enough data about them, so that the 'plotFast' functions can 'know' how to navigate them.

    There were other things that it didn't 'know' how to detect and properly handle... situations like Abu Dhabi turn 7... or the "Andretti Hair-pin" at Laguna Seca. When you see these types of corner sequences, they can look like corners that are close to 180 degrees... when actually, they are 2 corners close to 90 degrees, separated by a short straight, or short loose curve. There are 2 apices, and when watching races, drivers in most series tend to turn in late and skip the first apex, and then exit using only the second apex. This driving line gives the (very close) pair of corners a longer radius arc through the sequence, and results in a faster path.... Now it's no longer a problem for aiw~thing to deal with.... it 'knows' when to skip the first apex, and where to turn in when doing so.

    Several other on track 'situations' are also remedied with these changes. Won't go into them now... so as not to further bore you, but all together, re-writing the 'learn' functions was a much better way of dealing with them than piling on 'patches' would have been.

    Also got rid of the last of the "magic numbers". Early on (a couple of years ago) in the rev1 of the machine learning part of this software, there were quite a few "magic numbers" which when plugged in to various processes, yielded 'reasonable' results most of the time. Little by little, as I got a feel for how everything I had written actually worked, I began to see the math that actually made these numbers work. The last of the magics got 'mathed-out' this past weekend (a 2am epiphany).

    So... with these more extensive sets of data available, I'm a day or so away from finishing the rev3 'learn' functions, and can get back to parameterizing the vector calc functions in the 'plot' decision handlers that actually navigate everything that was learned by the new 'learn' functions.

    While re-writing the 'learn' stuff, I had to build a bunch of test tracks to test the range of sizes and angles that all these corners (and corner sequences) could assume. It wouldn't have been good enough to merely 'hope' things worked out.... so I build tracks to test everything. These same tracks will come in handy when I start plotting driving lines again (hopefully this weekend).

    I'll start posting images for these new driving line generations once I can output them again. Haven't posted lately, as it's been mostly data and formulas (hard to see if you haven't escaped the matrix..). It's been tough figuring out how to sequence all the 'learn' stuff, and it will be more relaxing working out the vector calc parameterizations in the coming weeks. Film at 11...

    Short Version:

    View attachment 19210
     
  5. WiZPER

    WiZPER Member

    Joined:
    Oct 5, 2010
    Messages:
    1,521
    Likes Received:
    186
    Hej, Bink! Det går fint, tak :D

    Thank you for the update, I won't claim that I fully understood everything, but what I did made a lot of sense. I'm impressed with your dedication and can't wait to get my hands in it - keep up the good work :D
     
  6. mschreiner

    mschreiner Registered

    Joined:
    Oct 5, 2010
    Messages:
    333
    Likes Received:
    90
    Sounds very impressive! Been waiting a long time to test drive this ~Thing~ LOL
     
  7. lagg

    lagg Registered

    Joined:
    Oct 1, 2012
    Messages:
    1,614
    Likes Received:
    1,021
  8. Bink

    Bink Registered

    Joined:
    Nov 20, 2011
    Messages:
    523
    Likes Received:
    2
    Thanks guys..

    Yea, I'd like to be done with it too. There are some other projects I have an eye on developing (in different fields), but aiw~thing is a solid enough bit of work to merit completion. There's also going to be a bit of baby-sitting needed after it's finished as well.

    When you're this far into a project, and you see something that can make it better, it's tough to resist taking steps to implement it. This most recent bit... re-writing the "learn" functions for the fast-line generator had too good a set of potentials to resist. Over the past couple months of re-structuring it, I've finally gotten back to where I was two months ago... but with more comprehensive abilities available.

    How it works:

    In the unlikely circumstance that anyone is still reading this post, I can tell you that there is not any magic algorithm or formula.

    Over this development, I've shared some of the goals with tech oriented friends. Early on, one of them who's a mathematician was convinced that this was some variation on the infamous "Traveling Salesman Problem"...[because, to a hammer, every job looks like a nail]. Well, it's not even close to being that problem. The fast-line problem is a closed circuit, and so, is serial in nature.

    Most of the others said something like, "I'd be interested in seeing your algorithm.." (which is the polite way of saying, "you're f__in' crazy").

    All I've done is to just split the problem into a bunch of little problems (sections of track).

    It breaks down into where you are, where you came from, and what's ahead of you. There are a finite number of general corner types, corner sequences, and types of straights that you can find looking at various road courses around the world. If you can generalize them as ranges of situations and relate them as ratios of average angles, or lengths / widths.. with respect to those around them, then you can come up with a finite set of solutions.

    For non-programmers: In programming, you solve things with functions or methods. They look like this: paintTheHouse mainColor trimColor. In this example, the bold type is the function name, and the italics are the arguments. There is a block of code after the function name & arguments that does the work based on the parameters (the color arguments). After it's written, all you have to do is write it's name and provide the arguments, and the language 'calls' the block of code, and does the work (tailored by the arguments).

    For aiw~thing, I've written a moderately complex set of 3 "vectorCalc" functions. They have about 9 arguments, and each of them can solve a general set of straight, corner, or corner-sequence problems and 'fit' the fast line through that particular section of the track. Each "solution-slot" gets called based on where you are (say.. a straight), what's behind you (a corner or corner-sequence), and what's ahead (another corner or corner-sequence).

    The set of generalized situations you can find on various tracks ends up being a relatively large number.... with the categories of straight, corner, and corner-sequences I have generalized, it comes out to needing hundreds of solutions to solve anything you may come across on a track. As you have seen from my fast-line postings, these solutions work pretty well.

    So the "learn" part of the program breaks the track into parts, and labels each part with the proper sub-types. The "plot" part of the fast-line generator goes through the track sequentially, and "points" to a specific solution based on the sub-type of the piece of track you are sitting on... the sub-type of the piece of track behind you... and the sub-type of the piece of track in front of you. Based on those 3 sub-types, the program "points" to one of the solution-slots.

    The test track I posted on post #97 of this thread used about 50 of those 'solution-slots'. For each solution-slot, I write the name of one of my 3 vectorCalc functions, and figure out the 9 arguments after it (based on what the solution requires). When a track has that particular situation, the program calls that solution, and finds the fast line with the least angle of arc that is within the corridors... through that particular section of track. Then, it goes to the next section, and calculates the spline's math (only) in it.... etc... etc... until the entire track is done. When that is finished, the "Build" button gets enabled, and pushing it uses the previously calculated positions, vectors, and vector magnitudes to build the 3d (fast) spline in 3dsMax.

    That test track in post #97 was my way of seeing if this process would work... and if you look at those images, it performed pretty well.

    As I said, there are 'solutions-slots' for hundreds of situations.... and as of this moment, only the 50 or so of them have had one of my vectorCalc functions parameterized in it. Many of them will never be 'called', unless someone designs a really dumb track. But to be complete, they need to be there. So I've got the rest to 'fill in' now. They each take about 5 minutes for me to parameterize, then test on one of the test-tracks I've made. Each test track covers the range of configurations each solution could be, and most cover several solutions.

    If, in the future, something comes up that doesn't fit neatly into one of my general categories of straights, corners, and corner-sequences, it's easy to add more 'solution-slots' to the program.

    There's nothing magic about any of this, no genius necessary, no secret formulae.... just brute-force, and at this point, quite a bit of grunt-work ahead for me.

    So.. "holy or lying" - neither..... "f__in' crazy?" - perhaps, but as the images on post #97 illustrate, this is all very doable.
     
  9. mschreiner

    mschreiner Registered

    Joined:
    Oct 5, 2010
    Messages:
    333
    Likes Received:
    90
    Very impressive! Keep up the good work! I am just glad someone like you had the patience and drive to start and finish a project like this.
     
  10. Bink

    Bink Registered

    Joined:
    Nov 20, 2011
    Messages:
    523
    Likes Received:
    2
    @mschreiner... thanks.

    Sorry about the novel in post #128, but I was trying to find a way to illustrate where the project is at... and what it requires. It would be great to be able to give a finish date, but I've never written a program that does this specific set of tasks, and there doesn't seem to be any prior examples published to gauge a time-line from. So "finished" will be when it's stable and does the things we expect it to do.
     
  11. Bink

    Bink Registered

    Joined:
    Nov 20, 2011
    Messages:
    523
    Likes Received:
    2
    Howdy...

    Had jury duty which didn't allow me to work on aiw~thing for the past couple of weeks. If you don't have jury duty in your country... it fits somewhere between death & taxes in the scheme of things.... and every bit as pleasant. Wikipedia probably has a more apt description.

    Prior to that, the first 2 weeks of the month were quite productive... just not on what I thought it would be:

    There was a fast line problem that I was aware of on a previously posted test track (here: View attachment 19471 ). If you look in the upper right corner of the image... near xSector2 you'll see it. Made some refinements to the existing code and inserted an extra process in the sequence to ensure that this is now properly calculated (can't happen anymore).

    While I was fixing that, I found a separate issue with finding the driving line vectors along straights that showed up on a different one of my test tracks. It also manifested on one of the non-Tilke European F1 tracks. The bad news is that I spent about 4 days re-writing (and making more robust) several functions where I thought the problem was... but it turned out to not be the problem. The good news is that the problem was something easy somewhere else... and the functions I re-wrote will make things more accurate (faster line) entering and leaving long straights.

    Lastly, in a different area of the fast line data structure, there was something strange going on in a recursive function that handles the calling of a mildly complex set of other functions.

    For non-programmers: The Recursive Function (in this case) is one that does as much of the solution as it can, and then... calls itself to try and solve the remainder of the original objective. As you might guess, you can end up with many instances of the function working on different parts of the same problem. Eventually each thread backs-out of the 'youngest' one of itself, and goes back to an elder (caller) of itself to continue solving the rest of the goal... now that it has the data to do so. Generally a pain in the ass, but elegant when executed properly. For some tasks, it's the only reasonable way to solve them.

    Like most recursives, it became weird to trouble-shoot because it was difficult to know exactly which of the 20 something instantiations of the original function (and other functions which they can call) that could be causing the problem. Also, different situations (tracks), because of their design, necessarily spawn different quantities of this function's instances. So for each different situation, you have to learn how it is choosing to work, before you can find the turd in the punch bowl. Eventually resolved it, and life was good again.

    Sorry I was not more specific about some of these things above... doing so would have taken forever, and I need to get back to the combinatorial grunt work I had intended on starting early in the month.

    Hope to have some new shinier objects to post images about soon.
     
  12. Hazi

    Hazi Registered

    Joined:
    Jan 15, 2012
    Messages:
    766
    Likes Received:
    76
    :confused: but nice to read anyway.
    TIA
     
  13. WiZPER

    WiZPER Member

    Joined:
    Oct 5, 2010
    Messages:
    1,521
    Likes Received:
    186
    Thanks for the update :)
     
  14. lagg

    lagg Registered

    Joined:
    Oct 1, 2012
    Messages:
    1,614
    Likes Received:
    1,021
    Thank you for the info Bink.
     
  15. Bink

    Bink Registered

    Joined:
    Nov 20, 2011
    Messages:
    523
    Likes Received:
    2
    Found and fixed a flaw in some of the test track fast line code that I'd previously posted images of (above):

    View attachment 19505
     
  16. Bink

    Bink Registered

    Joined:
    Nov 20, 2011
    Messages:
    523
    Likes Received:
    2
  17. Butters

    Butters Registered

    Joined:
    May 20, 2011
    Messages:
    134
    Likes Received:
    0
    Cheers for the updates Bink. Hope all is well on the health front.

    Sent from my SM-G928I using Tapatalk
     
  18. Bink

    Bink Registered

    Joined:
    Nov 20, 2011
    Messages:
    523
    Likes Received:
    2
    Thanks Butters... Evidently, I still have some upgrade tokens available.
     
  19. Bink

    Bink Registered

    Joined:
    Nov 20, 2011
    Messages:
    523
    Likes Received:
    2
  20. Jka

    Jka Member Staff Member

    Joined:
    Jan 31, 2011
    Messages:
    921
    Likes Received:
    184
    ...which was already ended... Waiting for next sessions... :D
     

Share This Page