Racer v0.8.33 released

[Ruud]

Things have been very busy, lots of things going on at the edges of Racer (not really core Racer), but here's an update finally.

Get it at http://www.racer.nl/download/racer0.8.33.zip (75Mb)

Known issues:
- The current replay should be re-recorded
- AI training is very alpha, it currently s*cks

Changes:
- Added 'gfx.show_traffic_lines' option to visualize track grid
- Added 'show traffic' and 'hide traffic' console commands
- Traffic improved to be usable
- Added 'gfx.bestline.source' which determines whether the bestline is derived from AI or the ghostlap
- Added log.buffer_time to be able to change the log buffer size
- RTD logging improved
- DXT3 dds format was flipped incorrectly (bad detection of DXT3 format)
- dbg_controls.throttle/brakes/clutch/steer now work again (if dbg_controls.update=0)
- Multiview camera were slightly off wrt eye position
- Added 'show log' and 'hide log' console commands to show live log details
- Cg dll's updated to v3.0.16
- Added log.database.dir for eternal logging of RTD telemetry files (customer)
- Added ghost.time_scale for slow-motion ghost laps (mostly for testing use)
- Changes in thread creation (handle leak fix)
- Added data/images/fadeout.tga where Racer fades to in menus and other situations
- Added 'show ailines' (and 'hide') to visualize AI lines
- Pressing Ctrl-F6 to drive an AI lap now accepts AI cars; they will try to train themselves.
Use 'ai learn save' to save the trained lap.
Let it run for quite a number of laps. See http://www.racer.nl/tutorial/newtrack.htm#default_ai
- Added 'ai reset' console command to reset AI velocities to 50 km/h (for AI training purposes)
- Added 'ai scale <v>' console command to scale AI velocities
- Experimental friction circle method added; #6. Is like #3, only without clamping max_slip_len (dbg_car.friction_circle_method). Doesn't seem too viable though.
- Per-wheel tweaking of 'max_slip_len'; an addition to the tire model to constrict large slip lookups
See http://www.racer.nl/reference/wheels.htm#combinedforces

 

[camsinny]

Not sure if this is really a bug or not:
Drove a default AI line for a track, told a car to be self-aware and teach itself the speeds.
That was taking forever so I put "realtime X" into the console (X being increasingly higher numbers as my patience thinned) but soon the car just stopped going around the track. Plenty of fuel left.

Also, is the correct usage of "realtime X" this: say you set "realtime 20" then want to go back to normal time. Do you set "realtime 0.2" or whatever the reciprocal is?

I know the self-aware AI is under development...and it'll be fantastic when it's working well but it seems to be somewhat lackluster atm - cars just drive jerkily (throttle-brake-throttle-brake-etc) and end up going off the edge of the track. Also, cars just end up travelling at 55km/h on my track (I set the per-car ai.maxspeed or whatever to over 300 but it made no difference) is there something else I'm missing?

Also...what happened to the blog on racer.nl? No activity for about a year now

 

[boomer541]

Anyone know how to use the "new" traffic. I couldn't find any info on racer nl.

 

[AMGfan(BPM)]

God heard me finally one chance to see traffic being improved in racer!

 

[boomer541]

Yea! But how does one use it?

 

[Alex Forbin]

Anyone know how to use the "new" traffic. I couldn't find any info on racer nl.

I've tried to find info myself but it seems to be a state secret. Where's Bond?

Alex Forbin

 

[Alex Forbin]

Also...what happened to the blog on racer.nl? No activity for about a year now

I'm afraid Ruud has been distracted by a labor dispute at the main Racer factory complex. The Oompah Loompah's that act as Ruuds personal assistants are upset at the way they were treated at the annual company picnic. To be honest I have to kind of take their side on this one if everything they say is true. I wasn't actually there but apparently it all started with them being used as foot stools.
If things had stopped there it probably wouldn't have been so bad and it was probably just bad timing to announce a new retirement plan based solely on height. Things get a little vague after that depending on who you talk to but apparently the evening
finally ended with some activity involving a boxing kangaroo and a catapult.
Oompahs are normally good, honest, hard-working people, but they are also a very proud people and don't take kindly to insults.
And I would personally like to know what idiot that gave them alcohol, since as we all know Oompahs+alcohol=violence.
I'm just glad no one got killed.

Alex Forbin

 

[KS95]

 

[Alexander Knoll]

