Doom 1 Parallax Mapping (2 versions available)

[Tormentor667]

One more question, I noticed your GLDEFS lump looks like this:

Code: Select all • Expand view

material texture "BIGDOOR1"
{
   shader "shaders/displacement.fp"
   normal "materials/normalmaps/BIGDOOR1.png"
   specular "materials/specular/BIGDOOR1.png"
   texture displacement "materials/displacement/BIGDOOR1.png"
   glossiness 10.0
   specularlevel 0.5
}

The interesting part of this is only the "displacement" thing as I consider using this in Blade of Agony for various textures. Is there any way to make the engine automatically use the displacement texture with the same texture name instead of writing a GLDEFS entry to the lump for each texture?

Beyond that, what performance impact does this have in general?

[Rachael]

The interesting part of this is only the "displacement" thing as I consider using this in Blade of Agony for various textures. Is there any way to make the engine automatically use the displacement texture with the same texture name instead of writing a GLDEFS entry to the lump for each texture?

Personally I just would write a tool to automate this. I'm not fucking around with GLDEFS if I have to do everything manually en masse.

[Tormentor667]

If I'd only be able to program something like that Checking the "materials/displacement/" folder and writing a TXT file according to the existing textures in the folder. So a "BIGDOOR1.png" in "materials/displacement" would generate this:

Code: Select all • Expand view

material texture "BIGDOOR1"
{
   shader "shaders/displacement.fp"
   texture displacement "materials/displacement/BIGDOOR1.png"
}

I just wonder what could be done with longname textures...

[Rachael]

I could do it. In fact I could probably write a simple batch file for it. What I'd need, though, is knowing where to find the textures, and where to find their displacements.

As for longname textures, that shouldn't be a problem at all. I imagine it's just as simple as putting their longname in, instead of their shortname. Might have to do both, but the program can handle that.

[zhadoom]

Hello

Well, the much larger problem is to generate these displacement map files. I mean... there are so many awesome texture sets for GZDoom and none of them has displacement maps yet...

Kind regards
zhd

[Tormentor667]

I could do it. In fact I could probably write a simple batch file for it. What I'd need, though, is knowing where to find the textures, and where to find their displacements. As for longname textures, that shouldn't be a problem at all. I imagine it's just as simple as putting their longname in, instead of their shortname. Might have to do both, but the program can handle that.

Thanks for the offer, that would be cool The textures are in the „/textures/„ folder and its subfolders. The displacement textures are in the „/materials/displacement/„ folder, without subfolders.

[Tormentor667]

Sorry for the double post but is anyone able to explain how much impact the displacement maps have on the engine performance? Is it a CPU or a GPU feature? What makes it run slower or faster? The amount of textures visible or the amount of textures in the map overall?

[Rachael]

1) The displacement maps have a notable effect on engine performance, enough that you might consider distributing an add-on to disable the shader.
2) It's a GPU feature, the CPU is not affected. Anyone with a strong (ie GTX 1080+) GPU will probably not notice a difference, here, regardless of the power of their CPU.
3) The detail settings affect it running slower or faster, however even at minimum detail there is a performance impact and minimum detail is enough to create major artifacts. A card like a GTX 1080 will handle this like a champ, but anything older will have issues.
4) Only the amount of textures visible should affect things, but it depends on how much of the scene is culled. If you have a lot of the scene behind 1-sided lines, or closed (ie floorheight==ceilheight) sectors, it will speed things up considerably.

[Rachael]

