Ambient occlusion, is it possible?

[Some1]

Very nice work. However, I was hoping for a lot more ambient shadows under the car. But it only seems to work around the wheels... what gives?

 

[Mr Whippy]

Nice work Stereo.

I'm struggling to make it work here though, I guess like you said I need to use the shaders globally because you've changed stuff around!?
I'll have a proper play later.

As per the tuning params though, I guess that is where a test scene will be useful. Ie, take pictures of some matt white or grey boxes on a really overcast day and then take the values from the flat sides vs the corners between the floor and the box, and the falloff etc

No I haven't done that, but can if people want some reference?!

Rebuild that scene in Racer and then match it?

Dave

 

[Ruud]

@Stereo: you could abuse the velocity map I guess. That's an 8-bit RGB(A?) map where it stores velocities.
- enable velocity_map
- modify the motion blur shaders (motion_blur_v.cg/motion_blur_f.cg) to output normals instead of velocity.
- in your fs_filter shader, you now get normals instead of the velocity.

It's a bit ugly this way, but doable.
Also, don't you need a position buffer? (3D XY positions in view coordinates)

 

[Stereo]

Very nice work. However, I was hoping for a lot more ambient shadows under the car. But it only seems to work around the wheels... what gives?

There's definitely a problem with the algorithm there - polygons facing the camera get sampled much better than ones that are close to perpendicular (where half the sample points are 'behind' due to being chosen from a circle in screenspace) so only the more extreme shadows end up visible. For some reason, polies facing left are also sampled better. (merits further investigation)

I'll have to think about what to do. Really the sample points should all be coming from the halfspace the normal's pointing at, sampled randomly, and the GI/SS tutorials discuss this, but don't cover the math involved in actually doing it.


@ the position buffer, yes. I faked it :/ pos.xy = pos.z*uv.xy*viewingangle

 

[Mr Whippy]

I guess if you project samples only towards the camera then you get double the image quality or reduce FPS cost by half.

I suppose the danger then is halo effects possibly!?

All a bit beyond me when it comes to writing a shader for it. I get the mechanism but that is about it... usually I just press a button in my mental ray shader and sit back and let it go for a few minutes per frame haha

Dave

 

[Stereo]

So I changed the position calculation a little (since the way I did it wasn't accurate) and managed to tune it a little better, although still not based on any measurements of reality. The depth map should have 2-3 free channels still, it could be converted to a position map perhaps?

I think fewer samples is enough within context - the extra samples are only really visible when looking directly at the AO map. (still faking this in GIMP)

The lower screenshots are at original resolution, you can see some of the non-random patterns, in that certain lines are lighter, which are due to keeping the axes orthogonal probably. Which may be saving some computation time - will need to do side-by-side comparisons to be sure.

 

[Stereo]

@Stereo: you could abuse the velocity map I guess. That's an 8-bit RGB(A?) map where it stores velocities.
- enable velocity_map
- modify the motion blur shaders (motion_blur_v.cg/motion_blur_f.cg) to output normals instead of velocity.
- in your fs_filter shader, you now get normals instead of the velocity.

Trying this now, it doesn't seem like velocity map is getting an accurate normal though.
To test it I pretty much just pass the number through
motion_blur_v.cg
OUT.N = IN.normal;
motion_blur_f.cg
outColor.rgb = IN.N;
fs_shader.cg
fout.col.rgb = tex2D(normalMap,vin.tc0).rgb;

What I get is (0,1,0) for objects in the scene, (0,0,0) for the sky.

When I do a similar test with the position, I do get the correct position map of the track, but the car's not present. Hrm.

 

[Mr Whippy]

Looking good Stereo, it's improving from implement to implement

The lower sample AO looks good to me too... in practice *if* we get a nice motion blur working then most of the time we won't see the noise etc any way as it'll be blurred away.

When we stop, fair enough it'll look noisy, but we can always run 'photomode' to fix that (crank loads of settings up for nice pictures)


I wonder if we could, as per interior cams having unique shadow parameters, have unique AO parameters for use when in the interior view!? Perhaps we may be able to optimise better for each situation better just like we can with shadow maps??

Hmmmm

Dave

 

[Stereo]

I was a little intrigued, figured I'd see how few samples I can get away with.

Here's 4 samples:

2 samples:

And only 1 sample

Slightly surprised just how well the algorithm degrades. There's definite banding at the 1 sample level though, so I may have another crack at the random-direction function (remembered the Box-Muller transform, leveraged it. Random texture's probably the way to go though).

