I noticed that it works well for short texture names (e.h. FLAT10) but doesn't work for long texture names (e.g. textures/FLAT10.png). Can this be fixed somehow? I find it kinda unfortunate if this would only work for short texture names now that we have long texture names already for agesAnd the auto material folders are as follows:
- materials/brightmaps/auto or brightmaps/auto for brightmaps.
- materials/normalmaps/auto for normal maps.
- materials/specular/auto for specular maps.
- materials/metallic/auto for metalness maps.
- materials/roughness/auto for roughness maps.
- materials/ao/auto for ambient occlusion maps.
Material auto folders on full path textures don't work
Moderator: GZDoom Developers
Forum rules
Please construct and post a simple demo whenever possible for all bug reports. Please provide links to everything.
If you can include a wad demonstrating the problem, please do so. Bug reports that include fully-constructed demos have a much better chance of being investigated in a timely manner than those that don't.
Please make a new topic for every bug. Don't combine multiple bugs into a single topic. Thanks!
Please construct and post a simple demo whenever possible for all bug reports. Please provide links to everything.
If you can include a wad demonstrating the problem, please do so. Bug reports that include fully-constructed demos have a much better chance of being investigated in a timely manner than those that don't.
Please make a new topic for every bug. Don't combine multiple bugs into a single topic. Thanks!
- Tormentor667
- Posts: 13533
- Joined: Wed Jul 16, 2003 3:52 am
- Contact:
Material auto folders on full path textures don't work
According to the latest information about the material features, this is how it should work:
Re: Material auto folders on full path textures don't work
I implemented this feature to work exactly like the current auto folder for brightmaps. Does this mean brightmaps can only be used with short texture names too?
- Tormentor667
- Posts: 13533
- Joined: Wed Jul 16, 2003 3:52 am
- Contact:
Re: Material auto folders on full path textures don't work
I didn't test it myself but Talon did and according to him, it doesn't work on longnames, just shortnames, so my guess is that it's the same problem with the brightmaps as well.
*UPDATE*
Ozymandias tested it directly with the brightmaps mechanism, same problem here, works for shortnames, doesn't work for longnames.
*UPDATE*
Ozymandias tested it directly with the brightmaps mechanism, same problem here, works for shortnames, doesn't work for longnames.
- Ozymandias81
- Posts: 2063
- Joined: Thu Jul 04, 2013 8:01 am
- Graphics Processor: nVidia with Vulkan support
- Location: Mount Olympus, Mars
- Contact:
Re: Material auto folders on full path textures don't work
Just had a try with a longnamed texture which was previously defined inside our brightmaps def lump (boadefs.bm): I moved my brightmap on Auto folder (not the "material" one eh), then renamed the brightmap using exact texture name (texture in question was door_b89b.png, and it's name was bm_door_b89b.png): doesn't work, and this is what I did after uncomment this line.
Re: Material auto folders on full path textures don't work
That seems logical to me. materials/brightmaps/auto/foobar.png will match texture foobar.
If you want to match texture textures/longnamefoobar.png, you'll have to use materials/brightmaps/auto/textures/longnamefoobar.png I guess.
If you want to match texture textures/longnamefoobar.png, you'll have to use materials/brightmaps/auto/textures/longnamefoobar.png I guess.
- Tormentor667
- Posts: 13533
- Joined: Wed Jul 16, 2003 3:52 am
- Contact:
Re: Material auto folders on full path textures don't work
The problem is that sometimes the texture is used as TILE_R04 (shortname) and sometimes as "textures/tile_r04.png", so in your case we'd need both variants and twice the data amount.Gez wrote:That seems logical to me. materials/brightmaps/auto/foobar.png will match texture foobar.
If you want to match texture textures/longnamefoobar.png, you'll have to use materials/brightmaps/auto/textures/longnamefoobar.png I guess.
So on the other hand if we go for having all textures as "longnames", but is there some kind of a converter, that exactly does that? Renaming all used textures from "shortname" to "longname"?
Re: Material auto folders on full path textures don't work
I'm pretty sure the engine already treats them as different textures so you get twice the RAM usage from this inconsistency.Tormentor667 wrote:The problem is that sometimes the texture is used as TILE_R04 (shortname) and sometimes as "textures/tile_r04.png", so in your case we'd need both variants and twice the data amount.
Re: Material auto folders on full path textures don't work
Switch to full long name usage. Open the TEXTMAP in a text editor and do search and replace to fix the texture paths. And be sure to tick the "use long texture filenames" button in GZDB.
- Major Cooke
- Posts: 8175
- Joined: Sun Jan 28, 2007 3:55 pm
- Preferred Pronouns: He/Him
- Location: QZDoom Maintenance Team
Re: Material auto folders on full path textures don't work
That'll actually work?Gez wrote:If you want to match texture textures/longnamefoobar.png, you'll have to use materials/brightmaps/auto/textures/longnamefoobar.png I guess.
Re: Material auto folders on full path textures don't work
Dunno, try it and see!
Re: Material auto folders on full path textures don't work
Just looked at that commit and the follow up commit by Ozymandias81. Be careful not to mix specular materials with PBR materials. Stick to either normal+specular or normal+roughness+metallic+ao. If your goal is to enhance the visuals of an existing mod it is probably best to use normal+specular. Those materials looks best when placed next to those with no specular. For PBR you probably need all textures to use it for it to look good.
About the full path thing I'm not sure what is the best way to handle the auto loading. I could try change the code to do like Gez suggests, but I'd like confirmation from Graf or others that this is the preferred behavior.
About the full path thing I'm not sure what is the best way to handle the auto loading. I could try change the code to do like Gez suggests, but I'd like confirmation from Graf or others that this is the preferred behavior.
- Tormentor667
- Posts: 13533
- Joined: Wed Jul 16, 2003 3:52 am
- Contact:
Re: Material auto folders on full path textures don't work
What is actually the difference between both variants?dpJudas wrote:Be careful not to mix specular materials with PBR materials. Stick to either normal+specular or normal+roughness+metallic+ao. If your goal is to enhance the visuals of an existing mod it is probably best to use normal+specular. Those materials looks best when placed next to those with no specular.
Re: Material auto folders on full path textures don't work
The specular light model uses two color textures: a diffuse base texture and a specular map texture. The diffuse texture is the color you get from all directions (the light is diffuse, that is, spread out). This base texture is the same as you've always known and used in Doom. The specular texture is the extra color you get when light reflects on the surface. The specular level and shininess (variables you can type in the GLDEFS file) controls how spread out the reflection is and how strong it gets. This light model is the classical model you've seen most games use in approx 1998-2012.
Physically-based-rendering, or PBR for short, is a newer model that is more physically accurate. It is what newer engines uses, such Unreal Engine 4 and Unity. The textures looks better under varying light conditions compared to the more classic model, but also require more texturing work. Here's a link to a general description of PBR: https://www.marmoset.co/posts/basic-the ... rendering/
I recommend you choose only one of the models for a project. The reason being that dynamic lights hitting surfaces of one type reacts slightly different than if hit by the other. If the light in a scene isn't consistent then you could end up with visuals much worse than if you either had not used any of them, or if you had sticked to just specular textures. I added support for both models because the older specular version is 'backwards compatible' with classic Doom lighting, while the PBR one is not. That means you can much better get away with having only specular textures defined for some of your materials. For PBR it is an all or nothing proposition.
Physically-based-rendering, or PBR for short, is a newer model that is more physically accurate. It is what newer engines uses, such Unreal Engine 4 and Unity. The textures looks better under varying light conditions compared to the more classic model, but also require more texturing work. Here's a link to a general description of PBR: https://www.marmoset.co/posts/basic-the ... rendering/
I recommend you choose only one of the models for a project. The reason being that dynamic lights hitting surfaces of one type reacts slightly different than if hit by the other. If the light in a scene isn't consistent then you could end up with visuals much worse than if you either had not used any of them, or if you had sticked to just specular textures. I added support for both models because the older specular version is 'backwards compatible' with classic Doom lighting, while the PBR one is not. That means you can much better get away with having only specular textures defined for some of your materials. For PBR it is an all or nothing proposition.
- Ozymandias81
- Posts: 2063
- Joined: Thu Jul 04, 2013 8:01 am
- Graphics Processor: nVidia with Vulkan support
- Location: Mount Olympus, Mars
- Contact:
Re: Material auto folders on full path textures don't work
Thanks dpJudas, will take care of your precious suggestions and try to follow them as faithful as possible.
EDIT: So as a feedback, what do you think is the best solution for us visually? How much all of this would impact performance-wise? Also noticed that metallic maps which aren't combined with specular seems to suffer of some miscalculation materials seems to suffer of some issues/limits atm (these have all Ao/Normal/Metalness/Roughness materials)
And btw concerning explanations for Specular maps, found this, and it seems to work pretty well (that Eagle uses a diffuse map with inverted colors as Specular map + normal)
EDIT: So as a feedback, what do you think is the best solution for us visually? How much all of this would impact performance-wise? Also noticed that metallic maps which aren't combined with specular seems to suffer of some miscalculation materials seems to suffer of some issues/limits atm (these have all Ao/Normal/Metalness/Roughness materials)
And btw concerning explanations for Specular maps, found this, and it seems to work pretty well (that Eagle uses a diffuse map with inverted colors as Specular map + normal)