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

Hi,

The patch works very well on my machine. The 3D wheels are very very
nice. Too bad that only 2 car models support them in your patch ;-)

However IMHO it's a strange choice not to use the car XML file. If
nothing is defined about 3D wheels in the XML file then you would fall
back to standard wheels. I just can not see the point of not modifying
it !?! 

Advantages of using the XML file are that the file naming is not fixed
(but you have commented this point in your patch) and that it would
remove the burden of determining if the front wheel and the back wheel
are different and so on...

Regards,

Bertrand.

SpeedyChonChon wrote :
> Hi
> 
> Thank you for working on that :-).
> I noticed that you didn't use LOD for wheel any more. Have you tried
> with ten cars which had 3D wheel ? Didn't you loose some FPS ?
> (The LOD for wheel make a gain of FPS even without 3D wheels, and the
> look is not too much affected).
> 
> Thanks again. I hope that we will find a solution liked by
> everyone ;-).
> Cheers
> 
> Speedy
> 
> 
> Andrew Sumner wrote: 
> > Eliam submitted a patch over a year ago to allow use of 3D wheel
> > models in TORCS.  I've 
> > revisited the code, reducing the changes to just one file and adding
> > some improvements. 
> > 
> > With this version, no changes need be made to car XML files - if a
> > 3D wheel model is present 
> > it'll be used, otherwise TORCS will revert to the standard generated
> > wheels.  As the 3D ones 
> > are .acc files, the wheels will darken when driving into shadows in
> > the same way as cars are 
> > darkened.  I've included screenshots and examples for the
> > porsche-gt1 and sc-f1 in the zip, 
> > along with the sourcecode changes. 
> > 
> > Please let me know what you think - I'd really like to see this
> > feature make its way into TORCS 
> > if possible. 
> > 
> > http://www2.webng.com/locus/files/3dwheel.zip 
> > 
> > cheers 
> > Andrew 

Hi

Thank you for working on that :-).
I noticed that you didn't use LOD for wheel any more. Have you tried 
with ten cars which had 3D wheel ? Didn't you loose some FPS ?
(The LOD for wheel make a gain of FPS even without 3D wheels, and the 
look is not too much affected).

Thanks again. I hope that we will find a solution liked by everyone ;-).
Cheers

Speedy


Andrew Sumner wrote:
>
> Eliam submitted a patch over a year ago to allow use of 3D wheel 
> models in TORCS.  I've
> revisited the code, reducing the changes to just one file and adding 
> some improvements.
>
> With this version, no changes need be made to car XML files - if a 3D 
> wheel model is present
> it'll be used, otherwise TORCS will revert to the standard generated 
> wheels.  As the 3D ones
> are .acc files, the wheels will darken when driving into shadows in 
> the same way as cars are
> darkened.  I've included screenshots and examples for the porsche-gt1 
> and sc-f1 in the zip,
> along with the sourcecode changes.
>
> Please let me know what you think - I'd really like to see this 
> feature make its way into TORCS
> if possible.
>
> http://www2.webng.com/locus/files/3dwheel.zip
>
> cheers
> Andrew
>

Eliam submitted a patch over a year ago to allow use of 3D wheel models in
TORCS.  I've
revisited the code, reducing the changes to just one file and adding some
improvements.

With this version, no changes need be made to car XML files - if a 3D wheel
model is present
it'll be used, otherwise TORCS will revert to the standard generated wheels.
As the 3D ones
are .acc files, the wheels will darken when driving into shadows in the same
way as cars are
darkened.  I've included screenshots and examples for the porsche-gt1 and
sc-f1 in the zip,
along with the sourcecode changes.

Please let me know what you think - I'd really like to see this feature make
its way into TORCS
if possible.

http://www2.webng.com/locus/files/3dwheel.zip

cheers
Andrew

Hi

I've been fiddling a bit with some new tracks lately.
Although they are still in quite early stages of development, you can drive
along them without getting lost in a black hole ;)

Please give them a try and let me know what you think about them:

http://gabor.kmetyko.googlepages.com

PS:
don't expect *yet* anything like Andrew's fantastic works (I'm sure I'll get
there soon, in 5-6 years :D )

kilo
Gabor Kmetyko

Hi people,

I play Torcs for a while and I enjoy it very much. Thank you guys for
this great game.

