Racer v0.8.37 released

[Ruud]

Just in time for X-mas.

Get the new version at http://www.mediafire.com/?hc44aiq5izp4iqi
Then get the racer.exe/pdb which fixes reflections at www.racer.nl/temp/racer0838_alpha.7z

At some point we're going to have to call it v0.9rc1, since this one does a little tweaking to the graphics intensities (energy conserving) and sets cast_shadow to 0 by default. Most shadows will disappear; a huge fps boost until you put shadows back in shader files (.shd).

Merry Christmas!
Ruud

The changelist for v0.8.37:
- Added views.ini keep_aspect property to maintain aspect ratio for static images. See http://www.racer.nl/tutorial/dials.htm
- dyn_standard_reflect_window_f.cg now uses alpha as reflectiveness as well; opaque parts get less reflection
- TrackEd's AutoAseToDof has improved error messages on bad submaterial usage.
- TrackEd: some (progress) dialogs never appeared. Copy flags to group didn't work.
- TrackEd now colorizes the Collide and Surface flags in Props mode (F4) for easy tweaking of flags.
- standard_bump_detail_f.cg had a hardcoded 12x scale; now it uses the scale defined in the .shd file
- The garage track is not shown in the 'Select Track' screen anymore.
- Added log.events.host/port settings for remote racer tracking (niche usage).
- Lidar data (track.rld files) can now be sorted and driven on. Pro use only.
- Added car pitch/roll in body AND world coordinates in the Ctrl-9 debug screen.
- Added 'analyse shaders' command to check all shaders (track.shd/car.shd).
- The shaders default 'reflect' value for each layer is now 0 (was 1).
- Final tweaks in the shading system; energy conservation for diffuse and specular. For diffuse colors, this
means diffuse colors are divided by PI (assuming diffuse colors are kept between 0 and 1), and specular
colors are being corrected with (n+6)/8*PI.
See also http://www.rorydriscoll.com/2009/01/25/energy-conservation-in-games/
- Timers are now in microsecond accuracy using QueryPerformanceTimer(). Multicore machine issues?
- Profiling is more accurate due to the better timer accuracy. More graphics divisions added.
- Shader cast_shadow property by default is now 0; it's better to explicitly define shadow-casting materials
since you don't need a lot of shaders to cast shadows to still get a good image.
You *will* need to add cast_shadow=1 lines for shaders that you want to cast shadows.
- Depth texture setup optimized for shadowmapping; quite a big fps increase.
- Added look/left right controls (look_left, look_right) to dynamically look left or right (Q/W by default)
- In your controller file you can add global.left_right_look_velocity to set left/right look velocity (default=250)
- In your controller file you can add global.left_right_look_max to set the max left/right look angle (default=45)

 

[camsinny]

AAAAH!!!
BUG: Turn on wireframe mode.

Also, I think that the alpha blending isn't working in the envmap? I was cruising along on carlswood and noticed the tarmac went from white to black (specular there one second, gone the next) I think it's where the alpha decals are over the road surface, though I can't be sure because wireframe mode freaked me out. I don't wanna try it again.

 

[Mr Whippy]

Alpha blending doesn't happen in the envmap, I think it's meant to not happen in the envmap unless you use the right combo of alphafunc, blendfunc and alpha to coverage...

I can't remember the combo now, but my Elvington decals work fine iirc, so maybe the Carlswood shader is bad?

Hmmm

Dave

 

[Mr Whippy]

Been checking out Ver 0.0837-8a testing a number of tracks, results:

bahrain - car has very bright speculars that flicker can't find a fix.

freehand - get a overrun detected, fps goes from 180 to 7 just after starting to move car and at various locations.

Gyral - overrun detected just before crossing s/f line at end of run.

Some tracks have good lighting while others look like an overcast day, all dark with a bright blue cloudless sky.

Making a video from a replay crashes racer when finished with the audio run. Get the avi which is all blocky, using mpeg-4 codec.

