parallax mapping bugs

[illwieckz]

I noticed yesterday that XreaL had working parallax mapping, I know Darkplaces (used by Xonotic) has it too. What's missing to have that effect in our maps?

• [ ] ship height maps
• [x] automatically discover height map in normal map alpha channel
• [x] fix the reversed height map bug
• [x] support parallax offset

[DolceTriade]

We had (have?) it too. But it was SUPER expensive and no one could use it. In order to use it, we'd need to generate an additional height map for each of our normal maps I think...

[Viech]

I recall there is a texture shader keyword that needs to be set in order for the effect to appear. Not sure if height maps needed to be included.

[illwieckz]

So, after investigation, I discovered that Dæmon engine…

• requires height maps (there is no magic computation of height map from normal map at run time)
• expects height maps to be stored in alpha channel of normal maps
• requires a special keyword to be set in shader before the normalMap stage, this keyword is named parallax and would have been best named heightMapInNormalMap
• does not know how to load height map that is not stored in a normal map alpha channel

So, to get parallax in game we need a lot of work to do, but that's possible.

I discovered that 2010 edition of XreaL shipped height maps for ex texture set (as external files) and trak5 one (in normal map alpha channels), but better than that, I discovered that xonotic ships height map for almost every texture they ship, including pk01, pk02, trak5, ex… 99.99% of their height maps are stored in normal map alpha channel, without requiring shader keywords. Some rare files (less than 10 in their xonotic-maps pk3) are stored as external files.

But another great news, they have code (GPLv2+) to generate height maps from normal maps, in three stages:

• makenorms.sh
• fft-normalmap-to-heightmap-soft.sh
• fft-normalmap-to-heightmap.c

So, what we can do:

• import their height maps
• compute the others

What could be good:

• not requiring any shader keyword to guess the availability of an height map in a normal map file
• optional heightmap loading from dedicated file, perhaps by merging the height map to normal map alpha channel in engine so the internal representation is kept

So, it requires a lot of work, but we can do it for Unvanquished.

[illwieckz]

Quote from #159:

