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

Hi all

I commited the TORCS Racing Board source code, the Robot Tutorial and an 
updated FAQ into the CVS.

Bye, Bernhard.

-- 

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

I just added some options for the simulation. Four damage options are
implemented:

tyres:
floating value, tyres wear out. Defaults to 0 apart from pro level,
where it defaults to 1. They are repaired at every pitstop.

alignment:
messes up the alignment of the wheels when you hit large bumps.
Defaults to 1 for all levels. This is repaired fully at each pitstop.

suspension:
Makes the shock abosrber leak fluid when you hit large bumps. Defaults
to false, apart from pro, where it is true. This is repaired fully at
each pitstop.

aerodynamics:
Makes the aerodynamics add some torque to the car, which is
proportional to current damage. Defaults to false, apart from pro,
where it is true. This is not explicitly repaired, as the effect is
proportional to the amount of damage.

files changed and added in:
simuv3/

Also changed interfaces/car.h to register the new option names in case
someone wants to put them in XML files.

Note that after the default options are set up, then the options for
the car's xml file are read.


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

I have now made the following changes

libs/robottools/rttrack.cpp
- Added pseudorandom() and an associated class to replace the sinewave
bumps with a stochastic model.

modules/simuv3/
- Slightly stabilised static friction.
- Now ground effect is not reduced so much by slipstreaming.

modules/ssgraph/
- Fixed a bug in grsound, changed volumes a bit.
- Added zoom for background cam, by adding getFOV().
- Added rotating env, but is not very nice. Should be a real envlope.
- Added estimation code to olethros bot. Now it works much better.
- Still problems with crashing. Possibly GLUT-related.

drivers/olethros/
- Stabilised the algorithm.
- Added more estimates, smoother driving. Better times.
- Add some skins for some cars.
Read the README for details.


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

>
> I think the new formula 1 car (its great fun) need a bit parameter
> adjustment, I will do that if nobody opposes:
> - Changing drag coefficient from 0.01 to 0.28 [-]
> - Changing front area for 0.01 to 1.2 [m*m]
> - Perhaps more to come... e.g engine with 19000 rpm would be nice;-)
>

I was just checking the F1 rules..

Weight:
Minimum 600Kg.

Width:
Maximum 180cm.

The wings may not exceed 140cm at the front and 100cm at the rear.

Also the front wing may not exceed the front-wheel axis by more than
90cm.

Height:
A maximum of 95cm overall- excepting rollover structures, which must
be shaped to have any significant aerodynamic influence on the car's
performance.

The maximum height of the rear wing is 80cm.

Tyres:

The front tyre tread must not exceed 270mm.

Wheels:

A maximum of 380mmcm in width and 660mm in diameter.


Does the F1 car conform?


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

Hi all

I think the new formula 1 car (its great fun) need a bit parameter 
adjustment, I will do that if nobody opposes:
- Changing drag coefficient from 0.01 to 0.28 [-]
- Changing front area for 0.01 to 1.2 [m*m]
- Perhaps more to come... e.g engine with 19000 rpm would be nice;-)

Bye, Bernhard.


-- 

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

Hi All

> It's even more complex than that because when you get into shaders,
> there are limits on:
> 
> * The number of textures you can access for a particular polygon.
> * The number of texture COORDINATES you can send.
> * The total number of texture accesses.  (You may be able to access
>   the same texture more than once within a shader).

Yes, I know:-) Or other nice undocumented limitations like that you can 
just use 4 kills in a program and such stuff... brrr.

> Also, the limits are different when using a shader than with the
> standard pipeline.

Yes, but we use currently just fixed functionality. If I remember 
correct one could apply up to 16 textures with the FX5900 (depending on 
the situation).

> On some of the earlier GeForce cards, the driver used a texture
> to implement the user-defined clip planes - so the limits were
> different with and without user-defined clipping!

Arghh... that's news for me. Some weeks ago somebody reported with an 
ATI 9200 that the cars disappear in TORCS, we did not find the problem 
yet (hard for me without this hardware...). Now with such stories new 
potential problem candidates pop up...

