Spring RTS Engine

Tobi wrote:Besides this, a quick glance at the code indicated it is using bump mapping, and not normal mapping, which means one splat can be handled entirely by one texture unit (RGBH).

jK wrote:SM3 doesn't use normalmapping yet

Now I did some more work on SM3 it appeared it does normal mapping, and not bump mapping; my initial assumption was wrong. (blame the useBumpMaps variable )

More precise, it does blending of 3 component normal maps, and normalizes as last step, right before using the normal in lighting calculations.

So, it does need the TBN matrix (or at least it needs to use a different matrix solution, or the lighting angle's jacked, or something else). The resulting specularity looks like my early attempts to get normalmaps working before Kloot put that in.

As you can see in this screenshot, the results are wrong, vs. the Unit, which uses the TBN matrix. It's not that they're inconsistent or bizarre- they just aren't using the right matrix for the lighting calculation. I'll let you graphics experts argue about why exactly.

Stop mangling terms, TBN matrices are only needed for tangent-space normal mapping (which my shader does). The SM3 shaders do not operate in TS.

As I said, IDK what's causing the error. I'm just pointing it out, it causes other problems, but mainly it causes a fair amount of visual discontinuity with other stuff. It puzzled me why it would be doing that, the overall per-fragment lighting appears to be all right- but it's actually wrong, you can see it on the reverse sides of slopes where it's darker but not in shadows pretty clearly.

Stop mangling terms, TBN matrices are only needed for tangent-space normal mapping (which my shader does). The SM3 shaders do not operate in TS.

Yes they do. In QuadRenderData.cpp line 182 it builds the TSM as part of the vertex buffer, and in terrainVertexShader.glsl at line 72 it transform the world space light dir (wsLightDir) to tangent space which is passed to the fragment shader.

The Light function in the UseBumpmap section in terrainFragmentShader.glsl at line 66 uses the tangent space light dir to compute the final color.

WTF

You know you don't need any stupid matrix for normalmapping when you have a continuous uvmap/planar plane?

Edit: Sorry, but the more I know about sm3 the more I think it is helpless to fix it.

A heightmap is not a plane.
If you take the normals from the textures as if they were world space normals then it would look all weird on a slope.

Maybe you're thinking of converting the heightmap terrain data into a normal map. Then you don't need the TS matrix, but I tried this approach once and it doesn't look that good. The geometry is not really the bottleneck anyway as it in static vertex buffers, so you can render enough vertices that the terrain looks good without a 'heightmap normalmap'

To be fair, many engines do take the approach that terrain base normal (wrt. normal maps) is a global constant. The idea is that you're supposed to bake the normal of the poly itself into the normal map. Personally I don't like the approach, but I can see how it's more efficient.

Baking polygon normals into the normal map is only possible when every texel corresponds to a unique world space point (so no tiling), for example when rendering static meshes.
So to be fair, don't talk when you don't understand it :/

Baking polygon normals into the normal map is only possible when every texel corresponds to a unique world space point (so no tiling), for example when rendering static meshes.

IOW, Lurker's "on-site built" map concept would be a good use for it. Although since I know how long that takes in L3DT (which is why I brought up the whole SMF 2.0 idea, you can build whole-map normalmaps with detailmaps in it) it may be asking for more trouble than getting the TBN matrix.

Nice to know that I've actually learned a few things, though.

Oh, and here's another idea.

Lurker... what if a SMF 2.0 was composed of tiles? I.E., instead of the crude optimization used now, something totally explicit?

Mappers would use tiles that are powers-of-two, it's up to the mapper to define areas covered by them, so some areas of a map could be very optimized (at the obvious cost of a certain blockiness, that could be hidden by big tiles for organic areas such as hills)?

Wouldn't that save terrific amounts of memory and greatly reduce download sizes? I suppose that some sort of fix would be necessary for the joins, to prevent seams, but surely a zone 8 pixels out on either side could be blended, or something?

I know that mappers that want giant terrains that are whole-mesh worlds would be unhappy with this, but I thought I'd throw that out there, it'd solve a lot of problems- amongst other stuff, we mappers could build and trade tiles... and SME could be converted to use that pretty easy, since they already have the prefab idea working.

Argh, coding and making maps into that format sounds like a fucking nightmare. It would create a billion different problems while looking ugly on lod boundaries.

If anything, we need to make texturing of maps simpler than it used to be, and sm3 is the right track.

I'm not saying it would be a panacea, just an option we haven't looked at. Coding it wouldn't be the problem- the final maps would be SMF 2.0. I'm talking about pre-assembly.

And SM3 is *not* easier to build, if you want it to perform well and have anything past a really basic 3-tileset map. Having to carefully set up multiple blendmaps that don't overlap each other is not fun.

Oh, I suppose it's "easy" in the "lazy" sense, as in, "gee, any lazy mofo can make a map that looks all right". But "lazy" maps in SM3 will run like crap, and I don't like the idea of a map format where the typical mapper, who, let's face it, is usually pretty lazy (go look at the bazillions of crap maps on jobjol) will make stuff that performs terribly on a regular basis. At least with SMF, even if it's a tile-extravaganza with all of the skill of a four-year-old involved, it still runs at the same speed everything else does.

If you assume we're all using supercomputers and it doesn't matter that your test map runs at 20-30 FPS on my hardware, sans water, fine, I suppose that's something we can agree to disagree about.

I fixed my testmap to run with normals, so now its down to 1/3 of my previous fps :)

