Unity3D: Use and performance of built-in shaders

Recommended: Add NSDT Scene Editor to your 3D toolchain
3D Toolset: NSDT Jianshi Digital Twin

Built-in shader usage and capabilities

Shaders in Unity are used through __material__, which essentially combines shader code with texture and other parameters. An in-depth explanation of the shader/material relationship is provided here.

Material properties will be displayed in the Inspector when selecting the material itself or selecting a __GameObject__ that uses the material   . The Material Inspector panel (Inspector) looks like this:

Each material will look different in the Inspector, depending on the specific shader it uses. The shader itself determines the types of properties that can be adjusted in the Inspector. For a detailed description of the Material Inspector, see the Material Reference page. Remember, shaders are implemented through materials. So while the shader defines the properties that will be displayed in the Inspector, each material actually contains adjustment data from sliders, colors, and textures. The most important thing to remember in this regard is that you can use a single shader in multiple materials, but you cannot use multiple shaders in a single material.

Shader name

Changing the name of an old shader may affect its functionality. This is because prior to Unity 5.0, some functionality of a shader was determined by its path and name. This is still how legacy shaders work. For more information, see Legacy Shader Names

Performance considerations

There are many factors that affect the overall performance of your game. This page will be dedicated to performance considerations for built-in shaders. The performance of a shader mainly depends on two things: the shader itself and the rendering path used by the project or specific camera. For performance tips when writing your own shaders, see the ShaderLab shader performance page.

Rendering Paths and shader performance

Of the rendering paths supported by Unity, the deferred shading and vertex lighting paths have the most predictable performance. In deferred shading, each object is usually drawn once (regardless of which lights affect it). Also, in vertex lighting, each object is usually drawn once. Therefore, the difference in performance of shaders depends mainly on the number of textures they use and the calculations they perform.

Shader Performance in Forward rendering path

In the forward rendering path, the performance of the shader depends on two factors: the shader itself and the scene lighting. The following sections describe this in detail. From a performance perspective, there are two basic shader categories: __Vertex-Lit__ and __Pixel-Lit__.

Vertex lighting shaders in the forward rendering path are always cheaper than pixel lighting shaders. These shaders use all lights simultaneously to calculate lighting based on mesh vertices. Therefore, no matter how many lights are on the object, it only needs to be drawn once.

The __Pixel Lighting__ shader computes the final lighting for each pixel drawn. Therefore, the object must be drawn once for the ambient and main directional lights, and once for each additional light. Therefore, the solution is N rendering passes, where N is the final number of pixel lights that fall on the object. This approach increases the workload on the CPU to process and send commands to the graphics card and process vertices and draw pixels on the graphics card. The size of a pixel lighting object on the screen also affects how quickly the object is drawn. The larger the object, the slower it draws.

So, there is a performance cost to the pixel lighting shader, but that cost can produce some great effects: shadows, normal maps, nice specular highlights and light silhouettes, to name a few.

Remember that lighting can be forced into pixel ("important") or vertex/SH ("non-important") mode. Any vertex lights illuminated on a pixel light shader will be calculated based on the object's vertices or the entire object and will not count towards the rendering cost or visual effects associated with the pixel light.

General shader performance

The order of complexity of the built-in shaders from least to most is roughly as follows:

  • Unlit . This is just a texture and is not affected by any lighting. * Vertex lighting (VertexLit) .
  • Diffuse .
  • Normal mapped . This one costs slightly more than diffuse: it adds a texture (normal map) and some shader instructions.
  • Specular . This item adds specular highlight calculations.
  • Normal Mapped Specular . Again, this is slightly more expensive than specular.
  • Parallax Normal mapped . This adds parallax normal map calculation.
  • Parallax Normal Mapped Specular . This item adds parallax normal map calculation and specular highlight calculation.

Simplified shaders for mobile

Additionally, Unity has several simplified shaders for mobile platforms, located under the "Mobile" category. These shaders are available on other platforms as well, so if you can tolerate the fact that using them is simplified (e.g. approximate specular reflections, no per-material color support, etc.) give them a try!

To see the specific simplifications that have been made for each shader, check out  .shader the file in the "Built-in Shaders" package, which is listed in some comments at the top.

Some examples of common changes in mobile shaders include:

  • The shader has no material color or primary color used for shading.
  • For shaders with normal maps, tiling and offset of the base texture are used.
  • Particle shaders do not support  AlphaTest or  ColorMask.
  • Limited functionality and lighting support, for example some shaders only support one directional light.

Guess you like

Origin blog.csdn.net/jianshi2023/article/details/130527825