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

Hi Avinash

> Having said this, can someone shed light on how the current png capture work? Which files to look into? Also, how can one get data about the various objects (primarily) in that are rendered?

The interesting files for you are in src/libs/raceengineclient:
- racegl.cpp
- raceengine.cpp

grep for "capture" with "-i". The simulation is updated in 
raceengine.cpp, function ReOneStep. At the end of that function the 
tSituation structure s should be up to date and contains all properties 
you need. Because the graphics engine is a separate module, you have to 
look into the following file for the camera properties:

- src/modules/graphic/ssggraph/grcam.cpp

bye, Bernhard.

-- 

visit my homepage http://www.berniw.org

Thanks Eric, I will get the cvs and try that out.=0A=0ANow as for my requir=
ements: =0A=0A1) I need video sequence data from TORCS (that can be solved =
by your problem)=0A=0A2) I need to know the data structures of various rend=
ered objects (in our case Cars) that are displayed in the data in image coo=
rdinates. The data can include, their position, velocity, acceleration, etc=
.=0A=0AThere requirements stem from my desire to benchmark my Computer Visi=
on Object Recognition engine. For example, normally I use a caliberated cam=
era placed in a real car to capture my sequences. But then I have to hand l=
abel the objects present (and also assumption of their veloctiy, accelerati=
on) for each sequence. Then grade my engine on the hit-miss results. Using =
Torcs, I can do the same procedure for these synthetic sequences, but it wo=
uld be good to have the object data and not handlabel them. =0A=0AHaving sa=
id this, can someone shed light on how the current png capture work? Which =
files to look into? Also, how can one get data about the various objects (p=
rimarily) in that are rendered?=0A=0Abest,=0A=0A_avi=0A=0AOn Thu, 29 Jan 20=
04 Eric Espie wrote :=0A>Avinash Gore wrote:=0A>>Hi there,=0A>>=0A>>I was w=
ondering if it is possible to capture Image Sequences from Torcs. The image=
 sequences should also include ground truth data like, camera caliberation =
(to be given only at the begining only), vehicle ego motion, motion data fo=
r neighbouring objects (vehicles and obstacles, even lane data). Has anyone=
 thought/worked in this direction?=0A>>=0A>>My motivation behind this is my=
 PhD on Driver Assistance Systems. The work is to find an optimum selection=
 of image features (texture, orientation data, disparity etc.) and algorith=
ms to combine this data into an optimal representation of the world model. =
I was thinking of collecting some synthetic data from TORCS for benchmarkin=
g my results.=0A>>=0A>>It would be nice to get some idea on possible ways t=
o achieve this, interesting files, data structures, etc and lots of advice =
:)=0A>>=0A>>best,=0A>>=0A>>_avi=0A>>=0A>>--=0A>>This plan is so crafty, you=
 can put a tail on it and call it a fox - Black Adder=0A>=0A>I did not unde=
rstand well your needs, but yes you can capture=0A>image sequences with the=
 CVS version.=0A>=0A>here is the way to use the captures:=0A>=0A>Configure =
the video capture in the src/libs/raceengineclient/raceengine.xml=0A>file (=
or config/raceengine.xml in the runtime tree)=0A>=0A>Then during race hit t=
he "c" key to start/stop the capture.=0A>png images are stored in the speci=
fied directory.=0A>=0A>The names of the images are torcs-ssss-ffffffff.png=
=0A>where ssss is the sequence number=0A>and ffffffff is the frame number i=
n the sequence.=0A>=0A>Then you can use the png2jpg tool (in src/misc/pgn2j=
pg)=0A>to convert all the png to jpg images (you can use a quality=0A>of 10=
0 because it has no influence on the video size).=0A>=0A>then with mencoder=
 (the encoder of mplayer) you can easily=0A>create your video.=0A>I use the=
 following parameters for mencoder:=0A>-ovc lavc -lavcopts vcodec=3Dmpeg4:v=
hq:vbitrate=3D1800 \*.jpg -mf on:fps=3D25=0A>=0A>it seems that mencoder doe=
s not support the way the png=0A>files are generated by TORCS, that's why I=
 use a png2jpg=0A>converter.=0A>=0A>=0A>Bye,=0A>Eric.=0A>-- =3D+=3D+=3D+=3D=
