View source for Talk:Glowing textures (Source)

Hope I'm right about the .rad stuff. This is done from memory and I had no way to test and all my forums i woulda checked are blocked at work. Can someone see if its right? [[User:Angry Beaver|Angry Beaver]] 06:37, 12 Jun 2006 (PDT)

:I've been fiddling with it for the last couple days, and everything mostly seems right.  I did notice that when I use the lights.rad method, the texture doesn't self-illuminate.  So to have realistic-looking texture lights, I had to use both the lights.rad method and the $selfillum method.  Furthermore, if my alpha channel was pure white, my texture didn't self-illuminate.  Making an alpha channel that had an rgb value of 253,253,253, however, did work. [[User:Greeze|Greeze]] 18:52, 29 Jun 2006 (PDT)

::Are you sure your image editor doesn't cull pure white alpha channels? It may also be that vtex just assumes it's for transparency and culls it.&mdash;'''[[User:Ts2do|ts2do]]''' 19:53, 29 Jun 2006 (PDT)

:::Photoshop is my image editor, and I would assume it retains alpha channels as shown.  Re-opening the .tga restores the alpha channel exactly as it was.  So I'm guessing it's either vtex or the game engine that doesn't like the pure-white alpha channel.  It's all academic anyway, since if one really wanted a fullbright texture, one would use the UnlitGeneric shader.  For me, the full white alpha was a temporary step for testing purposes only. [[User:Greeze|Greeze]] 19:56, 2 Jul 2006 (PDT)

:::Another quick note... it seems that having a single non-pure-white pixel anywhere in the alpha channel fixes the problem. [[User:Greeze|Greeze]] 20:00, 2 Jul 2006 (PDT)

:::Another thing I noticed is that detail brushes don't cast light.  They will self-illuminate, however. [[User:Greeze|Greeze]] 19:58, 2 Jul 2006 (PDT)

== "Supported for legacy purposes" ==

Texture lighting generally looks a lot better, is a lot more easier to do, and therefore a lot more practical. I don't think it's appropriate to say it's an "old method supported for legacy purposes", however that could be applied to light entities. Light entities are clumsy when compared to texture lighting. [[User:JJ45|JJ45]] 12:38, 2 Mar 2007 (PST)
:I disagree on the looks better, and you loose and exorbarant ammount of control when you use texture lighting aswell. sure placing them is a little clumsy but I've never had much of an issue doing it as clone has been implemented. Remove it if you feel its not neccersarily correct, we all want accuracy. --[[User:Angry Beaver|Angry Beaver]] 11:53, 4 Mar 2007 (PST)
:I never mapped for the original HL very extensively, but I still wouldn't say that texture lights are just for legacy support. Their lighting results are unique and they can also serve for other purposes, for instance to reduce the number of light entities placed in a map. I'm here reading this article because I have to lower the entdata of my map, and replacing strings of light entities with a texture light surface has almost gotten my entdata below 100%. It just sucks that you don't have more control over the light generated by lights.rad. --[[User:SM Sith Lord|SM Sith Lord]] 16:07, 6 Apr 2008 (PDT)

== lights/white001_nochop? ==

What difference does the ''_nochop'' add to the ''white001'' selfillum texture? --[[User:Mattshu|Mattshu]] 02:24, 25 February 2011 (UTC)
:Hopefully my guess is somewhere close to the truth: Small textures tessalating many times over on a brush face, will make your graphics card work more, because instead of rendering two just two texture faces, it would have to render 200 texture faces on the same brush surface. In the case of self-illuminating textures, this also means adding a ''lightsource'' for every texture face, creating a huge compile impact. Early on when Half-Life 2 was released, players complained about choppiness, so I guess Valve did everything they could to limit this, resulting in many tweaks. The nochop texture may be one of those tweaks. This is just speculation, though. The only way for you to know for sure, is to compare the FPS's of those two textures. --[[User:MossyBucket|MossyBucket (formerly Andreasen)]] 03:52, 25 February 2011 (UTC)


== $selfillum doesn't work on LightmappedGeneric (brushes)? ==

Can't get it to work on brushes. Maybe it is not supported on LightmappedGeneric shader? --[[User:NvC DmN CH|NvC DmN CH]] ([[User talk:NvC DmN CH|talk]]) 11:05, 26 January 2019 (UTC)

: Requires a $selfillummask to work, note that the mask is inverted (or not, I don't remember) compared to vertexlitgeneric [[User:Ficool2|Ficool2]] ([[User talk:Ficool2|talk]]) 11:47, 26 January 2019 (UTC)

:: Yeah i use $selfillummask, tried with $selfillumtexture as well. Works fine on models, but not on brushes. --[[User:NvC DmN CH|NvC DmN CH]] ([[User talk:NvC DmN CH|talk]]) 15:56, 26 January 2019 (UTC)
::: Figured it out. Yet im not sure if i should edit the page. Using a $selfillummask on LightmappedGeneric doesn't work. LightmappedGeneric should use the alpha of the $basetexture (just doing a $selfillum 1 and having an alpha channel in the $basetexture will work) --[[User:NvC DmN CH|NvC DmN CH]] ([[User talk:NvC DmN CH|talk]]) 03:34, 5 February 2019 (UTC)

== Cubemap method ==

Supposedly having a bright manually-defined cubemap will also work as a selfillum workaround. Will try to remember to test.<br/>— [[User:SirYodaJedi|SirYodaJedi]] ([[User_talk:SirYodaJedi|talk]]) 07:32, 22 March 2024 (PDT)