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

> sprintf(fnbuf, "%s%s", GetLocalDir(), GR_SOUND_PARM_CFG);
> ...
>

Doing this is not very safe is fnbuf is not big enough. And for paths
you never known. We could either use something like what is in the man
section of printf (implemented as make_message in
learning/string_utils.cpp),  or use STL strings.

We could implement the first option as vector of chars so that it gets
destroyed without having to explicitly delete, although then
I'm not sure how different it'd be from STL strings.

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

Hi Christos

> What do you think would be a good location to do writing in?

Linux, Posix: ~/.torcs/drivers/olethros/...
Windows: drivers\olethros\...

You have already seen the mechanism e.g. in grsound.cpp (it is important 
to use this, because in Windows they go to a different location):
...
sprintf(fnbuf, "%s%s", GetLocalDir(), GR_SOUND_PARM_CFG);
...

If they are small, then don't care and write them (*). If they are big, 
please do not store them (10 Bots times 30 Tracks -> 300 Files). I would 
say if the average case does not exceed 1-2MB and the worst case is 
smaller than 4-5 MB then it is ok (we will write later other stuff as 
well, e.g. setups, replays etc). What would you consider as acceptable 
from a game?

Bye, Bernhard.

(*) If you really write them, the code must be able to handle every 
situation with evolving or broken data, take care of that (e.g. TORCS 
gets hard killed and there is a NaN in the file afterwards, updated 
TORCS Version with old files, etc.).

-- 

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

> Great sound, thank you very much. I commited as well some changes:
> - Disabled Olethros brain writing.

What do you think would be a good location to do writing in?

> - Module discovery mem leak (could you please make sure that this gets
> into your tree this time;-) ).

Hm, I think I have the correct one now.


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

Hi Christos

> I have now updated the sound code, plus the .xml for mclarenf1 and
> porsche-gt3s to add turbo sounds. This is all for the first test.
> 
>  For the second test release I am going to add turbo to all cars that
> have it, plus I am going to update as many sounds as I can with some
> better models.

Great sound, thank you very much. I commited as well some changes:
- Disabled Olethros brain writing.
- Module discovery mem leak (could you please make sure that this gets 
into your tree this time;-) ).
- Reverted commits of cam, screen and skids.
- New sound.xml (configuration right from start).

Bye, Bernhard.


-- 

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

I have now updated the sound code, plus the .xml for mclarenf1 and
porsche-gt3s to add turbo sounds. This is all for the first test.

 For the second test release I am going to add turbo to all cars that
have it, plus I am going to update as many sounds as I can with some
better models.


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

- ssgraph/ updated plib backend. Should work now?

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

- Updated learning lib to remove some 'function not used' warnings.
- Updated olethros bot to current competition bot.

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

Hi Christos

