Materials (PBR, Specular, Normal maps)

[skornedemon]

Thank you for clarification.

[hardcore_gamer]

I decided to take a shot at creating my own pbr material simply to test this out. It's nothing very fancy, just something I threw together in SD to test it. But when I start Gzdoom (I downloaded the latest 3.3 version) it just crashes. I decided to use the so called "auto folders" since it sounded more simple.

My pk3 file setup looks like this:

Firstly there is a textures lump with this code:

texture TC1, 512, 512
{
XScale 4
YScale 4
patch TC1, 0, 0

}


The original texture is 512x512 so I used this to make it fit inside the more tradtional 128x128 format.

Then I created the material folders in the manner in which is described in the op, or that is "materials/normalmaps/auto/texture.png

I did this for the normal map, the metallic map, the roughness map, and the AO map. The colormap I just put inside the textures folder (and that is the one that is resized in the code above). Each texture map inside the material folders is named the same thing as the texture in the textures folder since I assume that is how zdoom knows what they are used for. Example:

Materials/normalmaps/auto/TC1
Materials/metallic/auto/TC1
etc

Was this the wrong thing to do? Gzdoom just crashes when I start it

Here is the actual file as well as the test map that I used to test the texture: https://ufile.io/uq15f

[Talon1024]

It worked just fine for me after re-converting each PNG to a truecolour PNG using SLADE.

Maybe those PNGs were 16-bit instead of 8-bit? GZDoom cannot use 16-bit PNGs.

EDIT: I noticed your normalmap was a 16-bit PNG. This is what I get from the Linux "file" command, which gives info about files:

Code: Select all

materials/ao/auto/TC1.png:         PNG image data, 512 x 512, 8-bit grayscale, non-interlaced
materials/metallic/auto/TC1.png:   PNG image data, 512 x 512, 8-bit grayscale, non-interlaced
materials/normalmaps/auto/TC1.png: PNG image data, 512 x 512, 16-bit/color RGBA, non-interlaced
materials/roughness/auto/TC1.png:  PNG image data, 512 x 512, 8-bit/color RGBA, non-interlaced
textures/TC1.png:                  PNG image data, 512 x 512, 8-bit/color RGBA, non-interlaced

Converting the normalmap to an 8-bit PNG fixed the crash.

[hardcore_gamer]

I try to convert them but for some reason when I select some of the texture lumps slade just instantly crashes. Don't know why this happens but it's stopping me from converting some of the images. In fact I can't even delete them. Even indirect selection where I select many different lumps at once and then click the "convert to..." button causes a crash. It's driving me nuts. Is there some way to convert the images outside of slade?

EDIT: I just tried using slade on another computer and the exact same thing happened so it's not just my computer.

EDIT 2: For some reason only the ao map and the roughness map appear to crash slade when I select them. Wtf?

EDIT 3: I got it to work by saving the textues as jpegs and then converting them into png true color in slade. I am happy it works now but what that hell was even wrong in the first place?

Also, while I think the maps look cool they don't really look much different than normal textures unless you place some dynamic lights next to them. Though I guess that is to be expected since by default all lightning is sector based.

[wildweasel]

You might submit those files to SLADE's author for analysis.

[hardcore_gamer]

You might submit those files to SLADE's author for analysis.

I could if he is interested. Not sure how much I care now though, since I found a workaround.

[SanyaWaffles]

So, my question is does this work with full-path textures or am I limited to just 8 characters for my textures. It'd be nice to be able to use both full filename textures and materials.

[Reinchard2]

Guys are you sure everything is ok with ao in pbr shader? I have problem with ao in every material I made, it's almost invisible.

[dpJudas]

Guys are you sure everything is ok with ao in pbr shader? I have problem with ao in every material I made, it's almost invisible.

I'm not aware of any problems with the ao, but overall pbr really really needs the environmental light contribution to shine. The only thing that reflects right now are direct light sources and that overall leaves pbr textures pretty far from what you'd expect from other engines like UE4.

