Racer v0.8.29 released!

Ruud · Dec 31, 2010

For a happy New Year, v0.8.29

Get it at http://www.racer.nl/download/racer0.8.29.zip (75Mb)
** BEFORE using, set racer.ini's mastervolume to 255 to get a bit of sound

Changelist:
- Added surface 'forbidden' field (in special.ini); if set to 1 (default=0) it will reset your
car to the road if you set racer.ini's assist.time_allowed_offroad. See http://www.racer.nl/reference/tracks_surfaces.htm
- Car and track version checking is now updated to '090'. If your track/car doesn't match this
compatibility info, you'll get a warning in QLOG. All content must be updated!
- Autoclutch RPM now only really hunts for max torque in 1st gear. Other gears are the old way (more subtle).
- 'Ini' tool can now modify references ('ini wheel0.pacejka pacejka_front' for example).
- Clutch mechanism revised since some clutch-controlling subsystems (gearbox/anti-stall/controls)
would not mix correctly, giving hard jerks when shifting up/down.
- Added dbg_car.max_brake_reduction (=0.2) which determines the minimum brake torque reduction when wheels stop spinning.
- Added car.ini engine.launch_control to specify autoclutch_rpm=0 behavior in 1st gear.
- Added X-tree shaders for nicer X-tree shading, see http://www.racer.nl/tutorial/xtrees.htm
- Cg parameters Kd, Ka, Ke and Ks (diffuse/ambient/emission/specular) expanded to pass RGBA instead of just RGB.
Not used in the Cg shaders yet though; the use is a bit unclear still.
- Minimap painting was bad when car select screen was called first. Same for mirrors.
- Minimap paint could cause statistics paint to become transparent
- Added 'graph step 0 1 clutch' option to visualize clutch behavior.
- Wheel heat shader gives more light
- View elements get lit at night.
- panorama_f.cg had a syntax error.
- Just loading a controller profile would save it if controllers were missing.
- Newton.dll is back, since that got rid of NaN errors when colliding cars with the track. It's also Newton 2.29 now.
- Added 'timing.pause_every_step' to optionally step through each iteration
- Fixed a bunch of replay sound issues (engine/horn/indicatorLeft/indiRight/hazard). Replays are now definitely
incompatible with older replays; also may change before v0.9 comes out to fix further things (gearwhine?).
- The NoCG version was giving a lot of QLOG warnings.

Ruud · Jan 4, 2011

Alex Forbin said:
Bug report:

Particle.ini startvelocity/ startvelocity_var seem to be broken.

Alex Forbin

