Racer v0.8.25 released!

Ruud

RACER Developer
Another one, esp important with the tangents problems (white spots/dark triangles):

Get it at http://www.racer.nl/download/racer0.8.25.zip

Changes:
- Setting racer.ini's textures.compression to 0 had an effect on visuals (no SRGB).
- Ctrl-1 now shows when the force feedback is saturating the wheel (>20 Nm).
- Controller setup screen now removed POV and added horn and wiper controls.
- 'sunny' default was 0, should have been 1.
- standard_bump_f.cg now takes specularity from the normalmap's alpha channel (2nd layer)
- Only 3/4 of the tangents was passed for each objects. White spots and black triangles.
- Baja shader bug fixed (dyn_standard_bump_speca.cg was used)
- ff_damping (in car.ini) was applied to the wrong FF setting (friction instead of damping)
- Small change in spline triangle checking for road surfaces; in Carlswood doing Shift-F
4 times failed to recognize the underlying spline triangle.
- Y offset in viewelt_f.cg removed; dials were slightly moved up a centimeter.
- Using Cg 3.0 toolkit (was 2.2) from July 2010.
- smCor for the 3rd shadow split slightly increased
- Only angular 3D view elements (dials) were painted correctly. Other texts could appear rotated.
- 'show splines' and all debug lines & points were rendered in HDR mode thus dark. Now drawn in LDR
after postprocessing to remain visible at all times.
- Live track envmapping anti-aliased the whole main FBO on each side update (ouch). Faster now
when setting render_once to 0.
- Mirror was anti-aliased twice. Slightly faster now.
- Exposure gradient changed from 0.5 to 0.35 (darker exposures)
- Music & background image handling in all setup screens now supported.
- More live track options in the graphics setup screen.
- Added bestline_v/f.cg for visible rendering of the 'best line' (F3 to toggle bestline)
- Added bestline.tga in data/images as an overlay image (uses alpha channel).
- 'sunny' included in sky shaders (GetSkyColorAtm) for the sun disc
- Undetected controllers would crash the controller setup screen in a few places.
- The lobby was painted incorrectly when using 3 monitors.
- Fixed stack underflow in car selection screen.
 
Hm. I have a question here. Not sure if it is related to CoG but I imagine it might.
The thing is, that when you turn a car you use the front wheels meaning that the
front turns differently than the rear. Also the driving direction and motion of the
car is determined by the movement of the front wheels, right?

But it seems, in Racer, as if all movement is located to the /middle/ of the car,
so that when you turn, your turn is more like a twisting of the car with the twist
center in the middle, and not a linear turn based on the front wheels. It might be
that it just looks that way, or that it has been changed in newer versions..

.. just thought I should mention it..
 
Hm. I have a question here. Not sure if it is related to CoG but I imagine it might.
The thing is, that when you turn a car you use the front wheels meaning that the
front turns differently than the rear. Also the driving direction and motion of the
car is determined by the movement of the front wheels, right?

But it seems, in Racer, as if all movement is located to the /middle/ of the car,
so that when you turn, your turn is more like a twisting of the car with the twist
center in the middle, and not a linear turn based on the front wheels. It might be
that it just looks that way, or that it has been changed in newer versions..

.. just thought I should mention it..

The CG of most cars is somewhere near the center, so a car *should* rotate around its center. The front wheels just pull the car at a distance away from the CG, so you get a torque around the CG. Since the CG is near the center, it will rotate around that.
It is not that the wheels go a different way and the car drags towards that; the car is much too heavy for that. Instead, turning the front wheels create forces, and those forces are applied through the chassis/linkages so the whole body starts rotating (rotational acceleration).

v0.8.26 can shift CG appropriately now; I tried it with CG.z=1 (moving CG towards the nose), then moving back the wheels (susp<n>.z) so that you *should* get the same car again. Doesn't work in v0.8.25, but with dbg_car.move_cg=1 in v0.8.26, it does rotate around the CG again.
Funnily enough, I checked out Newton, and it states that you should be able to move the CG. I'm doing that, but torques can't work right it seems. So now I move all stuff; 3D, flares, wheels, pilot, wings etc.
 
