torcs-devel Mailing List for TORCS - The Open Racing Car Simulator

Hi Christos

> The reduction of drag reduction for cars in front will affect
> berniw_2004 significantly because the 2 cars follow each other very
> close. I am not an aero expert, but I think that the drag reduction
> should be much less for the cars in front. I set it up to half and to

I agree.

> 4 times the decay rate of the car in the back. Apart from the,
> unforunate effect on berniw, it aids greatly in cars using slipstreaming properly, as before the car
> in front got almost the same benefit as the one in the back from
> slipstreaming.

That's good, it will make the races more interesting. I hope it has no 
ugly side effects:-) Btw. I think I will revert the transmission fix for 
1.2.4, because I do not have the time to do 25-50 hours new 
parametrizing and test driving, and it is not recognized by most of the 
users anyway (keyboard driving with automatic gearbox).

> if 2 cars are far away then each one has 3 types of drag: impact drag
> from frontal wind, vacuum drag from the vacuum left behind, and
> turbulence. If they are so close as to be effectively joined (like
> train wagons), then they behave like one body so the impact drag
> affects only the car in front and the vacuum drag only the car in the
> back. Is this a correct way to view it?

You can think of it this way, yes, I think it is a good choice. But you 
can add (e.g. interference, areal, ...)/remove (turbulence) components 
or look at the system as a whole without decomposing it, whatever serves 
you most.

> Also with respect to berniw, in simuv3 collision code, CollideZ() also
> generates friction so if your suspension is very low/soft you're going
> to lose some speed. I will probably port the friction to simuv2, along
> with the missing sound effect.

The sound effect would be cool, but please do not add any more features 
to simuv2. The only things simuv2 needs for now are:
- collisions with static objects (pit wall), I will do that.
- Aerodynamic longitudinal stabilization (cause through wing tips ends 
and car body design), I will do that as well.

That's it then for the near future. By the way, I could use this 
opportunity to explain what I like generally for TORCS and what I do not 
like:
- I like clean, good documented, simple, performant, portable, well 
tested code without side effects, so make sure that you have fixed 
everything (!!!) which is affected.
- I like to do as well cool stuff, so I do not enjoy it fixing other 
peoples work.
- I do not like "correct" solutions, if there is no difference in 
perception other than the fan speed of the computer, e.g. if somebody 
states "I changed XY to be correct, but it does not affect anything", 
what is the point in doing it at all? Need a reason to buy a new CPU? 
TORCS is not a design tool where you put in a car and test like it 
behaves, it is a simulation where you parametrize the simulation till 
the behaviour fits your needs. Thats something competely different, at 
least for nowadays personal computers.

Bye, Bernhard.


-- 

Visit my homepage http://www.berniw.org
Official TORCS racing: The TORCS Racing Board, http://www.berniw.org/trb

> > particles that have average lateral speed ux and bounce elastically
> > from a rigid, planar wing surface.
>
> Uh, not a brilliant choice... a planar airfoil has some very special
> properties (e.g. that you have horrible turbulence at low AOA (Angle of
> attack)). I think your model is a bad choice and the result is screwed.
>

I'll take your word for that since you're more familiar with the
field.

> Better forget about that at least for the offical version. Your can get
> the same effect with the existing parameters (because the wing geometry
> is not dynamic and you do not know the real data anyway).

OK, it is just an option for now, active on simuv3 pro mode only.

> > I tested the fix last night, it seems that it fixes more or less all
> > our collision problems, including the 3D collision. I'll post an
> > update after I test a bit more.
>
> Great:-)
>

OK, after testing, everything seems to work. 3D collisions are a bit
naive, but I don't expect them to work any better at the moment. At
least the direction of the forces seems to be correct.

Maybe you can check whether dmgDotProd is needed anymore in simuv2, or
you can make do simply with dotProd on the CollideXYScene() function.

