VLT-PBR-POM - Reworked parallax shader, new PBR materials, parallax maps for doom 1, 2, Plutonia, and TNT

[Vault]

This was actually finished around December of last year but I hate making mod pages.
I will continue to tweak it as feedback comes in and eventually cover LOR once source ports figure out what to do with ID24.

GZdoom
https://drive.google.com/file/d/1x0LTTJ ... sp=sharing
VKdoom
https://drive.google.com/file/d/1JDFl3X ... sp=sharing

What's in the box:

- New parallax shader with greatly increased accuracy and parallax self-shadowing. Should run well even on low spec computers.
- New brightmap shader allows for granular control of light intensity including support for blinking lights. Backwards compatible.
- New liquid shader, very experimental and I'm not sure I actually like it.
- New Parallax maps take advantage of the greater accuracy gained from reworking the parallax shader.
- All-New PBR maps for most every material that can benefit from it.
- All-New brightmaps that utilize the new brightmap shader.

Usage:

Should work nicely on top of voxeldoom but equally as well by itself.
You will need a lighting mod like Relite if you do not play on maps with built-in dynamic lights in order to see the PBR work. Parallax should work on any map that uses retail textures.
This release has two versions, one for vkdoom and one for gzdoom, make sure you install the correct one to match your source port.

License: GPL v3.0
Thanks to:
Resources: Cheello, Arl, Reinchard2
Code: dpJudas, Nash, Pr0bability, Ashley, themistercat, Dileepvr

[cosmos10040]

Got this error:

script parsing took 0.00

Script error, "VLT_PBR_POM - RC1GZ.pk3:gldefs.txt" line 1079:
Custom hardware shader texture 'materials/heightTex/walls/SW1BRN1.png' not found in texture 'SW1BRN1'

[Enjay]

Curious. The only error I get is different:

Code: Select all

Script error, "VLT_PBR_POM - RC1GZ.pk3:gldefs.txt" line 689:
Material definition refers nonexistent texture 'LITEMET'

This is a relatively subtle attempt at materials of this kind. Most previous attempts have tried to be too extreme and ended up looking quite bad, especially with Doom's low resolution textures.

That being said, the low resolution nature of the textures, coupled with the often sharp-cornered nature of the architecture in Doom maps, can easily make most walls look a bit off if you look at them from certain angles.





and the whole starting corridor, with the blue lights and grey holes in the ceiling where bright lights should be just looks off to me.

[Vault]

I'll have to investigate what is going on with the GZdoom version, thanks for bringing it to my attention. The parallax overdraw is impossible to fix without access to vertex shaders. VKdoom has recently made progress on that front but GZdoom has not.

Thus, I recommend the VKdoom version in the mean time, as that is what the mod was built on.

[Vault]

It's a problem with how GZdoom renders its PBR. that is, the PBR maps don't get properly masked by the brightmap, so instead of shining through, it turns the map blue. I don't think I can fix it on my end.

[Enjay]

It certainly does look a lot better in VkDoom.



Still plenty of corner and extreme angle weirdness though.




It's a valiant attempt - one of the best I have seen. However, I think the bottom line is that the default Doom resources are not the best fit for this kind of technology.

[Darkcrafter]

A really nice attempt but it doesn't work in GZDoom due to how warp shaders are made. As soon as you remove the gldefs definitions with them it's going to work... I'll tell you what's wrong with parallax textures - it's the parallax offset value set at 0.6 instead of 0.5. That's gonna push your overall textures depth inside and treat overall texture as if it was farther than its surface, thus dancing textures.

You must set the offet value at 0.5 and you know some little depth details like switches will be gone and that's ok due to the way of how adaptive layering algorithm works. The layers are becoming to thin to account for such little bumps.

So you also have to rework those texture by bringing them more contrast via simple contrast filter or even unsharp mask -carefuly, not to cause ringing, then reasure that your base height is 0.5 (50% gray) with a high pass filter.

[Vault]

A really nice attempt but it doesn't work in GZDoom due to how warp shaders are made. As soon as you remove the gldefs definitions with them it's going to work... I'll tell you what's wrong with parallax textures - it's the parallax offset value set at 0.6 instead of 0.5. That's gonna push your overall textures depth inside and treat overall texture as if it was farther than its surface, thus dancing textures.

