Racer blog

Blog

Daily (well) diary.

Dolphinity Organiser - free planning, project management and organizing software for all your action lists

I got myself a Logitech G27. :) It has a nice feel to it, quite good for a 'consumer' wheel with its helical gears (makes much less noise than any of my other wheels). I revised the setup screen, since this trinket has so many buttons. It now displays the controller name, plus the 'Reset' button has been renamed to 'Auto detect'. Currently it will only discover G25 and G27 wheels, where the G25 is probably wrongly configured (since it has less buttons).

Now onto those LEDs on the wheel... I've requested the LED SDK from Logitech, let's hope they respond soon...

logitech g27 setup

I've devoted some time to getting a bot to connect & host races in the lobby. It behaves like a player logging in, then automatically hosting a game and starting the game in due time. Racer v0.8.7 will hide bots from the 'real' player list, as shown below. If no players enter, it cancels the race, then goes on to the next. It works using a server.ini file, which, if enabled, defines what races, what cars & tracks, and the wait times involved. Would be nice if people host races on their idle hardware in the future.

All currently quite alpha stage; just 1 race type is hardcoded (Lambo on Carlswood) and it needs some syncing of # of laps and more rules before its really useful. Still, I did manage to do a multiplayer race against my own bot last night. One extra thing that is needed is to have a multiplayer server which doesn't enter a car (like a spectator), so you're left with all human racers.

lobby

Here's another video demonstrating moving suspension. The car shown will be included in Racer v0.8.5.

Here's a small video showing the new & improved generic models in action. The idea is to add this car to the Racer distro, since creating all the models, aligning them and such is quite a complex job, so having an example ready will certainly help.

The model below uses 10 models per side (!): upper arm, lower arm, steering rod, axle, spring (2x), spring & damper upper fix (2x), damper upper (2x). v0.8.5 has 50 generic models present per car, and it seems you really need them.

Since the Cg motion blur shaders still have a lot of trouble with moving objects, the subject came up to get FBO's working with blur_alpha (see racer.ini). That all turned out to be very easy so the new motion blur of choice is FBO's (motion_blur.method=4) and using a blur_alpha of around 0.75 (which should really be framerate-dependent).

An example is shown below. Note that bloom is a bit more apparent than in v0.8.4. It also uses live track environment mapping; v0.8.5 supports FBO's for this as well, including deciding whether it's done in 8 or 16 bit (HDR). The projected shadow uses the stencil buffer (in FBO mode) to avoid the X-ray look that plagued previous versions.

I've been experimenting with another physics library; Newton (I've used ODE - Open Dynamics Engine upto now). The nice thing is that is has relatively stable triangle soup collisions, combinable with a number of collision primitives such as boxes & convex hulls.

I've split up Carlswood's cones to be able to move them separately (as you can see above). This took a small roundtrip through 3D Studio Max and some juggling with material names to get things right.

A new collision system does mean renewed issues, such as bounciness, elasticity etc. I know that multiplayer won't work currently, since it will probably collide the cars to eachother; for that to work I need to add the sense of materials (something built-in in Newton).

A start has been made with implementing ghost cars. Only really useful when you're driving by yourself, but fun nevertheless to compete with yourself. Frustrating at times too. ;-) See the Ghost tutorial page for more details.

Everyone who's ever done a track knows about the problem with alpha-sorted polygons. Blending trees nicely has always been hard. The best in Racer sofar, more or less, was to use alphafunc on an alpha-blended polygon and blend it anyway (keeping depthwrite=1, so writing the Z-buffer). Still, this leaves edges visible. Some rFactor tracks use a technique with 2 passes; the first with alphafunc, to depthwrite the opaque parts of the tree; the 2nd pass only for the semi-transparent parts without Z-buffering. That gives sorting errors at the edges of the leaves, but those are less noticable.

I'm now investigating alpha-to-coverage, a technique only useful when using multisampling (but you should be doing that anyway in 2009). The alpha values of the pixels are transformed into a pixel write mask that determines which pixels should be updated. Since it's multisampling, the output is not bad at all.