>>code crashing :-( during qualif just after the end of the qualif of
>>any olethros robots, TORCS exits.
>>
> 
> 
> Did anyone else have problems recently with the olethros bot?

No, but I did not often run AI's recently.

Bye, Bernhard.

-- 

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

Hi all

I commited the following updates to the CVS:

- Fixed a bug in collision detection which happend when 2 wrecks where 
overlapping. This caused permanent collisions, which in turn avoided to 
call dtProceed and therefore avoided the needed update of the data 
(Bernhard).
- Fixed: non ending races because of failing virtual crane, was a 
floating point error accumulation problem in simu.cpp (Bernhard).
- Barrier has now a field with normal used for barrier collision 
detection, reworked SimCarCollideXYScene, collide.cpp (Bernhard).
- Added vector classes, such that all berniw/bt derivates can use the 
same copy, instead of having a copy in each bot (Bernhard).
- Collision code refactoring/cleanup, removed doubled code, etc. (Bernhard).
- Initial wall collision support, good enough for now, but needs 
improvment and more testing. The damage is currently set very low, such 
that the robots have some time to adopt (Bernhard).
- Fixed skid sound at low speeds (Christos, Bernhard).
- Fixed scroll lists numbering with more than 100 entries (Bernhard).
- Enabled configure checking for OpenAL (Bernhard).
- Fixed skidmarks when driving in reverse, bug introduced by me when 
enabling backface-culling for skids (Christos, Bernhard).
- Added trackgen option to just calculate the track parameters 
(Charalampos).
- Increased a "margin" in trackgens track.cpp, will need further 
inverstigation (Charalampos).



Remaining TODO before 1.2.4 ("*" means movable to 1.2.5):

- Fix XSLT/DTD for viewing results (Report by Eugen)
- Hunting lost open filehandles if any left.
- Bugfixes.
- * Add cameras (alpine, spring)
- align widgets in sound config screen.
- * check for ssgSimpleStates and replace with grManagedState where 
appropriate.
- Check for lost open filehandles in Windows module loader.
- Olethros bot: disable writing, init mem leak, textures, warning in 
learning lib.
- * plib backend, missing sound effects (would be nice)?
- * Update sound maximum 30-50 times a second (perhaps this helps with 
the plib timing problem).
- Does sound stop in menus?
- grep for strndups not guarded by portability.h.
- Windows port.
- Windows installer.
- All-in-one.
- Linux installer.
- Separated packages.
- Prepare docs (Robot tutorial -> OpenAL section, installation etc).

Bye, Bernhard.


-- 

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

This should be OK, check it out from CVS.

The only minor problem that remains in simuv2 is that because of the
very small driving wheel inertia the wheel speed goes up and down very
very fast so on very rough tracks like g-track-1 you get a very
accentuated wheel skid pitch modulation. You should get _some_ of
that, of course but it's a bit ridiculous with simuv2 and g-track-1. I
might tone that down a bit anyway.

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

>
> code crashing :-( during qualif just after the end of the qualif of
> any olethros robots, TORCS exits.
>

Did anyone else have problems recently with the olethros bot?

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

Christos Dimitrakakis wrote:
> Regarding the variable width tracks, I guess this is something that
> will have to be reworked for all robots, if we create tracks that do
> have variable width. And conceivably robots could take advantage of
> the road side for curves if it has a relatively good traction.
> 
> 
>>One small point that I have not investigated is that olethros robots
>>are crashing when used in endurance or non-championship races just after
>>the qualif.
>>
> 
> 
> Crashing, as in the car crashing on a barrier or the code crashing?

code crashing :-( during qualif just after the end of the qualif of
any olethros robots, TORCS exits.

> 
> If the former, I know that some tracks which have a very small number
> of segments on curves cause this behaviour. (1.2.3 e-track-1 and eroad
> are examples of that). I started re-writing all the code so that it
> uses logical rather than track segments. But AFAIK this problem does
> not exist with the updated versions that Bernhard made.
> 
> Ciao,
> Christos
> 

Eric.

Regarding the variable width tracks, I guess this is something that
will have to be reworked for all robots, if we create tracks that do
have variable width. And conceivably robots could take advantage of
the road side for curves if it has a relatively good traction.

> One small point that I have not investigated is that olethros robots
> are crashing when used in endurance or non-championship races just after
> the qualif.
>

Crashing, as in the car crashing on a barrier or the code crashing?

If the former, I know that some tracks which have a very small number
of segments on curves cause this behaviour. (1.2.3 e-track-1 and eroad
are examples of that). I started re-writing all the code so that it
uses logical rather than track segments. But AFAIK this problem does
not exist with the updated versions that Bernhard made.

Ciao,
Christos

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

Hi Bernhard and Christos,

Don't forget that robots are based on the fact that the tracks
have fixed width, and at least my robots store the value localy...

BTW, I tested the 1.2.4-test1 from CVS last night, it's really
good, I mean it looks and sounds cool :-)

One small point that I have not investigated is that olethros robots
are crashing when used in endurance or non-championship races just after
the qualif.

Bye,
Eric.

Bernhard Wymann wrote:
> Hi Christos
> 
>> Since the track segments have a startWidth and endWidth property, why
>> is it not possible to have tracks with variable width?
> 
> 
> Is it not? I have actually never tried.
> 
>> Is it simply a matter of changing rttrack.cpp (in robottools) and
>> trackgen? (replacing seg->width with seg->Width(position) or
>> something)
> 
> 
> Perhaps. If you care you/we can have a look into that after 1.2.4.
> 
> Bye, Bernhard.
> 
> 

Hi Christos

> Since the track segments have a startWidth and endWidth property, why
> is it not possible to have tracks with variable width?

Is it not? I have actually never tried.

> Is it simply a matter of changing rttrack.cpp (in robottools) and
> trackgen? (replacing seg->width with seg->Width(position) or
> something)

Perhaps. If you care you/we can have a look into that after 1.2.4.

Bye, Bernhard.


-- 

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

Since the track segments have a startWidth and endWidth property, why
is it not possible to have tracks with variable width?

Is it simply a matter of changing rttrack.cpp (in robottools) and
trackgen? (replacing seg->width with seg->Width(position) or
something)

Just curious

Christos


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

Hi Christos

> Replying to myself here, it seems that using cullface causes this,
> which is normal, because the polygon is drawn the other way around
> when the car is moving backwards. Hmm.. solutions:
> 
> a) remove cull face -> skids might be visible from underneath
> 
> b) swap left-right vertices when car goes backwards.
> 
>  On Wed, 13 Jul 2005, Christos Dimitrakakis wrote:
> 
> 
>>When the car is moving backwards, and you lock on the
>>brakes, there should be a) skid sound, b) smoke c) skid marks. In my
>>local version it seems that skid marks are missing in this case.
>>
>>Is it the same on 1.2.3 or is it a newly introduced bug?

