Skip to content

Build and Shader Stripping

This section covers NiloToon's build settings, shader stripping configuration, and version control strategies when editing source code.

Build and Shader Stripping

When building the following from the Editor:

  • Application for a target platform
  • .warudo
  • Asset Bundle / Addressable

Usually no extra steps are required for NiloToon to run correctly in the build. However, some features used in the Editor may not be included by default for a target platform.

Features Not Included by Default

  • Receive URP Shadow
  • Dither Fadeout
  • Dissolve
  • BaseMap Override
  • Screen Space Outline
  • Debug features
  • XR features (e.g., character vertex shape not synced in both eyes in VR)

Resolution Steps

  1. Create a NiloToonShaderStrippingSettingSO asset.

    Create NiloToonShaderStrippingSettingSO

  2. Enable the required features for your target build platform. For example, enable Dissolve for Android and iOS if you find that Dissolve is missing only on those platforms.

    Enable features per platform

  3. Assign the NiloToonShaderStrippingSettingSO from steps 1-2 to all target NiloToon Renderer Features.

    Assign to Renderer Feature

  4. Assign the same NiloToonShaderStrippingSettingSO to Edit > Project Settings > NiloToon > Shader Stripping Setting. This step is required if you build using the command line.

    Assign to Project Settings

  5. Build again and wait for shader compilation. The problem will be solved. This applies equally to direct application builds, Asset Bundles, Addressables, and .warudo files.

Reducing Build Time

If shader build time is too long and you want to remove unnecessary shader variants to speed up the build, you can do the opposite by removing features for a platform. See the Optimization Guide for details.

Editing NiloToon Source Code

For Non-Programmers

You can skip this section.

Editing NiloToon's source code is not recommended as it makes future updates difficult. If you must do it, the following version control strategy is suggested.

3-Branch Strategy

Generally, you need 2 extra branches in version control to improve future merging.

Branch Purpose
Extra Branch A (NiloToon source update only) Push only new NiloToon .unitypackage updates into this branch, without any other edits
Extra Branch B (Your NiloToon edits) Merge "Branch A" into this branch from time to time, and push only your NiloToon code changes into this Branch B
Main Branch Merge Branch B into Main Branch from time to time

With this 3-branch setup, you can reduce many merge conflicts while continuing to update NiloToon and maintaining your changes to NiloToon's code.

Potential Conflicts

When updating NiloToon (e.g., merging "Branch A" to "Branch B"), conflicts may still occur if you edited the same code lines as NiloToon's developers.

Editing NiloToon's HLSL

Before editing any NiloToon-related HLSL, first open the following files from the Project window:

  • NiloToonCharacter_ExtendFunctionsForUserCustomLogic
  • NiloToonEnvironment_ExtendFunctionsForUserCustomLogic

These are HLSL files designed for users to edit. They provide different empty functions (entry points) for injecting custom logic into the shader at various stages, similar to MonoBehaviour's empty functions like Update() / LateUpdate().

Recommendation

Try using these files first. Development will be much cleaner and easier since the NiloToon team will not edit these files for a long time. Version control conflicts will be very rare, and you can safely develop extra rendering logic without worrying about future breaking changes.

Using Rider for HLSL Development

Rider is highly recommended for HLSL development. It allows you to write and read HLSL just like working with C#.

Feature Shortcut
Go to Declaration or Usages F12
Go Back (previous location) Ctrl + -
Extract Method Ctrl + . or Ctrl + R, M
Rename Ctrl + R, R