Originally posted by Praxeos1:

Now that I'm getting the hang of the basics with materials, I'm starting to think about optimization. At the prompting of a friend, I've begun paying attention to my advanced frame timing stats. I was hoping that someone could confirm or correct my assumptions about the way materials work with regard to performance. Obviously, individual system configurations, etc. are a factor, but I'd like to know if my understanding is generally correct for most situations.

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!

1) I assume that tiling a single 1-k texture four times over a surface would use less disk space and RAM than using one 4-k texture, but would tax the GPU and CPU about the same because both options require the system to draw the same number of pixels.

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.

2) Given the same frame rate and same number of pixels per frame, I assume that GPU and CPU resources would be similar whether an animated material shows 100 different frames or alternates 100 times between two frames- i.e. the system must draw the same number of pixels within the same period of time. The same caveat as above would apply for RAM and disk space.

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.

3) I assume that a normal map still renders on a per-pixel basis, but the system only renders the actual number of pixels on the map's surface, while giving the illusion of a greater surface area.

4) While multiple maps (ambient occlusion, normal, color, gloss, etc.) will take more disk space, I assume that the render information is compiled into one chunk of data by the vmat, rather than forcing the system to calculate each map separately at run time- i.e. using multiple maps in a material doesn't dramatically compound the GPU and CPU workload.

5) I would tend to think that the cost of using reflectance and glossiness is not all-or-nothing, but falls along a continuum. My guess is that increasing either of those increases the resolution of the render result (more pixels). Thus, resource-consumption would increase proportionate to the levels. If true, would this also apply to transparency/opacity and Fresnel controls?

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

6) I noticed an option under the Map menu that shows the total amount of texture memory. What's a reasonable number for the typical VR user? Is that a constant amount of memory allocated to the RAM throughout the game or does memory use change depending upon the number of textures within the player's FOV.

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

I'm not a tech guy, so responses in layman's terms would be greatly appreciated! Thanks in advance.

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!

Thanks! This information is very helpful. I've thought about water and glass, but hadn't even considered the computational cost of overlapping vegetation. One of the things on my to-do list is to learn to make trees and plants. That raises another question; is the wind attribute for materials resource-intensive? Are there any special tricks to keep in mind when using it?

Cargo Cult has already done a fantastic job answering the majority of points here, but I’ve added a few points below that are hopefully useful.

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.

Originally posted by Steve:

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.

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...

Good question, It's one of those things that would require thorough testing to see if it would actually provide valuable benefits, I'm also not sure that LOD models would be a scalable solution.
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.

Thanks. I found the following tutorial on LOD (https://developer.valvesoftware.com/wiki/LOD_Models ), but it looks like it's outdated. Is there a more up-to-date resource for this? Is it just a simple matter of some entity property setting that points to a secondary vmdl file (one can always hope it's simple, but that's probably being too optimistic)?

Originally posted by Praxeos1:

Thanks. I found the following tutorial on LOD (https://developer.valvesoftware.com/wiki/LOD_Models ), but it looks like it's outdated. Is there a more up-to-date resource for this? Is it just a simple matter of some entity property setting that points to a secondary vmdl file (one can always hope it's simple, but that's probably being too optimistic)?

It's about that simple, you add additional meshes (like .fbx instead of .vmdl) to the same model from the model editor. Then pick Model->Mesh->Add LOD groups from the menu, create LOD groups for each distance you want to switch meshes at, and fill in the distances and meshes in the properties.

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

It's worth noting though that Valve doesn't seem to be using LOD's in any of their SteamVR Home maps. So perhaps its not an optimal solution for VR content.