> The glGet feature only really tells you the number you can GUARANTEE
> to get under the worst circumstances - which is not at all the

Yes, but then at least the application should work like expected.

> same thing.   In some driver revisions, ATI cards tell you the most
> you can EVER get - which is almost as un-helpful.

Crazy. That screams for trouble...

> It's a mess.

Sounds like it is... horrible stories:-) Thank you for the information,

bye, Bernhard.


-- 

visit my homepage http://www.berniw.org
coming soon: The TORCS Racing Board, http://www.berniw.org/trb

Bernhard Wymann wrote:
> Hi Christos
> 
>> Hey guys, after all this discussion concerning multiple textures, I am
>> left with the impression that something is wrong with my configuration
>> since I can only see two at a time.
> 
> 
> That is perfectly possible, try "glxinfo -l | grep 
> GL_MAX_TEXTURE_UNITS_ARB" or glGet* in a program. I get "4" on my 
> GeForce FX5900 and GeForce 3. On the GeForce 1 and 2 I got 2 if I 
> remember correct...
> 
> What was confusing for me when I started with hardware accelerated 
> computer graphics was that the number of pixel/fragment/textel pipelines 
> is not the number of texture units. The number of pipelines defines how 
> many pixels/texels/fragments get computed per clock cycle (parallel) , 
> the number of texture units equals the number of possible texturing 
> stages (sequential) in the pipeline.

It's even more complex than that because when you get into shaders,
there are limits on:

* The number of textures you can access for a particular polygon.
* The number of texture COORDINATES you can send.
* The total number of texture accesses.  (You may be able to access
   the same texture more than once within a shader).

Also, the limits are different when using a shader than with the
standard pipeline.

On some of the earlier GeForce cards, the driver used a texture
to implement the user-defined clip planes - so the limits were
different with and without user-defined clipping!

The glGet feature only really tells you the number you can GUARANTEE
to get under the worst circumstances - which is not at all the
same thing.   In some driver revisions, ATI cards tell you the most
you can EVER get - which is almost as un-helpful.

It's a mess.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

Hi Christos

> Hey guys, after all this discussion concerning multiple textures, I am
> left with the impression that something is wrong with my configuration
> since I can only see two at a time.

That is perfectly possible, try "glxinfo -l | grep 
GL_MAX_TEXTURE_UNITS_ARB" or glGet* in a program. I get "4" on my 
GeForce FX5900 and GeForce 3. On the GeForce 1 and 2 I got 2 if I 
remember correct...

What was confusing for me when I started with hardware accelerated 
computer graphics was that the number of pixel/fragment/textel pipelines 
is not the number of texture units. The number of pipelines defines how 
many pixels/texels/fragments get computed per clock cycle (parallel) , 
the number of texture units equals the number of possible texturing 
stages (sequential) in the pipeline.

Bye, Bernhard.


-- 

visit my homepage http://www.berniw.org
coming soon: The TORCS Racing Board, http://www.berniw.org/trb

Hey guys, after all this discussion concerning multiple textures, I am
left with the impression that something is wrong with my configuration
since I can only see two at a time.

Is there any way to get some info on the abilities of my setup through
plib or opengl functions?


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

I've been putting the final touches on the olethros bot, which is
based on BT, when I realised why the BT's accelerate/braking
behaviour is so badly oscillating. It's because BT has essentially
this structure:

accelerate = accel2target(speed, current_segment, 0);
brake = brake2target(speed, current_segment, look_ahead);
if (brake) accelerate =0;

the discontiuity of accel2target() and brake2target() not
withstanding, the problem is that the function that computes the
acceleration uses a lookahead of 0. This obviously causes oscillatory
behaviour when the reason for braking is that one of the segments
ahead has a lower speed limit. By appropriately modifying the
getAccel() function in BT, the driving becomes ultra-smooth, and fuel
consumption reduces dramatically.

I also tried a way to calculate the approximate radius of a set
of points. It is done thusly:

Have a set of points A={(x_1,y_1),..,(x_n,y_n)}
Find x,y,r that minimises
	sum_i r^2 - [(x_i-x)^2 + (y_i-y)^2],