+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=
=3D+=3D+=3D+=3D+=3D=0A>                        TORCS=0A>             The Op=
en Racing Car Simulator=0A>         AKA The Other Release Coming Soon (Skin=
'r)=0A>                  http://torcs.org=0A>=3D+=3D+=3D+=3D+=3D+=3D+=3D+=
=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D=
+=3D=0A>=0A>=0A>-------------------------------------------------------=0A>=
The SF.Net email is sponsored by EclipseCon 2004=0A>Premiere Conference on =
Open Tools Development and Integration=0A>See the breadth of Eclipse activi=
ty. February 3-5 in Anaheim, CA.=0A>http://www.eclipsecon.org/osdn=0A>_____=
__________________________________________=0A>Torcs-devel mailing list=0A>T=
orc...@li...=0A>https://lists.sourceforge.net/lists/lis=
tinfo/torcs-devel=0A=0A=0A--=0AThis plan is so crafty, you can put a tail o=
n it and call it a fox - Black Adder

Avinash Gore wrote:
> Hi there,
> 
> I was wondering if it is possible to capture Image Sequences from Torcs. The image sequences should also include ground truth data like, camera caliberation (to be given only at the begining only), vehicle ego motion, motion data for neighbouring objects (vehicles and obstacles, even lane data). Has anyone thought/worked in this direction?
> 
> My motivation behind this is my PhD on Driver Assistance Systems. The work is to find an optimum selection of image features (texture, orientation data, disparity etc.) and algorithms to combine this data into an optimal representation of the world model. I was thinking of collecting some synthetic data from TORCS for benchmarking my results.
> 
> It would be nice to get some idea on possible ways to achieve this, interesting files, data structures, etc and lots of advice :)
> 
> best,
> 
> _avi
> 
> --
> This plan is so crafty, you can put a tail on it and call it a fox - Black Adder

I did not understand well your needs, but yes you can capture
image sequences with the CVS version.

here is the way to use the captures:

Configure the video capture in the src/libs/raceengineclient/raceengine.xml
file (or config/raceengine.xml in the runtime tree)

Then during race hit the "c" key to start/stop the capture.
png images are stored in the specified directory.

The names of the images are torcs-ssss-ffffffff.png
where ssss is the sequence number
and ffffffff is the frame number in the sequence.

Then you can use the png2jpg tool (in src/misc/pgn2jpg)
to convert all the png to jpg images (you can use a quality
of 100 because it has no influence on the video size).

then with mencoder (the encoder of mplayer) you can easily
create your video.
I use the following parameters for mencoder:
-ovc lavc -lavcopts vcodec=mpeg4:vhq:vbitrate=1800 \*.jpg -mf on:fps=25

it seems that mencoder does not support the way the png
files are generated by TORCS, that's why I use a png2jpg
converter.


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

Hi there,=0A=0AI was wondering if it is possible to capture Image Sequences=
 from Torcs. The image sequences should also include ground truth data like=
, camera caliberation (to be given only at the begining only), vehicle ego =
motion, motion data for neighbouring objects (vehicles and obstacles, even =
lane data). Has anyone thought/worked in this direction?=0A=0AMy motivation=
 behind this is my PhD on Driver Assistance Systems. The work is to find an=
 optimum selection of image features (texture, orientation data, disparity =
etc.) and algorithms to combine this data into an optimal representation of=
 the world model. I was thinking of collecting some synthetic data from TOR=
CS for benchmarking my results.=0A=0AIt would be nice to get some idea on p=
ossible ways to achieve this, interesting files, data structures, etc and l=
ots of advice :)=0A=0Abest,=0A=0A_avi=0A=0A--=0AThis plan is so crafty, you=
 can put a tail on it and call it a fox - Black Adder

Original reply:

Followed to the letter. In addition, running
`make && make install datainstall`, as the CVS instructions recommend,
gives me the extra line 
'make: *** No rule to make target `install'. Stop.'

Which is even weirder. The Makefile, after a clean CVS checkout and
running configure with no errors, does not contain a target for
`install' or, indeed, a target for `clean'. Might this have something to
do wtih broken installations of autoconf or any other part of the
building process? It's possible that I need to reinstall something in
order to replace missing or corrupted files.

