ZDoom

Yeah, creating normalmaps from scratch is not easy, especially if you're working from a texture rather than a proper diffuse/albedo map and using correct height and surface information exported directly from a 3D modelling application or some such. Just generating height and normal maps (with a tool like AwesomeBump, for example) from a photo or texture that already has lighting information baked into it is an uphill struggle, nevermind also generating the proper PBR maps to go with it!

With regard to your example, that is by design, and always has been AFAIK. When creating materials for GZDoom, all of the map files for the chosen material workflow need to be present otherwise it will not work in-game. For a PBR material like the ones I'm using, you MUST have the all of the following maps present: normalmap / ao / roughness / metallic. You can leave the custom displacement shader out, but all 4 material maps must be present for GZDoom to display a PBR material otherwise it will just show a normal texture. Also, I believe the specular and glossiness values do not do anything when using the PBR workflow, they're for the normal/specular workflow only, so you can leave those out too (this is why they are missing from my original examples.)

If you aren't bothered about PBR and want to make things a bit easier on yourself, you can still use an old-style normal/spacular workflow instead, which only requires the normalmap and the specular to be present. Even in this case though, if only the normalmap is there, it won't work. This has always been the case with GZDoom, even before 4.10.

The GLDEFS documentation is actually pretty good at covering all of this: -

[url]https://zdoom.org/wiki/GLDEFS#Materials[/url]

The problem I've been having is that both of those examples should work exactly the same and yet, with any GZDoom version from 4.11 onwards, they do not. Having the material maps in the "auto" folders should mean that we do not need to define them in GLDEFS at all, they should be automatically detected by the game providing the files are there. This is why it works for you in 4.10 even after you added the remarks to GLDEFS excluding them - the files are still being autodetected. For any version after 4.10, autodetection now only seems to work if there are also no definitions attached to the material in GLDEFS.

I was just starting to create some custom textures with normal maps for the first time myself. I spent too much time getting a simple normal map to work when I stumbled upon this thread.
I tried your 'working' demo which I can confirm runs fine in 4.10 but not in 4.14.10 with this change:

material texture floor4_8
{
//shader "shaders/displacement.fp"
//texture displacement "materials/displacement/floor4_8.png"
normal "materials/normalmaps/auto/floor4_8.png"
//metallic "materials/metallic/auto/floor4_8.png"
//ao "materials/ao/auto/floor4_8.png"
//roughness "materials/roughness/auto/floor4_8.png"
specularlevel 8
glossiness 8
}

I don't see any normal map effect when shining on the floor texture with a flashlight while crouching in 4.14.10. The whole floor is lit up as a normal texture.
It does work correctly in 4.10. I see some lighting around the edges of the hexagonal tile.

This makes the situation even worse? I tried different combinations. In 4.14.10 I only see any effect when I enable normal, metallic, ao and roughness in the code above. So you can't just have a normal map for example.
I really hope they fix things again soon in a future release. I think we need to report a bug.

To make this a bit easier to understand and so you can see it for yourself directly, I have uploaded a pair of PK3 files to GoogleDrive that demonstrate the issue in the simplest way possible. Just drag them onto the GZDoom executable one at a time with no other mods loaded, start a new game, go into E1M1, and look at the floor texture (floor4_8) in the first room.

Both PK3 files are identical apart from the fact that one has everything defined in GLDEFS and one relies on the "auto" folders for the PBR maps. Both of these work correctly in 4.10 and give the exact same results (full PBR materials with displacement) when displayed in game. For any version of GZDoom after that, only the one called "working.pk3" works correctly, the other one just gives plain textures with no PBR materials or displacment maps added.

[url]https://drive.google.com/file/d/1yiVokfMVip55Tum5uiQDbRSioTQzhj_b/view?usp=sharing[/url]
[url]https://drive.google.com/file/d/1hvZOF6dqnVetHtA25hJm4LX_2q-9fvDv/view?usp=sharing[/url]

Yep, I already did all that and have identified the issue in isolation, which is why I posted here and how I know where the problem lies. This happens if I only use one single texture and nothing else, so there are no possible conflicts in my mod that could be causing this problem.