The reduction of drag reduction for cars in front will affect
berniw_2004 significantly because the 2 cars follow each other very
close. I am not an aero expert, but I think that the drag reduction
should be much less for the cars in front. I set it up to half and to
4 times the decay rate of the car in the back. Apart from the,
unforunate effect on berniw, it aids greatly in cars using slipstreaming properly, as before the car
in front got almost the same benefit as the one in the back from
slipstreaming.

Let me see if understand the physics properly:

if 2 cars are far away then each one has 3 types of drag: impact drag
from frontal wind, vacuum drag from the vacuum left behind, and
turbulence. If they are so close as to be effectively joined (like
train wagons), then they behave like one body so the impact drag
affects only the car in front and the vacuum drag only the car in the
back. Is this a correct way to view it?

Also with respect to berniw, in simuv3 collision code, CollideZ() also
generates friction so if your suspension is very low/soft you're going
to lose some speed. I will probably port the friction to simuv2, along
with the missing sound effect.


-- 
Christos Dimitrakakis
IDIAP (http://www.idiap.ch/~dimitrak/main.html)

I contacted one of the authors of libff and it seems that the project
is dead :/

-- 
Christos Dimitrakakis
IDIAP (http://www.idiap.ch/~dimitrak/main.html)

Hi Christos

> 1. Validation of the areo model:
> ================================
> 
> I performed a validation of the simple aero model using a particle
> based approach and found that the model needs to be adjusted.
> More specifically, we should have, for a = angle of attack,
> 
> Fx = K ux^2 sin(a)^3
> Fz = K ux^2 sin(a)^2 cos(a)
> 
> This result is based on a particle simulation with brownian motion of
> particles that have average lateral speed ux and bounce elastically
> from a rigid, planar wing surface.

Uh, not a brilliant choice... a planar airfoil has some very special 
properties (e.g. that you have horrible turbulence at low AOA (Angle of 
attack)). I think your model is a bad choice and the result is screwed.

> 
> So, the question is this: should the model be fixed? If yes, what will
> it mean for the game?

No. Look at your above results:
Ok, how big is cos a for usual conditions -> yes, ~1.0.
Now sin(a)³ is wrong I think. Simply look at airfoil windtunnel data 
(constant Reynolds number, Lift/AOA), if you gradually increase the AOA 
the lift increases first linear and at ~15 degrees starts grow slower, 
the curve drops off -> approximately the shape of a scaled sine 
(surprise, surprise...).

> - In the current simulation, wings with the same area are equivalent
> in the sense that you can make both generate the same forces if you
> put them at the proper angle. However, with the adjusted code, while
> it will be possible to generate the same downforce with a smaller wing
> as compared to a bigger one, the smaller wing will generate more drag.
> So the new code will create a distinct advantage for cars with larger
> area wings.

That could be correct (that very depends on the airfoil and the wing 
tips design) but is totally pointless. It will make stuff more 
complicated, slower to compute and in the end you recognize no 
difference -> no.

> - In the current code, the ratio of downforce (Fz) vs drag (Fx) is
> fixed to 4.0. As you can see from the attached graph, this ratio is
> changing depending on the angle. This seems to make sense for me.

Depends on the airfoil, your model is a bad choice. Really.

> - Gameplay wise, if the cars are properly set up, I do not see much
> difference, apart from the amount of drag generated relative to the
> downforce.
> Pros:
> - The fix is very small.
> - It pushes the model towards correctness without much overhead.

Correctness does not help at all, because it does not increase the 
experience in any way.

> - Driving is not affected a lot.

Hmm, what is the point then in adding complexity?

> - It gives a nice advantage to cars with larger wings.
> 
> Cons:
> - Requires setting the cars up again.
> - Might break some robots.
> - Model is only correct for wings consisting of a single flat surface.
> I imagine curved wings will have a completely different response.
> 
> Resolution:
> - Write up fix in the simuv3 source only, as an option, with comments.
> Probably use a variable enum aeroflow {SIMPLE, PLANAR, CURVED} as the
> switch.

Better forget about that at least for the offical version. Your can get 
the same effect with the existing parameters (because the wing geometry 
is not dynamic and you do not know the real data anyway).

> 2. Validation of the collision model
> ====================================
> 
> It turns out that the corner velocities are calculated wrongly. There
> is a mixup between local and global frames of reference in that code.
> That might also explain the problems with car to car collisions
> failing and other strange bugs such as damage rising like crazy.
> 
> I tested the fix last night, it seems that it fixes more or less all
> our collision problems, including the 3D collision. I'll post an
> update after I test a bit more.

Great:-)

Bye, thank you,

Bernhard.


-- 

Visit my homepage http://www.berniw.org
Official TORCS racing: The TORCS Racing Board, http://www.berniw.org/trb

data/tracks/road/ole-road-1/

- slight optimisations

src/modules/simu/simuv2/

- Tuned down reduction of drag for cars in front.
- Fixed calculation of corner speed in car.cpp. This has the sideffect
of fixing collisions it seems.
- Changed damage amount to proportional to energy rather than
momentum. (makes trivial collisions like pushing the car in front not
cause any damage - almost the same as in simuv3).

src/modules/simu/simuv3/

- Tuned down reduction of drag for cars in front.
- Fixed calculation of corner speed in car.cpp.
- Fixed 3D collisions (it seems).
- New aero model, plus options to change it. One option for a
downforce multiplier factor and one option for a different wing model,
which makes the ratio between downforce and drag not a constant, but
dependent on the angle.


-- 
Christos Dimitrakakis
IDIAP (http://www.idiap.ch/~dimitrak/main.html)

I have good news and bad news. Bad news first.

1. Validation of the areo model:
================================

I performed a validation of the simple aero model using a particle
based approach and found that the model needs to be adjusted.
More specifically, we should have, for a = angle of attack,

Fx = K ux^2 sin(a)^3
Fz = K ux^2 sin(a)^2 cos(a)

This result is based on a particle simulation with brownian motion of
particles that have average lateral speed ux and bounce elastically
from a rigid, planar wing surface.

So, the question is this: should the model be fixed? If yes, what will
it mean for the game?

- In the current simulation, wings with the same area are equivalent
in the sense that you can make both generate the same forces if you
put them at the proper angle. However, with the adjusted code, while
it will be possible to generate the same downforce with a smaller wing
as compared to a bigger one, the smaller wing will generate more drag.
So the new code will create a distinct advantage for cars with larger
area wings.

- In the current code, the ratio of downforce (Fz) vs drag (Fx) is
fixed to 4.0. As you can see from the attached graph, this ratio is
changing depending on the angle. This seems to make sense for me.

- The problem now is that this will mess up a bit the setups. I could
always choose a scaling factor so that the forces will be the same for
a given angle (i.e. in the graph, the downforce is the same in both
models for 15 degrees), but some cars might need adjustment.

- Gameplay wise, if the cars are properly set up, I do not see much
difference, apart from the amount of drag generated relative to the
downforce.

- Robot drivers that calculate downforce by the old calculation
will need to adjust it.


Pros:
- The fix is very small.
- It pushes the model towards correctness without much overhead.
- Driving is not affected a lot.
- It gives a nice advantage to cars with larger wings.

Cons:
- Requires setting the cars up again.
- Might break some robots.
- Model is only correct for wings consisting of a single flat surface.
I imagine curved wings will have a completely different response.

Resolution:
- Write up fix in the simuv3 source only, as an option, with comments.
Probably use a variable enum aeroflow {SIMPLE, PLANAR, CURVED} as the
switch.


2. Validation of the collision model
====================================

It turns out that the corner velocities are calculated wrongly. There
is a mixup between local and global frames of reference in that code.
That might also explain the problems with car to car collisions
failing and other strange bugs such as damage rising like crazy.

I tested the fix last night, it seems that it fixes more or less all
our collision problems, including the 3D collision. I'll post an
update after I test a bit more.


-- 
Christos Dimitrakakis
IDIAP (http://www.idiap.ch/~dimitrak/main.html)

Christos Dimitrakakis wrote:
> I had the chance to play TORCS with a steering wheel recently, on
> Windows and thought that since I added the force-feedback calculation
> I could try and interface with the hardware at some point. Anyone
> knows which of the most common wheels are supported by Linux? Which
> one would be easiest to use for development? My previous experience in
> this department consisted of reading RC timer registers in the Amiga..
> I have no idea whether there exists an API for that sort of thing ;)
> 
> 

I've one link I hope it's useful :

http://user.it.uu.se/~johannd/projects/ff/doc.shtml

Eric.

Hi Stephen

> Anyone stil have a copy of the drawing?   or able to rework the explination with a new one :)

http://torcs.sourceforge.net/manual/api/index.html

Bye, Bernhard.

-- 

Visit my homepage http://www.berniw.org
Official TORCS racing: The TORCS Racing Board, http://www.berniw.org/trb

Howdy,

Reading the archives... this message...
http://sourceforge.net/mailarchive/message.php?msg_id=6989312

Eric Espie said he attached a drawing, but the mailing list archive didn't seem to retain it.

Anyone stil have a copy of the drawing?   or able to rework the explination with a new one :)