for (x_i,y_i) in A

The estimates are quite good - such a thing is useful for the case
where the path is made up of a distribution of points, for example.
Like the set of points defined when you drive many times in a curve.

This stuff will be available in the next release of the olethros-bot.


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

> I have added a configure option
>
> ./configure --disable-xrandr
>
> in order to get the old behaviour if necessary
> (XRANDR mode is enabled by default).
> this is working well for me :-)
>
> All is commited in CVS
> torcs/configure*
> torcs/src/libs/tgfclient/fg_gm.cpp
>

I am using GLUT, not FreeGlut, and I have had problems with the
--disable-xrandr.

A few months ago (with last official release, I think), it was working
fine, using freeglut. Then with the latest CVS freeglut stopped
working completely so I switched to glut. I have not tried to use
--disable-xrandr with freeglut.



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

> In fact there are 4 textures applied on the cars :
> - the painting
> - 2 env textures
> - 1 shadow texture
>
> the 2 env textures are very well visible on g-track-3:
> the fisrt one is a displacement along the track as the car goes
> forward (you can see a bug if you travel in the wrong direction
> of the track.
> The second one is for the sky, and only rotate as the car rotate
> (may be in the wrong direction I admit)
>
> The shadow texture is applied with global maps coord.
>

From what I can see in the code this is true, but it seems to me that
only the painting and the first env texture is visible on my machine.
Maybe my card can only apply a double multi-texture? It's an NVIDIA
GeForce 4.

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

Bernhard Wymann wrote:
> Hi Christos
> 
>>> Especially to apply textures which are fixed in the world coordinate
>>> system this would be an easy solution to "light map". I think of this
>>> because the textured skid marks from christos (which look great on most
>>> tracks) miss the light map (especially annoying on mixed-1).
>>>
>>
>>
>> Not just the skidmarks, the cars miss the light map too.
> 
> 
> Hmm, that can't be true, at least not on all tracks, let drive a car on 
> g-track 3, it is clearly visible that the car gets dark as well...?!
> 
>> On the subject of maps, shouldn't the environment map of the cars
>> rotate in the opposite direction of the cars rotation? Now it only
>> moves when cars move but it does not rotate when cars rotate. I think
>> it'd look better if it did rotate.

In fact there are 4 textures applied on the cars :
- the painting
- 2 env textures
- 1 shadow texture

the 2 env textures are very well visible on g-track-3:
the fisrt one is a displacement along the track as the car goes
forward (you can see a bug if you travel in the wrong direction
of the track.
The second one is for the sky, and only rotate as the car rotate
(may be in the wrong direction I admit)

The shadow texture is applied with global maps coord.

> 
> 
> Perhaps... at least one could try it, it would be almost for free if the 
> current solution uses the texture martrix stack (IIRC it does)... but 
> the main problem of the environment maps IMHO is that the maps are 
> actually not environment maps:-) I think even with the latest hardware 
> it would be too expensive to crate all environmaps dynamically... so I 
> was never really a big fan of them...
> 
> What one could try is just to create the environment map of the focused 
> car dynamically and on the other still use the "faked" ones... perhaps I 
> will try that (cube mapping), but not before TRB is ready.
> 
> Bye, Bernhard.
> 
> 

Eric.
-- 
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
               TORCS - http://torcs.org
             The Open Racing Car Simulator
         AKA The Other Release Coming Soon (Skin'r)
            How soon is soon ? (RaceBlizter)
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=

> For the simulation options, have you made some variables
> to control the options ?

Not yet. Here are the options planned, they are currently in
#ifdefs or if(1)/if(0) blocks

working options, defaults are marked with *

"suspension type", enum
	*wishbone, simple, ideal

"tyre wear", real in [0,1]
	amount of tyre wear sustained
	pro: 1
	other levels: 0

"tickover type", enum
	pid_controller, *pid_with_auto_clutch, magic

	- the pid_with_auto_clutch controls the gas pedal and clutch
	when revs fall below the tickover so that the engine does not
	stall which is the standard behaviour in automatic
	transmission cars, I think.

	- pid_controller only contorls the gas pedal, like in most
	stick cars

	- magic is the old way of doing it, just don't allow the revs
	to fall under tickover. Right now pid_with_auto_clutch should
	be working almost the same as magic.

"airflow influences ground effect",
	bool, *true

	If true then ground effect is reduced when airflow is
	reduced.

"airflow influences wings",
	bool, *true

	If true then wing downforce is reduced when airflow is
	reduced.

speculative options (i.e. they don't work yet, and may never do
work):

"tyre profile", bool, can cause uneven wear and temperature on tyre
surface, also causes tyre to become 'bumpy' if it is worn out
unevenly.

"free wheels", bool, model wheels as rotating cylinders and couple
forces indirectly. This does not work properly yet.



Are there any other aspects of the simulation that make it a
bit too difficult for robots?

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

I have added a configure option

./configure --disable-xrandr

in order to get the old behaviour if necessary
(XRANDR mode is enabled by default).
this is working well for me :-)

All is commited in CVS
torcs/configure*
torcs/src/libs/tgfclient/fg_gm.cpp

Bye,
Eric.

Eric Espie wrote:
> Hi all,
> 
> I have some problems with the 2 last versions of the
> NVidia drivers (both linux & windows): I cannot
> use anymore the window mode in 3D accelerated mode.
> The screen begins to vibrate/blink then goes to black...
> may be it's a hardware pb.
> The fact is that in fullscreen mode it's ok, just
> the screen becomes fuzzy and blink when I exit from
> the full screen mode.
> Funny, I did not find anything on that problem on Internet.
> 
> Well, this is not really a TORCS related problem, so here it is:
> I am now bound to fullscreen mode.
> In the current CVS version, when exiting the screen resolution
> is not reset to the initial one, and it seems impossible with Ctrl-Alt-+
> to go back to the correct resolution (under Linux).
> The only way to continue to work is to restart X11 :-(
> I thought it was due to the latest NVidia drivers until
> I tried the version 1.2.2 this week for the TRB tests.
> 
> With the 1.2.2 version (same freeglut version)
> all is OK when exiting from the fullscreen mode.
> 
> I'll try to find the differences between the 2 versions
> (1.2.2 and CVS) but if anybody could help he is welcome :-)
> 
> Thanks,
> Eric.


-- 
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
               TORCS - http://torcs.org
             The Open Racing Car Simulator
         AKA The Other Release Coming Soon (Skin'r)
            How soon is soon ? (RaceBlizter)
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=

Hi all,

I have some problems with the 2 last versions of the
NVidia drivers (both linux & windows): I cannot
use anymore the window mode in 3D accelerated mode.
The screen begins to vibrate/blink then goes to black...
may be it's a hardware pb.
The fact is that in fullscreen mode it's ok, just
the screen becomes fuzzy and blink when I exit from
the full screen mode.
Funny, I did not find anything on that problem on Internet.

Well, this is not really a TORCS related problem, so here it is:
I am now bound to fullscreen mode.
In the current CVS version, when exiting the screen resolution
is not reset to the initial one, and it seems impossible with Ctrl-Alt-+
to go back to the correct resolution (under Linux).
The only way to continue to work is to restart X11 :-(
I thought it was due to the latest NVidia drivers until
I tried the version 1.2.2 this week for the TRB tests.

With the 1.2.2 version (same freeglut version)
all is OK when exiting from the fullscreen mode.

I'll try to find the differences between the 2 versions
(1.2.2 and CVS) but if anybody could help he is welcome :-)

Thanks,
Eric.
-- 
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
               TORCS - http://torcs.org
             The Open Racing Car Simulator
         AKA The Other Release Coming Soon (Skin'r)
            How soon is soon ? (RaceBlizter)
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=

Christos Dimitrakakis wrote:
>>>downforce, to be
>>
>>When coding the aero forces, I found that reducing the
>>effect of the downforce when following a car was too difficult
>>to handle for the robots, so I did not apply penalty in
>>downforce in that case, just I reduced the air resistance for the speed.
>>
>>I understand that it's not very good for simulation but
>>it's complex to handle for the robots.
>>
> 
> 
> Yet another option to add for the simu.
> 
> Do we have an options framework somewhere in the torcs base, so that
> processes can set/get options of other processes without having a
> strict interface? Something similar to tgf I guess.

We can start with an xml configuration file, they make the GUI interface
later.

> 
> Or, even more easily, options for players/robots can be just set from
> the car .xml file.

I'd prefer to associate simulation options to the skill level of the robots as
it is done today.
One skill level called "custom" can be added to let the player select the
simulation options on a driver basis anyway.
I'll study that.

> 
> I have now done that for "suspension type", for simuv3. It defaults to
> 'wishbone'. The 'ideal' suspension is the one in simuv2. The 'simple'
> suspension should only be used for some vintage cars - it is a
> two-point suspension and it changes the camber a LOT.
> 
> I'm uploading some new stuff to CVS now... will post a message when
> done.
> 
> 

Bye,
Eric.
-- 
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
               TORCS - http://torcs.org
             The Open Racing Car Simulator
         AKA The Other Release Coming Soon (Skin'r)
            How soon is soon ? (RaceBlizter)
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=

I have added a new directory:

src/drivers/olethros - A predictive control bot based on BT.

This bot does not use the policy classes at the moment, I started
doing a bot like that using berniw, but the berniw code was too
complex and interfered with the learning. I will do an example code
with the policy classes based again on BT.

I have updated the following directories:

src/interfaces
src/modules/simu/simuv3
src/libs/learning

I updated simuv3 with the susqpension option, and now the ground
effect reduction due to slip-streaming is halved. There are some other
changes which may or may not have made it to the previous CVS update I
had made, I am not sure (the collision fix and the engine fix). This
includes some changes in the carElt structure. Now you can have the
max horsepower, and tq, and associated rads in the structure. There
are also wheel forces available for joystick feedback (I have added
torsion forces Mz to the Fy force read-out on the wheels). This is all
on simuv3, I think it is possible to retro fit all of those changes
back to simuv2 as well.

The learning lib now has a set of new classes:

The low-level ANN class.

The Distribution set of classes.

The basic DiscretePolicy class.

The advanced ANN_Policy class.

Some helper functions/classes
(SmartAssert, MathFunctions, List, string_utils).

Documentation for these classes is aplenty and can be generated with
Doxygen.

I hope to be able to make a nice, simple, clean robot using these
classes soon.




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

> > downforce, to be
> When coding the aero forces, I found that reducing the
> effect of the downforce when following a car was too difficult
> to handle for the robots, so I did not apply penalty in
> downforce in that case, just I reduced the air resistance for the speed.
>
> I understand that it's not very good for simulation but
> it's complex to handle for the robots.
>

Yet another option to add for the simu.

Do we have an options framework somewhere in the torcs base, so that
processes can set/get options of other processes without having a
strict interface? Something similar to tgf I guess.

Or, even more easily, options for players/robots can be just set from
the car .xml file.

I have now done that for "suspension type", for simuv3. It defaults to
'wishbone'. The 'ideal' suspension is the one in simuv2. The 'simple'
suspension should only be used for some vintage cars - it is a
two-point suspension and it changes the camber a LOT.

I'm uploading some new stuff to CVS now... will post a message when
done.


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

Christos Dimitrakakis wrote:
>>From the current code, I see that all aerodynamics are broken down
> into 1) wings and 2) ground effect. When a car is in the wake of
> another car, effectively two things change
> 
> a) The air density.
> b) The air velocity.
> 
> I can model density and velocity changes together as 'airflow'.
> The airflow gets diminished at the beginning of a wake and
> increases to 1 with very simple exponential drop-offs.
> 
> This is how I then calculate aerodynamic forces, please tell me if
> something does not make sense for you:
> 
> All forces are normally proportional to airspeed^2. I multiply
> airspeed with airflow, and use (airspeed*airflow)^2 as the squared
> speed term in my calculations.
> 
> I think this is a valid model, as long as the model of airflow itself
> is meaningful.
> 
> Now, as I said before, the car aero is split into wings and ground
> effect. I think the wings airflow calculation is correct. However
> bernhard recently pointed out that the airflow for the ground effect
> should be constant. As far as I can understand, he is correct:
> The car ground effect is similar to that of the airplain ground
> effect. When an airplane is flying, it deflects air downwards.
> However, when it is close to the ground, the air is reflected back, so
> to speak, and pushes the airplane up even more. I guess something
> similar happens with the car. All the air is moving over the body of
> the car, creating a vacuum in the bottom. The existence of the vacuum
> then forces the air to push down on the car. Since vacuum is vacuum no
> matter what you do, the airflow should not matter at the bottom, only
> at the top of the car.
> 
> The problemis I think that the current model is implicitly bundling
> together two things: the body downforces and the ground effect.
> If I ignore the airflow for the ground effect + body then I have a
> very big problem in cars that only have a rear spoiler. As soon as
> they approach a car, they oversteer like hell. However, if I don't
> ignore the airflow at all, then the cars jump up as soon as they are
> behind another car (though they are quite stable). The compromise for
> me is to have a value for airflow, for the ground effect + body
> downforce, to be
> 
> (alpha) + (1-alpha) * airflow
> 
> I right now have alpha=.5, but I am not very satisfied with the
> elegance of this... any ideas?
> 