For clarity, I'll outline the issue again. If I create a material by fully defining everything in GLDEFS, along with the displacement shader, it works fine. If I leave out the displacement shader and just have everything done via the "auto" folders it also works fine and shows the full PBR material in game (obviously without any displacement, though.) If I just define the displacement shader in GLDEFS and rely on the auto structure for the ao/normal/roughness/metallic maps, it breaks and I just get a plain texture in game, not a complex PBR material. This was not the case before version 4.11. I've also tried several different custom shaders and the same happens, so it's not the shader itself either. Seems to me like the way GZDoom builds the materials at runtime has changed. I can no longer combine automatically detected material maps with custom shaders, it's all or nothing.

As I said, I've also gone through every version after 4.10 right up to the current release and cannot see anything that might be causing this. Obviously, there are a lot of changes in some of those releases though, so I am probably missing something, hence me asking you guys for assistance. The developers who wrote the code are far more likely to just know what is happening off the bat and be able advise me appropriately than I am to find out what's happening by just randomly poking around until I stumble upon the answer or, more likely, just end up working around it by completely rewriting all of my GLDEFS, which is what I'm trying to avoid with this thread.

Since I do not know how HD-Overhaul-Doom is structured I would suggest to brake it down and introduce one section at a time to find out which part is causing the problem.

So, just add the textures, then add models, then add shaders, etc until the offending part reveals itself. I know it probably will be a lot of work, thus I asked for a link to maybe have others do some of the work.

Browse through the [url=https://forum.zdoom.org/viewforum.php?f=1]GZDoom releases[/url] to find out if something untoward catches your eye.

HD-Overhaul-Doom is the mod I have created and is what has stopped working. It has all the HD textures, PBR materials, 3D models, shaders, and definition files required for my HD overhaul of the Doom resources. It contains over 8000 files and overrides pretty much every resource included in the base WADs and the GZDoom PK3 files, fully segmented into the appropriate FILTER folders to cover all variations of the base Doom games. I'm pretty well-versed in the internal structure of mods and how GZDoom's resources work, or I was until after 4.11, it seems. :)

This is why I'm asking about any technical changes to the way materials are loaded at runtime and how that interacts with the shader pipeline as I spent a LONG time going through the documentation and playing about with it to get this all working correctly, so I really don't fancy going through every single texture and creating customised material entries for them in each GLDEFS unless I have no other choice. The whole point of the "auto" feature for assigning material assets to textures is to get around having to do this, but it now appears that how this works when custom shaders are in play may have changed post version 4.11, so I need advice on what to change to make it work the way it did in 4.10 again or else a confirmation that combining automatically assigned materials with custom shaders is not now possible and, ideally, why the change was made.

I hugely appreciate your engagement on this topic, so please don't take this the wrong way, but I think we need Graf or Rachael or someone who is familiar with the internal workings of the material and shader code to chime in here. This isn't really a basic configuration issue!

Do you have any problem when playing GZDoom 4.14.2 without [i]HD-Overhaul-Doom[/i]?
Untick the [i]Extra Graphics[/i].

[imgur]https://imgur.com/xXz3xmo[/imgur]

If that works for you, then it would be appropriate to dig into the code of that resource,
or provide a link to that resource to have someone else check it out.

Thanks for the response!