Yeah, I know, I've been using normals from the start. It's pretty bad, and the only way to mitigate it is to avoid multiple blend layers. I've figured out a way to do that fairly well without it being a mind-numbing process, thank goodness.

I know bugger all about coding to be honest, but some people might find this interesting:
http://www.moddb.com/games/overgrowth/n ... l-textures
It explains how a mix of detail textures and normal maps were used to create terrain in Overgrowth. Looked a nifty implementation...

Their technique's pretty interesting, honestly- it's like a blend of SMF and SM3, using what looks like a distance-based formula for applying the detail maps.

So, is that worth talking about? SMF, just as it is, but using a semi-automatic closest-match system to apply detail tiles with normalmaps on near polygons? I mean, I can see writing a nearest-match system in the GLSL, or just doing it for every heightmap square at runtime, and storing the results...

Hell, maybe I should get off my lazy ass, and finish that normalmapped version of jK's LUPS groundscars I wanted to write. Then we could test this concept out without a new map format. I don't think I have time before release, though

You can make tiles right now that will work perfectly if they are divisible by 32, barring bugs in mapconv.

Here, lemme try to explain better, with a picture:

At a distance, we'd be seeing the tiles. We could have a SMF format where the overall resolution went down by 1/2 or even 1/4:



Up close, each would turn into a normalmapped tile, using an alpha channel (unless it's the base level):


Black is base-level, ofc.

So, basically we'd have a two-stage LOD system, and most of the time players would see what's in the second shot (only more tiles would be defined, etc.

Anyhow, just a crazy idea I had, just trying to see if there are any alternative strategies. This wouldn't allow for the rich, organic blending I'd like to see, ofc, but it'd probably be fast.

Okay, I'm not a graphics coder, but what is the actual drawback of SM2 besides how it fails on steep slopes? To me, the obvious approach for a map textures would be simply using a list of non-overlapping rectangles, each with an arbitrary-resolution rectangular image (32x32 multiples for tiling, and aspect ratios don't need to match), where the corners must correspond to heightmap vertices. It would be backwards-compatible with SM2, but also allow workarounds for SM2's flaws (like having lower or higher res available when you need it). That ensures no need for blending, but also lets you use an resolution and stretching you like (including using a very narrow rectangle with a very high-res square image to put onto a cliff-face).