Still doing testing with the fast line generator this week. It is actually a data structure called fastSplineSt that has a butt-load of functions... and probably about 4 to 5 thousand lines of code. Testing has been going so well, that I started worrying that it hasn't been tested in enough different track environments. Don't want the testing to be so specialized for these few test tracks, and fail on others. I've been using about 7 tracks, and to get variety, been doing some of them forward, backwards, upside-down, and upside-down-backwards. So.... I wrote a little stand-alone script a couple of days ago that reads aiw files, and creates enough 3dsMax objects to pretty quickly build a track surface, pits, and some 25m terrain around the perimeter in Max. It seems to be quicker than using the gmt --> max converter, because I don't have to worry about materials, and try to decipher which names in the file are the track, pit, and terrain surface(s)... which is mostly what I need. Some of the object names in these track files are too abstract for my meager 'merican mind... but aiw files are just coordinates, so much easier. Before anyone asks for this little test track building tool... the answer is: "No way". Pretty sure it would piss-off a bunch of people, and wouldn't be too ethical. Yesterday, I completed test tracks for Zolder, Watkins Glen, Surfers Paradise, and Spa. Today I'll start making the rest: Silverstone, Shanghai, Sebring, Nordschleife, Singapore, MoSport, Monza, Montreal, Monaco, Long Beach, Lienz 24hr, Istanbul, Interlagos, Estoril, and the long track at Le Mans. Ran the script on all of them during the NBA Draft last night, so today I'll start crafting more tracks out of the parts it built in the Max files. Hopefully this mix of cadd-designed, and natural terrain tracks will help me find weak or broken areas of aiw~thing that it hasn't 'seen' yet. Not terribly fun, but should be an efficient bug catcher. View attachment 17159
Nice work Bink. If ya feel like adding a small dirt oval to your testing I've got a few awaiting your tools completion
Thanks Butters... [Is that an offer to a pm link for your dirt oval? If so, it'd be handy to have a max file for just the track surface.] Finished building the (above mentioned) 20 test tracks early in the week. Took about 3 days. Found and fixed a couple little (non fast line) things that showed up already. Wrote some test code for the 'fastLine viewport follow' in the spline editor that worked great. I'll implement that after getting these fast line issues ironed out. Also found a couple of max api functions that I wasn't aware of before which will hopefully speed up 'ori' and other calculations, so I'm glad I took this detour. Having all these test tracks to generate fast lines on is really helpful. Main thing that needs work are short straights bounded by opposite direction corners... particularly shallow chicanes. I noticed this on Toban (long) several months ago... not a show stopper, but not as good as it could be. Found the same thing at Le Mans, and Surfer's Paradise this week. Already have an idea on how to resolve them, so working on that presently. It's weird, but as the fast-line data struct gets more complex, you start seeing things while testing that aren't just right, and it's not always completely clear 'who did that'. So I installed debug code a week ago that lets me click on the fast line and print out precisely which functions went into the decisions on how to make the line in that particular track section. Its been a big help with testing. There're reasons we haven't seen 'fast line generators' offered commercially. The variables amount to: "any track anyone (or nature) has ever thought of". So... it's not the easiest thing to formulate, without resorting to trial & error (simulate & test), which would adversely affect the amount of time it would take in Max. In contrast, I've been calculating where the fastSpline vertices, vectors, and control handles need to go BEFORE building it. May not be as easy as brute force, but better suited to the platform I'm writing for, and pretty quick to crunch.
How's things going Bink? Managing to win on ironing things out or taking a well deserved break? Sent from my GT-I9505 using Tapatalk
Hey Butters, [thanks for pm'ing Wellington... impressive track & facility you built there.] I take a day off once a week to help friends get their cars ready for races the following weekend. They race on dirt ovals... one owns a sprint car team, the other races stock cars. Most of it is suspension work, as people tend to run in to each other pretty often in those series. Last week was replacing a bent 'A' arm, and splicing together a new drive shaft. The other 6 days of the week I've been working about 10 to 12 hours a day on aiw~thing. As posted above, I made 20 more test tracks recently, and have started to go through them to find things that the fast line generator could do better, and other corner sequences that it needs to 'know' how to handle. The first I started on was Estoril (found & fixed 3 bits of weirdness), and the current one I'm working on is Interlagos (found 2 more issues). Two of those problems (used to) also exist at Le Mans, so I should find less and less as I go through these 20 tracks. The final track will be Nordschleife... the green hell. For the past few days I've been teaching myself how to write vector calculus test functions in maxScript for the purpose of finding the fastest (quadratic) spline around corners that start loose then get tighter (or others that do the opposite). Finished writing the real function last night before dinner, and will start testing it this morning. Most of the changes are replacing bits of code where I had previously 'estimated' things that I now calculate precisely. Probably would have been easier to learn this kind of math 50 years ago, but never had the opportunity of a formal education. Better late than never. It's much faster (for the user) if the entire spline is calculated (control points and io vectors) before ever building the fast line. For an average 4km fast line, the whole process currently takes about 5 to 10 seconds. The fast line generator is about 1/7 of the 30,000 lines of code that comprise aiw~thing. Been thinking I should do another 10 minute video on completing an aiw file now that the control panels have all been standardized and include indicators to better guide you through the process. There are also a number of 'steps' (controls) in the process that I found ways of calculating rather than having the user select or do things..... so it's gotten smaller, easier to use and understand as well as more accurate. I know it must be terribly frustrating waiting for this thing... (and boring reading these posts)... but hopefully it will be worth the wait. Fast line computation... "..is like mathing about poetry". [zappa]
Never get bored reading these posts and I would say excited over frustrated knowing that it is still in progress. Would love to see an updated video as a teaser of what's to come. Your work on this is very much appreciated Sent from my GT-I9505 using Tapatalk
Thanks for the props WiZPER, mschreiner, and Butters.... I'll probably get to the video in a few weeks (next time I wake-up and don't feel like working in the fastSpline data structure). Too much momentum on this stuff to stop atm. Got the new spline fitting function running last night. Up till 3am (w/ pencil & quad-paper) thinking about other fast-line applications for it: (loose-tight, loose-short_straight-tight, and their mirrors, + corners close to 180 degrees). It excels at corner sequences where the 'fastest' path is NOT necessarily hugging the inside all the way through. Today I'll start to make it generic enough to use for some of these other curve sequences. It's pretty quick, given it's written in a scripting language (extra layers between the code and processor). The 'old' way I was doing it took about 0.9 sec per corner sequence... and was less accurate. This new function did the same (Fuji test bed) corner sequence in 0.008 sec. ... so more than 100 times faster per usage. English: I can feed it the apices and their driving directions... and it outputs the shortest legal (between corridors) path that requires the least steering angle input from the car. Nerdlish: Data returned are apex Bezier handle vector magnitudes and (where necessary) intermediate spline control point parameters. So... a new weapon in the 'fun with cubic splines' ordeal.
Amazeballs!!!!!!! Look forward to the video in a few weeks hopefully Sent from my GT-I9505 using Tapatalk
Hey, Juergen-BY... bitte sehr! A few years ago, I was having trouble getting rF1 DevMode to make an aiw file for a 30km track. Any time it got above ~8000 waypoints, it went to (win xp) blue-screen-of-death. Bought 3dsMax + win7... then sat with an existing aiw file, did some rough calculations and made a little drawing to try to visualize what some of these aiw parameters looked like. Once I could 'see' the parameters in 3D, I realized it was probably possible to make an aiw file using the 'Max api. So... aiw~thing kind of started rolling with this little drawing: View attachment 17554
So.. new data structure for this vector calculus stuff I've been working on. This allows for making it generic enough to navigate a generalized set of corner types and combinations that can show up on our tracks. The original framework is still used, but now it serves up the control points that this new code eats to find the best 'here to there' paths. It's not always the shortest path, but rather the one that allows for the car to maintain the highest momentum. With the vector calc structure in this new modular form the code is able to swap in & out small core modules that specialize in certain types of straight<-->corner-corner, and corner-->straight-->corner sequences. The first one implemented was the most basic one: same direction corners with a short straight between them. Today I'm working on a 2nd module to handle entry, traversal, and exit of corners close (enough) to 180 degrees, such that they can't be treated like 'normal' corners. "Close180's" used to be more difficult when asymmetrical.... not anymore. Next week will be fitting opposite direction corners (or corner combos), with a short straight between them. The final implementation will be for "stranded sequences" of corner types (those not bounded by straights). Doesn't sound very exciting, but it's pretty fast and accurate.... and for me, it's one of the weirder bits of work on this aiw~thing so far. Making an aiw file (in retrospect) was pretty easy. 'Learning' a fast line is by far the more difficult part of this thing. With this new struct, it's getting easier each day. [It also helps that we no longer have to worry about how poor Kimi will be able to support himself next year...] aiw~thing internal structure(s): View attachment 17654
That's an impressive list of features. Thanks a bunch for the update. Sent from my GT-I9505 using Tapatalk
Thanks Butters... The function that 'fits' corners close to (or at) 180 degrees worked well yesterday. It provides a constant radius whether the corner is asymmetrical or not. ...... View attachment 17674
