Surface Shader

Rendering tends to become more processing-heavy as development criteria rise. We introduce the Surface Shader framework in v3.5.1 to provide a more efficient and structured process for creating shaders.

Developers can find the corresponding shaders and shader fragments in Assets -> internal -> effect -> surfaces and Assets -> internal -> chunk -> surfaces.

Surface Shader aims to facilitate fast and streamlined shader creation with simple codes in unified structures and processes. Users may easily define lighting and shading attributes, access public properties such as global lighting and debug viewing with the additional benefit of low maintenance, better readability and higher compatibility.

With Surface Shader integrated, Material system in Cocos Creator will continue to expand in future versions including visual coding for shaders. However, it will also prohibit ad-hoc modifications such as custom lighting and shading calculations. In the event of such development scenario rises, please revert to the legacy shader system.

Surface Shader is built on the Cocos Effect system, of which the syntax and properties are fully compatible.

Related Concepts

The following sections illustrate new terminologies introduced by the Surface Shader framework.

1. Rendering Usage

Render Target specifies the destinations for the pixels rendered by the shader.

A shader typically incorporates multiple passes to render to various data outlets, such as to the screen for displaying, to the shadow maps to create shadows, to the reflection map to create reflections, etc.

Relevant functionalities can be found in the folder Assets -> internal -> chunk -> shading-entries -> main-functions.

2. Lighting Model

Lighting model refers to the manner in which the material’s microscopic structures interact with lights and the visual outcomes thereof, such as specular, diffusion, reflection, etc.

3. Surface Material Model

Surface model refers to the material’s surface attributes such as IOR and roughness.

Surface models typically work in conjunction with lighting models. New models are to be introduced in future updates.

4. Shader Stage

Shader stage refers to the different stages in the render process, which includes:

Framework

Similar to legacy shaders, Surface Shader code also consists of Cocos Effect’s properties, techniques and UBOs but excludes macro definitions, in/out parameters, instancing, coordinate transformations and other calculations found in the legacy shaders.

A typical Surface Shader is comprised of three parts:

• Macro Remapping: Map declared parameters and macros in the Effect header to private macros
• Surface Functions: Declare functions in the Surface Shader
• Shader Assembly: Assemble the vertex shader and the fragment shader in the Surface Shader.

Using the default shader surfaces/standard.effect as an example, A Surface Shader include code such as:

Macro Remapping

When a certain functionality of the Surface Shader is required, users may choose to expose said functionality by defining a Marco in the Macro Mapping section of the Surface Shader. Doing so allows users to expose said functionalities in the Properties Panel with a name of the user’s choosing without interfering with the shading calculation involved.

These macros start with CC_SURFACES_ and the following is the complete list of macros.

NOTE: These macros can be left undefined and are automatically defined internally to the default value of 0; they can also be defined directly to 0 or some other value, indicating that they are forced off or on in this Effect and user adjustment is disabled.

Searching for the CCProgram macro-remapping paragraph, you can see that the content consists of the following three parts.

1. Macros Not Used In The Surface Function

// ui displayed macros not used in this effect file
#pragma define-meta HAS_SECOND_UV
#pragma define-meta USE_TWOSIDE
#pragma define-meta USE_REFLECTION_DENOISE
#pragma define-meta IS_ANISOTROPY
#pragma define-meta USE_COMPATIBLE_LIGHTING

#define CC_SURFACES_USE_SECOND_UV HAS_SECOND_UV
#define CC_SURFACES_USE_TWO_SIDED USE_TWOSIDE
#define CC_SURFACES_USE_REFLECTION_DENOISE USE_REFLECTION_DENOISE
#define CC_SURFACES_LIGHTING_ANISOTROPIC IS_ANISOTROPY
#define CC_SURFACES_USE_LEGACY_COMPATIBLE_LIGHTING USE_COMPATIBLE_LIGHTING

Surface Shader omits certain codes compared to legacy shaders such as #if HAS_SECOND_UV. To declare a macro of the same purpose, users may pre-defined the macro #pragma define-meta MACRONAME for it to be displayed in the Properties Panel first, then map the newly declared macro to one of Surface Shader’s functionalities as with standard GLSL: #define CC_SURFACES_MACRONAME MACRONAME.

2. Macros Used In The Surface Function

// ui displayed macros used in this effect file
#define CC_SURFACES_USE_VERTEX_COLOR USE_VERTEX_COLOR
#if IS_ANISOTROPY || USE_NORMAL_MAP
  #define CC_SURFACES_USE_TANGENT_SPACE 1
#endif

Macros being used in the Surface Functions can be declare in the format: #define CC_SURFACES_MACRONAME MACRONAME. In this particular case, normal mapping and anisotropy requires CC_SURFACES_USE_TANGENT_SPACE to be enabled.

3. Internal Functional Macros

// functionality for each effect
#define CC_SURFACES_LIGHTING_ANISOTROPIC_ENVCONVOLUTION_COUNT 31

Internal macros can be defined with its intended value attached.

Surface Function

The function of each material function is similar to the output of a material parameter to a specified material node in the material editor of DCC (Digital Content Creation) software. Similar to：

1. Definition

Surface functions can be declared in CCProgram code blocks or their separate .chunk files.

Note: For consistency’s sake, all vertex shader code should be encased in one block while all fragment shader code in another. Vertex shader and fragment shader should not use more than one code blocks each. Also, vertex shader and fragment shader should not share the same code block.

Surface Shader provides simple default functions internally, so these functions are not mandatory, if you want to overload a function, you need to predefine the macro corresponding to that function to do so. These functions are named with Surfaces + ShaderStage name followed by the function description. They can be found in editor/assets/chunks/surfaces/default-functions to see the specific definition and implementation of each Surface function in different material models, e.g.

