Universal way of doing wet materials

[Dram]

I was just playing around with material files and have thought of an excellent way of doing wet textures for every material that could have it. This would be set by the mapper in the map and would mean that instead of having 2 materials - one for dray and one for wet, we could just have the one material and be able to set a shaderparm to make it wet. The other advantage of using a shaderparm for this is that you can through a map script make a room etc look gradually more dry or more wet, not to mention other effects, such as making a dry basin appear wet when it starts getting filled with water etc. You can also make it (through script) gradually get more and more wet, simply by incrementing the shaderparm.

 

I have used the in-engine texture (_white) for the wetness texture. This means it is applicable to all textures we currently have, and all it requires is to add it to the material file. I can do that if noone else wants to.

 

Here is a screenie of it in D3:

 

Here is the code in the material file:

	{
	if ( parm5 > 0 )
	blend	   specularmap
	map		 _white
rgb		 0.25 * parm5
}

 

By setting shaderparm5 you can control the wetness. Of course, it defaults to 0 (not wet), and by 1 it appears wet.

 

In the image above the settings are (from left to right):

 

0 (dry), 0.25, 0.5, 1 (wet), and 2 (too much)

 

Anyways, I'll tweak it further and see what I can get.

 

 

Of course, if this is implemented, it will not break anything, but textures with already existing speculars will need tweaking to work properly. The other only limitation is that this wetness property cannot be applied to worldspawn, so any surfaces using it would have to be part of an entity, such as func_static.

 

 

Hehehe, just imagine a wet AI or even better, the player weapons when you crawl out of a river and are drying off

[Dram]

Ok, after applying a modulate layer (to slightly change the colour of the diffuse):

 

 

Again, the values are the same. I have also applied a cap though, so above 1 it does not show wet (to avoid ugliness).

 

Here is the new code:

	{
	if ( ( parm5 > 0 ) && ( parm5 < 1.01 ) )
	blend	   specularmap
	map		 _white
rgb		 0.25 * parm5
}

{
	if ( ( parm5 > 0 ) && ( parm5 < 1.01 ) )
	blend	   modulate
	map		 _white
red		 1 - ( parm5 * 0.2 )
	green	   1 - ( parm5 * 0.3 )
	blue		1 - ( parm5 * 0.4 )
}

[Dram]

Excellent - just tested and if there are more specular maps then one it just basically adds them, so basically all that would need to be done to apply this to all existing textures is just paste the "wetness" code into each material entry and it can be used straight away.

[Dram]

...and HERE is an example of it's use in action (just a quick 3 minute made cave)

 

 

So what is everyone's opinion's on doing "wetness" this way as opposed to new material entries?

[New Horizon]

Well, that's pretty cool if it's flexible. So, once this code is place in the material entry...is it set from within the editor? It would be cool if we could make reference to it in the editor specifically as wetness...and all materials that have the code would show up or be tagged as compatible somehow.

[Dram]

Well, that's pretty cool if it's flexible. So, once this code is place in the material entry...is it set from within the editor? It would be cool if we could make reference to it in the editor specifically as wetness...and all materials that have the code would show up or be tagged as compatible somehow.

 

Basically yes. It is the same way I did the editor-configurable light-rays. So basically, let's say I want to make a cave look wet (like in the last shot) then all I do is make it a func_static and add the key/val pairs: "shaderParm5" "1". 0 is dry, 1 is wet, so anything in between is a bit wet etc.

 

As for the editor reference, you could just make it check the material file for a commented out line something line "//wetness" or something.

 

I think one of the nicest applications of this would be character and object wetness, where if you submerge them they become wet and slowly dry off afterwards. This part could be done from the SDK, as setting shaderparms in the sdk is no problem either.

[Ishtvan]

That sounds cool, but I'm curious how it would impact performance. If the parm is 0, the stuff inside the if is skipped, so does that mean it won't actually bring in the new image if the if statement is 0? But then how does it know to precache it when a material starts out with that parm as 0? Does it not have to because it's just the engine texture _white? Anyway, just curious what it would add to calculations. Is it just an extra boolean check on that parm for all textures?

[Dram]

That sounds cool, but I'm curious how it would impact performance. If the parm is 0, the stuff inside the if is skipped, so does that mean it won't actually bring in the new image if the if statement is 0? But then how does it know to precache it when a material starts out with that parm as 0? Does it not have to because it's just the engine texture _white? Anyway, just curious what it would add to calculations. Is it just an extra boolean check on that parm for all textures?

 