As far as I recall, because position vectors already have one component rendered (depth) and normal vectors are on the surface of a sphere, the velocity map would be enough to put both in near losslessly - rg position, ba normal x/y, reconstruct normal's z as sqrt(1-x^2-y^2). Loses the sign, but it's pretty safe to assume all visible normals are facing the camera...

 

[Some1]

I was a little intrigued, figured I'd see how few samples I can get away with.

I would be interested to see some maxed out screens as well, for contrast How about 512 samples?

 

[camsinny]

I would be interested to see some maxed out screens as well, for contrast How about 512 samples?

When I implemented that AO technique I mentioned on another page I decided to see how it would go if I maxed it out.

128 samples crashed my 2 GTX580's. Whoops.

 

[QuadCoreMax]

Nice stuff Stereo, as always...

Will try to bake AO maps too, your images results are great !!
Keep it going

 

[Ruud]

Trying this now, it doesn't seem like velocity map is getting an accurate normal though.
To test it I pretty much just pass the number through
motion_blur_v.cg
OUT.N = IN.normal;
motion_blur_f.cg
outColor.rgb = IN.N;
fs_shader.cg
fout.col.rgb = tex2D(normalMap,vin.tc0).rgb;

What I get is (0,1,0) for objects in the scene, (0,0,0) for the sky.

When I do a similar test with the position, I do get the correct position map of the track, but the car's not present. Hrm.

I see indeed (got a Green & black picture here as well). Turned out the motion blur pass is disabling normal passing to the shaders. I've turned that off in the racer.exe at http://www.mediafire.com/file/8vvfil563vd4xbi/rr090rc2.7z

That gives me the right normals. The indeed, just keep motion blur velocity in R and G, put the normal.x/y in B and A. Then in fs_shader.cg, regenerate normal.z using the sqrt option. This prevents an extra pass just for the normals. Not sure if the cars get there though, they seemed to be turned off for the motion pass, hm... But it should work on at least the track.

EDIT: hm, it seems motion blur velocity is stored in 4 channels, to get 16-bits per velocity axis (R+G=16 bits so 1/65536 accuracy). So all channels are already in use. Velocity might need only 8 bits though, but this may require tuning of the range that the 0..255 value represents. Alternatively, I could make the motion blur FBO an RGBA half-float variant (not 8-bits RGBA but RGBA_16F).
I also see that R & G are not really 16-bits of resolution, but rather R stores positive movement and G stores negative movement. That doesn't make sense, the bits can be used much more efficiently; now it's like 2x 8-bits so 512 levels, pfff.

(changelist for that racer.exe / v0.9.0 RC2:
- Added resolution parameter for motion blur shader (motion_blur_f.cg). Requires vsync=1 to work reasonably well.
- Reverted SMD camera up orientation, since it sticked to up even if the car was rolling.
- Added 'uniform float2 resolution' parameter for Cg shaders. Used in the motion blur shaders.
- Added theoretical sprung mass weight distribution under Ctrl-9, see also http://www.racer.nl/index.php?jump=reference/carphys.htm#bodymass
)

 

[Mr Whippy]

1 sample would probably look good with the random map and motion blur (while driving around etc)
When you stop it'd probably look a bit iffy, but then 2 samples looks great...

I'm guessing the hit for 2 samples is pretty low too which is cool!


This is all feeling very much like working AO AND working motion blur may be coming along soon!?

Yay

Dave

 

[Stereo]

With RC2, using the velocity map (and yeah I shoved the velocities into red/green channels by taking 1 bit away so they vary from -128 to +128 in a single channel)