Okay, I made you something. I have made you a pull request that will stick it in your tools/ folder. (It will *only* work if placed in a first-level subfolder, if you need it someplace else you'll have to change the "cd %~dp0\.." line)

Right now, all it does is spit its output out to the console. If you want to create an actual file with it, it would be as thus:

Code: Select all • Expand view

call D:\WolfenDoom\tools\gldefs-mats-generator.cmd > D:\WolfenDoom\gldefs.autogen

The "call" is assuming you are using this within a batch file, and allows nested batch file execution with a graceful exit. Replace D:\WolfenDoom with your actual development folder path, obviously.

If I call the batch file with the branch in its current state, this is its output:

Code: Select all • Expand view

material texture "textures/AFRK_T02.jpg"
{
        shader "shaders/displacement.fp"
        texture displacement "materials\displacement\AFRK_T02.png"
}

material texture "AFRK_T02"
{
        shader "shaders/displacement.fp"
        texture displacement "materials\displacement\AFRK_T02.png"
}

material texture "textures/AFRK_T07.png"
{
        shader "shaders/displacement.fp"
        texture displacement "materials\displacement\AFRK_T07.png"
}

material texture "AFRK_T07"
{
        shader "shaders/displacement.fp"
        texture displacement "materials\displacement\AFRK_T07.png"
}

material texture "textures/BRIK_T05.png"
{
        shader "shaders/displacement.fp"
        texture displacement "materials\displacement\BRIK_T05.png"
}

material texture "BRIK_T05"
{
        shader "shaders/displacement.fp"
        texture displacement "materials\displacement\BRIK_T05.png"
}

material texture "textures/ROCK_G32.png"
{
        shader "shaders/displacement.fp"
        texture displacement "materials\displacement\ROCK_G32.png"
}

material texture "ROCK_G32"
{
        shader "shaders/displacement.fp"
        texture displacement "materials\displacement\ROCK_G32.png"
}

material texture "textures/SAND_T02.png"
{
        shader "shaders/displacement.fp"
        texture displacement "materials\displacement\SAND_T02.png"
}

material texture "SAND_T02"
{
        shader "shaders/displacement.fp"
        texture displacement "materials\displacement\SAND_T02.png"
}

material texture "textures/STON_G10.png"
{
        shader "shaders/displacement.fp"
        texture displacement "materials\displacement\STON_G10.png"
}

material texture "STON_G10"
{
        shader "shaders/displacement.fp"
        texture displacement "materials\displacement\STON_G10.png"
}

material texture "textures/egypt/EGYP_S03.png"
{
        shader "shaders/displacement.fp"
        texture displacement "materials\displacement\EGYP_S03.png"
}

material texture "EGYP_S03"
{
        shader "shaders/displacement.fp"
        texture displacement "materials\displacement\EGYP_S03.png"
}


[Tormentor667]

Works like a charm, thanks kinldy Rachael, more comments on the GitHub

[Ozymandias81]

I have two questions about this cool parallax mapping:

1. Could be the shader controlled via zscript to let users switch it on/off, and if yes how?
2. While I am a total noob with shaders coding, could be this one optimized in a way that the code interprete the effect with lowpoly details somehow? The effect actually impacts deeply in performance with low profile GPUs, for instance mine has 1gb of vram

[Rachael]

1) Unfortunately, no, not unless custom material-specific uniforms are created for shaders within GZDoom itself.
2) Honestly, I am not sure.

[Kazudra]

Okay, I'm at a stump, I wanted to see how this looked with Neural 2x textures, Good news is that everything is aligned (and still works with Brightmaps), Bad news is that every texture is now doubled in scale.
How can I go about fixing this?

[Darkcrafter]

I don't seem to like this neural upscale project a much, the aligns are bend up a lot since it's not sufficient just to place textures in "HIRES" folder and call it a day. To be completely fine, the project pk3 file must contain a special "TEXTURES" lump that would explain the engine what dimensions each particular texture has, what scale and offset they must be.

They definitely are doing an amazing job there but I'm a perfectionist (I know it's disease of some sort) and I don't like the way their scaler treats "noisy" areas like noise and blurs it out into a flat washed out surface that is being surrounded by scattered diagonal splashes. Also the upscaler adds some unwanted color noise that doesn't work that great if I would prefer to play with palette shader engaged without texture filtering at all.

Here is the comparison between Nearest Neighbor and AI performed with SUPPORT3 texture: https://imgur.com/7tj75le

So to me this pack is more of a draft quality rather than production ready and it's yet just 2x, as soons as it gets at least 4x it will gain even more artifacts and flubyness, so relying on just AI here isn't the best way of handling this problem, I believe it could take years of work to recreate it faithfully by just redrawing them pixel by pixel in photoshop or gimp. So we have to choose between premium quality work (redrawing by hand that could take years) or imperfect redrawing by combing tricks and tools. GIMP can easily pick up an amazing plug-in that suits upscaling some granular textures without losing the grain - Texture Synthesizer, it's free and I found a working 32 and 64 bit compiled windows versions that supports cpu multi-threading, hope it's fine I post it here because it's getting hard to find one: https://drive.google.com/open?id=1BaCnX ... 4mjJ2ykilm

Also, here is lost demo version of SmartEdge algorithm developed at MSU: https://drive.google.com/open?id=1JbY-9 ... LEtWAq9Ynq
If you're on Windows 7 or 10 turn on Windows XP compatibilty and give it administrator rights before launching. Choose bilinear as a scaling algo, press X2 button, turn every setting to 0 except "fractal substitution" and see what this thing does to pixel art.

https://imgur.com/a/fR7zE57