Background movie doesn't work.

The "overrun detected" is an interesting thing. I get it almost all the time I go to helicopter view with rain turned on... it also seems to be a function of a high number of render calls.

I think a lot of these converted tracks suffer from having oodles of shaders, dofs and thus a mentally high amount of render calls. Not ideal really. I'm not sure if we should be judging Racers performance on old tracks that are converted for the old rendering system.



As for skies/lighting, it's impossible to judge anything fairly right now. Not one track has been released with what I would call good lighting, everything is compromised.
TOD curves only suit ONE global location properly, and if you have set that differently, then the lighting will be inaccurate. More so the sky texture/image you use will impact the appearance of the TOD curves.

I think Ruud based his TOD curves in some parts from ones I posted, which at the time were works in progress. So even the default TOD curves are not great yet.


I've been busy over Christmas with lots of other stuff but really wanted to get Elvington a bit more finished and released, purely so we can have a track that I feel has a really good lighting setup (lots of static TOD's), so a rainy day, a cloudy day, a sunny day, a sunset etc... since dynamic TOD simply won't work nicely without more work in implementation imo.
It will also be built so that it has oodles of detail but also good FPS (optimised for very low render calls), which is a fairer test for Racer moving towards v0.9... it needs to be tested with content made for near v0.9!

Dave

 

[Mr Whippy]

Perhaps because Racer wants to connect to itself in single player.

Racer is so ronery it connects to itself

 

[Alex Forbin]

So why is "overrun detected" such a deep secret? We've had this error flashed at the top of the screen for several versions now and still we have no idea what it is. Why even have it show up? It kind of makes it pointless to troubleshoot when we don't know what the error codes mean.
I thought it might mean an "FBO buffer overrun" but it seems to be more of a Newton collision detection problem for me.

Alex Forbin

 

[Mr Whippy]

Hmm weird.

It would be nice to know what it means indeed

 

[Stereo]

It means FPS dropped below some number, I think it used to be called SLO MO. As far as I know it means a frame took over 100ms to render, which means visuals start lagging behind realtime.

 

[KS95]

I used to get that all the time, if it lasted long enough you could probably do the TG test track in 20 seconds

 

[Alexander Knoll]

...i think it will say...the power of the used texture is "overrun detected".....do you remember the funktion Ruud told us some time agoo....it was something with the used mipmapped layer of DDS textures...if i remember right...reduce the resolution of the texture fixes the "overrun detected"....message....hit me if i'm wrong....

 

[boomer541]

Of the two tracks I get overruns. on only one has DDS textures. Overrun has only occured on ver 0.037-8a.

The baja car has some real bad shaders which i'll post a fix of sorts tomorrow night and the damage lambo has a dent in the rear deck and it was'nt driven at all. Wierd.

 

[Mr Whippy]

I get overrun detected almost any time I'm in helicopter view with the rain turned on, maybe just for the first half second of switching to that camera view, but it is fairly consistent in doing it.
That is on any track too iirc.

Dave

 

[boomer541]

Baja fix and the profile I use which you might like to use also. The profile has the look left/right and head trackir, the trackir is commented out. The keyboard keys don't have the same key for two or more functions.

Change the .txt to .7z in the attached files

 

[Ruud]

So is it my understanding, then. That ur latter versions wont support ATI?, if this the case, this is most disappointing, as alot of people use them, i also guess my suggestions have fallen on deaf ears, so on that note, i bid u adew, fairwell, because i only use nvidia or ati gpus, all the leading game developers support ATI.....

Yes I want to support ATI. I got a new home PC a few weeks ago where I specifically chose an ATI board for this purpose. When doing quick fixes like in this thread, it would cost too much time to check it on various configurations. I do have it running now at my home PC; it detects the ATI driver and then ignores the envmap.generate_mipmaps=1 setting. That does mean you won't get blurry envmaps, but it does run on my ATI (HD6700 series, driver Catalyst 11.12).

