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

This is the second test, now all the sounds are working.

- As before, you should copy the files to a separate dir instead of
ssggraph/

- Also copy the new turbo sound into data/sounds/

- You again need to use the same interface/ and configscreens/ files
that were attached to my previous email...

- You again need to use the patched linux openal (dunno about
windows, if it uses directX maybe it works.. )

Caveats:

1. The PLIB implementation is not yet there

2. Looped sounds don't seem to work very well in OpenAL. There are
glitches which do not exist with PLIB, or indeed with any other
program.

3. OpenAL has pitch clamping hardcoded in many places, I am still
trying to figure out where all instances of it are. It also uses table
look ups to calculate periods, which IMHO is completely insane since
it's only one div per hundreds of samples.

4. I still don't know how to create new filters, so no engine low pass
filter at the moment.


PS. On other sound-related news, I have managed to improve my sound
modeller considerably.. and now it can be used to any degree of
accuracy, with some capability to remove noise [perfect accuracy just
gives you the original sample - low accuracy just gives you a
noise-free periodic wave - the leftover noise is then modelled
separately, as bandlimited white noise, and can be mixed freely with
the clean sample]..

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

OK, when two cars collide, the speed of the collision points is
calculated. I think this calcualation suffers from the same error that
CalculateCornerPos() did, namely mixing up the frames of reference.
However, fixing that does not fix car2car collisions.

What is observed in car2car collisions:

The collision result depends upon the orientation of the cars.

So, when car A hits car B on the front right laterally (coming
directly from its right side), the cars spin OK when car A faces West,
but the spin is the opposite when car A faces East.

Regrettably, I cannot really understand how the car2car code is
supposed to work, so I cannot determine whether there is a
problem in the design, a problem in
the equations, a bug in the implementation of the equations, or a bug
in SOLID.

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

Can we add Christophe Macours to the credits page for the next
release? He has been providing some sound samples. (Check out
http://users.belgacom.net/samples/ for some examples)


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

I have a small test release. Better rename the ssgraph directory to
something else and compile and install it. Also make a backup of
src/interfaces/graphic.h and src/libs/confscreens/soundconfig.cpp and
replace them with the versions in the archive.
The changes in graphic.h and soundconfig.cpp are there to change the
enable/disable switch into plib/openal/disable and to add a global
volume control.

For correct OpenAL behaviour under linux, copy the stuff in linux_src/
in the openal source tree under src/linux/ - it will work without the
patch, but it will sound weird.

Note that only the skid and engine sounds are currently available. I
will add the other sounds later, once I decide on a global strategy
for prioritisation that does not require code duplication.
Customisable queues seem to be the way to go.




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

With some help from Thorsten's code I have built a working OpenAL
implementation. Currently the only thing missing is the lowpass
filter and fixing a couple of annoying glitches.One of them is how to
avoid a the split-second full-volume burst of all sounds at
initialisation. Still haven't found the correct set up order.

Will submit to CVS in a couple of days. In the meantime, if anyone
knows how to add custom filters to openal..

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

Hm.. is it right to have a clutch inertia at 0.115 kg m^2? That's
around half the engine inertia in most cars.. perhaps 10 times
smaller?

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

I just finished the new sound framework and it was a matter of a
couple of hours to plug openal into it. It seems to work OK, though
OpenAL itself seems to have a couple of issues which I have to fix.
One is the doppler calculation, which is incorrect it seems and which
I already fixed, and the other is the pitch limiting which I have to
find where it is in the code :)

I also had a problem compiling the .sgml in the docs/ directory. I can
read the .info file in linux/doc, but the .sgml files seem to contain
much more information, which I tuink will be useful.

Anyway, I will post on the mailing list the new sound framework with
openal in a couple of weeks. If someone thinks they have some time to
help with bugfixing and development at this very early stage, I could
add 2 new directories in CVS. One for the new sound implementation and
one for openal (for bugfixes). Otherwise I'll post everything to the
mailing list when I think it is ready and we'll replace the current
CVS a bit after that.

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

> Thanks. I've had a little time for testing now. simuv3 feels much
> smoother now and the shock-absorber problem I reported earlier is gone.
> However, I think there's still something wrong with collisions. When I
> drive behind another car (tested with nascar and clk-dtm behind lliaw)
> and touch the other car slightly from behind, both cars suddenly start
> spinning, as if the reaction force was applied 90=B0 off. Not all car
> combinations seem to be affected though. When I crash into another
> nascar it behaves as expected.
>

