Racer v0.8.37 released

Ruud

RACER Developer
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)
 
Thanks for the update, Ruud :)

Despite having set the reflect value specifically for the corresponding shaders, I don't seem to be getting any reflections at all. There doesn't seem to be a related change in racer.ini or elsewhere I looked so far either, hm.

The cameras still seem to be bugged, as in the last release - even if they were already defined from the nullpoint (no cg.offset used), their position and movements aren't lining up with our inputs settings.

look_left/right sure is a nice little feature, useful not only for multiplayer. I wonder if we can have a look_back funtion as well. Also, Racer is still unable to recognize the directional pad on the G27's shifter unit, that would be nice for these camera controls really.

Will have to try out some of the other changes and additions, but for now, wishing you a nice holiday season :)
 
Hiya Ruud !!!
Happy Xmas To ALL :)

If you alpha map your bodywork map with a black color, you won't have any reflections while white will do the inverse...
I already tried it, it works nicely.

============================
Get Ready for huge content updating...LoL
Terminal / Qlog Enabled ...

Microseconds Timing....Crazy stuff...when will Racer become chemically simulatable, that idea came to my mind some days ago...
 
Those energy conservation things sound sensible.

However I'm seriously worried about implementing it just before a possible 0.9 final, when the implementation (from your changelog) sounds a bit iffy.



I really think it's a bad idea to go down this road now, unless we are going to make full changes to the reflection map system too, so it really IS energy conserving, and not just a quick implement that breaks more than it adds!

The current system isn't really all that great anyway, but adding this stuff on top of a system that isn't really developed enough to handle it in a proper sense, means we just end up with an imperfect system made even worse by trying to make it do more than it's capable of!

Why not dump specular altogether, and start using envmap mipmap reflections/fresnel on everything? That way we get the lovely blue soft specular reflections on the road even heading away from the sun, yet as we turn into the sunset, the road gets all nice soft orangey yellow reflections, despite the actual net illumination diffuse colour being near white!


Personally, I think a warning in the "analyse shaders" command would be best, if energy conservation is seen to be breached by the sum of the spec/diffuse intensities.



Dave

Edit: Edited lots, as posts further down sum up my observations better!
 
Why not dump specular altogether, and start using envmap mipmap reflections/fresnel on everything? That way we get the lovely blue soft specular reflections on the road even heading away from the sun, yet as we turn into the sunset, the road gets all nice soft orangey yellow reflections, despite the actual net illumination diffuse colour being near white!
This is my main feature request before 090f as well, setting up mipmaps for the envmap so they can be used in shaders instead of a point specular light.
 
This is my main feature request before 090f as well, setting up mipmaps for the envmap so they can be used in shaders instead of a point specular light.

I'm glad you agree!

It makes no sense to use the old fashioned specular when we have a live envmap and a whole bunch of mips that we can use. Perhaps even a system of cube envmaps that we generate at runtime, or when TOD changes, for track materials. They generally only need to be fairly low res for specular use!



I'll have to try this current addition in energy conservation, but it sounds like building a house of cards on a flawed system, a bit like when we had all the new shaders and stuff, but it was all in LDR. Suddenly going HDR made much more sense. In this case dumping specular sounds far more sensible for some other method.


In this case I think we need to move into a whole new material definition system as it is the only way to implement a proper energy conservation and proper material response system.
Anything else is just trying to mix the best of one system with the worst of another which will result in more difficulty for artists to get good results.


Cheers

Dave

Edit: Edited lots because it was babble repeated further down.
 
Well, the diffuse/spec thing doesn't seem to have 'hurt' anything. It was fairly badly described in that link.

I can see the logic in being able to set a materials diffuse/spec at certain values, and then adjust the shininess, and have the specular reduce in power as the shininess decreases, so the specular spot doesn't get huge and bright, it gets bigger and softer to maintain not getting overly bright (ie, too bright than is realistic)

