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

Hi all.

I was working on the 962C when TORCS didn't want run any more : 
Segmentation Faults. I had tryed every thing I could. After several lost 
hours (uninstall, compile, reinstall... several times), I found that it 
was the category definition of the 962C which was bad (I put History 
instead of Historic).

Isn't the segmentation Fault avoidable in this case ?

Bye
Speedy

I have finally solved the problem with the curbs - update on CVS,
rttrack.cpp.

Attached is a test track that illustrates the problem and the fix.

(though it's better to try it under simuv3, it should work in simuv2 in
the parts of the track where the angles are not very steep)



-- 
Christos Dimitrakakis
Homepage: http://www.idiap.ch/~dimitrak/main.html
Music: http://olethros.dmusic.com

Temporary fix, trying to make sure that
skids are above the road surface. (This had been there for some time,
but with a  z_adjust > 1, which had the opposite effect, namely, of
putting the skids under the road surface. Duh. Now I cleaned it up
slightly and corrected the constant.)

This is needed because the wheel position depends on the current
physical model road height, which is not exactly
the same as the gfx road height, even if it is so
on average, because the physical model adds some
sinewave to the road height to simulate uneveness
of the track.

So, does it work? There is a very good improvement, but on some tracks
(g-track-2 and g-track-3) skidmarks still flicker a bit. At least now we
are sure that the skidmarks are actually over the track surface and the
problem is due to z-buffering.


A better fix would be to add a routine grTrackHeightL(tTrkLocPos *p),
similar to  TrTrackHeightL(), but which aim to give the height
of the graphical track. This would also take care of the fact that the
wheels are slightly inside the track whenever the road is tilted (due to
simplifications in the suspension length computation).

-- 
Christos Dimitrakakis
Homepage: http://www.idiap.ch/~dimitrak/main.html
Music: http://olethros.dmusic.com