See one of my previous posting the last couple of weeks. Car2car
collisions sometimes calculate the opposite forces in the local frame
of reference than the ones they should be. I still have not looked
into it.

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

Am Montag, den 04.04.2005, 16:47 +0200 schrieb Christos Dimitrakakis:=20
> > I grepped for PRM_MODEL_TYRE_TEMPERATURE but I couldn't find it anywher=
e
> > in the source tree. Did you omit some file when you committed your
> > changes?
> >
>=20
> Thank you, I have ommited src/interfaces/car.h, which contains the
> related string constant definitions.
>=20
> Is there a better place to put such definitions? Changing car.h
> ususually forces a rebuild of the three. I'd imagine that these
> definitions will only be needed in simu and whatever module wants to
> change the simulation options.
>=20

Thanks. I've had a little time for testing now. simuv3 feels much
smoother now and the shock-absorber problem I reported earlier is gone.
However, I think there's still something wrong with collisions. When I
drive behind another car (tested with nascar and clk-dtm behind lliaw)
and touch the other car slightly from behind, both cars suddenly start
spinning, as if the reaction force was applied 90=B0 off. Not all car
combinations seem to be affected though. When I crash into another
nascar it behaves as expected.

Regards,
  Felix

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

One more thing, from what I read it seems that high performance cars
hardly ever have a free differential, so I guess the sc-f1 and
viper-gts should be changed to limited slip?



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

OK, after some study it seems to me that the open differential is
equivalent to a wheel mounted between two moving surfaces, and a
lateral force through its center of mass is applied to it. The wheel
can rotate freely and is rigid. The surfaces correspond to the wheel
gears. We assume gear contacts rather than any sliding frictive force
betweeh the wheel and the surfaces.

-------------
      O->F
-------------

A force F pushes the wheel laterally. If there is no resistance, the
two surfaces move along with the wheek.

Initially, F1=F2, but if plate 1 is immobile it reacts with force
equal and opposite to F1. This reaction gets transmitted back to the
other plate through the wheel, because the wheel can rotate freely.
So at the limit, F2=F, F1=0.

I guess in general we could say F1=F-reaction2, F2=F-reaction1.. I
don't think min/max operations are necessary... I'll check it however.

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

>
> Have you considered using oprofile (support is included in 2.6 kernels)?
> I've made some good experience with it profiling graphics drivers,
> including kernel drivers. The nice thing about oprofile is that it
> doesn't need code instrumentation. And if your CPU supports it (all
> recent AMD and Intel CPUs do) you can even profile stuff like cache
> misses.
>

Up to know I have been trying to use gprof, which I guess has minimal
instrumentation because it is statistical, but have had little success
with it so far with loadable modules. I'll definitely give oprofile a
shot once I upgrade my kernel then.


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

Am Sonntag, den 03.04.2005, 19:19 +0200 schrieb Christos Dimitrakakis:
> Hm, I wanted to run some detailed profiling on the simuv3 module with
> either gcov or gprof. I know how to do that with standalone execs, but
> how can I do it just for a module openeded with dlopen()? Any hints?

Have you considered using oprofile (support is included in 2.6 kernels)?
I've made some good experience with it profiling graphics drivers,
including kernel drivers. The nice thing about oprofile is that it
doesn't need code instrumentation. And if your CPU supports it (all
recent AMD and Intel CPUs do) you can even profile stuff like cache
misses.

Regards,
  Felix

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

Great, thanks. Does this include any extra overhead?
-- 
Christos Dimitrakakis
IDIAP (http://www.idiap.ch/~dimitrak/main.html)

Christos Dimitrakakis wrote:
> Hm, I wanted to run some detailed profiling on the simuv3 module with
> either gcov or gprof. I know how to do that with standalone execs, but
> how can I do it just for a module openeded with dlopen()? Any hints?
> 
> 

an embedded profiler is included into the code (provided by
Henrik Enqvist) just configure with --enable-profiler to activate
the code and put the following macros in your code:

START_PROFILE("my_label")

and

STOP_PROFILE("my_label")

calls can be nested (with different labels of course)
for detailed profiling.

on exit a call to PRINT_PROFILE() displays
the statistics.

Eric.

Christos Dimitrakakis wrote:
>>>Is the thing described here what DIFF_FREE is supposed to be?
>>>
>>>http://auto.howstuffworks.com/differential6.htm
>>
>>Yes. Its the classic differential without any intelligence in it, pure
>>gears:-) Please do not change simuv2 in that respect, 1.2.4 will use
>>transmission code of 1.2.3. A simple test case for it is if you place
>>the car with one driven wheel on sand/dirt and the other on asphalt.
>>
> 
> 
> OK, I think I understand how it works. I changed it in simuv3 the way
> I *guessed* it might be, but if it is correct that 'when one wheel is
> immobile, all the torque is output on the other wheel', then the
> current simuv2 implementation could be correct, though I am not sure
> yet how it was arrived at.
> 

