Talk:Decals: Difference between revisions

From Valve Developer Community
Jump to navigation Jump to search
m (SirYodaJedi moved page Talk:Decals to Talk:Decals/en)
 
(3 intermediate revisions by 3 users not shown)
Line 16: Line 16:


:Are you SURE you put them in the correct folder? I've once done the mistake to put it in the "steamapps\<username>\half-life 2 episode two\hl2\materials" folder instead of "steamapps\<username>\half-life 2 episode two\ep2\materials". Be sure to use the correct folder. I currently have custom decals for ep2, and they all work. --[[User:Pandaboy|Pandaboy]] 02:49, 17 November 2011 (PST)
:Are you SURE you put them in the correct folder? I've once done the mistake to put it in the "steamapps\<username>\half-life 2 episode two\hl2\materials" folder instead of "steamapps\<username>\half-life 2 episode two\ep2\materials". Be sure to use the correct folder. I currently have custom decals for ep2, and they all work. --[[User:Pandaboy|Pandaboy]] 02:49, 17 November 2011 (PST)
== On 'removed' vs 'broken' material params ==
This is about the edit I [https://developer.valvesoftware.com/w/index.php?title=Decals&diff=487990&oldid=487989 partially reverted]. I'll describe how I see the situation.
The two material params, <code>$decalfadetime</code> and <code>$decalfadeduration</code>, can't be found in the public code, because they're not shader params, they're VMT params that are supposed to be looked up by the engine code. I'll be referencing what can be seen in the leaked code available on the Internet.
In Source 2007 these two params worked for various decals like the Buggy tau-cannon impact glow, because <code>engine/r_decal.cpp</code> looked up these two params to determine how the decal should fade out. It was always the intention that some decals should fade out, and the material params were always present in the VMTs, even after they stopped working.
The code that looks it up was later rewritten; it is different in Source 2013. It is true that the particular bit that looks them up, was 'removed'. However it can be clearly seen that <code>engine/r_decal.cpp</code> still does contain variables <code>decalinfo->m_flFadeDuration</code>, <code>decalinfo->m_flFadeStartTime</code>, and the block that references these is commented as <code>// Get dynamic information from the material (fade start, fade time)</code>.
However, they're initially set to 0, and then no call is made to set them to the material variable from the VMT, which was the case in Source 2007. So it's not so much 'removed' in the same way DX7 support was removed, or [[env_terrainmorph]], or [[npc_ministrider]]. I would say this is indeed a broken feature now, as the code required for it was only partially completed when it was being rewritten. So, that's why I think it should be pointed out it's ''broken'' in Source 2013, not just removed. If they wanted it removed, why even keep the internal variables that are never updated?
Then there are the other two params, <code>$decalsecondpass</code> and <code>$decaldynamicscale</code>. They are also looked up by the engine, in the same file, in Source 2007. One sets the decal flag <code>FDECAL_SECONDPASS</code> and the other <code>FDECAL_DISTANCESCALE</code>. Again, Source 2013 lacks the code that sets these flags, but it does have the code that ''checks'' these flags. It's more ambiguous just how intentional the removal of these was, so I decided not to meddle with them. With the decal fade, I spent a while in the past figuring out just how it worked and how Valve broke it, so I felt I know well enough to partially revert the edit. With these two I decided not to. [[User:Cvoxalury|Cvoxalury]] ([[User talk:Cvoxalury|talk]]) 06:00, 4 September 2025 (PDT)

Latest revision as of 06:00, 4 September 2025

What's the deal with decals that go on models? Mine get repeated and weird.. Garry

dynamic footprint decals

On some snowy Counter Strike maps, players would leave a trail of footprints in the snow ... the footprints always seemed to follow the direction of the player ... does anyone know how is this done ? Beeswax

normal-mapped decals

Has anyone managed to get decals with their own normalmaps to work? So far my experiments have all failed, with the decal not rendering correctly. --Beeswax 19:05, 23 Apr 2008 (PDT)

I don't think decals are supposed to have normalmaps. It simply does not work. Decals are also very limited when trying to make them reflective - I only managed to get it to work when making the material an "unlitgeneric", and it can't have an $envmapmask. --Pandaboy 02:44, 17 November 2011 (PST)

Decals in Half Life 2 Ep. 2 Engine

Does anyone know where to place the materials so one can use them in Hammer when you are using the Ep. 2 engine? I've tried making a materials folder with a decals folder inside that with my decals in that in most of the main game folders (HL2 and episodes) but it doesn't even turn up on the browser. --Alfonzo 10/10/08, 6:55pm

   - Apparently you have to put them in the Ep. 1 folder. I have no king but Caesar.
Are you SURE you put them in the correct folder? I've once done the mistake to put it in the "steamapps\<username>\half-life 2 episode two\hl2\materials" folder instead of "steamapps\<username>\half-life 2 episode two\ep2\materials". Be sure to use the correct folder. I currently have custom decals for ep2, and they all work. --Pandaboy 02:49, 17 November 2011 (PST)

On 'removed' vs 'broken' material params

This is about the edit I partially reverted. I'll describe how I see the situation.

The two material params, $decalfadetime and $decalfadeduration, can't be found in the public code, because they're not shader params, they're VMT params that are supposed to be looked up by the engine code. I'll be referencing what can be seen in the leaked code available on the Internet.

In Source 2007 these two params worked for various decals like the Buggy tau-cannon impact glow, because engine/r_decal.cpp looked up these two params to determine how the decal should fade out. It was always the intention that some decals should fade out, and the material params were always present in the VMTs, even after they stopped working.

The code that looks it up was later rewritten; it is different in Source 2013. It is true that the particular bit that looks them up, was 'removed'. However it can be clearly seen that engine/r_decal.cpp still does contain variables decalinfo->m_flFadeDuration, decalinfo->m_flFadeStartTime, and the block that references these is commented as // Get dynamic information from the material (fade start, fade time).

However, they're initially set to 0, and then no call is made to set them to the material variable from the VMT, which was the case in Source 2007. So it's not so much 'removed' in the same way DX7 support was removed, or env_terrainmorph, or npc_ministrider. I would say this is indeed a broken feature now, as the code required for it was only partially completed when it was being rewritten. So, that's why I think it should be pointed out it's broken in Source 2013, not just removed. If they wanted it removed, why even keep the internal variables that are never updated?

Then there are the other two params, $decalsecondpass and $decaldynamicscale. They are also looked up by the engine, in the same file, in Source 2007. One sets the decal flag FDECAL_SECONDPASS and the other FDECAL_DISTANCESCALE. Again, Source 2013 lacks the code that sets these flags, but it does have the code that checks these flags. It's more ambiguous just how intentional the removal of these was, so I decided not to meddle with them. With the decal fade, I spent a while in the past figuring out just how it worked and how Valve broke it, so I felt I know well enough to partially revert the edit. With these two I decided not to. Cvoxalury (talk) 06:00, 4 September 2025 (PDT)