And after fixing a rounding issue when loading the velocity map...

This is now contained entirely in the FS + motion_blur shaders. Needs to be re-tweaked though, I was messing around last night and lost the optimal settings.

The only place it's actually visible is along the barrier :/ Not great for a 50% fps cut.

Since the velocity map doesn't render the car, the car's normals also are no longer correct. And the xtrees are rendering badly because their texture's transparency isn't used to cull them in the velocity map, so they end up affecting the normals of anything they're in front of. Still, progress.

 

[Ruud]

It's very subtle currently. ;-)
The velocity map not rendering the car is since 'modelMatrix' isn't used in motion_blur_v.cg. Drive to the track's origin and you'll see the car appearing there. Fortunately it's simple to fix (in motion_blur_v.cg):

  // Transform previous and current pos to eye space
  //float4 inCoord=IN.coord;
  float4 inCoord=mul(modelMatrix,IN.coord);
  float4 P=mul(modelViewProj,inCoord);
  float4 Pprev=mul(prevModelViewProj,inCoord);

So the inCoord must be transformed with modelMatrix. This fixes the car's position. I also needed to transform the normal:

OUT.normal.xyz=mul(modelMatrix,float4(IN.normal.xyz,0));

This then gets me the normal in world coordinates in the velocitymap.
The tree's not cutting through their alpha is the same problems as with projective lighting (the headlights). I must code the same thing there, where the texture of layer0 is still passed for alpha testing. Right now, I don't think the texture is passed and it's not possible to alpha-test (and 'discard' the pixel in motion_blur_f.cg). I must modify racer.exe for that though.

EDIT: those change above still give faulty velocity info for the cars though. Probably something with the previous MVP (modelViewProjection) matrix that isn't right for moving objects.
I've already adjusted the current motion blur shaders to use only R and G now. Have no time left this week though to go further.

 

[Stereo]

EDIT: those change above still give faulty velocity info for the cars though. Probably something with the previous MVP (modelViewProjection) matrix that isn't right for moving objects.

Well, if it needs the modelMatrix to get into the current position accurately, it'd also need the prev modelMatrix to project where it used to be.

I don't think this is a necessary feature of 090f, no rush. Would be nice to have it working, though.


motion_blur_f does have access to texunit0 (during the process of testing what worked I tried painting it in the velocity map - http://i.imgur.com/PudQA.jpg ) but I wasn't sure how to do the alpha test there, unless it's simply to threshold off and write alpha=0 only on pixels that shouldn't appear. Will defer to your experience.

That reminds me - is it possible to standardize the location of normalmaps (eg. to layer2) and add a parameter to the fragment shader that says whether it's present, based on tangents=? motion_blur_f can see other layers if they exist, but it's not being called directly by the .shd so there's no way for it to discriminate between normal maps on layer1 or layer2.
Once that's there it's fairly easy to add texture tangents to the normal map by copying the normal calculations out of dyn_standard_bump, plus the final mul(float3x3(modelViewProj),N)

 

[Ruud]

Standardizing the layer for the normal map might be tricky, since not all shaders may require at least layers. You generally have:
- simple shaders (1 diffuse texture)
- specular shaders (diffuse+specular map)
- normal shaders (diffuse+normal)
And reflective variants. You would say this would put a normal texture in layer1 always, hm.

On the normal regeneration; I modified the shaders to output the normal.xy coordinates. Now to get the Z back in the fs_shader my initial attempt was sqrt(1-x^2-y^2), but that always gives a Z>0, which is only valid for one half of the dome. Any idea how to retrieve the sign of that 3rd coordinate?

 

[Ruud]

I'm uploading a full v0.9.0 RC3, will be in a separate thread. That contains my revised shaders, which stores velocity in RG and the normal in BA. In bloom_shadows_blur_f.cg you can turn on #define DEV_SHOW_NORMALS to get a look.
Hopefully you can get the normals right and squeeze in the AO in realtime.

 

[skybh]

Hi, i was wondering, when the AO will be aviable for Racer?