DIFF_FREE is an open differential, and the behaviour is exactly
the one you described ;-) the power goes to the wheel that have
the less resistance that's why it is very bad on slipery surfaces.

Eric.

> >
> > You mentioned SDL before and I think I saw it in the README. Is it
> > going to replace something? Is it going to offer something additional?
>
> It should resolve the fullscreen issue, so it should replace GLUT

That'd be nice. I do recall the fullscreen working properly at some
point in time, with it even reverting to the correct resolution after
a crash.

> Sorry for being asshole sometimes (yes, I takl about myself), I do not
> basically like it to rollback good stuff, but I hope you have a little
> bit of understanding for my argumentation (that it simply takes too long
> to fix all dependencies up and that I have at least for me more
> important things in the queue).
>
There's not much 'good stuff' in the simu unfortunately :P

> Btw. I never asked you about your "vision" of TORCS, what do you think,
> where would you like to go (I would like to know it because you make up
>   a major part of the team curently)?
>

The main reason I joined the project was because I like two things:

1. Racing a good simu.
2. Writing robot code.

I particularly enjoy driving on heavily inclined tracks, so, I was
hacking at the simu mainly with the view to make this thing work
properly in TORCS. Overall I like getting the impression that I am in
a real vehicle - on the other hand the inadequaties of the available
control devices and the practical simulation limitations are factors
which I consider important when deciding to add or modify features.
The kind of features I like to add are things that add to realism
while making the driving a bit smoother (such as the smooth aero cut
off and the transmission fix). I also like adding things that everyone
expects from a real car (such as the engine stalling).

In the end, however, I just want to make a simu that works and does
not have glitches, while at least making sure that newton's laws are
obeyed :)

If I have time in the future I would like to work on some rather
important details, such as the static friction problem, on
a model with free wheels and perhaps on some aerodynamics models.
I will also probably do some work on real-time sound modelling. But
all this would be something I'd do just for me, to experiment with,
unless something turns out to be REALLY GOOD.

In the next few iterations of the project I would like to see TORCS
mature. Have a stable simu, 3D sound, no GUI grashes, good robot
drivers, interesting tracks. In the meantime I hope we can start work
on the networking by next year; that would give me an excuse to get a
net connection at home :)

For the long term I think it would be important for the project
to maintain and even extend flexibility, for example with respect to
realism settings. In that view, it would be nice if the loadable
module concept remained a central part so that we could have (say)
different types of tracks, by loading different track modules,
different rendering engines, different sound systems or different
simulations. This already exists in a large part with the robot code,
for which many different modules have already been created and are
used.

> Bye, thank you very much for your efforts,
>

Thanks for your kind words, it's an honour to work with you guys.

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

Hi Christos

>>1.4 will be for (probably, 1.3 could be for SDL, whatever is good enough
>>and ready frist).
>>
> 
> 
> You mentioned SDL before and I think I saw it in the README. Is it
> going to replace something? Is it going to offer something additional?

It should resolve the fullscreen issue, so it should replace GLUT (I'm
not that happy with the freeglut guys anymore as I was 2 year ago,
basically they perfer to discuss how to use asserts and how to format
code instead of fixing bugs...). It has as well a portable threading
interface which could be of relevance for me (SMP, in future multi CPU
cores this seems to come anyway). Perhaps OpenGLUT would be an
alternative as well, but I have to evaluate it first.

> Now that I have finished more or less with what I want simuv3 to do
> (which is to have accurate 3D dynamics), I'll leave it frozen for a
> month or so, until you guys have tested it sufficiently, and will
> continue openal development in the meantime. If I have free time I
> will do some simu cleanups.
> 
> Sorry for sending all those messages, it takes too much of your time I
> know.