I will try the Debian packages as my next option: I wasn't aware of the
more up-to-date www.falassion.de, so thanks for letting me know, Gernot.

*Updated reply*

Five minutes later, having hesitated before sending this to try other
things that didn't make sense, I have figured it out. I know what was
wrong, and it's weird.

I had an environment variable TORCS_BASE= pointing to the wrong value. I
had moved the TORCS sources since the last successful compile, but that
coincidence didn't occur to me. rewriting $TORCS_BASE to point to the
right directory now sees the sources merrily compiling away.

I really should make a note of this, in case I do it again. Is it
something that should go in docs, apart from berniw's robot tutorial?

JH

On Thu, Jan 22, 2004 at 07:34:31PM +0100, Eric Espie wrote:
> Hi,
> 
> Have you followed the instructions of the "download & install" page ?
> <http://torcs.sourceforge.net/sections.php?op=viewarticle&artid=3>
> 
> Eric.
> 
> Jonathan Hepburn wrote:
> >Hello all,
> >
> >I've had this problem before, but can't remember if it was with TORCS 
> >and, if so, how I got around it.
> >
> >I have:
> >Debian testing
> >gcc-3.3
> >A brand new, from scratch, CVS checkout of TORCS
> >
> >Configure has no complaints, but this is the sole output of 'make':
> >$ make: `Make-config' is up to date.
> >
> >Can anyone offer a solution? TORCS CVS is so much improved over the last 
> >release that I don't really want to go back and try that and, thanks to 
> >upgrading from Debian stable to testing and losing some libstdc libs, my 
> >current installation doesn't work.
> >
> >Cheers,
> >JH
> >
> 
> 
> -- 
> =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
>                        TORCS
>             The Open Racing Car Simulator
>         AKA The Other Release Coming Soon (Skin'r)
>                  http://torcs.org
> =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=

Hi,

Have you followed the instructions of the "download & install" page ?
<http://torcs.sourceforge.net/sections.php?op=viewarticle&artid=3>

Eric.

Jonathan Hepburn wrote:
> Hello all,
> 
> I've had this problem before, but can't remember if it was with TORCS 
> and, if so, how I got around it.
> 
> I have:
> Debian testing
> gcc-3.3
> A brand new, from scratch, CVS checkout of TORCS
> 
> Configure has no complaints, but this is the sole output of 'make':
> $ make: `Make-config' is up to date.
> 
> Can anyone offer a solution? TORCS CVS is so much improved over the last 
> release that I don't really want to go back and try that and, thanks to 
> upgrading from Debian stable to testing and losing some libstdc libs, my 
> current installation doesn't work.
> 
> Cheers,
> JH
> 


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

Hello all,

I've had this problem before, but can't remember if it was with TORCS and, if so, how I got around it.

I have:
Debian testing
gcc-3.3
A brand new, from scratch, CVS checkout of TORCS