#define CC_SURFACES_VERTEX_MODIFY_WORLD_POS
vec3 SurfacesVertexModifyWorldPos(in SurfacesStandardVertexIntermediate In)
{
  vec3 worldPos = In.worldPos;
  worldPos.x += sin(cc_time.x * worldPos.z);
  worldPos.y += cos(cc_time.x * worldPos.z);
  return worldPos;
}

Defining the macro CC_SURFACES_VERTEX_MODIFY_WORLD_POS allows its corresponding function to be overridden with the code in the current Surface Shader.

Note: Overriding functions can be assigned new names and parameters. Users may override functions according to their own design or call the default version of the same function. This allows easy extension for the shader capabilities and avoid conflicts with future updates.

2. VS Corresponding Functions List

Functions relevant to vertex shaders are listed as follows. All functions takes the SurfacesStandardVertexIntermediate structure as parameter. As vertex shader rarely see customizations, these functions require no overriding in most scenarios.

3. FS Corresponding Functions List

Functions relevant to fragment shaders are listed as follows. Most functions involve in modifying the value of one particular property while some modify more than one. In such cases, the respective functions can take multiple parameters.

4. VS Input Value Acquisition

Input values of the vertex shader, which is stored in the format of a SurfacesStandardVertexIntermediate structure, include members as follows:

5. FS Input Value Acquisition

Input values of the fragment are listed as follows. Most can be accessed without macro condition evaluations.

Shader Assembly

Users may assemble multiple modules with the include keyword for each pass of the Surface Shader. For instance, the fragment shader of the default Surface Shader is assembled by 6 parts:

1. Macros

Macros are required to be mapped and defined in the Marco Mapping section of the surface shader, which is integrated in the form of CCProgram code blocks or .chunk files.

By including common-macros, users can integrate most macros to the Surface Shader.

Pass standard-fs:
#include <macro-remapping>
#include <surfaces/effect-macros/common-macros>

In scenarios where only part of the Surface Shader’s capabilities are used, users can also include specific macros involved in the shading process.

Pass shadow-caster-fs:
#include <surfaces/effect-macros/render-to-shadowmap>

2. Shader Generic Header File

Header files should be included with their Shader Stage specified, such as:

Vertex Shader：
#include <surfaces/includes/common-vs>
Fragement Shader：
#include <surfaces/includes/common-fs>

3. Surface Utility Functions

Surface functions that are created in their separate .chunk file need to be included accordingly. Surface functions require access to the shared memory allocation to function properly. For this reason, shared UBO also need to be included prior to the .chunk files in question.

#include <shared-ubos>
#include <surface-fragment>

4. Lighting Model

Lighting models are optional and can only be used in the fragment shader to render to screen.

When including lighting models, their corresponding names are also required to be specified.

Standard PBR Lighting：
#include <lighting-models/includes/standard>
Toon Lighting：
#include <lighting-models/includes/toon>

5. Surface Materials and Shading Models

Surface material models are optional and can only be used to render to screen.

When including lighting models, their corresponding names and render stages involved are also required to be specified.

Vertex Shader：
#include <surfaces/includes/standard-vs>
Fragement Shader：
#include <surfaces/includes/standard-fs>

6. Main Shader Function

When including main render loop functions, their corresponding render target and render stages involved are also required to be specified.

Pass standard-fs:
#include <shading-entries/main-functions/render-to-scene/fs>
Pass shadow-caster-fs:
#include <shading-entries/main-functions/render-to-shadowmap/fs>

Debug View

Note: The built-in rendering debugging feature is only available for materials using the Surface Shader framework**.

By selecting the corresponding debug mode in the upper-right corner of the scene preview window in the editor, you can view the model, materials, lighting and other computational data on the same screen, and quickly locate the problem when the rendering effect is abnormal.

To facilitate pixel-by-pixel comparison, we use full-screen debugging instead of picture-in-picture display, which allows us to quickly switch between different data in the same screen to locate rendering errors, and to use the color picker to explore the pixel-specific values.

In addition, Surface Shader has a built-in Irrational Number Visualization feature, so once some pixels appear to have abnormal Red(255, 0, 51) and Green(0, 255, 51) alternately blink, then the rendering calculation of these pixels appears irrational, please use the single debug mode to check the model tangent or other related data.

The rendering debugging functions are subdivided into the following three categories.

1. Common Options

Debugging options that are in effect in either single or combined mode, including:

2. Single mode

The debugging focus is on a particular piece of data that needs to be tested, and the entire scenario visualizes this data output.

The debuggable data includes four major categories.

I. Primitive Model Info

II. Primary Material Info

III. Lighting Info

IV. Misc Info

3. Render Composite Options

The debugging focus is on the overall rendering performance, and each module can be blocked or turned on, with modules unrelated to each other, to see how different modules affect each other's rendering effects.

single mode has higher priority than the composite mode, If you want to use the composite mode, you must check No single mode.

Including:

Advanced Usage

1. Manual inserting vertex shader outputs and fragment shader inputs: with the new varying property introduced in the Surface Shader framework, vertex shader outputs and fragment shader inputs can be accessed in particular Surface Functions.
2. Surface Shader and legacy shader codes can be used in the same render loop as long as the varying vertex data are kept consistent between the two.

Public function libraries

The library headers can be found under assets -> internal -> chunks -> common folder in different categories.

The functions in the library do not depend on any internal data (engine related uniform, mapping, etc.) and can be used directly as tool functions.

Surface already automatically contains common public function headers internally, which can be classified according to type as:

¹. Custom GPU geometry instancing properties are not supported. ↩