Sorry for being asshole sometimes (yes, I takl about myself), I do not
basically like it to rollback good stuff, but I hope you have a little
bit of understanding for my argumentation (that it simply takes too long
to fix all dependencies up and that I have at least for me more
important things in the queue).

Btw. I never asked you about your "vision" of TORCS, what do you think,
where would you like to go (I would like to know it because you make up
  a major part of the team curently)?

Bye, thank you very much for your efforts,

Bernhard.


-- 

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

Hi Christos

> For the transmission/differential, I was thinking that perhaps the
> FREE differential just seemed to be working correctly because the
> transmission was incorrect and made all differentials behave
> similarly because wheels where spinning up almost instantly when they
> lost grip.

They did not behave similarly (talking about simuv2), I quite tested it
when I wrote the robot tutorial. The behaviour was like you would expect
from it:
- with free you have one wheel spinning if not on the same surface.
- with free you come best trough the corners.
- short, it matches the expectation for the test cases.

> As for the engine stalling stuff, my decision was to remove it
> completely, but I wanted your feedback before I got rid of it.

I can't tell, I did not look at it.

>>That was one of the reasons why it did not make it to 1.2.3. The correct
>>first step IMO would have been to have a "simuv2 in 3d", without too
>>much new stuff to adopt gradually, but now this will become a tough cut
>>then, it simply changes too much at once...
> 
> 
> Unfortunately, according to my code profiling, almost all of the slow
> down occurs in the 3D parts. Most of it in wheel.cpp, which has 6
> coordinate transforms per wheel, and the rest in car.cpp. For the

What about scrapping camber?

> wheel quaternions don't help as each transformation has different
> angles. Simuv3 does not really have any extra features apart from:
> 
> 1) Engine angular momentum conservation when changing gears/using
> clutch. This takes up CPU only during those times.

Hmm, thats not entirely correct with cached cpu's in general. There is a
good chance that you have to wait longer for code/data because of a
cache miss if you have more code/data. And cache misses really hurt.

> 
> 2) Tyre wear/temperature. This is inactive by default.
> 
> 3) Calculation of wheel force feedback. This takes a fair bit of time,
> as it is a reapplication of the magic formula with a couple of
> different terms. Fortunately most terms need to be calculated only
> once, but it still takes up a bit of time.
> 
> 4) 3D collisions. No overhead unless a collision is detected (the
> detection is done in a very rudimentary manner, uses the suspension
> state for when the car is the right way up, otherwise does a
> coordinate transform of a point 0.5m above the center of mass of the
> car at each corner and sees if it touches the ground)
> 
> 5) Aero and downforce cut offs, gradual slipstreaming. This is just a
> couple of instructions right now.

Be careful about that, here and there a couple of instructions...

> 6) Engine braking/consumption. No overhead, should be on average same
> as simuv2.
> 
> This is all I can think of for the moment. I don't think there is a
> huge difference between the simus right now, at least nothing that I
> can feel on flat tracks. On any inclined surface there is a huge
> difference, but that is only to be expected. Robots are within a
> couple of seconds of performance in general.

That's not the point anyway, because you do not feel it if you run 5
seconds faster or slower.

> I think right now simuv3 is basically ready. We could fix the

I think I heard this statemant already one year ago, I think we should
reconsider it earliest after 1.2.5, there are more dramatic things to do;-)

> collision of cars and perhaps improve the body collision model a bit,
> although this very simple one is currently adequate. Otherwise I'd
> like to concentrate on cleaning up the code, removing redundant stuff
> and perhaps doing some optimisations if possible.

IMHO it is really necessary. But you forget the ugly part, you have to
bring ALL cars and most robots up to simuv3. And testing takes time as
well...

Bye, Bernhard.


-- 

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

Hi Bernhard,

> 1.4 will be for (probably, 1.3 could be for SDL, whatever is good enough
> and ready frist).
>

You mentioned SDL before and I think I saw it in the README. Is it
going to replace something? Is it going to offer something additional?

Now that I have finished more or less with what I want simuv3 to do
(which is to have accurate 3D dynamics), I'll leave it frozen for a
month or so, until you guys have tested it sufficiently, and will
continue openal development in the meantime. If I have free time I
will do some simu cleanups.

