Talk:Detail props

From Valve Developer Community
Revision as of 06:40, 21 March 2013 by JorisCeoen (talk | contribs) (func_detail_blocker: new section)
Jump to: navigation, search

Is it still a bug?

Bug.png Bug: In Valve's code, detail textures at custom locations must be of the same aspect ratio as detail\detailsprites. You can fix this if you are shipping your own binaries.

I'm almost sure there's a width property in worldspawn now, right next to the custom detailsprites path. I'm not home though, I can't check right now. --NykO18 13:20, 13 November 2009 (UTC)

Not in OB. Are you working with L4D? --TomEdwards 19:32, 13 November 2009 (UTC)
Yes, but I won't be home until monday, so if someone could check for me, that would be great. --NykO18 00:08, 14 November 2009 (UTC)


I've noticed there is no article for detail props. Perhaps we should create one and merge it and this article together? (Splaty)

Anyone care to post a screenshot? —Maven (talk) 05:20, 28 Sep 2005 (PDT)

I've noticed those plants in DOD:S....but this article isn't should show an example...are these in hl2dm also? or just in the dods code—ts2do (talk) 06:17, 28 Sep 2005 (PDT)

Copied data on auto-emitting detail props from Prop_Types_Overview. Changed the category to level design (?). Altered the general formatting and layout, though it still seems a little fragmented. If anyone has an easier-to-follow explanation on detail props in general, this would probably make a comfortable home for it. --splayu 07:25, 28 Sep 2005 (PDT)

Added pictures. It's possible that the "cross" picture is actually a "tri", but with "shape_size" set to 1. If anyone has seen an actual "cross" (as in, only two sprites crossing over - as I originally thought "cross" was), I urge you to replace the existing cross image. Thanks. -splaty 08:19, 28 Sep 2005 (PDT)

The image of a cross is actually a tri, with a very small distance value. A cross is actually a 4 pointed star.—Matt Boone (talk) 12:08, 1 Nov 2005 (PST)

Nice job splatly—ts2do (talk) 17:38, 28 Sep 2005 (PDT)

Aren't detail sprites processed by the Vbsp? if so, we won't be able to compile the shapes and stuff...—ts2do (talk) 15:15, 1 Oct 2005 (PDT)

This is true. The current version of vbsp appears to be unable to correctly parse the new detail sprite settings. However, I'm expecting the next SDK update to have an upgrade to vbsp (and vrad - for HDR?) to compile maps for DoD: Source with all the new features. -splaty 14:12, 2 Oct 2005 (PDT)

plus vtf2tga doesn't support converting the hdr mats yet —ts2do (talk) 14:39, 2 Oct 2005 (PDT)

I see. In that case an SDK update should almost certainly be on the way, and it would be foolish to omit the necessary compile tool updates for using the new detail sprites. However, the question is, will VALVe be updating the other games (Half-Life 2, Counter-Strike and HL2DM) to use detail shapes? I am under the impression that they're going to update date them all for HDR, so it seems logical that the detail shapes would also be enabled too. -splaty 08:03, 3 Oct 2005 (PDT)

It appears this prediction (that the other Source games will be updated to work with detail shapes) is correct, as Counter-Strike: Source now supports detail shape technology (along with HDR). No word yet on the other games such as Half-Life 2: Deathmatch, but it seems logical to assume they too will be updated at some point. Likewise, I've seen no indication that this technology is available to mod authors in the SDK source code, though I imagine that both this and the more popular HDR technology will be added at some point in the future. If someone from VALVe personal could comment, that'd be great! -splaty 08:29, 2 Dec 2005 (PST)

It would be worth indicating which materials use detail props by default. This would be helpful for mappers who want to have detail props on their textures but do not wish to edit vmts to make their own. The following source materials will all emit detail props after compiling. I have also listed what detail group will be emitted. To see what these are, have a look in detail.vbsp (or compile a small map with the materials in place - perhaps a sample map with each material would be a useful thing to add).

blenddirtdirt001a	citygrass01
blenddirtgrass001b	grass01
blenddirtgrass005a	coastline_grass01
blenddirtgrass006a	coastline_grass01
blenddirtgrass008a	coastline_redgrass01
blendgrassgravel001a	coastline_redgrass02
blendgrassgravel001b	coastline_redgrass03
blendgrassgravel002a	coastline_redgrass02
blendmuddirt001a	coastline_redgrass01
blendrockgrass004a	coastline_redgrass01
blendsandgrass008a	coastline_grass01
blendsandrock004c	canal_reeds
blendsandsand008a	coastline_grass01
canal_reeds		canal_reeds
dirtfloor001a		citygrass01
red_grass		redgrass
red_grass_thin		redgrass_light
rocks_red_grass         rocks_redgrass
short_red_grass         short_redgrass