When coding the aero forces, I found that reducing the
effect of the downforce when following a car was too difficult
to handle for the robots, so I did not apply penalty in
downforce in that case, just I reduced the air resistance for the speed.

I understand that it's not very good for simulation but
it's complex to handle for the robots.

Eric.
-- 
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
               TORCS - http://torcs.org
             The Open Racing Car Simulator
         AKA The Other Release Coming Soon (Skin'r)
            How soon is soon ? (RaceBlizter)
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=

Hi All

There are still 7 places left for the test, so if you would like to 
participate please send me a mail.

> I like to participate the test event if is not to late.

It is not too late till 13. Nov 00:00:00 GMT+1:-) You will receive the 
password tomorrow.

Bye, thank you,

Bernhard.


-- 

visit my homepage http://www.berniw.org
coming soon: The TORCS Racing Board, http://www.berniw.org/trb

Hi Bernhard

I like to participate the test event if is not to late.

-----Original Message-----
From: Bernhard Wymann <be...@bl...>
To: tor...@li...
Cc: tor...@li...
Date: Tue, 09 Nov 2004 00:31:20 +0100
Subject: [Torcs-users] TORCS Championship Infrastructure Test (The TORCS
Racing Board)

> Hello Racers
> 
> I have implemented the system proposed in the rules on the TORCS site 
> and the internal tests start tomorrow. I will need testers (at least 2,
> up to 9, the more the better) for a public test next week or later.
> We will do a championship with 3 races. Because it is a test I would 
> like an interval of just two days between the races, so it would be 
> quite demanding:-)
> If you have no robot it does not matter, there is a robot "template" 
> available with a script to quick derive a robot from it.
> 
> Your job would be the following:
> - Join the championship, upload robots, submit results, watch results, 
> post in the forum, etcetc... use the system.
> - Try evil stuff (SQL injection, can you modify other users data, 
> overwrite a file on the server, clever manipulate a XML result file, 
> ...). If you can do it, please let me know of course:-)
> 
> Here is the temporary schedule (of course it depends on if I find any 
> testers...):
> 11. or 12. Nov.: Sending password to testers.
> 12. Nov.: Site open for testers, you can create accounts and register 
> teams, upload initial robots.
> 13. Nov.: Download phase race 1 (e-track-4).
> 14. Nov.: Race/Result Submission race 1.
> 15. Nov.: Download phase race 2 (eroad).
> 16. Nov.: Race/Result Submission race 2.
> 17. Nov.: Download phase race 3 (wheel-1)
> 18. Nov.: Race/Result Submission race 3.
> 
> If you are interested please contact me, I will send you then the 
> password for the site (during testing it is protected). Be aware of
> that 
> I will delete all data before I open the system to the public, so you 
> will need to register/create the teams again (its just for the case we 
> mess the system up in the tests, if (!) everything goes fine this is
> not 
> necessary).
> 
> Attached you find the updated rules and the robot with the script to 
> derive your own one. Thank you for you interest.
> 
> Bye, Bernhard.
> 
> 
> -- 
> 
> visit my homepage http://www.berniw.org
> coming soon: The TORCS Racing Board, http://www.berniw.org/trb
> 
> 