Sorry for sending all those messages, it takes too much of your time I
know.

Cheers,
Christos

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

For the transmission/differential, I was thinking that perhaps the
FREE differential just seemed to be working correctly because the
transmission was incorrect and made all differentials behave
similarly because wheels where spinning up almost instantly when they
lost grip.

As for the engine stalling stuff, my decision was to remove it
completely, but I wanted your feedback before I got rid of it.

> That was one of the reasons why it did not make it to 1.2.3. The correct
> first step IMO would have been to have a "simuv2 in 3d", without too
> much new stuff to adopt gradually, but now this will become a tough cut
> then, it simply changes too much at once...

Unfortunately, according to my code profiling, almost all of the slow
down occurs in the 3D parts. Most of it in wheel.cpp, which has 6
coordinate transforms per wheel, and the rest in car.cpp. For the
wheel quaternions don't help as each transformation has different
angles. Simuv3 does not really have any extra features apart from:

1) Engine angular momentum conservation when changing gears/using
clutch. This takes up CPU only during those times.

2) Tyre wear/temperature. This is inactive by default.

3) Calculation of wheel force feedback. This takes a fair bit of time,
as it is a reapplication of the magic formula with a couple of
different terms. Fortunately most terms need to be calculated only
once, but it still takes up a bit of time.

4) 3D collisions. No overhead unless a collision is detected (the
detection is done in a very rudimentary manner, uses the suspension
state for when the car is the right way up, otherwise does a
coordinate transform of a point 0.5m above the center of mass of the
car at each corner and sees if it touches the ground)

5) Aero and downforce cut offs, gradual slipstreaming. This is just a
couple of instructions right now.

6) Engine braking/consumption. No overhead, should be on average same
as simuv2.

This is all I can think of for the moment. I don't think there is a
huge difference between the simus right now, at least nothing that I
can feel on flat tracks. On any inclined surface there is a huge
difference, but that is only to be expected. Robots are within a
couple of seconds of performance in general.

I think right now simuv3 is basically ready. We could fix the
collision of cars and perhaps improve the body collision model a bit,
although this very simple one is currently adequate. Otherwise I'd
like to concentrate on cleaning up the code, removing redundant stuff
and perhaps doing some optimisations if possible.



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

Hi Christos

> I'd like to begin that I would like some feedback on two features of
> simuv3:
> 
> 1. The open differential. Is it correct the way I did it now?

I do not know, but in simuv2 it worked reasonable at 1.2.3.

> 2. The auto-clutch code. Originally, as soon as you went below
> tickover, engine output tq was 0 and engine revs were clamped to
> tickover again. I changed that a while ago in simuv3, so that instead:
> 
> a) Below tickover, you have a controlling system that increases
> throttle so that revs can go back up.
> 
> b) Because now the car can stall under these conditions, I inserted an
> auto-clutch feature that pushes the clutch automatically.
> 
> I am not sure whether I should keep this feature, go back to the way
> it was, change its implementation, or add it as an option.. opinions?

Does it add to the experience and does not introduce a lot of other 
changes? Is it just a few lines of code -> threee times yes, then yes.

By the way I'm totally against choices for the users, because it will 
increase the amount of stupid postings and questions. This is as well 
the reason why there will be never a release from me with simuv2 along 
simuv3, there will be a cut in one version and we will fix up 
everything, such that the whole system fits (otherwise questions like 
"robot xy sucks with this and that setting" etc arise, no thanks...).

> As far as simuv3 performance is concerned, right now most of the time
> is spent on the wheel code. Right now the whole simuv3 takes around
> 20ms to run per second per car. The wheel code takes up around half of
> the time, which is not so bad considering that it is called 4 times as
> much as other parts of the code and that it contains multiple distinct
> coordinate transformations (car->wheel->road and back). That is 2
> times slower than simuv2, and that is with tyre temperature and wear
> turned off..

That was one of the reasons why it did not make it to 1.2.3. The correct 
first step IMO would have been to have a "simuv2 in 3d", without too 
much new stuff to adopt gradually, but now this will become a tough cut 
then, it simply changes too much at once... I prefer a working technique 
where you do little things 100%, and then going forward and not starting 
100 things and doing them just 60%, you know what I mean.