In some cases these are the same materials but with different detailtypes.

The following materials also have detail props, but the %detailtype string has been commented out with //. Valve must have decided that rocks1 didn't work.

blenddirtgrass001a		grassland1
blendrockdirt005b_lowfrict	rocks1
blendrockdirt006a		rocks1
blendrockdirt006b_lowfrict	rocks1
blendrockdirt007d		rocks1
blendrockdirt008c		rocks1
blendrockdirt008d		rocks1
blendrocksand008c		rocks1
blendrocksand008d		rocks_redgrass
blendrocksgrass005a		rocks1
blendrocksgrass006a		rocks1
blendsandsand008b_antlion	coastline_grass01

In addition to rocks1 there are several groups that were never used, such as street_junk and all the swamp groups. It may also be worth compiling a sample map to see what these unused groups look like.

As far as I know this list does not exist elsewhere, and it would be worth including (I went 'round the bend putting grass in my map following the Displacement Grass tutorial, not realising that blenddirtgrass001a does not have detail props but blenddirtgrass001b does. I would like to save others the same trouble). --Fitzroy doll 03:26, 30 Mar 2006 (PST)


Through a large amount of my tests I've found the detail prop system is actually pretty shitty. It can get expensive real fast unless the density is aggressively changed. This is even more so the case when rendering detail shapes and sway. The image that we have on the article from Dear Esther isn't even a good example as well, seeing as Robert Briscoe has stated the system they use has been completely redesigned to now handle on the GPU.
Of course this has vastly changed through engine branches but thats kind of the problem. I had italicized "cheap". However I think variating costs sounds much better, unless we want to describe the different levels of cost from engine branch to branch. They're decently cheap on Left 4 Dead 2 and beyond, but horribly bad in previous engines.
I also bring this up because a few of the images we have on the article may or may not lead people to believe they can get away with a dense amount of detail prop rendering, and that is simply not true.--Gear 20:15, 16 December 2010 (UTC)
Detail sprites are cheap compared to their alternative, i.e. models. I made a simple quad model and tested using that vs using sprite quads in Source 2007 and the sprites were over twice as fast on my system (which is quite powerful and is resilient to overdraw). The Dear Esther improvements are for calculating detail prop sway, not their actual rendering. Interesting to hear that the system became a lot faster in L4D2, do you have any more details? --TomEdwards 21:32, 16 December 2010 (UTC)
A lot of my tests we're done using the detail system how I feel it may likely be used for other serious situations. More or less a bit like Dear Esther. No doubt about them being much cheaper than models though, considering I believe detail sprites are always two polygons? A lot of the performance data I've collected was gathered from a painted radius of 256 units with a density of around 1300, which I later brought down to 900 for optimization and cost reasons. I found a perfectly painted area "give or take a few extra patchs" had around a decent amount of 30-65 sprites generated on it, of which had a 4.8ms cost per frame. Thats a pretty steep impact for a section that small. A lot of these tests however where done with both a light amount of sway and detail shape generation. I believe that sway is the main problem, but I also feel detail shapes can more than likely double to triple the cost of a single sprite.
From some of my other tests in games like L4D2 I decided to take the same detail.vbsp file and material and throw it in a test map. The cost there with the exact same detail sprites went down to about 2.3ms. Valve definitely did some extra work though. How much work though I am unsure of. Anyways I'm not sure if we should add up the different amount of costs from engine branch to branch, though it might be a good idea. I know a lot of people have used the detail system for huge amounts of extra cheap foliage, though usually never use sway or shapes. It's a little sad the cost is so steep when you want to get a lot of grass/greenery/weeds going on, but from L4D2 it seems that won't be much of a problem for say Episode Three.
Lastly I think if anyone really wants to heavily use the detail system thier best bet with perf is to disable sway if they must really use shapes. Or vise versa. Of course only on Orange Box and earlier.--Gear 20:02, 17 December 2010 (UTC)


I added the func_detail_blocker entity on this page as I found it very useful, and was surprised I didn't hear about it before, I badly needed it in CS:GO.