Note that since Xonotic ships a heightmap with almost all its normalmap, I enabled temporarily parallax on all shaders just to have a look. It works (and I haven't experienced preformance issue) but I discovered that xonotic heightmaps are upside down, or our engine is.

Perhaps it's a trick to not have to detect the presence of heightmap hidden in alpha channel of normalmap, as a missing alphachannel would mean a flat surface at the good level. Currently our engine displays a flat surface at the wrong level if we enable parallax on a normalmap without heightmap in alpha channel.

Since we never shipped heightmap file, we are at a redemption time allowing us to change the heightmap orientation in engine if it's more clever to do this way.

[illwieckz]

If I understand things well, according to the way a height map is stored, in one case black is up and in the other case black is down. In Dæmon the lack of alpha channel in normal map (storing the height map) produces a down height map, if heightmap was expected upside down, I guess a missing alpha channel in normal map would produce a up height map. What do people think about it? :thinking:

@gimhael @cmf028 @Amanieu @kangz any knowledge to share ? :smiley:

[illwieckz]

Setting r_parallaxDepthScale -0.03 displays parallax correctly, as an additional proof xonotic's height maps are reversed (or Dæmon engine is):

It proves that parallax works in engine if height maps are correctly provided, I see no performance issue.

[illwieckz]

more sreenshots:

[DolceTriade]

By no performance issue, what do you mean (ie, what FPS do you get with parllax mapping vs without)? Also, those screenshots look really nice. Do the above scripts work automatically?

[illwieckz]

By no performance issue I mean it's playable with 100+ FPS while my GPU is on powersaving mode. It's a powerful GPU (R9 390X) but I run it in powersaving mode. I think it's good enough to allow us to tell we support that and that means we can ship everything required to do parallax. If someone has performance issue, he can disable it in anyway.

All those screenshots were made without editing xonotic data (it's straight xonotic pk3 with dpk symlink for easy loading), using my work in progress extramap branch discussed in #159.

The only hack I will probably not merge is the hack that activated parallax for all shaders since it produces wrong results if heightmap is missing. Note that the hack is only done on autodiscovered xonotic normalmap so it still allows to render unvanquished maps at the same time, but it would be far better to detect the presence of that heightmap.

[illwieckz]

Do the above scripts work automatically?

I thought you were talking about the xonotic .shader files, but now I think you maybe talked about the makenorms stuff above… Those scripts are meant to be called on a given set, but they look like to be written to be run only one time so there may be some tweaking required, I don't know.

[Viech]

The last three screenshots look really noisy. You might want to set a minimum texture resolution for any notion of auto-enable of that feature, because the engine implementation clearly does no smoothing of the height data (and if it did, it would look bad as well I suppose). Also note that any form of lossy compression could be problematic here as well.

[illwieckz]

Sure, that's a problem, and we (Unvanquished) have a bigger problem: we have a playable character that have eyes almost at floor level: the Dretch. Parallax looks bad if looked too nearby.

[illwieckz]

@Viech, I just hink about this:

Also note that any form of lossy compression could be problematic here as well.

Xonotic uses DDS (hence lossy).

Btw for this screenshot, the groove was just drawed as a pure black line on a white background (probably a manual effort) to follow the lines of the diffuse map. If this is OK for xonotic (floor is seen from average human viewpoint), those are obviously not suitable for Unvanquished because of dretch:

But about the “lossy” issue, the hard lines still are hard lines, so probably no much worry about it…

[illwieckz]

@gimhael is our engine expecting normal map to be the DirectX way or the OpenGL way? https://answers.arnoldrenderer.com/questions/169/why-do-my-normal-maps-appear-to-be-inverted.html

[illwieckz]

Thanks to @bofh80 I got some answers, he linked this page in #85: web.archive.org|wiki.code43.net/index.php/Texturing

This is a wiki page from the now-disappeared Code 43 project that was aiming to redo TrueCombat: Elite on XreaL engine: web.archive.org|www.code43.net

The wiki pages says:

Displacement maps have to be stored in the alpha channel of the DDS or TGA normal map (unless you are for some odd reason using PNG or JPG textures, in this case they have to be stored in their own files). Important difference between the displacement maps stored in the 8bit alpha channel and in standalone files is that displacement maps, stored in the alpha channel have to be inverted - black is high and white is low!

That explains while XreaL 2010's heightmaps are correct when standalone but inversed when stored in alpha channel. This is absolutely weird. And we should not do that. In any way our engine does not support standalone heightmaps. We have to fix our engine to not have to reverse heightmaps stored in alpha channels. There is only one standard for heightmaps: black is low.

Btw it does not explains why our engine normalmaps are reversed compared to darkplaces (or the other way), perhaps our engine somewhat reverses the whole normalmap file (hence reversing the heightmap with it?) I don't know. We have to figure out this.

I just looked at Tech textures (both those shipped by Cr4zy and ours) and I see we don't reversed them. But Tech textures were produced for the Unreal Engine which uses the DirectX convention for normal maps. So either we use Tech textures wrong, either our engine is using the DirectX convention, which is probably not a good idea on this side of the modding scene.

[Edit: I remember some old post from Tr3b on now-dead xreal website talking about some support for some unreal tournament stuff].

[illwieckz]

I found this page about creating assets for DarkPlaces (the engine used by Xonotic): https://www.quakewiki.net/darkplaces-wiki/material-creation-for-dp/

They says:

The normalmap is OpenGL-style with green pointing up (often normalmap tools call this “inverted”), matching Doom3/Quake4/etc behavior, but contrary to several other games.

The height channel is black for deep areas and white for being flush with the surface, the height is used only when offsetmapping (r_glsl_offsetmapping) or reliefmapping (r_glsl_offsetmapping_reliefmapping also on) are active.

So they says Quake4 maps are the OpenGL way, but then we have a problem:

• we use PK02 textures as-is without reverting them, but they are Quake4 ones, hence OpenGL way.
• we use Tech textures as-is without reverting them, but they are Unreal ones, hence DirectX way.

[bofh80]

Just for inference this is an opengl engine, so hence opengl method https://blender.stackexchange.com/questions/100017/directx-and-opengl-normal-maps and i guess the code just to flip and read the dx method ones? (or convert in own repo)

[illwieckz]

Yep, it's just a green inversion.

[illwieckz]

Just for reference, Xonotic default parallax depth scale is 0.02, our engine set it to 0.03 but we never used it so we are not tied to it.

[illwieckz]

I'm closing this issue as code is master now correctly supports parallax. There is some room for performance improvement (see #193 for example), but that works. The need to ship heightmaps is an asset issue, so no need to wait on it to close this one.