However, the fonts used to render the text are pretty ugly and AFAICS
the current font mechanism does not allow for internationalization (see
http://sourceforge.net/mailarchive/forum.php?thread_name=BAY119-F25AF64C37E5992D2507ADBC6D90%40phx.gbl&forum_name=torcs-devel ). So as a maintainer of a library for text rendering with OpenGL (QuesoGLC see at http://quesoglc.sourceforge.net), I submit you the attached patch to use QuesoGLC instead of the current font rendering engine.

I used this patch since a few days and it just works Ok. When using my
patch, fonts are antialiased so they are nicer. Moreover, QuesoGLC uses
TrueType / Type 1 / OpenType and generally speaking any font format
which is supported by FreeType, so it is quite easy to customize the
fonts to your need (see the patched screen.xml for an example). QuesoGLC
also supports Unicode (UTF-8 and right to left ordering) so this might
ease the internationalization of Torcs. The library also takes care of
all the cache burden so you do not have to worry about memory and
texture management related to font rendering (only one 1024 x 1024 x 8
bits texture is allocated - that is 1 Mb of texture memory - which is
quite few with regard to the standard gfx card memory - even for the
good old TNT and its 32 Mb).

The drawback is that the use of QuesoGLC along with Torcs costs 15%~20%
of framerate but I am working hard to improve that ;-) Another drawback
is that it adds yet another dependency to Torcs. I do not know your
policy relative to dependencies and this patch is just a suggestion. 

Enough of self congratulations, you can find some screenshots at the
QuesoGLC web site :

http://quesoglc.sourceforge.net/torcs_before.png
http://quesoglc.sourceforge.net/torcs_after.png
http://quesoglc.sourceforge.net/torcs_before2.png
http://quesoglc.sourceforge.net/torcs_after2.png

Finally, some comments about the patch :

1. I modified the meaning of some of the parameters of screen.xml which
might not be suitable for backward compatibility. If it is an issue I
can change the patch so it uses "Menu TrueType Font" instead of "Menu
Font" for instance.

2. The patch uses a free TrueType font for the digital display which is
LCDMono2. You can download it at
http://quesoglc.sourceforge.net/lcd_lcd_mono.zip. The font files
(LCDM2*.TTF) must be installed in the Torcs directory data/fonts so that
QuesoGLC can find them. If some (or all) of the fonts are not available
on your system then QuesoGLC automagically falls back to one of the
fonts of your system (which font depends on your settings of
Fontconfig).

Whatever is your opinion I would appreciate feedback.

Regards,

Bertrand.

Hi,

Christos Dimitrakakis schrieb:
> On Thu, 10 Jan 2008 09:54:59 +0100, "Frieder Ferlemann"
> <fri...@we...> said:
>> Hi,
>>
>> Christos Dimitrakakis schrieb:
>>> It is not clear how to determine braking from the engine parameters, 
>>> which is why we have 'engine brake' parameter F.  From what you say, I 
>>> think that if F is set correctly according to each engine, the model 
>>> type (a constant + linear factor for braking) is adequate and the only 
>>> question is how to determine F.
>> If the engine inertia is known and one has the sound of the engine
>> rev'ing down while the clutch is open one could try to derive it
>> from there. Probably would work well for non-turbo engines?
>>
> 
> Sure, but there are difficulties:
> 
> 1) Collecting the data.
> 
> 2) Estimating the rpm from the sound.  I have tried that in order to
> convert engine sounds to the steady-rpm we need for the game.  It's not
> easy.  It's probably best to create a statistical inference model that

One could try to use FFT (Fast Fourier Transform) and visualize the results
as it's sometimes done with whale songs.
I searched a while for a nice link and didn't find a nice one, maybe
the figure here shows well enough:
http://www.baudline.com/
>From the position (and the shift) of the lines it might be possible
to derive the RPM (over time) from a given sound file.
No idea how good that would work for engine sounds.

> directly infers a constant and a linear deceleration parameter from the
> sound data.
> 
> 3) This procedure will only give you the friction up to a multiplicative
> factor.  Resolving this will require knowledge of the engine inertia. 
> This will require data from revving up and matching it with the known
> torque of the engine.

Yes, major problem.

> I used the following simple method to setup a car that is similar to the
> one I drive:
> 
> 1) Count the time needed to revup to redline
> 2) Count the time needed to revdown to idle.
> 
> Tweak inertia to fit revup time.  Tweak friction to fit revdown time.

Yes.

Greetings,
Frieder

On Thu, 10 Jan 2008 09:54:59 +0100, "Frieder Ferlemann"
<fri...@we...> said:
> Hi,
> 
> Christos Dimitrakakis schrieb:
> > It is not clear how to determine braking from the engine parameters, 
> > which is why we have 'engine brake' parameter F.  From what you say, I 
> > think that if F is set correctly according to each engine, the model 
> > type (a constant + linear factor for braking) is adequate and the only 
> > question is how to determine F.
> 
> If the engine inertia is known and one has the sound of the engine
> rev'ing down while the clutch is open one could try to derive it
> from there. Probably would work well for non-turbo engines?
> 

Sure, but there are difficulties:

1) Collecting the data.