Thanks.

  Stephen

Halfway through my simuv3 code review. Committed an update on simuv3
that fixes a serious bug with the calculation of angular velocities
from rotational inertia. This brings simuv3 fully in line with simuv2.
Tests with the 2005 championship cars on various tracks show a
difference of only +-1 second depending on whether simuv2 CVS/1.2.3,
or simuv3 is used, for the flatter tracks.

TODO:

- Collisions.

- Test force feedback.

- Test options such as tyre temperature for consistency..

- Make sure that momentum is always conserved in
engine/clutch/drivetrain inertia model, even during transitions.

- I did a particle-based simulation of aerodynamic forces on a simple
inclined plane, and it seems we need to adjust the drag/downforce
calculation for wings to also use the cos of the angle of attack. I
will evaluate that later, as a model option.

-- 
Christos Dimitrakakis
IDIAP (http://www.idiap.ch/~dimitrak/main.html)

I had the chance to play TORCS with a steering wheel recently, on
Windows and thought that since I added the force-feedback calculation
I could try and interface with the hardware at some point. Anyone
knows which of the most common wheels are supported by Linux? Which
one would be easiest to use for development? My previous experience in
this department consisted of reading RC timer registers in the Amiga..
I have no idea whether there exists an API for that sort of thing ;)


-- 
Christos Dimitrakakis
IDIAP (http://www.idiap.ch/~dimitrak/main.html)

Hi Stephen

> In reply to a thread a year ago ( 2004-04-14 ):
> http://sourceforge.net/mailarchive/message.php?msg_id=7874785
> 
> Did anything come of this... is there still some effort underway... looking for someone to join the effort?

I do not know, I heard nothing from a result...

Bye, Bernhard.


-- 

Visit my homepage http://www.berniw.org
Official TORCS racing: The TORCS Racing Board, http://www.berniw.org/trb

Howdy,

In reply to a thread a year ago ( 2004-04-14 ):
http://sourceforge.net/mailarchive/message.php?msg_id=7874785

Did anything come of this... is there still some effort underway... looking for someone to join the effort?

Thanks.

  Stephen Gutknecht
  Arica, Chile

keywordz: trackgen, tracks, track

Hi all

There is a reworked version of g-track-2 in CVS.

Bye, Bernhard.



-- 

Visit my homepage http://www.berniw.org
Official TORCS racing: The TORCS Racing Board, http://www.berniw.org/trb

Hi all

I commited a reworked version of Aalborg.

Bye, Bernhard.


-- 

Visit my homepage http://www.berniw.org
Official TORCS racing: The TORCS Racing Board, http://www.berniw.org/trb

> losing traction or regaining it. At first I thought I got hit by another
> car whenever I lost traction with the nascar. It's a big jerk every
> time.
>
Definitely simuv2 feels more smooth and linear in this respect.

> One thing I noticed when looking with a track camera is that the cars
> are much lower now, almost as if the shock absorbers are not simulated
> correctly.
>
I will check into that

> What I really like about simuv3 is how cars can completely somersault.
> The Olethros Road track is particularly suited for this. :) Twice I saw
> it happen that cylos1 ended up laying on its roof.

