Talk:Detail props

Is it still a bug?

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.  [todo tested in?]

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)

Considerations

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 useful...it 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)

Cost

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)

Since these comments are now pretty old I wonder if the cost is still high, particularly in regards to detail props? The comment about directx on the detail props page ("There is a per-object DirectX overhead that becomes more and more pronounced as the number of models increases, regardless of how many polygons are being drawn.") was added in 2005 and both the engine and directx have evolved since then. Though it may be the same directx version for which is what i'm interested in, so maybe it's still a problem? Surely hardware improvements since then mitigate some of the issue, if it still exists. Manually placed detail props can be used for pretty neat stuff but if the cost is so high it's obviously pretty limiting. --Sirhephaestus (talk) 09:35, 14 November 2024 (PST)

More pronounced as the number of models increases, regardless of how many polygons are being drawn

It's due to the number of draw calls; Source doesn't batch render MDLs with the same materials, unlike brush geometry. prop_detail is cheaper than prop_static, but 100 detail props will still be more expensive than a couple combined static props (and the way detail props are lit makes combining them like static props ill advised). Manually placed prop_detail entities are fine, as long as you don't go overboard.
— SirYodaJedi (talk) 14:22, 14 November 2024 (PST)

When you say 100 detail props is more expensive than a couple static props are those just random numbers? I'll have to do some testing to see about this. And if you can combine prop_details then i imagine the lighting isn't an issue as you're forced to use unlitgeneric anyway, no? Though one of the use cases and the main one i can think of of using a prop_detail entity is for the detailorientation which i imagine combining the props would defeat the purpose of since all the props would then be in sync. --Sirhephaestus (talk) 16:48, 14 November 2024 (PST)

It's an arbitrary number, yes; the actual values will depend upon your specific scene. And afaik, even though prop_details are UnlitGeneric, they get a uniform tint based upon the lightmap luxel underneath their origin, like prop_detail_sprite, so if some of the props more are in shadow.

Also, I'm not sure what detailorientation actually does for models? It's designed for sprite orientation.
— SirYodaJedi (talk) 07:13, 15 November 2024 (PST)

Detailorientation does the same thing for prop_details as it does sprites, working exactly as you'd expect it to. It appears to use the same code for both. --Sirhephaestus (talk) 04:16, 16 November 2024 (PST)

func_detail_blocker

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. --JorisCeoen 06:42, 21 March 2013 (PDT)

Newest Prop Detail commands with CS:GO's Danger Zone for materials

If you take a look at CS:GO's Sirocco Danger Zone map, you can find some new types of commands that were never listed before, and are also not documented at all... does anyone even know what these are doing?

grass
{
	"$basetexture"       "detail/foliage_atlas002"
	"$masks"       "detail/foliage_atlas002_masks"
	"$alphatest"         "1"
	"$vertexcolor"       "1"
	"$worldspacetint"    "detail/dust_massive_grass_tint"
	"$worldspacetype"    "detail/dust_massive_grass_type"
	"$worldspaceburn"    "_rt_grassburn"
	"$worldspacezone"    "_rt_zoneprojection"
	%notooltexture       "1"
	"$minimumspritesize" "16"
}

So far I've been able to understand that worldspacetint is sort of a large mask that represents the whole map, and somehow will change how detail props look in the spots that are marked with a different color in the texture. Worldspacetype then also changed the type of detail prop that is being represented depending on the color on the texture. Weirdly enough, these detail textures also have masks, in which each color channel has a different purpose. I've tried understanding what they do, but I fail to get the overall picture of each different map. All except the green channel, because that one seems to be used for 'regular' transparancy. JorisCeoen (talk)

"Grass" Shader?

the last section of the page says that detail sprite VMTs should use either the UnlitGeneric shader or the Grass shader. what's the Grass shader? I can't seem to find anything about it, on the wiki or elsewhere. Kestrelguy (talk) 14:04, 12 April 2022 (PDT)

It's CSGO-only from what I can tell, and pretty undocumented. If you use any other shader, the lighting gets super weird. The one strange thing is that sprite shapes work in csgo if you use unlitgeneric or lightmapped (and the lighting is broken), but they don't work if you use Grass. 9yz (talk) 13:07, 21 April 2022 (PDT)

More info about above 2 topics

See ​https://www.mapcore.org/topic/23002-decompiled-dz_blacksite/?tab=comments#comment-444933
— SirYodaJedi (talk) 15:15, 9 October 2023 (PDT)