pssm material allowance

[fidoj]

this allows pssm to work on terrains with 6 materials. for backwards compatibility.

the problems stem with limiting the blend maps, this can cause some uneven material edges.
this needs to be discussed and balanced.

[ohlidalp]

Heh, to be honest I lack knowledge in this area. My thoughts/questions:

• where does the initial freeTextureUnits = 16 budget come from? Doesn't this differ based on HW?
• I didn't even know you can share/divide/whatever texture units like this...
• // each layer needs 2.25 units (1xdiffusespec, 1xnormalheight, 0.25xblend) < --The comment suggests a "texture unit" is a 4-channel "RGBA" storage. "diffusespec" means RGB=diffuse, A=specular; "normalheight" means RGB=normalmap, A=heightmap. Using 0.25 of a texture unit makes sense to me - we simply use 1 channel out of 4. But 0.16 of a texture unit? To use 0.64 out of 4 channels? I'm baffled.
• Anyway, we could drop the "height" portion of "normalheight" texture - the heightmap is only useful for parallax mapping and may be used for improved texture blending - but we do none of that.
• AFAIK the usual solution for limited number of terrain material layers is to partition the terrain into 'pages' - each page is a separate mesh and can use different materials. OgreTerrain supports it but it's currently broken in RoR - when me&Ulteq optimized terrain collisions, we dropped support of it, we always read from page(0,0)
• I'm about to port to OGRE 2.1+ this year, and that's a completely different beast when it comes to material/textures/shadows. Current OGRE 1.9 is outdated and slow. Improving gfx at this point isn't really worth it IMO. Also, OGRE 2.1+ doesn't have OgreTerrain - we'll need to port it ourselves to maintain compatibility, or code a similar sollution. There's a 'Terra' sample terrain for OGRE 2.1+. Also, there's no pagedgeometry/batchedgeometry anymore because it's not needed - DirectX11+ and OpenGL3+ don't suffer from the draw call overhead which motivated the geometry batching.

[fidoj]

i read it as a shader limit, it allows 16 layers at 2.25 layers each 7.5 textures, the blend maps when generated are half maps that are stored, they become a physical media and use layers. the 0.16 is 6textures*0.16 0.96 (as close to 1.0 without 0.166666666666666667), remember when its a limit rounding up will result in a failure 0.17 1.02.
i wrote a post on one of my forum threads saying im excited of where ror is going, if you are going to release a new stable with based on current code, this could help with some of the its broken BS that's going around, i want to help you with what i have, this is a hack, i tried to change the integer to allow more layers (but im hacking it not coding it)

[fidoj]

normal height is bump mapping. im using that on my rdesv3 map
all of the detail about the speedo is normal mapping
i dont think dropping that is wise. another solution since shadows are a blend hows about making it so shadows uses a space of 0.5 textures. inverse to what ive done with blend.

[ohlidalp]

@fidoj I absolutely wasn't suggesting to drop normal mapping, it's possibly the most important basic shader effect to date - cheap and extremely visually appealing. 😄

However, there really are data we don't need. The "normalheight" actually carries 2 separate image maps, just like "diffusespecular":

• RGB = normal map, does all of normal mapping.
• A = heightmap. Usable for "bump mapping", but we don't do that. Also usable for parallax or blending, but AFAIK we don't do that either.

Also, bump mapping and normal mapping are 2 different techniques to archieve the same result, although majority of internet resources (including high profile engine docs) confuse it:

• Normal mapping is a technique where surface normals are encoded into colors: a color value of 0.0 - 1.0 maps to angle -90 - +90 degrees; RGB components read as angles along XYZ axes (order may be different).
• Bump mapping is a technique where normals are deduced from a grayscale heightmap by comparing values of neighbour pixels. Older technique - less resource demanding, but less accurate.

EDIT: Allright, maybe I got it wrong, too. Perhaps "bump mapping" means any sort of simulating rough surface via manipulating normals, and "normal mapping" is just one way to archieve bump mapping. But my point stands: You don't need both heightmap and normalmap to do it.

PS: Hacking instead of coding is great, keep doing it! It very often provides interesting insights.

[ghost]

Should this be merged? It's kind of a "hacky" way to fix the issue, but it works.

[ohlidalp]

@Michael10055 If it works, then it should be merged. I'm currently unable to test enough myself to detect possible issues. Also, I don't really understand how it's working, I need to ask on OGRE forums to be sure. However, if you say it works, then I guess it works.

I'm merging now. If it causes issues, we can always revisit it and make it configurable in terrn2 or revert it.