You must set the offet value at 0.5 and you know some little depth details like switches will be gone and that's ok due to the way of how adaptive layering algorithm works. The layers are becoming to thin to account for such little bumps.

So you also have to rework those texture by bringing them more contrast via simple contrast filter or even unsharp mask -carefuly, not to cause ringing, then reasure that your base height is 0.5 (50% gray) with a high pass filter.

an offset of 0.6 was a conscious decision. Without access to vertex data in the shader there is no way to prevent parallax overdraw and the best you can do if you find overdraw intolerable is in fact to set bias to 0.5, which is an intended feature at the cost of destroying parallax detail. All textures in this pack are normalized to V=50 for this reason.

[Vault]

Fixed straggling bugs. Still waiting for fix from GZDoom regarding brightmaps.

[Darkcrafter]

an offset of 0.6 was a conscious decision. Without access to vertex data in the shader there is no way to prevent parallax overdraw and the best you can do if you find overdraw intolerable is in fact to set bias to 0.5, which is an intended feature at the cost of destroying parallax detail. All textures in this pack are normalized to V=50 for this reason.

How an access to vertex data in the shader can help btw? I discovered an interesting workaround to modify my relief mapping shader a bit by separating layer calculations for pixels that are darker than 50% gray of heightTex and those that are brighter (elevations). So that maxLayers for elevated is always at small amounts like 16 while maxLayer for flat and depressed are way way higher. That way you can have lots of layers on regular depressed values and few layers for some "pimples" to show through without a need to offset the whole height of the heightmap texture. The drawbacks are still some depth sorting issues like flat/depressed showing trough elevated details and it's still being masked by non-elevated details. A shader like this may still be useful for some materials like switches and pretty much anything with not that much going on on elevated details.

Another issue with texture filtering of GZDoom and pretty much any other game there is that how mipmaps are generated and it makes the matters worse for distant surfaces even with 16x anisotropy as moire wave like patterns arise. There was a paper on the web called "eliptical texture filtering" or something that enhanced the matters somewhat.

Well as soon as you push the offsets into the surfaces, the tiling beomes smaller and the idea I had was to enlarge the textures scale by modifying T = vTexCoord.st * 0.98 but then it doesn't compensate UV coordinates properly and texture go seriously misaligned, there was even an attempt to track down changes of UV coordinates and compensate that shift via (vTexCoord.st * 0.98) - vTexCoord.st but it really just looks like if no texture scale enlargement occured...

[Shidfard]

Hello, and thank you for making this! I like these more than the Arl PBR pack. I did get an error at first:

Script error, "VLT_PBR_POM - RC1GZ.pk3:gldefs.txt" line 1079:
Custom hardware shader texture 'materials/heightTex/walls/SW1BRN1.png' not found in texture 'SW1BRN1'

I managed to fix it by just ripping the 2 missing textures from the other PBR wad.

My only complaint is that some of the obvious light textures are not lit up like they are in the other pack. Example:
Old PBR:https://i.ibb.co/DDnnLPvV/Screenshot-Do ... 032218.png
New PBR: https://i.ibb.co/DHxpxvJ5/Screenshot-Do ... 031026.png

[Cataflexia]

for me on vkdoom shows the following error:

Code: Select all

+E1M1 - Hangar

Execution could not continue.
Shader compile failed: ERROR: shaders/VLTMATShader.fp:209: 'constructor' : can't convert 
ERROR: shaders/VLTMATShader.fp:209: ' temp 4-component vector of int' : cannot construct with these arguments 
ERROR: shaders/scene/frag_main.glsl:0: '' : missing #endif 
ERROR: shaders/VLTMATShader.fp:209: '=' :  cannot convert from ' const float' to ' temp highp 4-component vector of int'
ERROR: shaders/scene/frag_main.glsl:0: '' : compilation terminated 
ERROR: 5 compilation errors.  No code generated.

My ini is configured in this way:

Code: Select all

[doom.id.Autoload]
Path=$PROGDIR/efx/VLT_PBR_POM - RC2VK.pk3