We will update the collision model in the future hopefully.

> The other new feature: car deformations. They look a bit odd sometimes
> though, like a huge dent pointing out of the side of a car, half as long
> as the car's width.
>

That has something to do with car to car collisions, but in any case
the deformations model will probably be dropped completely.

> I hope this helps.
>
> Best regards,
>   Felix
>
>

-- 
Christos Dimitrakakis
IDIAP (http://www.idiap.ch/~dimitrak/main.html)

Am Samstag, den 12.03.2005, 17:52 +0100 schrieb Christos Dimitrakakis:
> I found another idiotic bug in simuv3, concerning the calculation of
> the angular velocity. Instead of calculating it directly from the
> angular momentum the old calculation was left over, so frequently the
> two of them were not agreeing! I also removed all the temperature
> and wear effects from wheel.ccp.. I left the susp.cpp code configured
> by default for 'Wishbone'. If you change it to 'Ideal', then you get
> times with all robots that are virtually the same in simuv2, simuv3.
> The car feels the same.. can people please take a look at this?

I got it from anonymous CVS yesterday, so my comments may be slightly
outdated ...

simuv3 is definitely usable. It feels a bit different, especially when
losing traction or regaining it. At first I thought I got hit by another
car whenever I lost traction with the nascar. It's a big jerk every
time.

One thing I noticed when looking with a track camera is that the cars
are much lower now, almost as if the shock absorbers are not simulated
correctly.

What I really like about simuv3 is how cars can completely somersault.
The Olethros Road track is particularly suited for this. :) Twice I saw
it happen that cylos1 ended up laying on its roof. But the roof was
about 1 meter below the road, so you only saw the lower part of the car
sticking out of the road.