If you clamp to 0...1 for both diffuse and specular, then I guess it keeps specular intensities in realistic ranges relative to the diffuse intensity (ie, no more energy off the surface, than onto it)
BUT, was that ever a problem anyway? Surely you can just tell your artists to check intensities off their specular reflections vs the sun intensity (that is what I've done since we had the mouse pointer intensity readout (kLux))

From my perspective, it's just covering up for bad content authoring, however bad authors who are not considering realism will probably just use unreal values generally anyway (ie, go over 0...1 range)
Hmmmm


Interestingly, the mouse intensity value has stopped working now?!

Auto exposure is turned off too, leaving us with horrible fixed exposure on Carlswood. Hmm, that seems to be the reason the mouse intensity value has stopped working... back now AE is on.


Can't seem to get reflections back on any cars.

Also, another thing I thought was fixed, but maybe it wasn't. Shadows from cars seem to be softer nearer the camera than further away.
Ie, the Lambo on Carlswood, camera8. If you just dolly to the side a bit (ctrl + num6), you can clearly see the shadow at the front of the car is soft, and at the back of the car it is sharp. It just looks weird.


Good points are that the dials are now properly round if you run widescreen resolutions, yay!




Hmmm, just thinking more.

How is the energy conservation done?

Specular are currently driven off the sun diffuse only yes? That value is a really bad value to use.

The sky dome output values are MUCH more relevant (ie, the colour the sky and sun are rendered). They are what we actually SEE, and so what we expect our scene to respond properly to. Ie, if we set a sunset scene, and pump the sun intensity value up high, the specular stays the same intensity, because the sun diffuse and sun intensity are separate values. The light the sun imparts on the scene diffuse is quite independent from what is rendered in our Racer sky, and what is technically really generating the speculars we need to see!

Also, incident intensity on any given surface that generates soft reflections (what we use specular for), are the function of the sun intensity AND environment intensity. Ie, the glow of the sky may impart a great deal more energy into a soft reflection, thus meaning it could be higher than Racer is currently going to allow it to be.

I honestly think the conservation of energy is a good idea, but it's just not a logical thing to add into the Racer engine since we are using too many different techniques to light our scenes and dictate the response of our scene materials.



My 2p,

Dump sun diffuse rgb and sun ambient rgb.

Those values are simply made up by us.

What we really need to do is check the envmap (every 1000 frames or so maybe?), and take the bright spot for the sun, and pass that to the sun diffuse rgb value.
Then we need to take the average value of the rest of the top half of the envmap (sky), and pass that to the sun ambient rgb.

That way, we should get the *right* values, or better values, passed to the specular energy, so that the energy conservation is done properly.
Right now the sky and reflections (sharp from envmap) will look a certain way (correct), yet the speculars will look wrong because they don't match.


Ideally, for lots of materials, we should also be using low-res cube maps (envmap mips?) for soft reflections, rather than trying to fudge the visual effect with specular.



Sorry for going on everyone. I just want to make sure every step forward is a firm footing towards improving Racer.
Energy conservation right now seems like putting a sticking plaster on a gun shot wound.
Racers specular right now are weak because specular as a technique is not so good.

I'll try post some pics tonight using a low-res envmap at sunset, to show the effect I'm talking about :D

Dave
 
OK, so a bit fudged here.

Racer's rendered sky dome always seems to be orange opposite the sun, despite that not being normal... as evidenced here in a real photo-skydome of a sunset :D


Anyway, quick explanation, this is running clouds 3.5 (so the intensity of the sky around the glowy clouds is about the same as the sun without the clouds turned on)
There is NO Racer sky coming through here, it's 100% my texture. The Racer sky looks good still if I set clouds 0, but it's just orange all over at sunset, so we don't get this lovely gradient from blue heading away from the sunset, to orange heading into it, which is what I'm trying to show off as important generally.


I've tweaked the TOD curves quite a lot, but the values are all roughly correct.

The envmap is turned down to 32, from 512

Surface reflection = 1, alpha adjusted intuitively, and fresnel adjusted to work better with this kinda rougher surface (not perfect, just quick tinkering values)



This shows the weakness of specular. Specular comes from the sun only, but we know in practice specular are really soft reflections, and since everything can reflect, we should get speculars all over.
In this case the sun is casting an orange specular at sunset, but when we head away from the sun, we should get a bluey hue to the road. That is because the road is reflecting the sky, but a soft reflection, and 'specular' reflection.

We can't do this effect because we don't have a soft reflection to sample (well we do, the envmap mip map would work ok)... ideally we want cube-maps but anyway.
Note: Look how nice alloy wheels look with a soft envmap too, we really REALLY would benefit from being able to use a mip-offset on the envmap to pick a "softer" version for lots of materials!!!


In theory this also applies to car dashboards for example. At sunset my fairly flat matte looking car dashboard is orangey heading into the sunset, and bluey heading out of the sunset. Again, the only way to achieve this is to have a reflection of what is actually generating the scene light, which is the sky!

A downside is that in the shadow we get the sun reflection still, but we could perhaps have two low res cube maps generated.
Say pick a coordinate near the middle of the track at say 50m high. Generate a cube map at that location every 1000 frames or when TOD is updated.
But, generate a cube map with sunny=1 and one with sunny=0. Then use the sunny cube map everywhere except in the shadows. Sorted. No sun specular in shadows... I think :D


Maybe the effect in my video is a bit over-done, but it shows quite nicely that specular is a function almost purely of the environment, NOT just the suns diffuse colour. It is impacted by the mie/rayleigh, sun intensity value, and the clouds, and the sky colour/intensity too.


I think it'd cost very little to actually implement this kind of system and dump the old specular totally.

Perhaps even think about using the cube maps to IBL the cars themselves, to get us away from the ambient/diffuse values we input for the sun too!
Then everything is driven purely by the sky map itself, which is ultimately how 'real life' works too, when it comes to scene illumination anyway :D

Dave
 
Good points are that the dials are now properly round if you run widescreen resolutions, yay

In surround gaming resolution, that isn't the case, don't forget to mod your views.ini file with aspect = 0.
I don't think it should be shown or tweaked since it's already set in racer.ini....waste of space & time...
It should be automatically handled by the source code.

I agree with you about the shading problems actually occurring here...seems messy atm
 
I kinda agree, I've never understood why it was never all automatic.

If for some reason your ran anamorphic pixel displays, then you could correct for it with the relevant setting anyway.

In any case, it's nice that they are round after all these years. It's funny, they almost look too tall now I am so used to them being too wide haha!
 
Hi Ruud

Forgive me if this question has been asked before, but is this excellent game still being developed or updated for Mac OS X? I have downloaded a Mac version from 2008, and notice the version number for the above Windows version is higher.

Still a superb experience driving a Honda Civic at 120 MPH!

Peter Fludde
 
cheers Ruud, the game is really coming along, i dont understand anything you said..or any of the technical sides of things..but the cars look alot better now, they look more "real" and less cartoonish, not really what i wanted to say..but then again i'm not tech smart when it comes to explaining what i mean..i guess you get a more metallic look about them now..

can i offer you this one thought, maybe with your "modeler" the "template" shader thing that it spits out, could be a bit more "organised" instead of lines and lines of text, ie it could "spit" out an actual "shader file that looks like ones created by 3rd party modelers do, created by the settings in your program..again not explaining it to well...
 
Haven't worked out all the shadow problems yet. Cars will need to be updated with the car.shd file redone to include the shadow command for each shader I guess. Haven't changed racer.ini to test.

I get two 1282 errors in my Qlog file, why?

Overall a good update Ruud, thanks and Merry Christmas.
 

Latest News

Are you buying car setups?

  • Yes

  • No


Results are only viewable after voting.
Back
Top