FBO turned off worked! :D

Now I have another problem, at times of the day where the sun intensity is stronger, everything apears white (over exposure/saturation?). But if I change time to 20.00h for example, the issue disapears!

exp.JPG
 
The CG of most cars is somewhere near the center, so a car *should* rotate around its center. The front wheels just pull the car at a distance away from the CG, so you get a torque around the CG. Since the CG is near the center, it will rotate around that.

Ok, I can accept that.. might be that some cars are just badly tuned.
But it does look, and feel, kind of strange when the car appears to
have a wheel in the X centre which determines the movement..
But then again.. maybe that is just how the physics works. *shrug*
 
Just a quick question Ruud. How are the the moving arms coming along? Would be great if we could get them for 0.9. I know this has been asked many times and I'm sorry for bringing it up again. :redface:

Also, I saw a clip of GT5 and it's dials that light up at night. Would that be hard to implement? We now have the dials shader, so there should just be an option to change it's settings when the lights are on.
 
The CG of most cars is somewhere near the center, so a car *should* rotate around its center. The front wheels just pull the car at a distance away from the CG, so you get a torque around the CG. Since the CG is near the center, it will rotate around that.

I assume you only mean this when the car is floating in the air. A bus for instance will rotate around it's rear axle if the front wheels can turn to nearly 90 deg. the CG will of course rotate at some distance from that.
Now if the car is 4 wheel steering, it would behave more like you say. I'm not trying to be retentive but it would explain some odd torques I've noticed in the past, by that I mean it's always felt as though the car had several dead bodies in the trunk when it would turn or maybe that there was a really large weight attached to the rear bumper. I've mentioned before that it may be the reason tires have a longer recovery time than they really should.

Alex Forbin
 
The CG of most cars is somewhere near the center, so a car *should* rotate around its center.

This can be true but not at normal conditions, so I have to go with Alex and luthobu on that.
There are just to many arcades out there where car rotates around the CG.

Car will rotate around CG but only at the point when starting drifting and later at spinning off.

Before that sideway forces in rear wheels are far to big to allow car to rotate around CG. Thats also why rear wheels always make smaller circle in the corners. So the point to which CG applys torque is at rear wheels at slow speeds and goes towards CG as rear wheels slip angle increases with speed.

Just my 2ct.

Bye, Frank
 
I asked about ghost cars, but apparently no answer from anyone.
Sorry again, but... I see no ghost cars since Racer 0.8.24, and they are activated.
Someone has experienced same problem?

Best regards!
 
This can be true but not at normal conditions, so I have to go with Alex and luthobu on that.
There are just to many arcades out there where car rotates around the CG.

Car will rotate around CG but only at the point when starting drifting and later at spinning off.

Before that sideway forces in rear wheels are far to big to allow car to rotate around CG. Thats also why rear wheels always make smaller circle in the corners. So the point to which CG applys torque is at rear wheels at slow speeds and goes towards CG as rear wheels slip angle increases with speed.

I think it's a matter of visuals vs calculations. Visually the rotation point may lie indeed at a different spot than the CG, I haven't really ever dug deep in that. Physically-wise though, the chassis is the center point, with its CG static (wrt the chassis/car itself). All that is done is that tire torque are fed to the chassis at their linkage points, which makes torques and the chassis starts moving around its CG. Since the rear tires are pushing back, you get a sort of sideways motion so that the rotation point may appear to move.
All bodies in modeling packages are modeled using point-masses, where the single point in space has a position and orientation. Inertia matrices then make up for asymmetric mass.
 
I asked about ghost cars, but apparently no answer from anyone.
Sorry again, but... I see no ghost cars since Racer 0.8.24, and they are activated.
Someone has experienced same problem?

They probably do; an extra ghost recording was added (you have 3 now; playback, recording, best-of-heat. The loaded ghost replay may be repeated in the future, even if you drive better than the loaded ghostlap; for example if you want to practice a certain line, and are not that interested in the time itself) and that screwed up playback in most situations. Fixed in v0.8.26 (or should I say, v0.9 RC1).
 
