Talk:Shader Types and Parameters

Shaders

More parameter information on this section would be helpful - not sure if some of these shaders require certain params or not ... and not sure how i will know without insane amounts of trial and error

Perhaps each parameter should have three columns: Shaders that require it; Shaders that use it; Associated parameters

--Mungo 10:59, 21 Jul 2005 (PDT)

theres alot of missing stuff in this i just updated it a bit, but i suggest looking at

http://www.hl2world.com/wiki/index.php/Shader_Parameters

theres some things false there but theres more parameters.. lol also im starting a site with some freinds soon should help you guys out. http://lazydevs.com —Unsigned comment added by Pat Glynn (talk • contribs) Always sign your posts with four tildes (~~~~)

By now this list contains the entire contents of the hl2world list and then some. --Andreasen 06:30, 28 Jan 2008 (PST)

This list surprised me with some of the more obscure shader files (that I can't locate in my HL2 mod): http://www.inxbus.net/hldoc/dir_000138.html If you can figure out where to get files as "jojirium.cpp", please tell me. --Andreasen 12:47, 28 Jan 2008 (PST)

Finding Shader Types and Parameters

Whether you're verifying the existance of a fishy parameter, or trying to find new ones, it's going to be a bumpy road: We basically need the shader source code. Valve will give you most of that neccessary code if you create a mod. (Most is in the src/materialsystem/stdshaders/ folder.) Such files are also available online at places like Koders. (Just make sure that they're Source Engine files.) However, some working parameters (like "$selfillumtexture" and "$decalscale") are not found in this way. Shaders/parameters might possibly also vary from game to game.

Searching the gcf material files manually

Another way to find shaders/parameters (like the "predator" shader) is to check which are currently used for the games you have. This means unpacking the entire Source Materials.gcf file with something like GCFScape and searching its contents. (This is in case you are looking for shaders for regular Half-Life 2 materials. Shaders for materials in other games are found in other files, for example: counter-strike source shared.gcf, episode 1 shared.gcf, lostcoast content.gcf, half-life 2 deathmatch.gcf, half-life source.gcf or half-life deathmatch source.gcf. In this case, make sure to note down for which game you found the shader.)

Your method of search will depend on what type of Windows you are using.

If you are using Windows XP, be aware that your Explorer search engine is not able to search the contents of files not having the .txt file extention (which includes .vmt files). (It will simply skip these files.) As an alternative I recommend using the findstr DOS command instead. (Syntax: findstr /I /S stringtosearch *.*)

If you are using Windows Vista, your Explorer will search .vmt files if you add them to the index's list of filetypes. The same goes for CPP, H, and all other text files. (Thank you, TomEdwards.)

Also, you will need to verify the hits you get: Some lines that looks like they're shaders, are really something called Material Proxies, and should not be listed as shaders.

Again, Source Materials.gcf probably only contains the materials used by the game you have, and only the shaders/parameters currently in use. That's why parameters like "alienscale", "jellyfish" and "jojirium" still remains a mystery to me. If someone comes up with better ways to verify the existance of shaders/parameters, please let us know. --Andreasen 20:49, 23 Jan 2008 (PST)

Alot of these shaders can be found in the Source Leak, and I'd hazard a guess that unless they're actually used in any Source games, they're not production shaders and left there just... because they were made, I guess. I don't remember ever seeing materials using some of those shaders. Anyways, if you have the leak, you can look at the code and see what it does, or you can at least see parameters and try to figure out exactly what its used for. I also think that this page is very badly formatted anyway and really needs a look at, I'd propose that it get removed and give each shader its own page like LightmappedGeneric, but more detailed. Wraiyth 03:22, 24 Jan 2008 (PST)

Someone should verify if the unofficial shaders still work, but if even that fails, we should delete them from the list. The reason is that Valve feels very strongly about the leak, and don't want anything to do with supporting anyone who uses it. (Sites providing the leak has been deleted before.) ...but it's hard to tell which are unsupported, and which are just hard to get working, so what we really should do, is to ask Valve for help (with giving us (at least the names of) all the shaders available), because we don't seem to be able to do this on our own.

I don't think that this page should be removed, because it could be a good central page, linking the types together: People could click on a shader in the list, be linked to an individual shader page, from which they can click on one of its parameters to learn more about these on their page. --Andreasen 08:10, 24 Jan 2008 (PST)

If you can find someone from Valve to give us info about all the shaders, go ahead. But I think it would be easier for a community member to just utilized the leaked code, and if its the only way we can find out information, so be it. Wraiyth 16:46, 24 Jan 2008 (PST)

I told Jeff Lane about it (him being the most active Valve user at the wiki). If Valve decides against it, we should probably start to mark the shaders up with where we found the shaders. ("Source: Released in HL2 mod code.", "Source: Released in HL2 Ep1 mod code." "Source: Used in Source Materials.gcf.", "Source: Reported from leaked beta, but still found to work.", etc..) Unmarked shaders can be deleted in this way. --Andreasen 07:11, 25 Jan 2008 (PST)

OK, Come on now, you should really know better than this. Any more discussion of the stolen code will result in a permanent ban. I will talk to some of our engine programmers about getting some more documentation on the most useful shaders. Many of these are test or prototype shaders that are essentially useless for a mod developer and have no practical purpose. Various test shaders get created during game development. Chances are that if it wasn't used in materials in a shipping game, it's unfinished and of little use. Documentation purely for the sake of completeness with no real need is not a high priority. --JeffLane 13:50, 2 Feb 2008 (PST)

Didn't know it was forbidden to discuss here. It won't happen again. Just delete any beta shaders you find so we don't have to scratch our heads about it.

I'm not concerned with just useful shaders, because currently we have shaders that I doubt even exist in todays build, and there is probably no way for a regular user to verify which shaders doesn't exist anymore (unless you own all the games, I guess), no matter how useless they would be. --Andreasen 14:56, 10 Feb 2008 (PST)

Skybox rambling

A scribble about skyboxes, as I'm glancing over the vast amount of shaders:

A typical skybox is like this:

"UnlitGeneric"
{
	// Original shader: BaseTexture
	"$basetexture" "skybox/sky_borealis01lf"
	$ignorez 1
	"$nofog" 1
}

The last two parameters has not been mentioned in the article: $ignorez (Note the absence of quotation marks, as opposed to the "$ignorez" "1" in the HUD folder, or the "$ignorez" 1 in the hlmv folder.) and "$nofog". Let's guess: (By all means verify this before you modify the article.) $ingorez tells the rendering to ignore the Z buffer (I don't know what this means either.), and "$nofog" is probably so that the texture won't disappear at the otherwise maximum distance. (This might be what $ignorez is.) As for the stationary effect which is so typical of skyboxes, this might be simply because the name of the material has been input into the skybox field. Try it with a normal texture. --Andreasen 18:09, 20 Nov 2006 (PST)

Isn't Z Buffer what controls how far objects are away from you. Used to correctly render depth of field and such? --Frostbite 17:03, 24 Jan 2008 (PST)

I was quite "insane" when I wrote the above rambling, hoping to get around to checking it all out later, but fighting all the other things that hogged my attention. I had no idea, so you're probably right. You may delete the entire topic if you wish. --Andreasen 18:54, 24 Jan 2008 (PST)

Were Missing a paramater

glasswindowbreak070a has the property "$multipass" 1 what does it do? The computer I'm at is a little too low end to test it properly. --Angry Beaver 08:41, 22 Jan 2007 (PST)

My guess is that it allows decals or multiple textures to overlay on it.. --Frostbite 17:04, 24 Jan 2008 (PST)

Are these really shaders?

In my hunt for new shaders, I've found these: subrect, decalmodulate, Proxies, PlayerProximity, PlayerSpeed, PlayerPosition, PlayerLogo, Subtract, Clamp, GaussianNoise, Multiply, Equals, Add, Sine ...but the latter doesn't really sound like shaders. How can I tell whether they are shaders or something else?? I could very well have screwed up the list by adding entries that aren't shaders. --Andreasen 21:02, 25 Jan 2008 (PST)

Where did you find these shaders? Basically, the shaders are what can be used in a material file (DecalModulate is definitely one, just look up the Decal page on the Wiki and you'll see a material using it). That doesn't include Material Proxies, which some of those might be. Anyways, I've also updated a few of the shaders that I knew off the top of my head, but I'll probably have a look into alot of the others sometime soon. Wraiyth 16:31, 26 Jan 2008 (PST)

Yes, some are most certainly proxies - sorry about that. I'll verify and remove them in the next couple of hours. (Got held back by my gf.) On another note, I've removed the duplicate that you created of this page. I guess these things happen. --Andreasen 06:30, 28 Jan 2008 (PST)

I created a duplicate? Hm. Thats no good. Oh well. Wraiyth 15:23, 28 Jan 2008 (PST)

Splitting the list up into folder pages

I've been busy. I've found numerous new shaders. In fact so many, specialized so narrowly, that I don't think that one major list would be a good idea. It would simply get too long. We could do a split according to which letter the shaders begin with, but that would put the specialized shaders that no one needs, on the same terms as the generic shaders. A better solution, according to me, would be to split the shader list up according to the folders the shaders appear in, listing the specific shaders for that category, while linking to the others. I've already documented the less general folders in detail ("cable\", "Debug\", "Decals\", "Dev\", "Editor\", "Engine\", "hlmv\", "HUD\", "particle\", "scripted\", "shadertest\", "Tools\" and "VGUI\"). This left behind a very small and simple list of general shaders (and a few specialized ones for folders I lack the strength to document because of their size) that can be listed here without bothering viewers with mostly irrelevant/useless ones. Now I'm just awaiting your approval (or lack of protests) because this is a pretty uncommon split, into several pages. --Andreasen 21:29, 29 Jan 2008 (PST)

It's not a bad idea I guess, but in the long run it might become harder to document and maintain. In what regards to the article titles, I think we shouldn't stick with names that can "easily" (read, arbitrarily) change from one SDK/Engine version to the other (I'm referring to the folder names). It could also cause some articles to have very long lists (folders with lots of shaders), and others with very few of them.

I don't know a thing about shaders and I have no idea about how to organize this, but is something like Console Command List or List of entities not possible? I.e. having one page with a simple list (no details, or very few details) and then an article for each shader, with full information about it (if there's little information about each shader it's probably not a good idea... but the article on that shader can be filled with syntax reference, (code) examples, a picture exemplifying what that particular shader does in-game, etc... That way each shader would have its own page, which won't be a problem, since shaders (I believe) are unique (there aren't two shaders with the same name, I guess...) Bring me down to earth if I'm not being realistic and/or completely missing the point here :P --Etset 02:24, 30 Jan 2008 (PST)

If you (for whatever reason) are looking for just a name reference list, you might like the Category [Category:List_of_Shaders]. (It should probably just read [Category:Shaders] though.) That list is very small right now, but is meant to be expanded to contain all the links to individual shaders. (It don't think that anyone would bother finishing it though, or use such a list, because of the uselessness of 95% of the shaders, but there you have it.)

With that list under way, one also has to make a list for people who would like to make a material, but don't know which shaders to choose from, or which shaders are relevant or even at all working/supported (this in the same way that console variables are split up into categories of usefulness).

To get hit by a wall of names at this stage of the learning process (like I was), where most shaders (90-95%) will never be relevant, or might not even work, is very discouraging. (Unless you're doing something odd, there's only LightmappedGeneric, VertexLitGeneric and UnlitGeneric to worry about, and it will then be long before you dwell into more specialized things like Water or WorldTwoTextureBlend. It doesn't get more complicated than that unless you are looking to out-code Valve in shader technology (Bloom), or simply looking into making funky debugging effects (Wireframe) even funkier.)

Changing article titles in this wiki is not as hard as it is for Valve to change folder standards. In fact, I don't think Valve would dare to remove or move the contents of Source Materials.gcf as this could have unforseen ramifications to just about every mod made for the Source engine, making their users very upset. (If your map can no longer find the Valve-made materials in that file, Source will cease to display them in-game.) That's probably why they haven't removed what clearly looks like beta shaders.

I still expect updates to these folders though: A few new shaders will be added with the release of new episodes. (We'll be seeing such an update soon, and as I don't have Episode 2, I will not be able to update those folders.) Still, adding new shaders to a folder-based system isn't harder than adding them to a one-list system: If you find it in a folder, you list it in that folder, and if someone comes along and does a search of the gcf, finding out that another more relevant folder uses it more, the shader is moved only once before it settles.

If you believe that this categorizing involves multiple documentations of the same shader, that is not so. The relevant shader will only be documented either on its individual page, or in its more relevant folder. Other folders listing the shader will just provide a link to it.

I don't get the point of the length of the lists: One single list is the maximum length, and any category splitting it up (however long) would be shorter than that list. Some folders would contain less than others - I don't see where you are going with this. Some folders would instead contain more, but no more than perhaps 20 shaders (of which 75% is used exclusively for that folder only). If the size of a folder article would bother someone (due to (rare) extensive documentation) they are free to move the shaders to their individual pages and just link to them from that folder - that's no problem what-so-ever. --Andreasen 09:17, 30 Jan 2008 (PST)

I see your point. I wasn't trying to work against it, simply offering an alternative. But having read your (overwhelmingly huge!) reply, I can say that I agree with your idea; my point (still) being that each shader eventually ends up in its own specific page (just for himself and information about it), regardless of where it exists materially (i.e. where it can be found in the game files). That way you can easily implement what you suggest: an article that images a specific folder, and in that article one can find all the links (not the information itself... I'll come to that in a second) to the individual shader articles.

If a shader can be found in more than one folder, it is obvious that there might be a problem of documenting it twice (or more), which (like you suggest) is resolved by simply linking to that shader's individual page. But this could mean that the "folder article" would hold both documentation for some shaders (those with no individual page) and links to those shaders with individual pages. This is, documentation-wise, a mixture of two types of organization that I believe should be avoided, for both presentation and documentation maintenance purposes.

Having said that, I want to stress that I don't rule out the need/benefit of having these "folder articles", just that my opinion is that eventually each individual shader should have it's own page, rather than one specific folder documenting that specific shader (which I find restrictive given, for example, the possibility that a shader might be present in more than one folder). I truly believe it's much better to organize things that way.

Don't get me wrong here, I'm just trying to help. Again, shaders is something of which I know less than little, so I want to encourage you to see this through! I believe everyone here appreciates your dedication, and I'm no exception. Cheers!

Sidenote: That thing with Category:List of Shaders and Category:Shaders probably needs some tidying up. The latter is currently holding a series of tutorials, and that's more appropriate in an article (like, say, Your First Map, which is the "front page" for the whole tutorial). But throwing every Category:List of Shaders article into Category:Shaders would probably mean doing the same thing to Category:List of Shader Parameters, and that would simply bloat the category out of proportions (especially when (if) there is a "complete" list of shaders). Do you think it's a good solution anyway? --Etset 10:24, 30 Jan 2008 (PST)

By the way, I was just noticing something and you might be the right person to ask: currently, Category:List of Shader Parameters is categorized under Category:VMT_Commands, which has no articles under it. My question is: are there any "VMT Commands" that aren't Shader Parameters or names of Shaders? If so, Category:VMT_Commands is a redundant category (it could be an article instead of a category, right?). Otherwise, it's just lacking extra documentation :) --Etset 10:32, 30 Jan 2008 (PST)

I'm not standing in the way of each shader getting its own page. (If each shader would get its own documentation but still be in the same folder page, the folder pages would be even large than this page currently is.) I'm just saying that until that happens, the folder pages can serve as documentation pages as well, or else numerous stub pages would have to be created based on basically no information at all.

A clear "Dedicated Shaders" header of the folder articles is meant to separate those shaders intended for documentation from those documented elsewhere, so I'm not expecting a problem with shaders being documented twice. This is "mixing types", but that's also what this "big list" article is doing as we speak - it contains names as well as information. Sometimes this documentation is clearly too big for the list, but not big enough for the shader to get its own article page, so that's why I'm creating this middle ground, if only for the time being.

I didn't know there existed a Category:Shaders category - it's as simple as that. I'm wrestling with the idea of renaming all the articles about shaders to Category:Shader Tutorials, and then Category:List of Shaders to Category:Shaders, but it's a matter of taste that doesn't bother me enough to focus on. I'm just going to write the folder pages and leave it at that.

As for VMT "commands", there are shaders (and fallback shaders), there are their parameters, there are Material Proxies and their parametes, and there is also "%" and "//", which is preceeded by comments of various use, and there might still be some category that I've missed due to being somewhat new to VMT files. ...so yes, it's lacking entries - probably hundreds of them. =) --Andreasen 17:13, 30 Jan 2008 (PST)

Alrighty then! If no one else opposes, let's get this show on the road! :) About that thing with all of the Shader categories, I think yours would be a good solution. I'm giving it some though and I might do what you suggested in a few days, unless someone has something else in mind. Cheers! --Etset 03:31, 31 Jan 2008 (PST)

Okay, I've created the folder articles. I'll wait a couple of hours before I start removing the double entries from the main list. (I got a "priority interrupt" again, but this will provide chance for some criticism too.) The resulting list will be very small and useful. I had to rush some things in order to get the folders done in time. For instance I've linked many shaders to this page instead of their future folder, but currently that works out as it should. --Andreasen 10:39, 31 Jan 2008 (PST)

There: It should look shorter now. What is basically making it long now are strange shaders I can't find sources for, and possibly also Material Proxies. I'll remove the proxies in a couple of days, and also move the seemingly non-existant shaders into their own folder. (Not able to do it right away.) --Andreasen 20:34, 31 Jan 2008 (PST)

Shader/Parameter Sources

This is the beginning of a temporary list (at least until Valve decides for or against releasing all the shaders), detailing where the shaders/parameters are found. This list is particularly useful in locating shaders/parameters not released in the HL2 mod code (but still found to be working), not used in the gcf, or simply not used as much. (So far the list covers all the shaders currently listed in the main article, listed alphabetically. Feel free to add to it if you spot any new ones.) --Andreasen 11:04, 28 Jan 2008 (PST)

This is a list too huge to be listed here, so I moved it here. --Andreasen 18:55, 10 Feb 2008 (PST)

Split up shaders and parameters? Why parameters at all?

I guess the user who created this page didn't expect the shaders or parameters to be so very numerous, so he thought that he could jam all the shaders and all the parameters into one single page and still keep it a reasonable size. Of course this isn't possible, and now I'm wondering if it's okay to at least split up the page into two subpages: Shader Types and Shader Parameters. (...linking them back to this page as a main page, perhaps?) However, aren't parameters dependent on what shader you are using? The source code seems to suggest this. If so, shouldn't they be listed in the documentation of these shaders instead? Just asking. --Andreasen 10:44, 11 Feb 2008 (PST)

Hey. I've been working (recently) on trying to set up some infrastructure for Category talk:List of Shader Parameters. Had I known what I was taking on ... but anyway. It strikes me that if either Shaders or Shader Parameters were built as Categories, getting the corresponding links might be less painful? I'm also thinking that using template tags to label & categorise pages at the same time could save some work and makes it easy to have a page listed in a main category and a subcategory - eg using an 'VMT_LMG' template to list page in both Shader_Parameters and LightMappedGeneric categories ... and it was me who started the VMT command thing, which is probably a poor choice of words - template tags on pages instead of category tags would make this much easier to fix. AFAIK VMT is the only way to play with Shaders, and it's easier to write than 'Shader Parameters' ;-) Anyways - I'm on board and awaiting instructions. --Beeswax 18:31, 5 Apr 2008 (PDT)

One trick I have been using so far is creating loads of #REDIRECT pages, eg $basetexturetransform redirects to $basetexture#basetexturetransform. This creates placeholders which the wiki search engine can understand. IMO this is good in the long run (it took me ages to find the broken link for the Modulation shader ;-). Quite a few times I've offloaded a section into it's own page, and back again! without mucking up the indexing system. #REDIRECTS, like template tags, are more flexible than conventional weapons ;) and for a task of this complexity on this scale, I think the extra server queries they generate are justified. Unfortunately #REDIRECTs don't show up in Category lists :-( --Beeswax 18:31, 5 Apr 2008 (PDT)

Difference between Shaders/Fallbacks?

After finding the Half-Life 2 Shader Fallbacks article, I'm confused. With shaders sometimes being used as fallback shaders and vice versa, how am I supposed to know which ones are supposed to go in which list?? As it is now, I put fallback shaders into the Shader list. If this is wrong, please tell me how to tell the difference. --Andreasen 09:56, 12 Feb 2008 (PST)