The other new feature: car deformations. They look a bit odd sometimes
though, like a huge dent pointing out of the side of a car, half as long
as the car's width.

I hope this helps.

Best regards,
  Felix

--=20
| Felix K=FChling <fx...@gm...>                     http://fxk.de.vu |
| PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3  B152 151C 5CC1 D888 E595 |

Hi Albert

> I was wondering if there is a way to create a set of robots for each car
> type, reusing the existing robots.
> 
> As I see it, each robot takes into account the limits of the machinery
> for each car, and if a robot is "moved" from a car to another, it might
> misbehave. Is that correct?
> 
> What could be done to create an adaptable robot?

Like Christos pointed out, some robots adopt to the cars. Most robots 
are able as well to load a default setup up for all tracks, so you can 
have quite quick an acceptable driving robot.

What I plan for much later is to create a big set of opponents for human 
drivers, what we will need then are perhaps 10-20 textures for all free 
cars (-> some are nonfree and it is not allowed to retexture, do just 
retexture cars which are under the Free Art License, it is stated in the 
readme.txt's in the cars directories).

If you want to create your own set of opponents go to www.berniw.org/trb 
to the download section, there is a "bt" derivate robot with a script to 
create your own ones. Then read the chapters 5 and 6 of the robot 
tutorial to learn how to set up and texture the robots.

If you want that we can use your textures later keep the following thing 
s in mind:
- Do not use any existing trademarks or logos, create phantasy things 
and research with google if it does really not exist.
- Assign the drivers names which cannot be associated with real drivers.
- Create your texture a multilayer XCF with a resolution of 1024x1024 or 
higher (for later when every GPU has 512 or 1024 MB RAM).
- The texture will be currently used as 512x512, so make sure that it 
looks good with this resolution.
- The texture should be politically correct.
- The licence must be the GPL or Free Art License (I'm one of these guys 
who thinks that one can apply the GPL to artwork).


Bye, Bernhard.



-- 

Visit my homepage http://www.berniw.org
Official TORCS racing: The TORCS Racing Board, http://www.berniw.org/trb

Not sure if this should on -devel and not -users, but anyway:
Last year I had spent some time ona few tracks.. here are the
examples. Note that two of them will actually replace existing TORCS
tracks, with hopefully better versions. The last track uses a huge
amount of texture memory because I put all my textures in there.
Ugly.. still.

http://www.idiap.ch/~dimitrak/torcs/tracks.html



-- 
Christos Dimitrakakis
IDIAP (http://www.idiap.ch/~dimitrak/main.html)

> Hello,
>
> the appended patch simulates the delay for the reaction time
> of a camera man for the <F9> view.
>

I took a look at your patch. I had something similar to it before, but
I decided to remove it as sometimes the car was moving too fast out of
view... sometime I'll try it again. Comments:

1. Using a memory is not appropriate. This is probably one of the
reasons why you have jerks. Instead, one could use a filtered version
of the car position. This is what I had used in my previous code, it
seemed to work OK.

2. The other reason for jerky movement is that well, basically the
camera is moving and the rate of movement should be smoothly changing
 - while remembering that updates are not regular. I had a similar
problem with flying-cam, but that was recently fixed by Bernhard. It
is better to maintain the following:

a) camera position
b) camera orientation
c) camera speed
d) camera angular momentum