Configure has no complaints, but this is the sole output of 'make':
$ make: `Make-config' is up to date.

Can anyone offer a solution? TORCS CVS is so much improved over the last release that I don't really want to go back and try that and, thanks to upgrading from Debian stable to testing and losing some libstdc libs, my current installation doesn't work.

Cheers,
JH

Christos Dimitrakakis wrote:
> Some questions. First of all, the track. Is it possible to have a
> description of the track where the banking is varies in the lateral
> direction? i.e. how can I have a curve where the inside has no banking
> and the extreme out has 90 degree banking, with everything varying
> smoothly in between?

I have attached a drawing to explain how the height is computed
for the track.
The segments defined in the xml track definition are splitted into
small enough segments (represented on the drawing) for the simulation.

The X axis is the direction of travel.

The corners of the segment are:
SR - Start-Right
SL - Start-Left
ER - End-Right
EL - End-Left

The angles are:
XS - the rotation around X axis at the start of the segment.
XE - the rotation at the end of the segment.
YR - the rotation of the right side around Y
YL - of the left side.

The Kzl parameter is the grade of this segment at the right side
(tangent of YR).

The Kzw (not on the drawing) is the variation of the banking
along the segment (XE - XS)/(segment length)

To compute the height of point M:
first the right side is followed using Kzl,
then the XM banking at point M is computed using Kzw and the
lateral grade is computed for point M (purple path on the drawing).

Knowing that, the projection of the segment on the ground have
a constant width, so it is not possible to have a 90 deg banking.

> 
> The barriers currently don't let you go 'off-road'. The major problem,
> I guess, is that the TrackHeight() and TrackNormal() functions are all
> determined just for the track.. and there is no description for the
> scenery.. or is there? How is it accessible?

No, the simulation does not know that the scenery exists.
Only the track definition from the xml file is used by the silmulation.
This would allow (in theory) to have a 2D only graphic module.

> 
> 

Hope that the explanation were clear enough...
if not, don't hesitate to ask for precisions.

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

Some questions. First of all, the track. Is it possible to have a
description of the track where the banking is varies in the lateral
direction? i.e. how can I have a curve where the inside has no banking
and the extreme out has 90 degree banking, with everything varying
smoothly in between?

The barriers currently don't let you go 'off-road'. The major problem,
I guess, is that the TrackHeight() and TrackNormal() functions are all
determined just for the track.. and there is no description for the
scenery.. or is there? How is it accessible?


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

1. The view ratios in split screen mode are incorrect when the screen
is split in two parts (one top, one bottom).

2. In split screen mode, how do you change the view for each screen
separately? It is not obvious.

3. Sometimes you are racing and you switch to a different camera view
and change centered cars with PUP/PDOWN, but you can never go back to
the car you are driving.

Also, I should finish the sound support for 1.2.2 so that it at least
supports multiplayer. Though the OpenAL support will almost definitely
not be there.

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

Regarding the new quaternion code.. it only seems to work properly for
angular velocities in z. Let me give some more detail:
The car has, at every point in time, an angular velocity vector
describing its angular velocity around the three axis x,y,z. These
axis are the *car* axis. So, the aim is to rotate these axis by an
amount proportional to the angular velocity and then find out what is
the resulting angle of these axis relative to the world axis. I think
it is this last step that is causing problems. I am not sure what I am
doing wrong.

Camber angles: I have modified the fishbone geometry a little bit..
then I tried giving the berniw drivers different values for camber in
the car set up. It seems that the best values are between -1 and 0
degrees.

Other robot problems: Now that the sim is full 3d, the effect of
banking and slopes is greater. That is not taken into account by most
robot code, causing robots to go too slow in banked curves (i.e. in
michigan) and too fast in some other places (wheel-1, the double right
downhill curve)


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

> Now some time the wheels disappear... try a race on dirt-2
> with Berniw 10, K1999 and Astigot 4.
> I think that weird suspension values could give that results.
>
Yeah, that's because I used stupid values for the suspension links. I
don't know what are 'real' values.


> but the race ends rapidly because the cars spin like mad...
> nevertheless, the cars seems to roll-over less frequently.
>

I think the roll-over does not occur too frequently.. but the
behaviour after roll over should be correct. Unless you have any other
ideas.

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

Christos Dimitrakakis wrote:
>>No it's just that the car->_skid values have changed.
>>they were shifted before, now I have changed the
>>graphic code and it works like before.
>>
> 
> 
> So, now skidmarks appear when _skid is larger than 0.2?
> Before this was done in the wheel.code, transferring all values in
> [0,0.2] to 0 and all other values to x-0.2.
> 
> 
I added the 0.2 threshold in ssgraph, because it seems
that the value range was now [0,1] and I thought you made the modifs
for the sound.

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

> >
> No it's just that the car->_skid values have changed.
> they were shifted before, now I have changed the
> graphic code and it works like before.
>

So, now skidmarks appear when _skid is larger than 0.2?
Before this was done in the wheel.code, transferring all values in
[0,0.2] to 0 and all other values to x-0.2.


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

Eric Espie wrote:
>>
>> Also, when starting the race, the p406's rear wheels spin.
>>
> 
> Surprisingly, I saw that RWD cars have front wheels spinning
> (at start only) ...
> 
> Eric.

I fixed the problem (in simu.cpp) it was a pre-start
simulation problem.

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

> 
> Also, when starting the race, the p406's rear wheels spin.
> 

Surprisingly, I saw that RWD cars have front wheels spinning
(at start only) ...

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

Christos Dimitrakakis wrote:
>>Have you tried the Buggy ? It's *really* funny :-)
>>May be the application of the wheel forces
>>should not be done at ground level but perhaps at
>>suspension level ?
>>
> 
> 
> You are right. The application of the forces that are perpendicular to
> the suspension should be done at the exact point where they are
> generated since they are directly transferred to the car (it doesn't
> matter if they are not applied directly to the car.. remember how
> levers work). But the suspension forces (wheel->forces.z) actually
> originate from the suspension and so should be applied to the point of
> contact of the suspension with the car.
> 
> Let's look at the code:
> 	F.M.x += (car->wheel[i].forces.z * car->wheel[i].staticPos.y +
> 	    car->wheel[i].forces.y *// car->wheel[i].relPos.z;
> 	(car->statGC.z + car->wheel[i].rideHeight));
> 	F.M.y -= (car->wheel[i].forces.z * car->wheel[i].staticPos.x +
> 	    car->wheel[i].forces.x * //car->wheel[i].relPos.z;
> 	    (car->statGC.z + car->wheel[i].rideHeight));
> 	F.M.z += (-car->wheel[i].forces.x * car->wheel[i].staticPos.y
> +
> 	    car->wheel[i].forces.y * car->wheel[i].staticPos.x);
> 
> forces.z are the suspension forces... let's isolate them:
> 
>  F.M.x += car->wheel[i].forces.z * car->wheel[i].staticPos.y;
>  F.M.y -= car->wheel[i].forces.z * car->wheel[i].staticPos.x;
> 
> If staticPos.y and x are at the wheel's center then obviously this is
> wrong and the suspension point of contact is slightly shifted...
> according to the camber angle:
> 
> wheel->susp.staticPos.y
> =
> wheel->staticPos.y - wheel->susp.spring.X0 * wheel->susp.bellcrank
> 	* sin(wheel->staticPos.ax);
> 
> the z position of the suspension is not important unless the
> suspension is tilted (well, it is tilted according to the default
> cambers actually). The x position should be the same as that of the
> wheel.
> 
> So I guess we are slightly overestimating the torque applied to the x
> axis of the car, which might explain the Buggy behaviour. Or perhaps
> the buggy just has the GC too high.
> 
> Note that this behaviour does not appear if I remove the lateral
> reaction forces (Fn, Ft in wheel.cpp).
> 

Now some time the wheels disappear... try a race on dirt-2
with Berniw 10, K1999 and Astigot 4.
I think that weird suspension values could give that results.

Now we can see the suspension geometry in action on this
track, very cool :-)

but the race ends rapidly because the cars spin like mad...
nevertheless, the cars seems to roll-over less frequently.

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

Bernhard Wymann wrote:
> Hi All
> 
>>> so it is not there. It happens to me for example in the Aalborg track,
>>> when using berniw two 1,2,3,4,5 and me running with pw-corrola.. in
>>> the beginning the frame rate is ~50 then it drops to 12 or so.. I'll
>>> check again that I have the fix in my development tree.
>>>
>>>
>> It seems that the skid marks are always displayed now...
>> this can explain the performance drop...
>>
>> Eric.
> 
> 
> I suspect the skidmarks are displayed all the time because there is a 
> lot of slip between the road and the tire with the new camber code. If 
> you plan to release 1.2.2 with simuv3 we need to readjust the setups of 
> the cars, so let me know:-)
> 
> I think the resulting camber will be then almost 0:-( No cool look 
> anymore...
> 
> bye, Bernhard.
> 
No it's just that the car->_skid values have changed.
they were shifted before, now I have changed the
graphic code and it works like before.

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

> I suspect the skidmarks are displayed all the time because there is a
> lot of slip between the road and the tire with the new camber code. If
> you plan to release 1.2.2 with simuv3 we need to readjust the setups of
> the cars, so let me know:-)
>

Actually it is because I have modified how _skid[] is calculated.
Stupid me.

car->carElt->_skid[index] = MIN(1.0, s*reaction_force*0.0002);

The slip is calculated a bit differently, but it is essentially the
same.
	sx = wvx/absolute_speed;
	sy = wvy/absolute_speed;
	sa = atan2(wvx,wvy);
	s = sqrt(sx*sx+sy*sy);

Where wvx and wvy are the relative speed of the wheel wrt the road,
taking angular velocity into account. The absolute speed only has an
effect on the calculation of Bx and the rest of the magic formula,
which I am not sure what it does. Eric?

Anyways, I'll modify it so that when s*reaction_force*0.0002 <
threshold the _skid is set to 0. That should stop the skidmarks being
there all the time.


> I think the resulting camber will be then almost 0:-( No cool look
> anymore...
>

You still have 90% of the traction when the camber is 25 degrees, so I
don't think the effect is particularly big. The camber setting should
be such that when you turn the outer wheels have a camber close to 0.
Since the car tilts anyway a little bit, they need to have a camber
setting from the beginning.

Currently I am just using cos(camber) to calculate the
traction change because of camber. But that might be wrong.

....

I tried the FWD cars and they oversteer a lot. Is that because of the
suspension settings? I have the nagging feeling it's because there's
something braking the rear wheels.

Also, when starting the race, the p406's rear wheels spin.

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

Hi All

>> so it is not there. It happens to me for example in the Aalborg track,
>> when using berniw two 1,2,3,4,5 and me running with pw-corrola.. in
>> the beginning the frame rate is ~50 then it drops to 12 or so.. I'll
>> check again that I have the fix in my development tree.
>>
>>
> It seems that the skid marks are always displayed now...
> this can explain the performance drop...
> 
> Eric.

I suspect the skidmarks are displayed all the time because there is a 
lot of slip between the road and the tire with the new camber code. If 
you plan to release 1.2.2 with simuv3 we need to readjust the setups of 
the cars, so let me know:-)

I think the resulting camber will be then almost 0:-( No cool look 
anymore...

bye, Bernhard.

-- 

visit my homepage http://www.berniw.org

Right-o. The angular velocity is working properly now, using
quaternions. That solved the problem of strange behaviour on slopes
(try doing hard turns on a slope using simuv3-pre1 and you'll see).
Everything now is super-smooth.

Added a simple suspension geometry and a double-link geometry. By
default all cars use the double-link.

Minor problems:

I added a sound effect for when the car scrapes the ground (when it
enters the SimCarCollideZ code, I set car->collision|=1). Is this a
good condition for touching the ground? Because the Porsche GT1 has
such a low rideheight and such strong a downforce that its springs
compress completely after it passes 250Km/h or so and starts scraping
the track after that.. or maybe I should check that delta.z (equal to
whwl->susp.spring.packers - wheel->rideHeight in the horizontal case)
is > 0 also.. or maybe I should set the collision only when the
dotproduct of the speed with the track normal is < 0. Ahem. Hm.

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

> Have you tried the Buggy ? It's *really* funny :-)
> May be the application of the wheel forces
> should not be done at ground level but perhaps at
> suspension level ?
>

You are right. The application of the forces that are perpendicular to
the suspension should be done at the exact point where they are
generated since they are directly transferred to the car (it doesn't
matter if they are not applied directly to the car.. remember how
levers work). But the suspension forces (wheel->forces.z) actually
originate from the suspension and so should be applied to the point of
contact of the suspension with the car.

Let's look at the code:
	F.M.x += (car->wheel[i].forces.z * car->wheel[i].staticPos.y +
	    car->wheel[i].forces.y *// car->wheel[i].relPos.z;
	(car->statGC.z + car->wheel[i].rideHeight));
	F.M.y -= (car->wheel[i].forces.z * car->wheel[i].staticPos.x +
	    car->wheel[i].forces.x * //car->wheel[i].relPos.z;
	    (car->statGC.z + car->wheel[i].rideHeight));
	F.M.z += (-car->wheel[i].forces.x * car->wheel[i].staticPos.y
+
	    car->wheel[i].forces.y * car->wheel[i].staticPos.x);

forces.z are the suspension forces... let's isolate them:

 F.M.x += car->wheel[i].forces.z * car->wheel[i].staticPos.y;
 F.M.y -= car->wheel[i].forces.z * car->wheel[i].staticPos.x;

If staticPos.y and x are at the wheel's center then obviously this is
wrong and the suspension point of contact is slightly shifted...
according to the camber angle:

wheel->susp.staticPos.y
=
wheel->staticPos.y - wheel->susp.spring.X0 * wheel->susp.bellcrank
	* sin(wheel->staticPos.ax);

the z position of the suspension is not important unless the
suspension is tilted (well, it is tilted according to the default
cambers actually). The x position should be the same as that of the
wheel.

So I guess we are slightly overestimating the torque applied to the x
axis of the car, which might explain the Buggy behaviour. Or perhaps
the buggy just has the GC too high.

Note that this behaviour does not appear if I remove the lateral
reaction forces (Fn, Ft in wheel.cpp).

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

Christos Dimitrakakis wrote:
> On Wed, 14 Jan 2004, Bernhard Wymann wrote:
> 
> 
>>Hi Eric and Christos
>>
>>
>>>>>>2. Improved support for camber angles
>>>>>>- Now traction is reduced at very high relative angles between tyre
>>>>>>surface and track.
>>>>>
>>>My point of view is that vertical springs could be ok, I don't
>>>thinks that we could feel the camber change due to the
>>>rotation of the suspension... If you consider the low ride
>>>height of the race cars, the angle variation will be very small.
>>>
>>>goal was first visual: I had to avoid the wheel going through the
>>>car body.
>>
>>I agree with this point. I think the simulation feels realistic enough
>>without considering the suspension geometry. That was also the reason
>>why I would prefer the "old" camber code in the new simuv3, simply
>>because it looks better:-)
>>
> 
> 
> I tried it with the simplest possible independent suspension. It looks
> OK in general. To avoid going through the car body the only thing you
> need is to set the packers to an appropriate value and/or raise the
> ride-height.
> 
> One thing we need to keep in mind is that high-performance cars have
> an almost-ideal suspension in the sense that it is trying to
> approximate the suspension we are currently simulating. While far from
> ideal, this suspension is still not as 'good' as the one that we have
> in simuv3.
> 
> So, the simplest possible independent suspension has a single link at
> the axle, I think and thus the wheels point 'outwards' when the car is
> pushed down and inwards when it's pulled up. I think this design is
> not used anymore and that it was the first independent suspension
> design.. maybe we can use it on the Buggy and/or VWBug.
> 
> The double fishbone suspension simply has the effect of reducing this
> camber change, perhaps in a non-linear manner. The exact mechanics are
> not really important. We have the ideal case and the simple case.. so
> we could just make cases in-between for the various cars.. as for the
> fishbone suspension it is easy to model exactly since the position of
> the lower link is determined directly by the spring length, while that
> of the upper link by the point of intersection between two circles.
> (one originating at the end of the lower link and one at the root of
> the upper link, with the first having as radius the distance between
> the fishbone connections on the wheel and the second the length of the
> upper link).
> 
> 
> 

Have you tried the Buggy ? It's *really* funny :-)
May be the application of the wheel forces
should not be done at ground level but perhaps at
suspension level ?

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

Christos Dimitrakakis wrote:
>>The memory leak is caused by the following code in grcarlight.cpp (so it
>>was a side-side effect of the mirror):
>>
> 
> 
> I think there is still a memory leak somewhre. I see that the current
> code has been fixed:
> 
>       if (!disp) {
> 	  continue;
>       }
>       clight = (ssgVtxTableCarlight
> *)theCarslight[car->index].lightArray[i]->clone(SSG_CLONE_GEOMETRY);
>       clight->setCullFace(0);
> 
> 
> so it is not there. It happens to me for example in the Aalborg track,
> when using berniw two 1,2,3,4,5 and me running with pw-corrola.. in
> the beginning the frame rate is ~50 then it drops to 12 or so.. I'll
> check again that I have the fix in my development tree.
> 
> 
It seems that the skid marks are always displayed now...
this can explain the performance drop...

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

> be explained by the initial build up of skidmarks. Do you experience
> also a drop in the framerate when you set skidmarks to a low number
> (graphics settings)?
>
> The framerate drop is caused by the skidmarks I guess. What kind of
> hardware do you use (some DRI drivers have several restrictions, look at
> http://www.xfree86.org/4.3.0/DRI10.html#23)?
>
Hm.. this is the total number of skidmarks or the number of skidmarks
per car? In any case the frame rate continues to drop even after
skidmarks begin to be removed from the world..


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