Please concentrate on sound and simuv3, if you start to change other 
things (e.g. menus, etc.) it will take longer to 1.2.4, what I really 
NEED is OpenAL support, sombody has to do it soon because it needs to be 
ported to Windows as well (its sometimes not that easygoing as you would 
expect, really), there will be no 1.2.x with simuv3, thats what 1.3 or 
1.4 will be for (probably, 1.3 could be for SDL, whatever is good enough 
and ready frist).

You may ask yourself what's wrong with me that I'm against quite a lot 
of the changes, here we go:
- I requires a huge amount of work to fix the whole system up (e.g 
updating/setting up robots/cars -> btw. I'm looking for a 
maintainer/developer of Inferno, Damned, Tita, Tanhoj, LLiaw, etc.).
- A lot of changes really just heat the cpu up, no recogizable added value.
- More code in a subsystem -> more bugs -> harder to maintain -> less 
time for nice new stuff.
- ...

That's about it. Bye,

Bernhard.


-- 

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

> > Is the thing described here what DIFF_FREE is supposed to be?
> >
> > http://auto.howstuffworks.com/differential6.htm
>
> Yes. Its the classic differential without any intelligence in it, pure
> gears:-) Please do not change simuv2 in that respect, 1.2.4 will use
> transmission code of 1.2.3. A simple test case for it is if you place
> the car with one driven wheel on sand/dirt and the other on asphalt.
>

OK, I think I understand how it works. I changed it in simuv3 the way
I *guessed* it might be, but if it is correct that 'when one wheel is
immobile, all the torque is output on the other wheel', then the
current simuv2 implementation could be correct, though I am not sure
yet how it was arrived at.

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

>
> Hmm, I would expect that to be a quite usual scenario, perhaps they have
> that in the FAQ/Docs?
>

That's what I thought too, but I spent the best part of last evening
trying to find some info. The best I could do was run it with gcov,
which is not particularly useful since it just gives the number of
times each line of code was executed. There is no time information.

I also tried to insert the -pg flag in CFLAGS, CXXFLAGS and then into
the linking part of simuv3. That did not work, but adding it to the
main code in linux/ started up the gprof profiling. However, upon
inspection of the gmon.out file, only one or two functions per
objectfile were mentioned and without any detail whatsoever. I am not
sure what I should do to get it working yet.. well, if I find a
solution I'll post it later.


 > Bye, Bernhard.
>
>
>

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

I'd like to begin that I would like some feedback on two features of
simuv3:

1. The open differential. Is it correct the way I did it now?
2. The auto-clutch code. Originally, as soon as you went below
tickover, engine output tq was 0 and engine revs were clamped to
tickover again. I changed that a while ago in simuv3, so that instead:

a) Below tickover, you have a controlling system that increases
throttle so that revs can go back up.

b) Because now the car can stall under these conditions, I inserted an
auto-clutch feature that pushes the clutch automatically.

I am not sure whether I should keep this feature, go back to the way
it was, change its implementation, or add it as an option.. opinions?

As far as simuv3 performance is concerned, right now most of the time
is spent on the wheel code. Right now the whole simuv3 takes around
20ms to run per second per car. The wheel code takes up around half of
the time, which is not so bad considering that it is called 4 times as
much as other parts of the code and that it contains multiple distinct
coordinate transformations (car->wheel->road and back). That is 2
times slower than simuv2, and that is with tyre temperature and wear
turned off..

Anyway, here are the main udpates. I also have a new track
which is fun to play with simuv3:

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


configscreens:

	* simuconfig.cpp, soundconfig.cpp: Bugfix. (When parameter was
decremented, the index wraparound overflowed).

simuv3:

	* aero.cpp: Added aero factor.
	Added aeroflow model.

	* simu.cpp: Added some profiling stuff for the wheels.

	* collide.cpp: Added upside_down_timer.
	Changed to quaternions.

	* differential.cpp: Changed DIFF_FREE to what I think it
should be. Please test.

	* engine.cpp: Changed auto-clutch code. Please test.
	Rearranged calculations.
	Adjusted fuel consumption to match simuv2 more or less.

	* wheel.cpp: Changed some things to quaternions.

	* car.cpp: Changed to quaternions.

	* SimulationOptions.cpp: Set aeroflow model to SIMPLE always.

	* Options.h, SimulationOptions.h: New file.

	* carstruct.h, sim.h: t2sg3() and sg2t3() - new functions.






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