Am Sonntag, den 18.12.2005, 10:09 +0100 schrieb Bernhard Wymann:
> Hi Speedy
>=20
> > Sometimes I have a weirb display in the map zone. (behind the map I see
> > something like the screen I have when the game is loading (see the
> > image(It's a little image I hope it will pass on the mailing))).
>=20
> Welcome at NVidia;-) I think it is a driver "optimization" (I think it do=
es not
> draw obscured window parts in the back buffer, so the fetched map is not =
complete).

... FYI ...

This is not an NVidia feature. Most of the open source DRI drivers do
the same because all applications share a screen-sized back and depth
buffer. In this case it's not an optimization but it is necessary to
prevent windows in the background from corrupting the window in the
foreground. To make it even worse, the open source drivers don't support
pbuffers yet. FWIW I also get corruption in the map when the bottom of
the Torcs window is slightly off-screen (this is with ATI's proprietary
Linux driver).

>=20
> The fix will be to render the track map into a pbuffer and to fetch it fr=
om
> there, but I think it is not very urgent (it never happend to me in fulls=
creen,
> which most people will usually use in games, and if I remember correct it
> happens just with X and not with Windows).

Fullscreen mode doesn't work very well for me on Linux with a
wide-screen display. :-(

Regards,
  Felix

>=20
> Bye, Bernhard.
>=20

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

Hi Speedy

> Sometimes I have a weirb display in the map zone. (behind the map I see
> something like the screen I have when the game is loading (see the
> image(It's a little image I hope it will pass on the mailing))).

Welcome at NVidia;-) I think it is a driver "optimization" (I think it does not
draw obscured window parts in the back buffer, so the fetched map is not complete).

The fix will be to render the track map into a pbuffer and to fetch it from
there, but I think it is not very urgent (it never happend to me in fullscreen,
which most people will usually use in games, and if I remember correct it
happens just with X and not with Windows).

Bye, Bernhard.

Hi Frieder

> Hi,
> the ./configure step fails on OpenSuSE 10.0 although
> freeglut is installed (via YaST setup).

Hmm, that's odd, I have exactly this setup here, and it works. Could you send as
well the config.log, perhaps this help to track it down.

> fe@garden:~/torcs/torcs> locate glut.h
> /home/fe/torcs/torcs/src/windows/include/GL/glut.h
> /usr/X11R6/include/GL/freeglut.h
> /usr/X11R6/include/GL/glut.h

Hmm, usually the GL headers reside in /usr/include/GL, have you updated your
system from an older version (I have fresh SuSE 10.0 and the headers are in
/usr/include/GL). Looks as well like you have somehow 2 versions on your system,
the problem could be caused through this.

Bye, Bernhard.

Hi,
the ./configure step fails on OpenSuSE 10.0 although
freeglut is installed (via YaST setup).

The last lines before ./configure quits:

checking for unistd.h... yes
checking GL/gl.h usability... yes
checking GL/gl.h presence... yes
checking for GL/gl.h... yes
checking GL/glut.h usability... no
checking GL/glut.h presence... no
checking for GL/glut.h... no
configure: error: Can't find GL/glut.h. freeglut can be found on http://freeglut.sourceforge.net/

glut.h itself is present at:

fe@garden:~/torcs/torcs> locate glut.h
/home/fe/torcs/torcs/src/windows/include/GL/glut.h
/usr/X11R6/include/GL/freeglut.h
/usr/X11R6/include/GL/glut.h

Could /usr/X11R6/include/ be added as additional path?

Thx,
Frieder



PS: gl.h is present (and found) at /usr/include/GL/gl.h

The following updates:

wheel.cpp
---------

Removed all the complicated frame of reference change calculations and
also the not-so-necessary code that calculates the exact length of a
suspension.

The first bit was only of use for when the car was at an angle with
respect to the road surface, which is not very common and in any case
was never done very well.

The suspension length bit was useful in all cases where the road is 
not
flat. Without it the wheels can go a bit 'inside' the track, but I 
don't
think this is very important.

So, why the code was simplified?

Well, firstly, the 'calculation of forces when the wheels don't touch
the track properly' is a very tricky business. So it never worked 
properly.

Secondly, since the wheel code executes four times per car, any extra
code really has a strong impact. So, removed code.

Is there an impact in physics?
The quick asnwer is: yes, there is, but it is limited. In particular,
the forces acting on the car continue to be calculated in full 3d; 
this
means that banked curves continue to work as they should - in 
contrast,
simuv2's behaviour on banked curves is suboptimal to say the least.

Another side-effect is that it is impossible now for the car to stay
upside down, but that's only temporary.

aero.cpp
--------
Not much changed here functionally. However, I use the conservation of
energy to calculate the maximum possible lift that a car can generate
given its drag. Then I popup a warning if car's front and back lift
exceed what is possible with its given Cx and FrontArea.

This is exceeded in most cars, by a factor of up to 4.

The same excess occurs in the standard wing model. The torcs default
wing model can exhibit a lift larger than the theoretical limit by a
factor of 4. Here is a plot of wing lift versus drag for a wing of 
fixed
area,

http://www.idiap.ch/~dimitrak/torcs/lift.png

It shows:

a) the torcs wing model, with the lift scaled to be 4 times smaller 
than
the currently used value.
b) a planar wing model
c) the best possible wing model

So, it appears, as I had suspected some time ago, that we need to 
divide
all the lift forces in the game by 4, we'd get lifts that are a good
approximation to the theoretical limit. In fact I already put code for 
a
changeable 'aero factor' at that time.

So, for the future, I don't know. If we do something, we could do one 
or
more of these:

a) Keep this model and make Aero Factor a user option - though for
robots it would be hell - they don't like low aerodynamics.

b) Automatically enforce limits for Clift given Cx/FrontArea

c) Change the implementation of wings to 'Optimal' - code would not be
more complicated, and has two advantages:
 	Firstly, it is easier to set up. Set up only two things: i) 
Angle of
deflected air and ii) Efficiency. With efficiency = 1, you'd
get the theoretical limit. S
 	Secondly, it takes into account the fact that a wing with a 
larger area
can produce more lift for the same amount of drag when compared to a
wing with a smaller area.

OK, perhaps changing the code at the moment is not exceedingly
important, but I just wanted to share these results with you guys, so
that you know what is the situation.

It is good to at least know what the theoretical limits are, so that 
if
we violate them, at least we do so knowingly and we are not just
guessing in the simulation :):)

So, anyway, this is all for now. You can change aero factor to 1 in
SimulationOptions.cpp if you want to try driving with more realistic
downforce. It is certainly a challenge.

Ciao



-- 
Christos Dimitrakakis
Homepage: http://www.idiap.ch/~dimitrak/main.html
Music: http://olethros.dmusic.com