There is a pbr_environment branch in the gzdoom repository where I tried to add the specular component of the environment as a single color, but it doesn't look too good. Probably needs fully baked environmental maps. That leaves the problem of needing a baking tool, but more importantly there needs to be a way for a mapper to mark where those are placed on the map and what radius they should use.

[hardcore_gamer]

Guys are you sure everything is ok with ao in pbr shader? I have problem with ao in every material I made, it's almost invisible.

As far as I can tell, the PBR textures are useless unless you place some kind of light source close to them since Doom's sector based lightning model is useless for PBR. I created a test map where I placed down some dynamic lights next to my textures and then the textures looked properly pbr. But without said dynamic lights the textures looked barely any different from traditional HD textures. This is actually a pretty big problem because it means that doom levels not designed specifically with PBR textures in mind probably won't look any different from wads that don't have PBR textures. The only real difference would be that the normal maps add a bit of a 3D effect.

[dpJudas]

This is actually a pretty big problem because it means that doom levels not designed specifically with PBR textures in mind probably won't look any different from wads that don't have PBR textures. The only real difference would be that the normal maps add a bit of a 3D effect.

The new materials were never intended to enhance existing maps.

The diffuse+specular materials are intended to used by mappers that still wish to rely on original Doom textures and want to make visual improvements here and there. The PBR materials are meant for total conversions where the entire texture set is new and the maps are designed up around them. To be honest, I don't think anyone will be fully happy with the PBR variant until I land some form of environmental light support in GZDoom.

[Graf Zahl]

I don't think anyone will be fully happy with the PBR variant until I land some form of environmental light support in GZDoom.

Wouldn't it be more productive to implement a more modern model format first? All this stuff is really neat, but so far it always fails on the primitive look of sprites and old Quake-format models and their limitations.

[Reinchard2]

I'm not aware of any problems with the ao, but overall pbr really really needs the environmental light contribution to shine. The only thing that reflects right now are direct light sources and that overall leaves pbr textures pretty far from what you'd expect from other engines like UE4.

I'm working with PBR and UE4 every day and I must say that I'm really impressed how it works in GZDoom right now. Of course
I'm aware that I must use dynamic lights to see all maps working, but when this lights affects my material all AO dissapear (for some reason I see them proper displaying in places where I NOT use dynamic lights). So I just use AO as multiply layer over my albedo and make some kind of diffuse and use this kind of map istead of regular albedo).
Here's some screenshots from what I'm working right now - you can see the effect is really close to what we can see in modern engines like UE4, the only problem is lighting right now, but hey - this is Doom and I still can't believe my eyes how good it works. Big thanks to all you guys for your work
https://i.imgur.com/iE1PhJp.png
https://i.imgur.com/BlDMGZ5.png
Oh, and link to topic in DW with more stuff:
https://www.doomworld.com/forum/topic/1 ... ls/?page=2

[dpJudas]

Wouldn't it be more productive to implement a more modern model format first?

Sure, but I'm not technically working on the PBR environment thing either besides some simple tests in the pbr_environment branch.

Of course I'm aware that I must use dynamic lights to see all maps working, but when this lights affects my material all AO dissapear (for some reason I see them proper displaying in places where I NOT use dynamic lights). So I just use AO as multiply layer over my albedo and make some kind of diffuse and use this kind of map istead of regular albedo).

The shader does indeed not apply the AO map to the direct light sources. The tutorials I was reading when adding PBR didn't do this either. I did wonder at the time whether this was actually correct or not. It is easy enough to change, but before doing that I'd like someone to confirm that a non-baked light source shining directly at a PBR material applies the AO map in something like UE.

[Reinchard2]

I ask some other people from my company (we all workin with UE4) and you right - directional light don't applie AO to PBR material. BUT in GZDoom we have only directional lights, we can't bake environment lights on our PBR material, so the scenerio when AO will display correctly will never happen.