From the current code, I see that all aerodynamics are broken down
into 1) wings and 2) ground effect. When a car is in the wake of
another car, effectively two things change

a) The air density.
b) The air velocity.

I can model density and velocity changes together as 'airflow'.
The airflow gets diminished at the beginning of a wake and
increases to 1 with very simple exponential drop-offs.

This is how I then calculate aerodynamic forces, please tell me if
something does not make sense for you:

All forces are normally proportional to airspeed^2. I multiply
airspeed with airflow, and use (airspeed*airflow)^2 as the squared
speed term in my calculations.

I think this is a valid model, as long as the model of airflow itself
is meaningful.

Now, as I said before, the car aero is split into wings and ground
effect. I think the wings airflow calculation is correct. However
bernhard recently pointed out that the airflow for the ground effect
should be constant. As far as I can understand, he is correct:
The car ground effect is similar to that of the airplain ground
effect. When an airplane is flying, it deflects air downwards.
However, when it is close to the ground, the air is reflected back, so
to speak, and pushes the airplane up even more. I guess something
similar happens with the car. All the air is moving over the body of
the car, creating a vacuum in the bottom. The existence of the vacuum
then forces the air to push down on the car. Since vacuum is vacuum no
matter what you do, the airflow should not matter at the bottom, only
at the top of the car.