Yes, its back face culling. Thank you for pointing that out. Please do 
not touch everything else than your driver and sound for now anyway.

Bye, Bernhard.

-- 

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

Replying to myself here, it seems that using cullface causes this,
which is normal, because the polygon is drawn the other way around
when the car is moving backwards. Hmm.. solutions:

a) remove cull face -> skids might be visible from underneath

b) swap left-right vertices when car goes backwards.

 On Wed, 13 Jul 2005, Christos Dimitrakakis wrote:

> When the car is moving backwards, and you lock on the
> brakes, there should be a) skid sound, b) smoke c) skid marks. In my
> local version it seems that skid marks are missing in this case.
>
> Is it the same on 1.2.3 or is it a newly introduced bug?
>

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

When the car is moving backwards, and you lock on the
brakes, there should be a) skid sound, b) smoke c) skid marks. In my
local version it seems that skid marks are missing in this case.

Is it the same on 1.2.3 or is it a newly introduced bug?

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

> Hmm, you mean in robottools, I think that is a bad idea. E.g if the
> physics uses this function the car floor will hit the road earlier etc.
> Please do not commit it in this way for now.
>
Yes, the physics uses this function but this only means that the track
surface is raised overall. Shouldn't have any effect whatsoever. Try
it out.

Is there any other function that gives the height of the road
which is differs from this one? This will cause problems, but if
everyone calls RtTrackHeightL() to get this number I see no reason for
problems because the height will be consistent over all the code.

On another note, I _could_ have made it so that the gfx skidmarks code
increases the height of the skidmarks by kRoughness, but that has the
problem that changes in RtTrackHeightL() will break the fix in
grskid.

To sum it up, I really think we should leave the fix as is, (I
had already commited) unless there is another height function, or you
want to move the fix to the gfx.

> > So now skidmarks do not disappear.
>
> Hm, really, nowhere anymore, and it is not recognizible that it is above
> the track (I think we had a similiar solution in the very beginning for
> the shadow, at this time there where no skids)?