In the future I want to switch to GLSL; it seems UBO's are not supported (uniform buffer objects) which should cut down on most parameters being passed to a lot of shaders. And setting graphics pipe state seems oh so expensive. By now, GLSL is mature enough to outdo Cg it seems. But I guess that should come after v0.9, otherwise we'll never get those old car/track archives brought up to speed!

 

[Ruud]

Ruud, is there any easy way to batch DOF's using the same shader per frame? Ie, if we have 1000 trees as one big DOF, it is immeasurably faster than 1000 DOF trees as individual DOF.
Should we be batching our shared shader geometry at authoring or would it be better to do it in real time? Or is that too costly?

Just trying to get the ideal balance between loading all the geometry in one DOF even if a lot of it will not be visible that frame (so wasteful to load the polygons at all before they are culled), vs having more graphics calls than needed at other times due to having more than one DOF with that same shader in the view...

That is what TrackEd's split function is for; after the track is about done, you split it into big section of 400x400m somewhat. These are generated by shader and cell (geolocation). This makes tracks often a LOT faster. It does produce nasty outputs ofcourse, with cell_x_y tags attached to dofs, but that would be the case with any machine-generated track. You do have to keep the original track that is more logically built up for future splits in that case.

 

[Ruud]

Ie, the mipmap command would be best called mipmap_bias surely, like the other bias values, and then added under the specific envmap slot you want to use?

The current command is for the entire material, so I assume you can't use the envmap twice, a blurry one and a sharp one?

In v0.8.38, the shader is called mipmap_bias and is available both globally and per-layer, so doing the metal with diffuse & reflective layer both using $trackenvmap but with different mipmap levels should be possible.

 

[Ruud]

Speaking of audio, I still have the problem of almost no volume at all when Racer starts, it's fine once I hit pause or replay, but if I reset the car it goes quiet again.

Alex Forbin

Does 'hook_incar_to_camera' change anything?

 

[Ruud]

It means FPS dropped below some number, I think it used to be called SLO MO. As far as I know it means a frame took over 100ms to render, which means visuals start lagging behind realtime.

Indeed, it's a term coined in the professional industry. I've changed it to 'PHYSICS RUNNING SLOWER THAN REALTIME'. Indeed previously known as 'SLOMO'.
Sometimes these engineering terms are a bit selfcentered to their own area of expertise...

 

[Ruud]

I get overrun detected almost any time I'm in helicopter view with the rain turned on, maybe just for the first half second of switching to that camera view, but it is fairly consistent in doing it.
That is on any track too iirc.

Dave

Weird, does Ctrl-6 show anything? I can run Carlswood with rain=1 fine...

 

[Alex Forbin]

Does 'hook_incar_to_camera' change anything?

I'm not sure where to put that, I searched for it on racer.nl but had no luck. I tried it as a console command, and in the .car and .camera sections of car.ini. I also looked in the default car.ini for any hints.
If I remember that was a camera argument for giving additional volume to incar cameras, but I've never needed it before. I don't think that is the problem however since the volume error is universal and not isolated to just one camera.
I suspect it's a problem with the new version of Fmod, since that's when it first appeared.
This system is using the Realtek HD audio chipset, it's an ASUS MB and Q6600 (don't laugh) CPU running on WinXP pro. But it also does it on the new I7 Win7 pro64 system at the cabin.

Alex Forbin

 

[Alex Forbin]

Indeed, it's a term coined in the professional industry. I've changed it to 'PHYSICS RUNNING SLOWER THAN REALTIME'. Indeed previously known as 'SLOMO'.
Sometimes these engineering terms are a bit selfcentered to their own area of expertise...

OK that makes more sense as to why I would get the message when running a heavy bus at my test track over a flat topped ramp on my test track, when the bus would "high center" over the edge of the ramp, I suspected it was a collision box problem.
Thanks for the info.

Alex Forbin