As per my post, version 4.10 is the last release that worked properly. Any version beyond that breaks the materials (I've tried all of them after that, right up to the latest one.) Nothing has changed in my mod, so something is definitely different in the way the shaders/materials are being handled now. I'm using no other mods other than the one I've described in my post and this is loaded via a simple open "FILTER" folder structure rather than a PK3 as it's massive in size; pretty much every texture in the game is modified with PBR materials and/or some form of displacement or environment shader, and most of the sprites have been replaced by models with PBR materials.

The shaders are defined in GLDEFS for each texture as per the documentation: -

[spoiler][code]material texture BIGDOOR2
{
shader "shaders/displacement.fp"
texture displacement "materials/displacement/BIGDOOR2.png"
}[/code][/spoiler]

PBR materials are then added to these via the "auto" folder structure.

This was working previously before version 4.11, but now I have to define every material in GLDEFS as well as the shader for it to work. The problem seems to be some sort of change in the way the automatically assigned material maps work with custom shaders.

I am using the Vulkan renderer.

There is nothing I can see in the log files that is helpful, which is why I haven't posted them. Here is a copy anyway, for completeness and in case I've missed something.

[spoiler][code]Log started: 2025-06-08 10:11:18
GZDoom version g4.14.1
W_Init: Init WADfiles.
adding D:/Games/Doom/gzdoom.pk3, 692 lumps
adding D:/Games/Doom/game_support.pk3, 3308 lumps
adding D:/Games/Doom//WAD/DOOM.WAD, 2306 lumps
adding D:/Games/Doom/lights.pk3, 7 lumps
adding D:/Games/Doom/brightmaps.pk3, 499 lumps
adding D:/Games/Doom//MODS/HD-Overhaul-Doom, 8285 lumps
S_Init: Setting up sound.
I_InitSound: Initializing OpenAL
Opened device OpenAL Soft on Speakers (Realtek(R) Audio)
EFX enabled
Log stopped: 2025-06-08 10:11:22
[/code][/spoiler]

[spoiler][code]Log started: 2025-06-08 09:50:07
I_InitInput
I_StartupMouse
I_StartupKeyboard
I_StartupXInput
I_StartupRawPS2
I_StartupDirectInputJoystick
Vulkan device: NVIDIA GeForce RTX 3090
Vulkan device type: discrete gpu
Vulkan version: 1.4.303 (api) 572.280.0 (driver)
Vulkan extensions: VK_KHR_16bit_storage VK_KHR_8bit_storage VK_KHR_acceleration_structure VK_KHR_bind_memory2 VK_KHR_buffer_device_address VK_KHR_calibrated_timestamps VK_KHR_compute_shader_derivatives VK_KHR_cooperative_matrix VK_KHR_copy_commands2 VK_KHR_create_renderpass2 VK_KHR_dedicated_allocation VK_KHR_deferred_host_operations VK_KHR_depth_stencil_resolve VK_KHR_descriptor_update_template VK_KHR_device_group VK_KHR_draw_indirect_count VK_KHR_driver_properties VK_KHR_dynamic_rendering VK_KHR_dynamic_rendering_local_read VK_KHR_external_fence VK_KHR_external_fence_win32 VK_KHR_external_memory VK_KHR_external_memory_win32 VK_KHR_external_semaphore VK_KHR_external_semaphore_win32 VK_KHR_format_feature_flags2 VK_KHR_fragment_shader_barycentric VK_KHR_fragment_shading_rate VK_KHR_get_memory_requirements2 VK_KHR_global_priority VK_KHR_image_format_list VK_KHR_imageless_framebuffer VK_KHR_index_type_uint8 VK_KHR_line_rasterization VK_KHR_load_store_op_none VK_KHR_maintenance1 VK_KHR_maintenance2 VK_KHR_maintenance3 VK_KHR_maintenance4 VK_KHR_maintenance5 VK_KHR_maintenance6 VK_KHR_maintenance7 VK_KHR_map_memory2 VK_KHR_multiview VK_KHR_pipeline_binary VK_KHR_pipeline_executable_properties VK_KHR_pipeline_library VK_KHR_present_id VK_KHR_present_wait VK_KHR_push_descriptor VK_KHR_ray_query VK_KHR_ray_tracing_maintenance1 VK_KHR_ray_tracing_pipeline VK_KHR_ray_tracing_position_fetch VK_KHR_relaxed_block_layout VK_KHR_sampler_mirror_clamp_to_edge VK_KHR_sampler_ycbcr_conversion VK_KHR_separate_depth_stencil_layouts VK_KHR_shader_atomic_int64 VK_KHR_shader_clock VK_KHR_shader_draw_parameters VK_KHR_shader_expect_assume VK_KHR_shader_float16_int8 VK_KHR_shader_float_controls VK_KHR_shader_float_controls2 VK_KHR_shader_integer_dot_product VK_KHR_shader_maximal_reconvergence VK_KHR_shader_non_semantic_info VK_KHR_shader_quad_control VK_KHR_shader_relaxed_extended_instruction VK_KHR_shader_subgroup_extended_types VK_KHR_shader_subgroup_rotate VK_KHR_shader_subgroup_uniform_control_flow VK_KHR_shader_terminate_invocation VK_KHR_spirv_1_4 VK_KHR_storage_buffer_storage_class VK_KHR_swapchain VK_KHR_swapchain_mutable_format VK_KHR_synchronization2 VK_KHR_timeline_semaphore VK_KHR_uniform_buffer_standard_layout VK_KHR_variable_pointers VK_KHR_vertex_attribute_divisor VK_KHR_video_decode_av1 VK_KHR_video_decode_h264 VK_KHR_video_decode_h265 VK_KHR_video_decode_queue VK_KHR_video_encode_h264 VK_KHR_video_encode_h265 VK_KHR_video_encode_queue VK_KHR_video_maintenance1 VK_KHR_video_queue VK_KHR_vulkan_memory_model VK_KHR_win32_keyed_mutex VK_KHR_workgroup_memory_explicit_layout VK_KHR_zero_initialize_workgroup_memory VK_EXT_4444_formats VK_EXT_attachment_feedback_loop_dynamic_state VK_EXT_attachment_feedback_loop_layout VK_EXT_blend_operation_advanced VK_EXT_border_color_swizzle VK_EXT_buffer_device_address VK_EXT_calibrated_timestamps VK_EXT_color_write_enable VK_EXT_conditional_rendering VK_EXT_conservative_rasterization VK_EXT_custom_border_color VK_EXT_depth_bias_control VK_EXT_depth_clamp_control VK_EXT_depth_clamp_zero_one VK_EXT_depth_clip_control VK_EXT_depth_clip_enable VK_EXT_depth_range_unrestricted VK_EXT_descriptor_buffer VK_EXT_descriptor_indexing VK_EXT_device_fault VK_EXT_device_generated_commands VK_EXT_discard_rectangles VK_EXT_dynamic_rendering_unused_attachments VK_EXT_extended_dynamic_state VK_EXT_extended_dynamic_state2 VK_EXT_extended_dynamic_state3 VK_EXT_external_memory_host VK_EXT_fragment_shader_interlock VK_EXT_full_screen_exclusive VK_EXT_global_priority VK_EXT_global_priority_query VK_EXT_graphics_pipeline_library VK_EXT_hdr_metadata VK_EXT_host_image_copy VK_EXT_host_query_reset VK_EXT_image_2d_view_of_3d VK_EXT_image_robustness VK_EXT_image_sliced_view_of_3d VK_EXT_image_view_min_lod VK_EXT_index_type_uint8 VK_EXT_inline_uniform_block VK_EXT_legacy_vertex_attributes VK_EXT_line_rasterization VK_EXT_load_store_op_none VK_EXT_memory_budget VK_EXT_memory_priority VK_EXT_mesh_shader VK_EXT_multi_draw VK_EXT_mutable_descriptor_type VK_EXT_nested_command_buffer VK_EXT_non_seamless_cube_map VK_EXT_opacity_micromap VK_EXT_pageable_device_local_memory VK_EXT_pci_bus_info VK_EXT_pipeline_creation_cache_control VK_EXT_pipeline_creation_feedback VK_EXT_pipeline_library_group_handles VK_EXT_pipeline_robustness VK_EXT_post_depth_coverage VK_EXT_primitive_topology_list_restart VK_EXT_primitives_generated_query VK_EXT_private_data VK_EXT_provoking_vertex VK_EXT_queue_family_foreign VK_EXT_robustness2 VK_EXT_sample_locations VK_EXT_sampler_filter_minmax VK_EXT_scalar_block_layout VK_EXT_separate_stencil_usage VK_EXT_shader_atomic_float VK_EXT_shader_demote_to_helper_invocation VK_EXT_shader_image_atomic_int64 VK_EXT_shader_module_identifier VK_EXT_shader_object VK_EXT_shader_replicated_composites VK_EXT_shader_subgroup_ballot VK_EXT_shader_subgroup_vote VK_EXT_shader_viewport_index_layer VK_EXT_subgroup_size_control VK_EXT_swapchain_maintenance1 VK_EXT_texel_buffer_alignment VK_EXT_tooling_info VK_EXT_transform_feedback VK_EXT_vertex_attribute_divisor VK_EXT_vertex_input_dynamic_state VK_EXT_ycbcr_2plane_444_formats VK_EXT_ycbcr_image_arrays VK_NV_clip_space_w_scaling VK_NV_cluster_acceleration_structure VK_NV_compute_shader_derivatives VK_NV_cooperative_matrix VK_NV_cooperative_vector VK_NV_copy_memory_indirect VK_NV_corner_sampled_image VK_NV_coverage_reduction_mode VK_NV_cuda_kernel_launch VK_NV_dedicated_allocation VK_NV_dedicated_allocation_image_aliasing VK_NV_descriptor_pool_overallocation VK_NV_device_diagnostic_checkpoints VK_NV_device_diagnostics_config VK_NV_device_generated_commands VK_NV_device_generated_commands_compute VK_NV_external_memory VK_NV_external_memory_win32 VK_NV_fill_rectangle VK_NV_fragment_coverage_to_color VK_NV_fragment_shader_barycentric VK_NV_fragment_shading_rate_enums VK_NV_framebuffer_mixed_samples VK_NV_geometry_shader_passthrough VK_NV_inherited_viewport_scissor VK_NV_linear_color_attachment VK_NV_low_latency VK_NV_low_latency2 VK_NV_memory_decompression VK_NV_mesh_shader VK_NV_optical_flow VK_NV_partitioned_acceleration_structure VK_NV_present_metering VK_NV_raw_access_chains VK_NV_ray_tracing VK_NV_ray_tracing_invocation_reorder VK_NV_ray_tracing_motion_blur VK_NV_representative_fragment_test VK_NV_sample_mask_override_coverage VK_NV_scissor_exclusive VK_NV_shader_atomic_float16_vector VK_NV_shader_image_footprint VK_NV_shader_sm_builtins VK_NV_shader_subgroup_partitioned VK_NV_shading_rate_image VK_NV_viewport_array2 VK_NV_viewport_swizzle VK_NV_win32_keyed_mutex VK_NVX_binary_import VK_NVX_image_view_handle VK_NVX_multiview_per_view_attributes VK_AMD_buffer_marker VK_GOOGLE_user_type
Max. texture size: 32768
Max. uniform buffer range: 65536
Min. uniform buffer offset alignment: 64
Resolution: 2560 x 1440
I_Init: Setting up machine state.
CPU speed: 3192 MHz
CPU Vendor ID: GenuineIntel
Name: Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz
Family 6, Model 158, Stepping 10
Features: SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 AVX AVX2 F16C FMA3 BMI1 BMI2 HyperThreading
V_Init: allocate screen.
ST_Init: Init startup screen.
Checking cmd-line parameters...
S_InitData: Load sound definitions.
G_ParseMapInfo: Load map definitions.
Texman.Init: Init texture manager.
ParseTeamInfo: Load team definitions.
LoadActors: Load actor definitions.
script parsing took 469.20 ms
R_Init: Init Doom refresh subsystem.
DecalLibrary: Load decals.
M_Init: Init menus.
P_Init: Init Playloop state.
ParseSBarInfo: Loading custom status bar definition.
D_CheckNetGame: Checking network game status.
player 1 of 1 (1 nodes)

----------------------------------------

E1M1 - Hangar

[/code][/spoiler]

I do not use shaders myself, do not know much about them, but it would be interesting to know how, exactly, you install shaders in your project.

Which version of GZDoom are you using?
Which files are you loading into GZDoom?
What [b]Rendering API[/b] are you using?

Can you give us the log file?

I guess nobody has any clues about this...?

A few years ago, I made a large texture mod for my installation of GZDoom (version 4.10) that included a full set of HD flats, walls, model textures, along with a bunch of PBR material files and parallax/displacement shaders for them. After downloading the 4.14.1 update for GZDoom, most of these now appear to not be working anymore and just appear in game as plain textures with no materials on them.

I have the PBR material files in the appropriate ao/normalmaps/roughness/metallic "auto" folders, with the displacement shader being separately defined in GLDEFS. I did some testing and it appears that all of the affected textures are ones that have a displacement map defined in GLDEFS, but rely on the "auto" folders for assigning the PBR maps. After playing about a bit more with individual textures, I discovered that I can still get it working, but if I'm using a custom shader that needs to be manually defined in GLDEFS, I now also have to manually define every PBR map for it in GLDEFS too otherwise it just will not work. Seems like the "auto" option for material maps is now all or nothing, meaning we cannot combine manual and automatically defined materials? I've done some rollbacks with previous versions to find out where this started and it appears to have started on version 4.11.

I'm just wondering if this is by design and, if so, can I do anything to correct this issue other than fully define every single texture in GLDEFS (which would be a bit of a pain for me as there are hundreds of them,) or am I just doing something else wrong?

Any advice or assistance would be hugely welcome. If this is just the way things work now, then that's cool and I accept that, but I would be interested to know why this change was made.