I'm afraid Ruud has been distracted by a labor dispute at the main Racer factory complex. The Oompah Loompah's that act as Ruuds personal assistants are upset at the way they were treated at the annual company picnic. To be honest I have to kind of take their side on this one if everything they say is true. I wasn't actually there but apparently it all started with them being used as foot stools.
If things had stopped there it probably wouldn't have been so bad and it was probably just bad timing to announce a new retirement plan based solely on height. Things get a little vague after that depending on who you talk to but apparently the evening
finally ended with some activity involving a boxing kangaroo and a catapult.
Oompahs are normally good, honest, hard-working people, but they are also a very proud people and don't take kindly to insults.
And I would personally like to know what idiot that gave them alcohol, since as we all know Oompahs+alcohol=violence.
I'm just glad no one got killed.

Alex Forbin

....me too....

 

[twister77]

@Alex Forbin

haha, good stuff..

 

[Ruud]

Anybody else seeing this in their qlog with this beta?

[racer/12084] QInfo: 'car.physics' only found in fallback file.

Ruud, Mitch - what is this parameter/tree supposed to contain? Just a leftover from the commercial version, or relevant for us from now on?

It should be there in racer.ini. It gives the option of async physics (it seems reasonably stable, although we only use it when using Simulink compiled physics DLL's, which aren't in the internet version). With async=1, you also get the option of selecting cores; quite important to keep threads from jumping cores a lot.

 

[Raphael Buthmann]

Ruud , why racer just uses 25% of my processor ?

 

[Alex Forbin]

Ruud;

Bug? Hardcoded? I can't get materials to work no matter what I do.

I have added the following to my track shader

shader_tirefrnt~vf_standard
{
  layer0
  {
    map=tirefrnt.tga 
    material=plastic
  }
}

This is in the car.shd

shader_body~vf_reflect
{
 reflect=0.19
 layer0
 {
  map=body.tga
  material=metal
}
 layer1
 {
  map=$trackenvmap
 } 
}

This is in the materials.ini

pair_metal&plastic
{
  elasticity=0.4
  collide=1
  static_friction=0.9
  kinetic_friction=0.5
  softness=0.9
  sound
  {
    impact
    {
      file=thump.wav
      factor=0.2f
      speedthreshold=1.0f
      
    }
    scratch
    {
      file=skid.wav
      factor=0.00003f
      forcethreshold=100.0
      anglethreshold=0.8
      smoothness=0.90
      ;particlesystem=smoke
    }
  }
}

If this doesn't work right now it would be nice to know so I won't keep wasting my time on it.
I also think that defining all possible material interactions by pairing them will be a huge waste since the amount of possible combinations will be exponential.

Alex Forbin

 

[Mr Whippy]

Material type needs to be under the definition, not the layer?

Ie:

shader_tirefrnt~vf_standard
{
material=plastic
layer0
{
map=tirefrnt.tga
}
}

??

 

[Alex Forbin]

Material type needs to be under the definition, not the layer?

Ie:

??

Thanks Dave, but I've tried it both ways with no luck.

Alex Forbin

 

[Mr Whippy]

Hmmm, I'm not sure then.

I've made the cones on my track plastic and it worked... that is a weird problem... hmmmm

 

[Ruud]

Ruud;

Bug? Hardcoded? I can't get materials to work no matter what I do.

If this doesn't work right now it would be nice to know so I won't keep wasting my time on it.
I also think that defining all possible material interactions by pairing them will be a huge waste since the amount of possible combinations will be exponential.

There shouldn't be that many materials, thus pairs.
I've tried doing what you did and I do seem to get impact & scratch collisions (printing it out from code). I couldn't verify the sound triggering though. What seems the problem?

 

[Raphael Buthmann]

Ruud , nvidia's is bottlenecking racer without cpu thread optimization.
While CPU is 25% the gpu usage don't pass from 60%.

With Threading Optimization on I got 100% of gpu usage . But the CPU Bottlenecks the gpu when more than 6 cars are at the track.

So , with 10 cars at the track , 20% GPU , 25 % CPU , 18 fps. If the cpu were 100% , the gpu were 100% racer could handle 80 fps with 10 cars at the track.

Sorry for the complaint, but everything to improve Racer. LOL

(OBS:Nvidia uses 25% of racer processes to optimize the fps .)

 

[Alex Forbin]

There shouldn't be that many materials, thus pairs.
I've tried doing what you did and I do seem to get impact & scratch collisions (printing it out from code). I couldn't verify the sound triggering though. What seems the problem?