The problemis I think that the current model is implicitly bundling
together two things: the body downforces and the ground effect.
If I ignore the airflow for the ground effect + body then I have a
very big problem in cars that only have a rear spoiler. As soon as
they approach a car, they oversteer like hell. However, if I don't
ignore the airflow at all, then the cars jump up as soon as they are
behind another car (though they are quite stable). The compromise for
me is to have a value for airflow, for the ground effect + body
downforce, to be

(alpha) + (1-alpha) * airflow

I right now have alpha=.5, but I am not very satisfied with the
elegance of this... any ideas?

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

Hi Christos

>>Especially to apply textures which are fixed in the world coordinate
>>system this would be an easy solution to "light map". I think of this
>>because the textured skid marks from christos (which look great on most
>>tracks) miss the light map (especially annoying on mixed-1).
>>
> 
> 
> Not just the skidmarks, the cars miss the light map too.

Hmm, that can't be true, at least not on all tracks, let drive a car on 
g-track 3, it is clearly visible that the car gets dark as well...?!

> On the subject of maps, shouldn't the environment map of the cars
> rotate in the opposite direction of the cars rotation? Now it only
> moves when cars move but it does not rotate when cars rotate. I think
> it'd look better if it did rotate.

Perhaps... at least one could try it, it would be almost for free if the 
current solution uses the texture martrix stack (IIRC it does)... but 
the main problem of the environment maps IMHO is that the maps are 
actually not environment maps:-) I think even with the latest hardware 
it would be too expensive to crate all environmaps dynamically... so I 
was never really a big fan of them...

What one could try is just to create the environment map of the focused 
car dynamically and on the other still use the "faked" ones... perhaps I 
will try that (cube mapping), but not before TRB is ready.

Bye, Bernhard.


-- 

visit my homepage http://www.berniw.org
coming soon: The TORCS Racing Board, http://www.berniw.org/trb

> Especially to apply textures which are fixed in the world coordinate
> system this would be an easy solution to "light map". I think of this
> because the textured skid marks from christos (which look great on most
> tracks) miss the light map (especially annoying on mixed-1).
>

Not just the skidmarks, the cars miss the light map too.

On the subject of maps, shouldn't the environment map of the cars
rotate in the opposite direction of the cars rotation? Now it only
moves when cars move but it does not rotate when cars rotate. I think
it'd look better if it did rotate.

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