I think it's a matter of visuals vs calculations. Visually the rotation point may lie indeed at a different spot than the CG, I haven't really ever dug deep in that. Physically-wise though, the chassis is the center point, with its CG static (wrt the chassis/car itself). All that is done is that tire torque are fed to the chassis at their linkage points, which makes torques and the chassis starts moving around its CG. Since the rear tires are pushing back, you get a sort of sideways motion so that the rotation point may appear to move.
All bodies in modeling packages are modeled using point-masses, where the single point in space has a position and orientation. Inertia matrices then make up for asymmetric mass.

Yes, when the car is in a zero-G situation it will revolve around it's CG and the influences from tire forces when in contact with the ground will cause it to rotate around a point different from it's CG. We are saying the same thing just in a different way. I still am not sure why it takes the tires so long to recover sometimes, it seems to be much better when I'm using Pacejka5.2 however, so it may just be a difference in the tire models.

Alex Forbin
 
The recovery might have something to do with the max_tan_sa, which is set to let slip angles rise to almost 180 degrees. Still that wouldn't explain the mf5.2 improved behaviour. Next year we intend to have a closer look at physics. I don't really trust the arb for making a neutral car understeery, and we might add a thermal tire model since Pacejka loses out when doing extreme stuff with the car.
 
Just a few things I'd like to add.

Racer crashes if you have a G25 wheel defined for controller, but it's not plugged in.

We could do with a way to swap to different controls easily, but not lose the set up we had before. Ie, wheel, keyboard and mouse should each save to a wheel keyboard or mouse config, and you can toggle through them.
I can't use my wheel on a night, and plugging it in just so I can load Racer (and the associated calibration motion), just to get into Racer to load a different controls config from the console is rather silly (this also isn't ideal for users who are not familiar with console stuff)


Second is that I think we need the flag wave 'system' integrated into the tree shaders and grass shaders, so we can add some wave motion to them, and a scale for that motion too (so how much to deflect by, and the frequency?!)
These are things I continually add back to the standard shaders Racer offers, tracks go from looking a bit flat and lifeless to feeling a bit alive!

Dave
 
I have a question, how can I use inicators, hazard lights or highbeams?

indicator_left
{
axis=
min=0
max=1000
button=-1
pov=-1
negate=0
make_analog=0
linearity=1.000000
sensitivity_rise=0.000000
sensitivity_fall=0.000000
key=left
}
indicator_right
{
axis=
min=0
max=1000
button=-1
pov=-1
negate=0
make_analog=0
linearity=1.000000
sensitivity_rise=0.000000
sensitivity_fall=0.000000
key=right
}
hazard_lights
{
axis=
min=0
max=1000
button=-1
pov=-1
negate=0
make_analog=0
linearity=1.000000
sensitivity_rise=0.000000
sensitivity_fall=0.000000
key=w
}
highbeam
{
axis=
min=0
max=1000
button=-1
pov=-1
negate=0
make_analog=0
linearity=1.000000
sensitivity_rise=0.000000
sensitivity_fall=0.000000
key=f
}
 
The recovery might have something to do with the max_tan_sa, which is set to let slip angles rise to almost 180 degrees. Still that wouldn't explain the mf5.2 improved behaviour. Next year we intend to have a closer look at physics. I don't really trust the arb for making a neutral car understeery, and we might add a thermal tire model since Pacejka loses out when doing extreme stuff with the car.

That makes sense, if the SA is going that far I can see how it might take a while to recover. I've tried changing the dbg setting max_tan_sa and it doesn't seem to make any difference.
Do you have any idea which tire model? I would like to start researching it if possible.

Alex Forbin
 

Latest News

Shifting method

  • I use whatever the car has in real life*

  • I always use paddleshift

  • I always use sequential

  • I always use H-shifter

  • Something else, please explain


Results are only viewable after voting.
Back
Top