Sorry Ruud,
Dave was right, evidently I did not move all of the material references to be global. It works now, the only problem is I'm driving into a
stack of 15 crates and after the impact my car will lose sound, sometimes it's the interior sounds sometimes the exterior. I'm guessing it may be a problem with a buffer overrun?

For anyone else wanting to work with materials here is an example of the proper place to put the material defs in the shader...

Car.shd

 shader_body~vf_reflect
{
 material=metal <-------------------- This is the only line that matters in regards to materials
 reflect=0.19
 layer0            <-------------------- Make sure it's above your layer0
 {
  map=body.tga
  shininess=1300
  specular=3 3 3
  diffuse=.7 .4 .4
  ambient=.1 .1 .1
}
 layer1
 {
  map=$trackenvmap
 } 
}

Track.shd

shader_box~vf_standard
{
        material=plastic <------- Material 
  layer0
    {
        map=crate.tga
        shininess=10
        specular=.5 .5 .5
        ambient=.3 .3 .3
        diffuse=1 1 1
        depthwrite=1
    }
}

While I have your ear can you possibly look at the SMD cameras in the cars again? Right now they seem to kind of float around the point of origin at low spring rates, sort of like the camera is hooked to an arm, the arms length is dictated by the src_offset. This would explain why the cameras will swing toward the dash in a left turn and to the right in a left turn. They also have a tendency to "twitch" once they have reached their limit of travel.
I really like the feel the SMD cameras give to the sim, it would be even better however if they worked better.
This is the camera setting I'm using, it is very loose but it shows the effect well.

camera0
{
  offset
  {
    x=0.385
    y=0.64
    z=-0.36
  }
  offset_to
  {
    x=0.385
    y=0.64
    z=4
  }
  angle
  {
    x=180.000000
    y=180.000000
    z=0.000000
  }
  name=Driver
  follow
  {
    pitch=1
    yaw=1
    roll=1
  }
  fov=50
  model=1
  wheels=0
  view=1
  src
  {
    mass=20
    k=5000
    damping=2590
    maxdist=0.25
  }
  dst
  {
    mass=6
    k=1200
    damping=90
    maxdist=0.00
  }
}

Thanks
Alex Forbin

 

[Mr Whippy]

I'd rather have SMD cameras replaced for the driver head camera.

I think having the head held rigidly in place (to avoid jumpy cameras at large distances from origin), but have it pitch, roll and yaw instead.

Each one should have it's own properties. The degree of each movement should be linked to the cars g forces.


It's not technically realistic, BUT, when considering cues from the visuals we see to gauge what is happening, they would work better.


Right now if you brake hard the camera moves forward. When it's moving forward you can gauge the rate of change of deceleration nicely. However, at a constant deceleration there is no indication of that force, except you trying to remember how far the camera moved forward by.
Instead, if we pitch the head down under braking hard, the harder we slow down, the more the head looks down. Because the head is altering the view in a dimension not in line with the force, we can gauge it better. Ie, we know that when we can see the bottom of the steering wheel, we must be braking really hard.

To get a similar level of feedback with SMD, they are too soft, and you get motion sick, or end up outside the car haha... I think pitching would work better... I think that is probably why it's seen in Gran Turismo 5... they realise users have no motion platforms, and no way to feel the g's, so they have to provide a visual cue that approximates the forces in some way that you can feel the magnitude of the force, rather than only the rate of change of the g force (which is what Racers SMD's do)


Not sure what anyone else thinks. In theory we could achieve this right now if when we used an SMD camera the 'angle' parameters we still available to use... although it wouldn't alleviate the juddery camera movements on big tracks away from the origin!

Dave

 

[Alex Forbin]

I'd rather have SMD cameras replaced for the driver head camera.

I think having the head held rigidly in place (to avoid jumpy cameras at large distances from origin), but have it pitch, roll and yaw instead.

Each one should have it's own properties. The degree of each movement should be linked to the cars g forces.


Dave

I think pitching movement would make ME want to "pitch" Seriously this has been used elsewhere and it ruined the gameplay for me.
I really think current f/b-l/r motion would work fine and obviously others have figured out solutions to the large distance from origin problem since it doesn't happen in Rfactor or RBR for instance.
From what I've seen, the car doesn't jump at large dist. from the PO (poo?) why can't the cameras position simply be calculated from the car, that way it would always be a fairly large number to deal with.
Here are a couple of links I found while googling the problem...
http://forums.create.msdn.com/forums/p/15124/93535.aspx
http://home.comcast.net/~tom_forsyth/blog.wiki.html#[[A matter of precision]]

Alex Forbin