They are overruled for many particles, such as smoke (to be dependent on a car's velocity for example).

Ruud · Jan 4, 2011

DavidI said:
One other question for Ruud or Mitch, is using texture.max_wid/hgt & texture.quality the same as physically reducing the texture sizes manually (in PS or other), or does it have some sort of FPS overhead?

It's at loading time, so no runtime performance overhead.
Note that each card has its own limitations; generally, Racer seems quite bandwidth hungry. As long as use_vbo=1, the geometry is on the card and renders quite quickly. All interactions with the card is slow (Cg parameters, lots of shader switching).

Ruud · Jan 4, 2011

Mr Whippy said:
Ruud, is there any reason a minimap and splines might not work for AI recording?

They are working fine for driving on, or not with them turned off (use mesh hits), they are working fine for resetting to the track too.
However, my minimap isn't there, and the car position icon is right at the edge of my screen and only rotates. No map is visible.

I have 1750 splines, track is point to point, re-created in latest trackEd just now, and still no minimap.

I see no problems with the minimap on Carlswood or a few other tracks here.
Perhaps it's possible if you could mail me the track without images and cache/ directory. That might be relatively small?

topdrive · Jan 4, 2011

0.8.29 doesn't run on my machine. I am running a Radeon HD4670 with 10.12 drivers. Here is the QLOG:

Code:

Tue Jan 04 18:18:36 (INFO): [noqapp/1948] --- application start ---
Tue Jan 04 18:18:36 (INFO): [noqapp/1948] 4 processor(s); setting affinity to 0xf
Tue Jan 04 18:18:36 (INFO): [racer/1948] Racer version: 0.8.29 (Dec 31 2010/13:02:57) - customer: Internet
Tue Jan 04 18:18:36 (INFO): [racer/1948] DGPUShaderManager::Init() Geometry shading is not supported on this card (ATI?).
Tue Jan 04 18:18:36 (WARN): [racer/1948]  DGPUShader:Load(data/renderer/fullscreen_shaders_hdr/bloom_shadows_f.cg):  The profile is not supported.
Tue Jan 04 18:18:36 (INFO): [racer/1948] WorldRenderer: you have an ATI  graphics card (ATI Technologies Inc.). Working around some long-term  bugs.
Tue Jan 04 18:18:36 (INFO): [racer/1948] Physics engine: NEWTON v2.29
Tue Jan 04 18:18:41 (INFO): [racer/1948] Safety changed: SAFE
Tue Jan 04 18:18:43 (INFO): [racer/1948] Loading track 'carlswood_nt'
Tue Jan 04 18:18:44 (WARN): [racer/1948]  DGPUShaderManager:MakeObject(standard_xtree_f.cg): can't create CG  fragment shader program
Tue Jan 04 18:18:44 (WARN): [racer/1948]  DGPUShader::LoadAndCreateFromFile[data/renderer/shaders/standard_xtree_f.cg]:  The compile returned an error.
Tue Jan 04 18:18:44 (WARN): [racer/1948]    data/renderer/shaders/shadowmapping.cg(168) : warning C7011: implicit  cast from "float4" to "float2"
data/renderer/shaders/shadowmapping.cg(214) : warning C7011: implicit cast from "float4" to "float2"
data/renderer/shaders/shadowmapping.cg(261) : warning C7011: implicit cast from "float4" to "float2"
data/renderer/shaders/shadowmapping.cg(269) : warning C7011: implicit cast from "float4" to "float2"
data/renderer/shaders/shadowmapping.cg(277) : warning C7011: implicit cast from "float4" to "float2"
data/renderer/shaders/shadowmapping.cg(329) : warning C7011: implicit cast from "float4" to "float2"
data/renderer/shaders/shadowmapping.cg(337) : warning C7011: implicit cast from "float4" to "float2"
data/renderer/shaders/shadowmapping.cg(345) : warning C7011: implicit cast from "float4" to "float2"
data/renderer/shaders/shadowmapping.cg(353) : warning C7011: implicit cast from "float4" to "float2"
data/renderer/shaders/standard_xtree_f.cg(111) : warning C7011: implicit cast from "float4" to "float3"
data/renderer/shaders/standard_xtree_f.cg(112) : warning C7011: implicit cast from "float4" to "float3"
data/renderer/shaders/standard_xtree_f.cg(85) : error C3004: function "float ddx(float);" not supported in this profile
Tue Jan 04 18:18:46 (FATAL): [racer/1948]  DGPUShaderManager:MakeObject(standard_xtree_f.cg): can't create CG  fragment shader program
The compile returned an error.
data/renderer/shaders/shadowmapping.cg(168) : warning C7011: implicit cast from "float4" to "float2"
data/renderer/shaders/shadowmapping.cg(214) : warning C7011: implicit cast from "float4" to "float2"
data/renderer/shaders/shadowmapping.cg(261) : warning C7011: implicit cast from "float4" to "float2"
data/renderer/shaders/shadowmapping.cg(269) : warning C7011: implicit cast from "float4" to "float2"
data/renderer/shaders/shadowmapping.cg(277) : warning C7011: implicit cast from "float4" to "float2"
data/renderer/shaders/shadowmapping.cg(329) : warning C7011: implicit cast from "float4" to "float2"
data/renderer/shaders/shadowmapping.cg(337) : warning C7011: implicit cast from "float4" to "float2"
data/renderer/shaders/shadowmapping.cg(345) : warning C7011: implicit cast from "float4" to "float2"
data/renderer/shaders/shadowmapping.cg(353) : warning C7011: implicit cast from "float4" to "float2"
data/renderer/shaders/standard_xtree_f.cg(111) : warning C7011: implicit cast from "float4" to "float3"
data/renderer/shaders/standard_xtree_f.cg(112) : warning C7011: implicit cast from "float4" to "float3"
data/renderer/shaders/standard_xtree_f.cg(85) : error C3004: function "float ddx(float);" not supported in this profile
Tue Jan 04 18:18:47 (FATAL): [racer/1948] Exception 0xC0000005, flags 0, Address 0x004FA062
(this dialog text is stored in QLOG.txt)

OS-Version: 6.1.7600 () 0x100-0x1

0x004FA062 d:\source\trunk\dev\src\libs\qlib\qdebug.cpp (line 375): QCrash()
0x004EC20D d:\source\trunk\dev\src\libs\qlib\qmessage.cpp (line 535): qfatal()
0x004141E4 d:\source\trunk\dev\src\libs\d3\dgpushader.cpp (line 788): DGPUShader::LoadAndCreateFromFile()
0x0041446F d:\source\trunk\dev\src\libs\d3\dgpushader.cpp (line 202): DGPUShaderManager::MakeObject()
0x00500B31 d:\source\trunk\dev\src\libs\qlib\qobjectmgr.cpp (line 209): QObjectManager::Get()
0x00412E6A d:\source\trunk\dev\src\libs\d3\dgpushader.cpp (line 250): DGPUShaderManager::GetFragmentShader()
0x004203ED d:\source\trunk\dev\src\libs\d3\dshaderloader.cpp (line 524): DShaderLoader::Parse()
0x0041DB8C d:\source\trunk\dev\src\libs\d3\dworld.cpp (line 473): DWorld::LoadShaders()
0x004C55D7 d:\source\trunk\dev\src\libs\world\scene.cpp (line 349): WorldScene::LoadShaders()
0x0048288E d:\source\trunk\dev_racer\src\lib\rtrackv.cpp (line 1650): RTrackVRML::LoadShaders()
0x00484778 d:\source\trunk\dev_racer\src\lib\rtrackv.cpp (line 1255): RTrackVRML::Load()
0x0042805A d:\source\trunk\dev_racer\src\lib\rmanager.cpp (line 2066): RManager::LoadTrack()
0x0054C554 d:\source\trunk\dev_racer\src\libu\track.cpp (line 120): rrTrackLoad()
0x004036E8 d:\source\trunk\dev_racer\src\mrun.cpp (line 1713): Setup()
0x0040393E d:\source\trunk\dev_racer\src\mrun.cpp (line 1925): Run()
0x00401504 d:\source\trunk\dev_racer\src\main.cpp (line 222): main()
0x00401573 d:\source\trunk\dev_racer\src\main.cpp (line 229): WinMain()
0x0055385B f:\dd\vctools\crt_bld\self_x86\crt\src\crt0.c (line 263): __tmainCRTStartup()
0x75E13677 [kernel32]: (filename not available): BaseThreadInitThunk
0x77CE9D42 [ntdll]: (filename not available): RtlInitializeExceptionChain
0x77CE9D15 [ntdll]: (filename not available): RtlInitializeExceptionChain

is there any way to make it running?

Mr Whippy · Jan 4, 2011

Ruud said:
I see no problems with the minimap on Carlswood or a few other tracks here.
Perhaps it's possible if you could mail me the track without images and cache/ directory. That might be relatively small?

I'll try email a copy later.

Thanks

Dave

Some1 · Jan 4, 2011

topdrive said:
is there any way to make it running?

Yes, the answer is somewhere in this thread.

I am just too lazy to look it up for you, because you were too lazy to find the answer yourself in the first place hehe

topdrive · Jan 4, 2011

Read the whole thread, must have skipped this little one before. Now it's running. Thanks!

Alex Forbin · Jan 5, 2011

Ruud said:
They are overruled for many particles, such as smoke (to be dependent on a car's velocity for example).

Oh, is there any way to get it working again? I swear it was working on an earlier version since I could actually get it to shoot smoke foreward if I wanted. ( A small amount combined with a little -x) I have some ideas for a new smoke shader as well.

I've been working some more on the metallic shaders.

Alex Forbin

Mr Whippy · Jan 5, 2011

Looking good there Alex.

Is it actually discrete flakes? I guess this shows that at most view distances you can't really tell if metallic is a specular splodge or lots of small reflections

Does it use a texture map to do that if it is actual 'flakes'?

It'd be cool to do it procedurally in 3d space, because quite often you do get some stretching of UVW's here and there, or scaling variations, which have come through with distorted metallic flakes... hmmm...

We deffo need specular flakes for stuff like this though, clearly visible even at a few metres

Not sure it's a v0.9 priority though

Just thinking and talking with Camsinny the other day, I think what would really help paints have some real depth is a falloff capability for the diffuse slot, so we define the facing/edge colours, and the fresnel parameters for that falloff. Then we can get the pearl effects of multi-coat paints, which are common on most modern metallic finishes.
At the extreme that technique helps do the above kind of metallic better, or TVR cascade/reflex type paints a bit more realistically, but many car paints use a similar subtle effect to add depth and lustre.
Even my old Peugeot 306 HDi was a bluey metallic, but it was almost a flat light blue in overcast conditions, but in the sun you get a metallic bloom (specular for us), and also the edges seemed to go a deeper blue, with the reverse side feeling almost mid-blue.
Just no way to get that with amb/diff and a specular right now

Hmmmm

Dave

Alex Forbin · Jan 5, 2011

Mr Whippy said:
Looking good there Alex.

Is it actually discrete flakes? I guess this shows that at most view distances you can't really tell if metallic is a specular splodge or lots of small reflections

Does it use a texture map to do that if it is actual 'flakes'?

It'd be cool to do it procedurally in 3d space, because quite often you do get some stretching of UVW's here and there, or scaling variations, which have come through with distorted metallic flakes... hmmm...

We deffo need specular flakes for stuff like this though, clearly visible even at a few metres

View attachment 33630

Not sure it's a v0.9 priority though

Just thinking and talking with Camsinny the other day, I think what would really help paints have some real depth is a falloff capability for the diffuse slot, so we define the facing/edge colours, and the fresnel parameters for that falloff. Then we can get the pearl effects of multi-coat paints, which are common on most modern metallic finishes.
At the extreme that technique helps do the above kind of metallic better, or TVR cascade/reflex type paints a bit more realistically, but many car paints use a similar subtle effect to add depth and lustre.
Even my old Peugeot 306 HDi was a bluey metallic, but it was almost a flat light blue in overcast conditions, but in the sun you get a metallic bloom (specular for us), and also the edges seemed to go a deeper blue, with the reverse side feeling almost mid-blue.
Just no way to get that with amb/diff and a specular right now

Hmmmm

Dave

I made the shader to be able to handle the Chromashift or Reflex style paints too, all you do is assign the alternate color to the specular and ambient. The reflections are picked up along with the hotspot. The hotspot fades out under bridges and trees affecting the bloom as well.
The current version is bitmapped flakes, I want to do a test on procedurals to see how much slower they are.

Here is a shot with a red basecoat and the following settings (in your studio set)...
ambient=.2 .5 .1
diffuse=.5 .5 .5
compression=0
specular=.5 .9 .2
shininess=22

Alex Forbin

camsinny · Jan 5, 2011

Indeed, JPG compression is hurting you quite badly there. For the sake of demonstration you should upload a PNG or similar.

Mr Whippy · Jan 5, 2011

That looks cool...

Not sure how it's working though

Where does the red base coat gets it's colour from, do you need to use a red base texture? (and that is what is being adjusted with diffuse= 0.5 0.5 0.5)?

Would be ideal if base maps for main paintwork were just light grey with AO burned in, and then the shader could do all the colouring etc on top... that way we can have those cool colour wheels and custom paints etc... seems silly to limit ourselves to having lots of fixed base coat colours for each car.
If thats how yours works though, all the better

Dave

Alex Forbin · Jan 5, 2011

Mr Whippy said:
That looks cool...

Not sure how it's working though

Where does the red base coat gets it's colour from, do you need to use a red base texture? (and that is what is being adjusted with diffuse= 0.5 0.5 0.5)?

Would be ideal if base maps for main paintwork were just light grey with AO burned in, and then the shader could do all the colouring etc on top... that way we can have those cool colour wheels and custom paints etc... seems silly to limit ourselves to having lots of fixed base coat colours for each car.
If thats how yours works though, all the better

Dave

The reason I use a bitmap for the basecoat is it lets us have custom multicolor paint, I figure AO will be coming in the future anyway.
Here is a larger .png, keep in mind the mapping on the car is not final so it's a bit messy in spots. This is showing the Reflex style paint with a custom basecoat. One nice thing about doing things this way is you can alter the size of your bitmap. For example if you want a whole body custom graphic just use something like 1024x1024, if you are just wanting a blue basecoat just use a 2x2 resolution.

The upper layers DO have color and can be adjusted, so you should be able to make your AO map gray and for a red just set the diffuse to...

ambient=.5 .2 .2
diffuse= 2 .3 .3
specular= .9 .2 .2
shininess=12

Here are some pngs for Cam...

Alex Forbin

Mr Whippy · Jan 5, 2011

That is cool.

BUT, I don't like unreal values, and that diffuse.r = 2 multiplication is worrying me

What rgb intensity is the base map? If the total sum of red is going over about 230, then that is rather unreal... unfortunately... I know these values are far from real to start with, but it just doesn't make sense to have values that big vs other reds in the scene etc... hmmmm...

You are deffo on the right path though, I like the idea of scaling down the map if the colour is just a generic one, and using a higher quality one for details... makes lots of sense

Only downside is no AO in the map unless we store all the maps at higher res, which just gets heavy on storage size and download size, when ultimately the data is almost the same across them all, just with a different colour overlay

I guess the issue is if we get AO any time soon, or not, which means a generation of cars without any shading... or a shed load of base textures with AO in them for each colour variety...

JUST if we could have the ability to tint that initial texture map we would be winning

I think with the success of your shader there, it's certainly something I think Ruud might be able to properly do for us for near v0.9?

Then we have ultimate flexibility with using little colour swatches, colours defined over AO maps like Cam's F458, and the ability to do these fancy colours like you have, ALL with one shader

Dave

Alex Forbin · Jan 5, 2011

BUT, I don't like unreal values, and that diffuse.r = 2 multiplication is worrying me

What rgb intensity is the base map? If the total sum of red is going over about 230, then that is rather unreal... unfortunately... I know these values are far from real to start with, but it just doesn't make sense to have values that big vs other reds in the scene etc... hmmmm...

The base color is actually blue 6,10,158. As far as to how real it is, this is using the stock TOD curves and it works well with different lighting so I just have to go with that. :wink:

You are deffo on the right path though, I like the idea of scaling down the map if the colour is just a generic one, and using a higher quality one for details... makes lots of sense
Only downside is no AO in the map unless we store all the maps at higher res, which just gets heavy on storage size and download size, when ultimately the data is almost the same across them all, just with a different colour overlay
I guess the issue is if we get AO any time soon, or not, which means a generation of cars without any shading... or a shed load of base textures with AO in them for each colour variety...

JUST if we could have the ability to tint that initial texture map we would be winning

You can still tint the base texture @1024x1024 in gray and use the diffuse and specular to color it with, albiet the colors aren't so bright.
I don't really like the idea of burning lighting into a shader since it should be done dynamically. From what I have seen SSAO would probably be a better solution anyway.

Pardon the fakey AO I just did a quick tint on a basemap of 100,100,100 but it's just to show what I mean. This might get you by until real AO comes.

I think with the success of your shader there, it's certainly something I think Ruud might be able to properly do for us for near v0.9?

Hopefully he can optimize it a bit as well.

Then we have ultimate flexibility with using little colour swatches, colours defined over AO maps like Cam's F458, and the ability to do these fancy colours like you have, ALL with one shader

The only thing about having one ultimate shader is it seems like there would be a lot of dead weight if all of the options weren't needed.

Alex Forbin

Mr Whippy · Jan 5, 2011

I think it's not so much an ultimate shader, but an ultimate car paint shader, which I guess is what many cars do need.

What you have there doesn't seem excessively bloated considering many paints have some element of pearl to them, or metallic. Only totally flat colours wouldn't really need them, but I'd argue they still have very slight elements of pearl to them, probably not enough to really see, but hey ho.

Hmmm, I'm probably confusing what your shader can do then. It sounds like you can have a non-colourised base texture, and then colourise it through the shader values, AND still get the visual effects you have shown off working too.
If you don't mind sharing it I'd be really interested even at this stage. I'm re-working the Lambo for a decent v0.9 release, and want to remove the need to have Raven variants, and just have a base map with AO in there, and tint it. The cool pearl effect would also be desireable for many of the Lambo paints.
I also want the odd paintwork with details on (I've done a UK police car livery for the Lambo which I want to be able to toggle to as well

)

Not sure I need the 'real' metallic, if the shader can degrade back so I can just use a specular splodge to do what your metallic map does, that would be cool. I don't really think the Lambo's UV's will be perfected enough for the metallic to be so good up-close for it to do the effect justice in the first place (ie, metallic specular is only seen close up, and when your close, you'll see the stretching and compressing if the UV are not perfect anyway)

Either way, well worth me having a play with if thats possible... I want the best solution to this problem, and yours so far is feeling like the right one all said and done, just like GTP's headlamp/falloff shader. It does what it's meant to do, and nothing it's not, so it must be ideal

I'm sure Camsinny may be interested too. I know he wants his F458 out for v0.9, and he has done a generic base map with AO, and is colourising via shader values...

PS, on that red issue, your multiplying 6 by 2, so it's only 12, way off 230, or 255 for that matter

Just if output values get too big (over 255 per channel in isolation, or 230 average), we are tending to get out of realistic reflectance values for materials, which generally, isn't ideal. What you have there should be spot on then

Dave

Ruud · Jan 6, 2011

Alex Forbin said:
Oh, is there any way to get it working again? I swear it was working on an earlier version since I could actually get it to shoot smoke foreward if I wanted. ( A small amount combined with a little -x) I have some ideas for a new smoke shader as well.

Why would you do your own smoke velocity? It is now dependent on the car velocity and such to get a nice movement, plus wind effects. Shooting it forward doesn't sound like an improvement.

Been working a small bit on color grading. Now per-track, although a zillion ideas are possible, but not for v0.9.

(I might call it 1.0 really, hm): http://racer.nl/tutorial/colorgrading.htm

Ruud · Jan 6, 2011

I remember BTW why those flare textures weren't mapped directly to the viewer; I had a problem with a 3rd brakelight, a wide polygon for a number of lights at once. Rotating that towards the viewer meant it started to rotate away from the real 3D polygon.
I guess it might be optional; each flare then would have a 'billboard=1' option or something.

Some1 · Jan 6, 2011

Ruud said:
I remember BTW why those flare textures weren't mapped directly to the viewer; I had a problem with a 3rd brakelight, a wide polygon for a number of lights at once. Rotating that towards the viewer meant it started to rotate away from the real 3D polygon.
I guess it might be optional; each flare then would have a 'billboard=1' option or something.

Ah, ok. Well, I would prefer proper billboarding. For wide lights, one might just use more flares (like somebody wanted to create the Audi R8 headlights that feature quite a large number of small LEDs).

Maybe making the flares do a proper billboarding by default and one could overwrite with billboard=0 would be a better solution?

Alex Forbin · Jan 6, 2011

Ruud: Why would you do your own smoke velocity? It is now dependent on the car velocity and such to get a nice movement, plus wind effects. Shooting it forward doesn't sound like an improvement.

Been working a small bit on color grading. Now per-track, although a zillion ideas are possible, but not for v0.9. (I might call it 1.0 really, hm): http://racer.nl/tutorial/colorgrading.htm

I was using it to hide the smoke popping in. I found if I gave it a little base movement to the front and across the car it looked good at slow speed but would still hide the initial pop-in of the smoke. Eh, Oh well.

The new colorgrading looks interesting, I don't know what all it can do other than recolor the image but I'm always up for new toys.

Alex Forbin