I just noticed the skid problem in the new track, with the high
roughness, so I went there and checked it and voila. The problem also
exists in g-track-2 and g-track-3. It's just that without the fix, the
skidmarks actually go under the gfx and are (correctly) not visible
all the time.
(Actually the correct behaviour would be that they are visible in some
parts and not visible in other parts but with short wavelengths this
does not work very well).

> Amazing that this does the trick, but it does not solve the other
> problem for sure (skids and shadows visible through walls).

Yeah, that's something else altogether. Same problem as that of
skids/shadows been visible behind the crest of a hill.

> To solve
> that problem I have more a bugfixed polygonoffset and for "advanced"
> GPU'S a stencil buffer improvment in mind (we will need stencil anyway
> for a lot of things... in 2 years or so...;-) ).
>

So, let me know what you want and I'll do it. (Or you can do it if you
prefer)


PS. Is there a way to remove revisions rather than revert the changes
I made?

Ciao

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

Hi Christos

> In libs/robottools/rttrack.cpp
> tdble
> RtTrackHeightL(tTrkLocPos *p);
> 
> The height of vertices was basically
> 
> height + k * sin (x)
> 
> Since sin : R -> [-1,1], this meant that track points could be lower
> than that of gfx by -k.
> I added a DC offset in the 3 places where this occurs:
> 
> Curb, border:
> height + k * (1 + sin (x))
> 
> normal road:
> height + k * (1 + sin (x) * sin(y))

Hmm, you mean in robottools, I think that is a bad idea. E.g if the 
physics uses this function the car floor will hit the road earlier etc.
Please do not commit it in this way for now.

> So now skidmarks do not disappear.

Hm, really, nowhere anymore, and it is not recognizible that it is above 
the track (I think we had a similiar solution in the very beginning for 
the shadow, at this time there where no skids)?
Amazing that this does the trick, but it does not solve the other 
problem for sure (skids and shadows visible through walls). To solve 
that problem I have more a bugfixed polygonoffset and for "advanced" 
GPU'S a stencil buffer improvment in mind (we will need stencil anyway 
for a lot of things... in 2 years or so...;-) ).

> Note that when seg->style is not a curb, when y (which is the distance
> from the right) is 0, the oscillations disappear. So this seems
> a bit wrong.

Yes, but leave it for 1.2.4.

> Also, on the curb and border there has been an effort to linearly vary
> the roughness from 0 to seg->kRoughness from the inside to the outside
> of the segment. That probably should have been a linear function not
> from 0, but from the roughness of the segment that is next to it (i.e.
> the road) - that is a minor detail, of course, but hey.

Dito. I will put it in the todo list for later.

Bye, thank you,

Bernhard.


-- 

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

In libs/robottools/rttrack.cpp
tdble
RtTrackHeightL(tTrkLocPos *p);

The height of vertices was basically

height + k * sin (x)

Since sin : R -> [-1,1], this meant that track points could be lower
than that of gfx by -k.
I added a DC offset in the 3 places where this occurs:

Curb, border:
height + k * (1 + sin (x))

normal road:
height + k * (1 + sin (x) * sin(y))

So now skidmarks do not disappear.

Note that when seg->style is not a curb, when y (which is the distance
from the right) is 0, the oscillations disappear. So this seems
a bit wrong.

Also, on the curb and border there has been an effort to linearly vary
the roughness from 0 to seg->kRoughness from the inside to the outside
of the segment. That probably should have been a linear function not
from 0, but from the roughness of the segment that is next to it (i.e.
the road) - that is a minor detail, of course, but hey.


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

> >
> > Btw. where are the meanings of car->collision defined?
> >

I was nonplussed about that when I was looking at the code sometime
ago. There seems to be no 'official' definition. How about

#define COLLISION 0x01
#define COLLISION_XYSCENE 0x02
#define COLLISION_CAR 0x04
#define COLLISION_Z 0x08
#define COLLISION_Z_CRASH 0x10


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

Hi all

