![]() |
|
windows build + cars - Printable Version +- Forums (https://www.vdrift.net/Forum) +-- Forum: Project (https://www.vdrift.net/Forum/forumdisplay.php?fid=4) +--- Forum: Development (https://www.vdrift.net/Forum/forumdisplay.php?fid=9) +--- Thread: windows build + cars (/showthread.php?tid=1031) |
- zimluura - 12-16-2008 thelusiv wrote: Here's how I understand the suspension hinges. The suspension does not follow a straight up-and-down path. Instead it follows a curve. This curve is defined by the hinge point indirectly. It's as if the wheel itself was attached by a straight rod of some kind from the hinge point to the center of the wheel, and the hinge allows up-down movement. Take for example the front wheels, which usually have a hinge point behind them. So if the wheel moves up, since its attached to the hinge behind it, it's also going to move towards the back of the car a little along the curve. The big difficulty in this is predicting how the car will react under this movement. ok, so i think i see how hinge works. it's L/R coord's sign is a reverse of what the associated wheel has because the actual single conceptual hinge-point is so far behind its wheel that it's literally outside of the car on the other side. with that in mind my plan is to make a pass at the hinges of all the cars i've done thus far, and set them as such. and then resume work on teh other cars. also, i happen to notice on my own usdm tc6's rear suspension that: as the springs compress it's wheel moves noticeably toward the rear of the car. with only 2 points involved in the suspension, i'm guessing this isn't modeled in the physics yet. is that correct? or is the 3rd point derived from the wheel position? =========== edit, i'm noticing some strange things with some of these hinges. lots of hinges have an L/R position at 0. tc (& tc6 which i copied suspension) seem to have had their hinges originally right next to its own wheel. so virtually no suspension travel. in these cases should i try to tune each car so that the hinge is somewhere near/past the opposite side's wheel? a change like that will need to be tested a bit for each car () and might require extra changes to be made to the spring tension. or should i just try to get the coords and signs swapped to just update each one? - joevenzon - 12-17-2008 zimluura Wrote:ok, so i think i see how hinge works. it's L/R coord's sign is a reverse of what the associated wheel has because the actual single conceptual hinge-point is so far behind its wheel that it's literally outside of the car on the other side. Here's an awesome old post by reece that describes how the hinge should look with different suspension types (with pictures): http://vdrift.net/Forum/viewtopic.php?p=7531#7531 It almost makes me wonder if the .car files should just define the suspension type, and then vdrift would automatically place the hinges in a location that made sense... maybe that's an idea for the future. Anyway, I *think* the hinge point should be placed halfway between the "Side view IC" and "Front view IC" points on the "Instant Axis" line on the third diagram from reece's post. With the refactored code, the anti-squat and anti-dive will be dependent on where the hinge is placed. Quote:also, i happen to notice on my own usdm tc6's rear suspension that: as the springs compress it's wheel moves noticeably toward the rear of the car. with only 2 points involved in the suspension, i'm guessing this isn't modeled in the physics yet. is that correct? or is the 3rd point derived from the wheel position? The way the hinge point works in VDrift (with the refactored code) is: as the springs compress the wheel moves around the curve defined by the perimeter of a (vertical) circle with its center at the hinge point. So you can get the behavior of the wheel moving to the rear of the car as the spring compresses by placing the hinge point forward of and above the wheel. Does this make sense? Quote:edit, i'm noticing some strange things with some of these hinges. lots of hinges have an L/R position at 0. tc (& tc6 which i copied suspension) seem to have had their hinges originally right next to its own wheel. so virtually no suspension travel. in these cases should i try to tune each car so that the hinge is somewhere near/past the opposite side's wheel? a change like that will need to be tested a bit for each car () and might require extra changes to be made to the spring tension. The old vamos physics had hinge code that wasn't working right, so most of the cars have either: zeros, values that were by trial and error and give good results with the buggy vamos code but aren't realistic, or values that were placed realistically as if the vamos code worked like it was supposed to. So, feel free to move the hinges to places that make sense. I also noticed wikipedia has some info about the "hinge" point, which in car lingo is (I think) the "Instant Center": Quote:Instant center (In VDrift we don't simulate the IC moving as the suspension is deflected, we just approximate with a single IC point.) from http://en.wikipedia.org/wiki/Suspension_(vehicle)#Instant_center - zimluura - 12-18-2008 ok, that all makes pretty good sense to me. i've gotten about half the cars converted, most of which are committed too. i'm sorta in the zone for doing the coord swapping now. when the suspension hinges L/R point is non-zero i'll keep it the same but adjust the sign so its on the opposite side of the car as the wheel it goes with. i sorta like the idea of just make suspension types to choose and have the game set things up appropriately. but i also still like the idea of a physics experiment land where cars can be dropped, observed under speed, and turning, and on bumpy or smooth roads. and all positions can be indicated over a semi-transparent car you could pan around. i sorta think something like that will need to happen eventually to get all the values really realistic. but that's not something that needs to happen for me to finish converting the cars and re-positioning drivers. - zimluura - 12-18-2008 ok, it's done. everything is converted to v2. and the driver positions are mostly good. some smaller cars will not work until there's some kind of driver scale option. but evenso the driver doesn't look horrible. the c7 has an opaque windscreen, but the hood-view will still work. the m8 and the xm aren't converted. i have done the files for them. but since i can't test them (or figure out their driver positions) i haven't committed them. i can write a torque curve for the xm and get that working if you want. same goes with the m8 if you can tell me what it needs to make it load. fuel tanks might be on the wrong L/R side, or they might be correct, really just something i can't be sure of. all contact point sections have been removed (added as particles for points over 1kg) - joevenzon - 12-19-2008 Nice work! It looks really good: http://vdrift.net/Gallery/media.php?f=0&sort=0&s=20081218213852391 Now I just need to finish re-implementing shadows and it'll really look cool with the driver casting shadows on everything.... - joevenzon - 12-19-2008 I fixed the M8's loading problem, so it's ready to be converted. If you can find a torque curve that seems reasonable for the XM (M3 GT or GTR, maybe?), go for it. - zimluura - 12-19-2008 ok, the m8 and xm are in and working and committed with decent driver positions. now having a hard time building the new bullet: /bin/build_bullet.sh: ./configure: No such file or directory Jamfile: No such file or directory Compiler is GCC with Mingw ...found 7 target(s)... Jamfile: No such file or directory Compiler is GCC with Mingw ...found 7 target(s)... any ideas? edit: that screenshot looks tight! - joevenzon - 12-19-2008 With the new bullet they added a new first step: you have to run ./autogen.sh, and then that creates the ./configure. - zimluura - 12-19-2008 yeah, i tried that and get this: /d/vdrift/source/bullet-2.73 $ ./autogen.sh running aclocal ./autogen.sh: ./aclocal: is a directory An error occured, autogen.sh stopping. edit: actually that's wrong, i looked around and someone somewhere on the net about making an aclocal directory, so i did that and got that error message. the one i got before was similar. after some research it looks like i need to get automake for msys as well. edit: ok, now i have aclocal, but the build_bullet script isn't seeing it yet. working on it. edit: worked a bunch on this yesterday. got a little further, but the version of automake that's in the msys dtk doesn't quite do it. some error about a non-existent single quote on line 2 of a make-file. this site looks like the one i'll be needing to read. http://ffmpeg.arrozcru.org/wiki/index.php?title=Installling_newest_autotools ahh, compiler hell. time to get some coffee - zimluura - 12-20-2008 omg this is involved. hey joe, any ideas for a real up-to-date and capable version of msys & mingw? or something that can just handle building bullet? should i maybe get the old bullet? - joevenzon - 12-20-2008 I'll fiddle around with it today or tomorrow and see what I can find out. In the mean time, if you still have the older version of bullet (2.68) and just rename the folder to be the same as 2.73 VDrift will probably work just fine. - joevenzon - 12-20-2008 Okay, you need to install the MSYS developer's toolkit (DTK). I added a link to the wiki: http://wiki.vdrift.net/Compiling#MSYS_DTK This will install automake/autoconf and perl (which is a real pain in the ass to install otherwise, and is needed for autotools). I updated the windows scripts tools/win/setup-win32-dev-environment.sh and build_bullet.sh in R2265. It turns out the msys autoconf creates a screwed up corfigure file, so I have the scripts copy one over that I generated in linux. Man, I hate autotools. Anyway, *should* all work now. - zimluura - 12-20-2008 after the stuff i tried yesterday, i also hate autotools. still a few things that aren't working: when running build_bullet.sh configure.ac:120: error: possibly undefined macro: _AC_SRCDIRS If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. ... ... ... checking how to disable C++ exceptions... -fno-exceptions ./configure: line 21217: syntax error near unexpected token `_AC_SRCDIRS(".")' ./configure: line 21217: ` _AC_SRCDIRS(".")' Jamfile: No such file or directory Compiler is GCC with Mingw ...found 7 target(s)... Jamfile: No such file or directory Compiler is GCC with Mingw ...found 7 target(s)... when running build_vdrift.sh c:\applications\development\mingw\bin\..\lib\gcc\mingw32\3.4.5\..\..\..\..\mingw 32\bin\ld.exe: cannot find -lbulletcollision collect2: ld returned 1 exit status scons: *** [build\vdrift.exe] Error 1 scons: building terminated because of errors. - joevenzon - 12-20-2008 zimluura Wrote:checking how to disable C++ exceptions... -fno-exceptions The ./configure file generated by autoconf is screwed up. So, the build_bullet.sh file was supposed to copy over a configure file generated on linux... but an error in the build_vdrift.sh was preventing it from doing so. R2266 should work. - zimluura - 12-21-2008 updated and it tried it. still didn't work. actually had the same error. so i manually copied the file. bullet-2.7.3/configue was still different than what was in the tools/win directory. though i think bullet-273-configure was present in the bullet dir. and proceeded to run the rest of build_bullet.sh line by line. then i had success after that vdrift built without a hitch and then ran, and after changing some options it looked good. yay!!! |