Forums

As hinted to in the Car graphics config thread ( http://vdrift.net/Forum/viewtopic.php?p=11414#11414 ), I have been working expanding the scope of suspension types simulation. Of particular interest to me is double wishbone suspension which some of you may realise cannot properly be simulated with a single hinge point, being described by an offset pair of additive sine curves (or, in other words, two circles, as opposed to the one that is available right now.

Anyway. For various reasons relating to doing things the "right" way, I'm trying to put this together with some supposedly straightforward polymorphism.
It now makes sense for CARDYNAMICS to contain not a vector of CARSUSPENSION but pointers there to (because you need pointers or references in C++ and you can't uses references like that). Easy to deal with — except that it buggers up the joeserialize stuff. I'm not entirely sure what joeserialize is supposed to achieve, but simpling preventing the suspension for being serialized doesn't seem to cause any problems.... Someone tell me if this is bad and will leak memory or something?
Moving on, I'm also interested in what the point of having a CARSUSPENSIONINFO struct is? In the interest of reducing the number of data types that need to be derived, is there a problem with storing that data directly in the CARSUSPENSION class (and derivates)?

Quote:what the point of having a CARSUSPENSIONINFO struct is?

Separate constant data(suspension spec) from variables to be able to share it between car instances "someday". Can you share some more info on your suspension implementation idea. What are the configuration parameters? I guess you plan to make GetWheelPosition(T displacement) virtual? Maybe CARSUSPENSIONINFO can be adapted to support different suspension types.

Currently the configuration looks something like

Quote:[wheel/fl]
texture = oem_wheel.png, oem_wheel-misc1.png
mesh = oem_wheel.joe
orientation = left
position = -0.69, 1.27, -0.49
suspension = double-wishbone
upper-chassis-rear = -0.35, 1.27, -0.07
upper-chassis-front = -0.35, 1.33, -0.07
lower-chassis-rear = -0.28, 1.22, -0.44
lower-chassis-front = -0.28, 1.32, -0.44
upper-hub = -0.64, 1.28, -0.37
lower-hub = -0.64, 1.27, -0.56
camber = -1.27
caster = 4.9
toe = 1.2
ackermann = 7.9
steering = 32.8

This would only apply to double wishbone suspension, I intend to implement further suspension types also (I started with DW because it's the most complex independent suspension system, and should give a good idea of what needs to be present). Currently this is all done in LoadSuspension, which I've moved to a static member function of CARSUSPENSION so that CARDYNAMICS doesn't have to know anything about different suspension types. A different scheme similar to what zim suggested with the info about hinge points in a separate config block might make sense also, eg.

Quote:[wheel/fl/wishbone-hinges]
upper-chassis-rear = -0.35, 1.27, -0.07
upper-chassis-front = -0.35, 1.33, -0.07
lower-chassis-rear = -0.28, 1.22, -0.44
lower-chassis-front = -0.28, 1.32, -0.44
upper-hub = -0.64, 1.28, -0.37
lower-hub = -0.64, 1.27, -0.56

[wheel/fl]
texture = oem_wheel.png, oem_wheel-misc1.png
mesh = oem_wheel.joe
orientation = left
position = -0.69, 1.27, -0.49
suspension = double-wishbone
camber = -1.27
caster = 4.9
toe = 1.2
ackermann = 7.9
steering = 32.8

My prelim implementation virtualises GetWheelPosition (pure virtual), SetSteering (rotational travel offset), and Init. At the moment I have moved the hinge from the CARSUSPENSIONINFO struct directly into CARSUSPENSION. Unless you're expecting to one day have a thousand of the same type of car in a particular game instance, I'm not convinced about the data sharing — but that's just my opinion, of course.
EDIT: Actually it doesn't make Init virtual so much as admit it takes overloading now. I might change the access to protected.

On the subject, I've been thinking on how to implement codepedent suspension, and my current theory is the best option goes in configuration with something like:


Codewise, the suspension links themselves could be stored for loading purposes in a string map that is initially empty, the first wheel to look up a mapping creates it, every subsequent look up will reference the same map — during the actual simulation each wheel position refers to its relevant link directly, avoiding the STL overhead. The caveat is that CARDYNAMICS Load routine would need to know a little about linked suspension (at the least provide a map), but I guess that's not so bad. Additionally all wheels linked together would need to update their positions before force is applied to any of them.

I've coded and tested and rearranged and re-tested, rebased, fixed conflicts, corrected for ABI changes, tested again, and decided that apart from finalising the configuration format I have a functional double wishbone simulation.

I'm currently preferring the concept of deferring the hinge locations to a config subsection (now using '.' instead of '/' I guess) A second, third, or possibly authoritative opinion would help

Also if anyone has a series 2 Elise sitting in their back yard and would like to measure the lengths of the wishbone arms (one front pair and one rear pair should be sufficient), ...

Can you post/upload a patch for data && code.

PS: The double wishbone code could be used to simulate other independent suspension types. MacPherson strut is actually a double wishbone with a very long(infinite) upper wishbone.

Elise S2(from a photo/outline)
lower rear: about 0.35m
upper rear: about 0.23m

You could simulate a simple model of a macpherson strut in data by defining the lower arm and then inserting an identical length and parallel virtual upper arm at any point along the axis of the strut.

EDIT: Uh, scratch that. Macpherson struts have exceedingly little variation in horizontal movement. One other major difference from 2 wishbone suspension is that the wheel is actually mounted on the variable length upper arm.
IMO the simplest way is to keep those types separate and define the macpherson type with the strut's mount point and the far end of the strut when fully extended (heck you could just use the wheel position and and offset from the top of the strut equivalent to the offset of the wheelfrom the bottom of the strut).

I'll get patches ready just as soon as I've had time to test with a vehicle that's not ridiculously tweaked to try and match reality in just about every other way.

I don't seem to be able to add attachments, so here goes:

I made a few additional alterations to the data, mostly the torque curve — I don't know what the data in there was supposed to be for, but I replaced it with some 'clean' data extrapolated from graph data for the Toyota 1ZZ-FE powertrain as paired with the 5-speed gearbox. It now accelerates from 0-100 in ~5 seconds as it's supposed to.
I moved the particles down because the centre of mass was ridiculously high and causing the car to prefer tipping over to cornering. I moved the engine forwards to try and unbalance the back end while cornering – also the -0.9 basically had it hanging almost over the rear axle a la a Beetle with a Porsche 6cyl engine forcibly inserted throught the luggage space.

https://github.com/fjwhittle/vdrift – A tree, wot can be cloned.

https://github.com/fjwhittle/vdrift/commits/master - commit list

Set of 5 patches against 2922 :roll::

https://github.com/fjwhittle/vdrift/comm...764c6.diff
https://github.com/fjwhittle/vdrift/comm...93b1d.diff
https://github.com/fjwhittle/vdrift/comm...b72ee.diff
https://github.com/fjwhittle/vdrift/comm...efec4.diff
https://github.com/fjwhittle/vdrift/comm...938da.diff

Actually I'm not sure how well these will work. Best to get a tarball of the latest tree if they don't apply well.

http://www.youtube.com/watch?v=BhYdSfKMk_E

Okay it's not the LE. Here's a complete .car, 'coz it's that different:

cars/GTV6/GTV6.car:

Will look into the code asap.

One cosmetic change I'd like to see in the config:

PS: I've got Macpherson strut wrong too. Look here: http://www.youtube.com/watch?v=e2D0BHUm2BI&NR=1

NaN Wrote:Will look into the code asap.

One cosmetic change I'd like to see in the config:

Then you may want to also apply https://github.com/fjwhittle/vdrift/comm...18d94.diff (and make relevant changes to config sections)

MacPherson struts, too!

https://github.com/fjwhittle/vdrift/comm...5ea9b.diff

And a data diff for M3 (I've also done some work on TL[2] but that's been a little more involved):

Nice job!

What do you think about, renaming BASICSUSPENSION to HINGESUSPENSION, moving hinge parameter from wheel.bla to wheel.bla.hinge?