Once more talking to myself: Yes, I was right and fixed it in my tree, I 
will commit it after some more work is done. This was a quite esoteric 
one:-)

Bye, Bernhard.


> I am reviewing the current collision detection code to add pit wall 
> collisions, and I think I found the problem which caused this:
> "in long races car-to-car collisions fail somehow sometimes"
> 
> Look below at:
> 
> if (dtTest() == 0) {
>     dtProceed();
> }
> 
> Please comment if I got the concequences right:
> If two wrecks got placed over each other (which happens sometimes), the 
> collision detection detects this all the time, therefore dtProceed is 
> never again called. So the face normals needed for collision detection 
> are basically not updated anymore, do you share this oppinion?
> 
> SOLID docs: http://www.win.tue.nl/~gino/solid/solid2.html#SEC10
> 
> Btw. where are the meanings of car->collision defined?
> 
> Bye, thank you for your help,
> 
> Bernhard.
> 
> 
> 
> 
> SimCarCollideCars(tSituation *s)
> {
>     tCar *car;
>     tCarElt *carElt;
>     int i;
> 
>     for (i = 0; i < s->_ncars; i++) {
>         carElt = s->cars[i];
>         car = &(SimCarTable[carElt->index]);
>         dtSelectObject(car);
>         // Fit the bounding box aroung the car, statGC's are the static 
> offsets.
>         dtLoadIdentity();
>         dtTranslate(-carElt->_statGC_x, -carElt->_statGC_y, 0);
>         // Place the bounding box such that it fits the car in the world.
>         dtMultMatrixf((const float *)(carElt->_posMat));
>         memset(&(car->VelColl), 0, sizeof(tPosd));
>     }
> 
>     // Running the collision detection. If no collision is detected, 
> call dtProceed.
>     // dtProceed just works if all objects are disjoint.
>     if (dtTest() == 0) {
>         dtProceed();
>     }
> 
>     for (i = 0; i < s->_ncars; i++) {
>         carElt = s->cars[i];
>         if (carElt->_state & RM_CAR_STATE_NO_SIMU) {
>             continue;
>         }
>         car = &(SimCarTable[carElt->index]);
>         if (car->collision & 4) {
>             car->DynGCg.vel.x = car->VelColl.x;
>             car->DynGCg.vel.y = car->VelColl.y;
>             car->DynGCg.vel.az = car->VelColl.az;
>         }
>     }
> }
> 
> 


-- 

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

Thanks for the reply

> > Also, with respect to the roughness implementation. Maybe it is a
> > good idea to try and put back the pseudorandom periodic function I had
> > done a few months back, perhaps as an option. I liked the way it
> > behaved, though for some surfaces (such as cobblestone road) the
> > sinewave function would be better.
>
> Hmm, I did not like the effect at all, although it might make sense on
> dirt tracks and on potential gravel scenarios (on asphalt it makes no
> sense because of the above effect and the manufacturing process of the
> roads -> both lead to longitudinal sine similiar waves in the surface).
> Its simply not necessary for now, there are real issues to fix first.
>

Yeah, it's a minor point, which I just wanted to clear up. Interesting
fact about the asphalt anyway.


> > Another thing, it seems that the 'wavelength' specification is
> > used as frequency in the code - but maybe I am mistaken.
>
> Perhaps, I did never look at it, I think:-) There are as well weird
> effects with the rolling resistance, at least if the parameter means
> what I would expect from it.
>

The rolling resistance is currently implemented wrt the car's overall
speed iirc. I just bugfixed it (remember the stuck-in-the-sand bug?),
and ported it over to the simuv3 with necessary changes for 3D sim.

Had it been me, I would have implemented it in the wheel.cpp code
rather than in the car.cpp code....
quickly changing the code....

 I just did a check on that and changed it and it seems to make a
difference, at least for simuv3. It gets rid of some problematic
behaviour at low speeds.

I'll check some more and update it so you can check it out then we can
see if we need to bring it back to simuv2.

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