Many textures that are preloaded already use _white so precaching it is not a problem. Also, it is an engine texture so imo it would be 1 pixel, though I don't know for sure of course. I don't think it would really impact performance, all it does is add a modulate layer (which is basically a filter so should be really cheap), and a specular layer (which is calculated by default afaik anyway). It's actually a float not a boolean, but that is still quite cheap.

 

We'll have to performance test this I guess, but I doubt it will have any effect.

[Springheel]

Hmm, I don't know. When you see a high-spec version without a default to compare it to, it doesn't register as wet to me, it just looks strangely shiny. It might be interesting as some kind of blend over time, though I think that would have limited uses.

 

think one of the nicest applications of this would be character and object wetness, where if you submerge them they become wet and slowly dry off afterwards.

 

There's more to looking wet than just shine, however. If you just apply a high specular to an AI material, it wouldn't look wet at all (well, the metal, perhaps). Cloth doesn't get particularly shiny when wet, but it gets darker or more saturated. I think shiny cloth would just look like it turned into velvet or something.

It wouldn't work well for wood, either.

[Tels]

Hmm, I don't know. When you see a high-spec version without a default to compare it to, it doesn't register as wet to me, it just looks strangely shiny. It might be interesting as some kind of blend over time, though I think that would have limited uses.

There's more to looking wet than just shine, however. If you just apply a high specular to an AI material, it wouldn't look wet at all (well, the metal, perhaps). Cloth doesn't get particularly shiny when wet, but it gets darker or more saturated. I think shiny cloth would just look like it turned into velvet or something.

It wouldn't work well for wood, either.

 

I agree that the "wet" effect needs to be tweaked, as it looks just a bit more shiny to me. However, this is just some different shader for every material, so it can be done.

 

Being able to tweak it manually/scriptually is cool

 

Just a few general questions, tho:

 

* Is there a list of shaderparms and what they do? AFAIK we only have 15, so we will run out them. the wiki doesn't list them yet.

* in some material by angua I saw "FOO_MACRO". So I guess we can declare macros in materials, that wouldbe MUCH better f.i. for all the frob code that gets now pasted into every material. Likewise, I think defining macros for WET_WOOD, WET_CLOTH etc. would be usefull.

 

However, I don't know how and where to define these macros.

[SneaksieDave]

Perhaps a single (or a few, depending on need) generic 'wet' specular surfaces (some bumpy, some rocky, some grainy), instead of _white, would do the trick. Kinda like using generic detail textures for many surfaces.

[OrbWeaver]

* in some material by angua I saw "FOO_MACRO". So I guess we can declare macros in materials, that wouldbe MUCH better f.i. for all the frob code that gets now pasted into every material. Likewise, I think defining macros for WET_WOOD, WET_CLOTH etc. would be usefull.

 

Do you mean you actually saw "FOO_MACRO" or are you referring to "DECAL_MACRO"? The latter is a predefined macro from Doom 3, I am not aware that you can define your own macros.

[angua]

Do you mean you actually saw "FOO_MACRO" or are you referring to "DECAL_MACRO"? The latter is a predefined macro from Doom 3, I am not aware that you can define your own macros.

Ah well, I think that would be DECAL_MACRO then. (FOO_MACRO? What is foo anyway? Some kind of "blah"? ) This is a shortcut predefined from Doom3, meaning

 

polygonOffset 1

discrete

sort decal

noShadows

 

which is often used for decals. I don't think it would be that easy to define your own macros.

 

Regarding the wet textures: wet surfaces are often darker than dry surfaces, so I think it would make sense to darken the diffuse and additionally add a specularmap like you did already.

[Tels]

Do you mean you actually saw "FOO_MACRO" or are you referring to "DECAL_MACRO"? The latter is a predefined macro from Doom 3, I am not aware that you can define your own macros.

 

DECAL_MACRO it was - couldn't remember the name, so I used the universal placeholder:

 

http://en.wikipedia.org/wiki/Foo

 

Hm, do we have control over the parser? Defining our own macros would be a really good way to cut down on that horrible copy&paste and making it easier changing f.i. all definitions of "frob" etc.

 

If we can't do this, we could still build a preparser for materials. (I am toying around building a parser for some special stuff, anyway).

[Ishtvan]

Hm, do we have control over the parser?

No, we don't have access to the material parser. That's why we had to add that extra surface types crap in the description string, rather than just expand the existing bitfield, because description is the only customizable thing we get access to when we get our hands on a material reference in the SDK.