2) Estimating the rpm from the sound.  I have tried that in order to
convert engine sounds to the steady-rpm we need for the game.  It's not
easy.  It's probably best to create a statistical inference model that
directly infers a constant and a linear deceleration parameter from the
sound data.

3) This procedure will only give you the friction up to a multiplicative
factor.  Resolving this will require knowledge of the engine inertia. 
This will require data from revving up and matching it with the known
torque of the engine.

I used the following simple method to setup a car that is similar to the
one I drive:

1) Count the time needed to revup to redline
2) Count the time needed to revdown to idle.

Tweak inertia to fit revup time.  Tweak friction to fit revdown time.

-- 
  Christos Dimitrakakis
  ole...@fa...

-- 
http://www.fastmail.fm - Send your email first class

Hi,

Christos Dimitrakakis schrieb:
> It is not clear how to determine braking from the engine parameters, 
> which is why we have 'engine brake' parameter F.  From what you say, I 
> think that if F is set correctly according to each engine, the model 
> type (a constant + linear factor for braking) is adequate and the only 
> question is how to determine F.

If the engine inertia is known and one has the sound of the engine
rev'ing down while the clutch is open one could try to derive it
from there. Probably would work well for non-turbo engines?

Greetings,
Frieder

wi...@ca... wrote:
> On Wed, 09 Jan 2008 21:19:42 +0100, Christos Dimitrakakis 
> <ole...@fa...> wrote:
> 
>> (rather than having the engine break simply proportional to the 
>> maximum engine torque at each rpm, it is a linear function of the 
>> torque produced at maximum power - this means that there is always 
>> some engine break, and it is always higher at higher revs).
> 
> 
> Hi,
> 
> maybe this is just a first order approximation but isn't the engine 
> breaking more a function of engine capacity, compression ratio and 
> number of cylinders ? Although these factors will affect the max torque 
> it does not mean the torque is what determines the engine breaking.
> 

Well, it is not easy to determine this.  The idea for the model is to 
say that there is a 'engine brake' parameter for each engine, which we 
can call F.  Now, in this model, F just tells you how much of the 
produced power is wasted at maximum output power. (So F is the converse 
of efficiency at maximum power)  I think that for most engines it's 
fixed at 30%.

  > I guess this fix is an improvement on the old model but may be somewhat

This fix just fixes a bug in the old model (where in some cases you had 
no engine braking at all, and where fuel was magically generated in your 
tank).

> off target in that it is not related to the engine parameters that do 
> determine the engine breaking.

It is not clear how to determine braking from the engine parameters, 
which is why we have 'engine brake' parameter F.  From what you say, I 
think that if F is set correctly according to each engine, the model 
type (a constant + linear factor for braking) is adequate and the only 
question is how to determine F.

Here's a fix of the issue that Andrew discovered in his testing, again 
backported from simuv3.  It is simply a fix for the engine break and 
fuel consumption calculation (rather than having the engine break simply 
proportional to the maximum engine torque at each rpm, it is a linear 
function of the torque produced at maximum power - this means that there 
is always some engine break, and it is always higher at higher revs). 
Incidentally, this fix also corrects the 'consuming a negative amount of 
fuel when not accelerating' bug.

Andrew Sumner wrote:
> Ok, I think I've found a bug.
> 
> Accelerate up to third gear, then get the revs nice and high.  Change
> down to 2nd and the revs will be well above the redline.
> 
> The bug is that the car isn't slowed down by the gear until the rpm
> drops below the redline, and then suddenly the gear takes effect.  Until
> then it just slowly drops in speed as if the car was in neutral.
> 
> cheers
> Andrew
> 
> 
> 

The changed files are transmission and engine .h and .cpp.

This is my original simuv3 working attempt.  I am not very satisfied 
with the method I used to solve the problem, but the effect is as 
intended.  You can use the clutch or change gears to spin the wheels, or 
brake suddenly.

So now you can spin the wheels at start if you want, even if you have a 
low-powered car on a road surface that offers good traction.  Just push 
the clutch and let go if it after revving up.  Similarly, with a 
rear-wheel drive you can do a kind of hand-brake turn by downchanging 
the gear - most effective in small gears.

This is probably not the best solution, but please try it out.  I have 
some ideas for a different one - and I'd love to hear some suggestions.

Sorry, I'm not quite sure if this belongs to the 'devel' list, but I didn't 
found a better place for it:

I'm looking for somebody who can make a TORCS car for me. Of course, I don't 
want to have this job done for free, I'm willing to pay for it. Details can 
be found here:

http://www.microjobzone.com/project/making-car-torcs-racing-car-simulator

If somebody is interested , please leave me a note on above page as I don't 
want to spam this mailing list with the subject. Thank you !

Regards,
Donnar