Overview

The material editor is opened when double-clicking on an asset of type “material” (with the “.pkma” file extension) inside the content browser.

This is the window that allows you to edit materials, which can then be assigned to particle renderers.

A material is also called a “feature-set” as it is a collection of rendering features, defined in a rendering interface.

When creating a custom material, there are two things to consider:

• What rendering features are available when this material will be applied to a renderer
• How will this material look in PopcornFX Editor (and in your engine if you rely on PK-SampleLib and PK-RHI SDK libraries to render particles)

Rendering features

1. List of available rendering features in the selected rendering interface
2. Preview of properties from the selected rendering feature
3. List of rendering features in this custom material. Features can be manually added or drag&drop-ed from section #1. A material can contain features from various .pkri files.
4. Preview of available properties on the renderer if this material is applied (and all features are enabled).

Mandatory in section #3 determines whether the rendering feature is enabled by default (and can’t be disabled). In this material, GeometryBillboard, Transparent, Diffuse and EnableRendering are considered the minimum features for this material.

IMPORTANT: It is mandatory that each feature set contains one Geometry* rendering feature (with Mandatory enabled). This feature determines the kind of renderer this material will be compatible with.

Shader editor

1. Shader editor type (Available types are Source, PreprocessorIn, PreprocessorOut). Source is the source shader editing mode.
2. Type of renderer this material is compatible with, this is because GeometryBillboard is a rendering feature from this feature set.
3. Fragment shader path, it is possible that several .pkma files use a common .frag file
4. Shader defines available to this fragment shader. There will be one per rendering feature (apart from Geometry* which are mandory) and can be used in the shader code to #ifdef code.
5. Available samplers, driven by the .pkri’s rendering feature properties (see rendering feature)
6. Generic scene info data
7. Per renderer constants, those are rendering feature properties of “Property” type
8. Fragment input data, this contains both generic rendering data (fragWorldPosition, ..), mesh rendering data (fragUV0, ..) and per particle “additional inputs” (fragAtlasID, fragColor, fragTextureID, ..)
9. Fragment shader expected output

A vertex and fragment shader editor are available to write the shaders, so artists work with a preview of their effects matching the final game engine’s viewport.

IMPORTANT: Currently, those shaders are only used for rendering in PK-Editor and any engine integration using PK-SampleLib’s RHI implementation. Those shaders will not be exported to the game engine, so the integrators will have to re-create those materials in the final game engine.

When in the “Source” view mode, saving (Ctrl+S) will trigger an asynchronous shader compilation of the currently used shaders permutations (this is determined by the number of renderers using this material in opened effect editors).

Shader errors

Writing custom shaders often comes with errors. Two additional views are available to inspect those:

• PreprocessorIn -> Final generated shader, passed to mcpp
• PreprocessorOut -> Final shader, passed to the shader compiler

Mcpp in

1. Switching the view to “Preprocessor in”, we now see the shader (for the selected permutation in #2) before it’s being preprocessed by mcpp
2. List of shader permutations generated for this material (combination of all possible rendering features, enabled or not)

This view helps viewing the final generated shader, before it’s preprocessed.

Shader compiler in

This view shows what comes in the shader compiler, after the shader has been preprocessed. This is the final shader code.

Hovering a shader permutation displays the shader error (if any), allowing to find the issue.