And then, update the speed and angular momentum accordong to where the
cameraman wishes to move the camera, then integrate
position/orientation with speed/angular momentum to get a
smooth movement. Note that for orientation/angular momentum you will
not to use rotation matrices or quaternions rather than Euler angles.

Hope that helps..

-- 
Christos Dimitrakakis
IDIAP (http://www.idiap.ch/~dimitrak/main.html)

> Hi,
>
> I was wondering if there is a way to create a set of robots for each car
> type, reusing the existing robots.
>

Currently most of the robots are coded so that the same code can be
used to drive any kind of car.

> As I see it, each robot takes into account the limits of the machinery
> for each car, and if a robot is "moved" from a car to another, it might
> misbehave. Is that correct?

Better think of it as tuning the car settings so that they are
compatible with the driving style of the robots. Most of the robots
however are coded with the assumption of not a huge amount of
understeering/oversteering. Although they are able to recover from
such conditions, it is not their 'natural' driving mode.

As for adaptation, most bt-based robots try to learn the speed with
which they can take curves. In additin, the olethros bot is trying to
do adaptive braking and steering, but that is really experimental
code.

-- 
Christos Dimitrakakis
IDIAP (http://www.idiap.ch/~dimitrak/main.html)

Hi,

I was wondering if there is a way to create a set of robots for each car
type, reusing the existing robots.

As I see it, each robot takes into account the limits of the machinery
for each car, and if a robot is "moved" from a car to another, it might
misbehave. Is that correct?

What could be done to create an adaptable robot?

Bests,

    Albert.

Hello,

the appended patch simulates the delay for the reaction time
of a camera man for the <F9> view.

You get a better feeling for the acceleration/deceleration
as the car moves slighty off-center:) The car looks "snappier".
The effect is f.e. visible if the car is viewed (after
pressing <F9>) near from the side and quickly moved back and forth.

Unfortunatley this patch causes ugly unsmooth movements of
the camera at higher speeds, so this patch is not ok for inclusion.
What am I doing wrong?

Greetings

Frieder


PS: Torcs uses 100% CPU (45% user, 55% sys) when the menu is displayed.

Some interesting screen shots with olethros and an experimental track

http://www.idiap.ch/~dimitrak/torcs/screens/view0.html

-- 
Christos Dimitrakakis
IDIAP (http://www.idiap.ch/~dimitrak/main.html)

I found another idiotic bug in simuv3, concerning the calculation of
the angular velocity. Instead of calculating it directly from the
angular momentum the old calculation was left over, so frequently the
two of them were not agreeing! I also removed all the temperature
and wear effects from wheel.ccp.. I left the susp.cpp code configured
by default for 'Wishbone'. If you change it to 'Ideal', then you get
times with all robots that are virtually the same in simuv2, simuv3.
The car feels the same.. can people please take a look at this?

-- 
Christos Dimitrakakis
IDIAP (http://www.idiap.ch/~dimitrak/main.html)