A thought: ssbumps as a replacement for AO bake?

[Pocket]

All the improvements Valve has been making to the CSGO engine lately got me to thinking a lot about rendering tech. And one idea that popped into my head was the potential for self-shadowed bump maps to be used as a substitute for baked-in ambient occlusion.

Let me give you an example: the ever-popular Gorge crate.

It consists of six flat sides criss-crossed with various single planks. The AO bake of one side looks roughly like this:

(anyone else weirdly reminded of the Errant Signal title screens?)

Anyway, the idea is to create a "fake" heightmap underneath where the slats go, and then use that to generate an ssbump map, which might look something like this:

The issue with this method is that ssbumps on models aren't actually supported. See, in Source, brush faces and models use different methods to implement bump mapping; Source's is something called "Radiosity Normal Mapping", and among other things it's the reason why we can do cool stuff like this...

...where the light direction in the bump map changes from one luxel (that's the technical term for a pixel in a lightmap) to the next. But the normal maps in models are lit using a simpler method.

Until now, that is. One of the changes they made to the CS:GO engine was, quote, "upgrading the lighting of our normal mapped static props by implementing full, per-vertex lighting that uses the same radiosity calculations as our lightmaps do." While this probably means that ssbumps on models is not, as such, currently available (I don't have CS:GO myself or I'd test it right now), it would probably be an easy feature to add.

This is significant because, for all the improvements Valve has been making, Source still does not have true real-time ambient occlusion and continues to rely on the baked-in kind. Thoughts?

 

[worMatty]

So the vertices in the props would use directional lighting data, as opposed to just measuring the light received. They would then use this with a prop's normal map to create fine detail shading on the materials that takes in to account the direction of the light source. Is that right?

It would be great to have another prop shading option. I think the AO used in TF2 models is as much to do with the art style as it is for emulating finder shading detail. Our props are somewhat simpler and flatter, but I don't know if that's by design or due to technical limitations, or both.

The normal map you created seems odd, to me. It looks like its purpose is to bias shadow to the right side of the slat, and to the lower left. I'm not very experienced with them or modeling, though.

Hypothetically, if TF2 were rebuilt in Source 2, and every prop had dynamic shading, if you were to move a barrel crate through the world, would you still want a little bit of baked AO to give it a cartoonish style? Does it help readability from a distance, because of its ever-present subtle contrast between its component parts?

 

[Pocket]

The normal map you created seems odd, to me. It looks like its purpose is to bias shadow to the right side of the slat, and to the lower left. I'm not very experienced with them or modeling, though.

Are you familiar with how ssbumps work, compared to traditional normal maps? Because it sounds like you don't, but I can't tell. Basically it's a way to make bumpmapped textures cast directional shadows on themselves when lit from grazing angles, without using any additional texture data. The first diagram in the SIGGRAPH paper I linked does a good job of showing the difference in-engine, and the third page compares the raw textures involved. The gist of it is that the hue is mapped to the angle (similar to that ring in Photoshop's color picker), rather than using the R, G, and B channels to represent anything in particular, so no, there shouldn't be any bias. I used this thing to generate the image from a pure monochrome heightmap.

 

[hutty]

Source still does not have true real-time ambient occlusion and continues to rely on the baked-in kind.

I completely forgot I had my nvidea control panel forcing ambient occlusion onto tf2 for the past year.

 

[worMatty]

No, I'm not clued up on ssbumps but after reading up a bit more I think I understand, now. The red, green and blue in your example image don't each influence the shading directly, in place of AO baking. Instead, they are used for self-shadowing if the light source is shining onto the face from the direction they are associated with.

So if the light source was above and to the right of the face, the green colour would be used most of all for self-shadowing, casting shadows downwards and to the left. And so on with the red and blue from the lower left and lower right, respectively. I think.

In any case I would very much like to see the same kind of bump map shading used on props that is used on brush faces. I expect this would mean that every qualifying prop would have to have its own lightmap(s)?

 

[Pocket]

It shouldn't. The improvements Valve made to the prop lighting in CS:GO sound like they're per-vertex instead of per-luxel; they never said you need to enable lightmapping in order to use it. I'm not even sure lightmapped models are a thing in CS:GO yet.

Again, I really need to snag me a copy of that game so I can play around with the editor. I have so many experiments to do.