I'm still confused as to options are available to me as a texture artist. I know there's a lot of good information above, but I'm not a programmer; I'm an artist. Is there a more detailed explaination of this procedure available? Or maybe, a program designed where I can enter the types of material effects I'm looking for (i.e. metallic, shiny, whatever) and have the code generated for me?
You want VTFEdit.
This article could use a lot more information about how to write proper VMT files, and the basic parameters that can be added. --JeffLane 09:09, 19 Jul 2005 (PDT)
- Though on second thought, this has gotten pretty long, so any new information should probably be linked instead of added. It may have to be divided up at some point. The sections on creating .VMT files and .TXT parameters could probably be pulled out into their own smaller articles, for example. --JeffLane 14:34, 19 Jul 2005 (PDT)
- Agreeing: I'm thinking this page should just describe what a material is. Everything describing the creation of a material could be moved to a "Material Creation", and details about Vtex should be put on the Vtex page. Too bad I got the flu and a faulty monitor, or I would have fixed it myself. --Andreasen 14:35, 27 Aug 2007 (PDT)
Does anyone know how to force the render order of translucent/additive textures? When I have multiple transparent textures in front of one another, the game gets confused about which is in front of the other and flips between them based on the view angle. Is there a shader parameter to force the game get it right? --Mungo 10:29, 23 Jul 2005 (PDT)
- That would be interesting, Modal/TopMost for textures. I've noticed that my nVidia GeForce card does a lot better job of this than my ATI Radeon, might be system specific. --wisemx 10:53, 23 Jul 2005 (PDT)
- This is called a "sorting issue". It all depends on what type of object the material is applied to. Some classes of objects, such as standard world brushes and func_detail, are rendered (and sorted) together for speed reasons. Same goes for models (a single model is rendered as a batch). When this happens, the hardware has a hard time "sorting" -- determining what object with a translucent material should be rendered last (in front).
- One way to force a brush object to render seperately is to make it a brush entity, such as a func_brush. This obviously has its own share of limitations, including reduced performance and lighting differences, so it's not always a solution.
- The only way I know of to fix this in the .VMT itself is to make the material alphatested instead of alphablended, which has a high visual cost. Regardless, no simple addition to the .VMT will fix this problem without a performance or visual quality penalty. --JeffLane 15:43, 23 Jul 2005 (PDT)
- Thanks a lot. I should also mention that this is occurring in the 3D skybox specifically. There are two separate props I'm using in the sky. Could that be part of the problem? Do the shader parameters "$writez" and "$comparez" have anything to do with this? --Mungo 19:29, 23 Jul 2005 (PDT)
- I'm looking into the exact function of these variable for correctness, but no, I don't believe they will help you in this case. Dynamic props are not included in cubemap rendering because they are by definition dynamic, and may not always be present in the scene, which would make the cubemaps be an incorrect rendering. If you need it to be in the cubemap, you should make it a prop_static. --JeffLane 17:20, 25 Jul 2005 (PDT)
Binding VMT/VTF files to map
I created a decal for my map, but when I was serving the map and someone connected to my server, they couldn't see my decal, because the decal files didn't get transferred to their computer. I guess I could set up MY server so that the client is required to download the file, but if someone else is using the map on their server, they won't necessarily do that for their server and the decal will be lost. Thanks.
- Create a resfile --Pon 01:12, 24 Sep 2005 (PDT)
- You can also embed the decal inside your map using bspzip. Kodak 17:36, 9 May 2006 (PDT)
This targa type didn't work. Vtex thought this type was "bogus". 24 and 32 bits/pixel types worked fine though. Edit: Tested this again with a similar texture, and got the same results: 24- and 32-bits pass, while 16-bits fail Vtex convertion. Unless you have gotten 16-bits to work, the article should exclude 16-bits as an option. --Andreasen 22:52, 21 Oct 2006 (PDT)
- Edited out 16-bits/pixel. --Andreasen 14:28, 27 Aug 2007 (PDT)
Are there any examples of what the "nice filter" does? --TomEdwards 07:10, 22 Apr 2007 (PDT)
- Yes. It does nice things. :P
- Nah, might do some filter stuff like in photoshop. No idea really. --Sortie 02:39, 25 Apr 2007 (PDT)
merge with VMT?
It seems to me that "Material" by itself is such a common word it is too vague for use in technical documentation:
- "Material" is often used simply as shorthand for "Valve Material Type" (a specific set of Brush/Mesh Surface Properties), for which VMT is a specific, accurate, and concise term.
- "materials" may also refer to the
- "material" is also unavoidably in common use on the VDC, eg "reference material" or "assemble your tools and materials ...".
- Strictly speaking the "material that a world object is made of" is a physical and procedural property, not just a surface property of an object. Prop Data is an important part of the "World" Material System but it is defined in QC rather than VMT. Many VMTs describe non-physical surfaces; eg those in the
So unless I've missed something, I would like to propose merging the "Material" into the "VMT" article, and possibly renaming it Valve Material Type. A Human-readable explanation of "materials folder contains Valve Material Type (VMT) files" should go in a Material System Introduction and/or the Glossary. --Beeswax 10:57, 4 Apr 2008 (PDT)
- Sounds good to me.--Gear 13:41, 4 Apr 2008 (PDT)