Material auto folders on full path textures don't work

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!

Post a reply

Smilies
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :geek: :ugeek: :!: :?: :idea: :arrow: :| :mrgreen: :3: :wub: >:( :blergh:
View more smilies

BBCode is ON
[img] is OFF
[url] is ON
Smilies are ON

Topic review
   

Expand view Topic review: Material auto folders on full path textures don't work

Re: Material auto folders on full path textures don't work

by Graf Zahl » Sat Mar 31, 2018 4:12 am

Due to different semantics between normal short-name textures and long-name textures this can only be done when the files are put in a different directory.
Fortunately the current path names are new, so I suggest for full path names to leave out the 'auto', and for brightmaps look in 'materials/brightmaps' and append the full path there.


So in case you use 'textures/scenery/skies/mountains.png' the brightmap would be looked up in 'materials/brightmaps/textures/scenery/skies/mountains.*' with '*' one of the common extensions. This won't be in the next point release, though, it has to wait until the next minor release, i.e. 3.4.0, because it requires a bit more changes to allow proper lookup of the files (the resource manager has no list to look after long file names without an extension and will require a new hash list for that.)

Re: Material auto folders on full path textures don't work

by Ozymandias81 » Fri Mar 09, 2018 6:03 am

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)

Re: Material auto folders on full path textures don't work

by dpJudas » Thu Mar 08, 2018 4:46 pm

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.

Re: Material auto folders on full path textures don't work

by Tormentor667 » Thu Mar 08, 2018 3:15 pm

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.
What is actually the difference between both variants?

Re: Material auto folders on full path textures don't work

by dpJudas » Thu Mar 08, 2018 3:37 am

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.

Re: Material auto folders on full path textures don't work

by Talon1024 » Wed Mar 07, 2018 11:14 pm

Re: Material auto folders on full path textures don't work

by Gez » Wed Mar 07, 2018 8:24 pm

Dunno, try it and see!

Re: Material auto folders on full path textures don't work

by Major Cooke » Wed Mar 07, 2018 7:06 pm

Gez wrote:If you want to match texture textures/longnamefoobar.png, you'll have to use materials/brightmaps/auto/textures/longnamefoobar.png I guess.
That'll actually work?

Re: Material auto folders on full path textures don't work

by Nash » Wed Mar 07, 2018 6:06 pm

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.

Re: Material auto folders on full path textures don't work

by Gez » Wed Mar 07, 2018 12:01 pm

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.
I'm pretty sure the engine already treats them as different textures so you get twice the RAM usage from this inconsistency.

Re: Material auto folders on full path textures don't work

by Tormentor667 » Wed Mar 07, 2018 11:52 am

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.
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.

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

by Gez » Wed Mar 07, 2018 5:54 am

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.

Re: Material auto folders on full path textures don't work

by Ozymandias81 » Wed Mar 07, 2018 5:41 am

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

by Tormentor667 » Wed Mar 07, 2018 4:41 am

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.

Re: Material auto folders on full path textures don't work

by dpJudas » Wed Mar 07, 2018 3:36 am

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?

Top