Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
I'm definitely not a graphics programmer, but I've done a fair amount of performance optimisation work on SteamVR Home content - so here's my understanding of things!
Per-pixel rendering cost is exactly that - how much computational work is needed to draw individual pixels. Texture resolution doesn't matter beyond total texture memory being used - if you hit that limit, then performance will plummet. Up to that point, things will be just fine.
A side note: one big measure of scene complexity is the number of draw calls - usually switches between different materials. Given the same number of pixels drawn on-screen, a single material with giant textures is much cheaper to render than many materials with tiny textures - it's the switching between materials that poses an additional cost per switch.
I think the animated material feature is doing something clever with UV values - basically it's just fiddling with texture alignment, setting new UV offsets for every new 'frame'. The underlying textures are large sheets containing all available frames - so yes, the cost is the same whether it's rendering from just two frames or a hundred.
You can see how a material makes use of the underlying compiled textures in the Material Editor - the tab is called something like 'Compiled Textures'.
Most of the time, textures get compiled to 'DXT1' or 'DXT5' formats. These are compressed image formats which the GPU will decompress on the fly - as well as using less texture memory, use of this texture compression is actually faster than using uncompressed textures since the GPU has to transfer less data when rendering.
DXT1 - colour only.
DXT5 - colour and an alpha channel (which can get used for lots of different things).
You can consider all the compiled textures as being ingredients for a recipe. The more ingredients, the more complex the recipe is likely to be - although you might have a recipe with few ingredients but which does very complicated things with them.
For GPU rendering, the recipes are shaders - small computer programs which calculate pixel values (along with other things in the case of vertex shaders etc.). Enabling more features in the material will give a more complex version of the shader, but some features will add much more to rendering cost.
In SteamVR Home, transparency is rather expensive - especially the alpha-tested version which does some very fancy anti-aliased edges. For use of those, be careful of overdraw - basically, lots of transparent surfaces rendered over each other. (For translucency, it has to render every single layer - it can't do a quick depth check and discard everything except the surface in the foreground.)
For the Summit Pavilion maps, you'll notice that the trees and foliage surrounding the building usually don't overlap each other by too much. Earlier versions had a veritable forest out there, which really didn't agree with low-end hardware...
General answer here: be careful with translucent and alpha-tested surfaces. The rest should be fine, unless you're doing something really weird. You're more likely to get caught out by draw calls, lighting complexity or something else...
(Lighting complexity? Basically, make sure you have as few dynamic lights shining on surfaces as possible - cost really adds up. Having as much light as possible being 'baked' into the map helps loads.)
I'm not sure what the upper limit is for SteamVR Home, but since 'min-spec' hardware is a GTX 970 with 3.5-ish gigabytes of memory, and a workshop addon is a maximum of two gigabytes - even with all the temporary buffers, additional props and so on you'll be doing well to run out of texture memory.
(Some of my photogrammetry stuff is using something like a gigabyte of texture memory, on meshes with several million triangles in total. Modern GPUs are fast...)
There's some more stuff here: https://developer.valvesoftware.com/wiki/SteamVR/Environments/Introduction#Performance
For larger maps, there are many tricks for helping performance - setting fade distances on static props so that they disappear from rendering if they're a long way away, the precomputed visibility system which will drop entire sections of map if they're 'behind' solid objects... Loads of stuff to learn! Do let me know if you need help with any of it - posting on here is a good way of helping many people.
Hope that's of some use!
Assuming that your material is not unlit, the largest part of the individual per pixel shading cost comes from the lighting equations. A good performance optimization is to go through your scene and disable specular on materials who’s specular contribution is not perceivable to the player.
The same can be done for materials that make use of cubemaps (indirect specular) but that are not needed to be perceivably glossy.
When doing any kind of material optimizations I would strongly recommend to constantly check the quality of the updated material in VR, This seems especially notable for glossy surfaces, Id imagine this is because your head is constantly in motion in VR and thus the variation in surface roughness is more perceivable compared to the relatively fixed perspective of the editor. - What you can get away with in the editor is not always representative of what you experience in the HMD.
Wind on its own is a relatively cheap feature as it performs modifications to the mesh in the Vertex shader and so this isn't a per pixel operation. However, the caveat to this is that materials with wind enabled are normally also materials that have some kind of transparency enabled and as such are already relatively expensive. See Cargo Cults explanation above of why Transparency is expensive.
To combat this I would advise prioritising the usage of wind materials to only be used on meshes that are within a closeish distance to the player and create a cheaper tree material for trees that are in the distance.
I'm wondering if it would be useful to add level-of-detail models with cheap materials to complex objects you see up close, like tools. It would probably increase the number of draw calls though...
Though I guess I'm making some broad assumptions, so who knows :)
An alternative idea could be some kind of shader or material LOD, like the current per instance prop fade options, but instead of fading the object, fade certain shader features over distance to reduce shading complexity for expensive materials.
Everything is done per model in the model editor, so there is nothing to set up in Hammer itself. Note that the LOD distance is calculated from the center of the play area rather than the players eyes (guessing this is a bug), so using small values can cause pop-in if the model is moved to the edge of the play area.
There is a very small tutorial here:
https://developer.valvesoftware.com/wiki/Dota_2_Workshop_Tools/Model_Editor/How_To#Add_Level_Of_Detail_Meshes