A 100% view follows of the trees in CarlswoodNT with alpha-to-coverage. To do this, I took out (in track.shd, for tree materials) the 'blendfunc=blend' line, I added 'alphafunc=gequal 1' and 'depthwrite=1'. As you can see it looks transparent. The nice thing is that you can Z-buffer things (depthwrite=1), so you (or rather, Racer's graphics engine) no longer need to worry about sorting issues; the Z-buffer will take care of that.

For this to work, I added racer.ini's renderer.alpha_to_coverage. If set to 1, it will use alpha-to-coverage when you have an 'alphafunc' defined.

FBO's are fun; they're so fast you're beginning to wonder whether we should run the Windows kernel on the GPU. It might make things even faster. Today I explored glGenerateMipmap(), which generates mipmaps on the fly, on the GPU. It's amazingly fast. I now use it on the rendered image in the main FBO to completely downmipmap to the highest mipmaplevel, which is a 1x1 pixel. After all that mipmapping, the final pixel is just about the average brightness of the screen.

Cg shaders though need tweaking to generate real HDR values, not while rendering but at the back-end when the FBO is finally rendered to the framebuffer. At that point exposure comes in. The 1x1 mipmap gives an idea of the brightness of the scene, and you tweak exposure in the final end: colorLDR=1.0-exp(-exposure*colorHDR).

It needs tuning ofcourse, but looking into the sun gives you the image below. It was not resized, not multisampled, yet it looks nice. It does feature HDR, bloom, 16x anisotropic filtering. It ran at around 60fps on my nVidia 8800GT.

Some days are just better than others, when everything seems to work. Beginning to understand FBO's better, suddenly a texture format change to floating point worked to get HDR (floating point rendering instead of just 0..255) and 2 extra FBO's to Gaussian filter a bloom map was possible. In just 2 hours, the basis for HDR+bloom was working.

The problem now is content and contrast ranges; how much needs to change to get HDR skies & cars, how did Half-Life 2 do it, and what would be suitable values for a sun vs just diffuse surfaces.

One of the first shots is below; note that it doesn't have any regular anti-aliasing, which doesn't work in conjunction with HDR/bloom yet. Also, the way the bloom map is constructed is still crappy (just a high-contrast version of the framebuffer, or rather FBO, is used). So the image is too dreamy, but the reflections are beginning to give signs of blooming. Note that this is running on a 8800GT; the main FBO is 16 bits deep (64-bit total HDR), the blur FBO's are also 16-bits (first a horizontal Gaussian blur, then a vertical blur into the 2nd blur FBO).

This week a lot of focus went into 2 things; putting names above the cars, so you can recognize multiplayer drivers, and motion blur. First, motion blur seemed to go nowhere, but I'm getting much closer now. I'm rendering a velocity map into a texture, storing velocity in RGBA (R=positive X, G=negative X, B=positive Y, A=negative Y), then doing a post-process pass using the FBO with the image and a texture representing the velocity map. Per-pixel velocity calculations were needed, but the result is great (although it needs a bit of tweaking at the borders, and there's a big bug with the tires):

The Corvette C6 on Carlswood:

An example of floating names with multiple cars:

Just before I move off again to enjoy some snow, I started work on moving helmets. I added 2 models to the cars: helmet & pilot body. The helmet is designed around the pivot point so that I can rotate it easily based on the car accelerations. The method is relatively simple; first get an 'up' vector of the head, using the accelerations almost directly (just a factor & a filter to avoid VERY shaky heads ;-) ), then make a forward vector. From those 2, derive a side vector and rebuild the forward vector again to get an orthonormal matrix.

There's some documentation on this already here.

The sun direction was off a bit for non-Cg shaders. Fixed that. A nice image to show things off. Live track environment mapping turned on. 16x FSAA on an nVidia 8800GT.

Atmosphere is finally beginning to look ok. Here is the Corvette C6 on Carlswood at 7.30 pm with default fog (fog rayleigh 0.0025, fog mie 0.001). The atmosphere function is in a separate Cg file to be able to include from other shaders (it's not trivial). There is now also a 'standard' shader for regular materials which support emission, ambient, diffuse and specular lighting (in the files standard_v.cg and standard_f.cg). All this for v0.7.2.

Before corner 1 at Carlswood, also 7.30 pm but fog mie 0.01.

I'm on a long pursuit to get a better day/night system. Scattering coefficients, aerial perspective, there's a whole new world to discover. After some frustrating days & lots of reading, Sean O'Neill's work seems quite nice. It gives a somewhat 'free' sun, although I'm having difficulties relating the sun position that rolls out of Sean's Cg shaders to my own. Admittedly, Racer's sun position was just a bunch of hacked-together keyframes, but last week I obtained an algorithm which uses month/day/year to get a more accurate sun position. Unfortunately, it doesn't really match with Sean's shaders. However, things are improving after a lot of seemingly weird bugs.

Here are some screenshots at Carlswood. Not all shaders use Cg yet, but the woods in the rear do, obtaining some atmospherical influences. In order: 7 am, 3 pm and 7.30 pm.

Dolphinity Organiser - free planning, project management and organizing software for all your action lists

(last updated December 30, 2014 )