Proposal: Move ZenithCompiler.cs to a separate Zenith.NET.Shader project to decouple runtime from Slangc.Net

[dooogee]

Feature Description

Description
Currently, ZenithCompiler.cs resides directly in the core project, and the core project has a dependency on slangc.net (the .NET binding for the Slang compiler). This means that any project using the Zenith.NET core runtime (e.g., a game's release build) must carry the compiler SDK dependency.

Proposed Improvement
I suggest extracting all shader compilation-related code (including ZenithCompiler.cs and associated compilation logic) from the core project and moving it into a new, separate project called Zenith.NET.Shader.

Benefits of This Change

1. Clear Separation of Concerns: The core project would focus on shader loading, binding, and runtime execution (RHI), while the Zenith.NET.Shader project would focus on offline shader compilation and validation.
2. Reduced Runtime Dependencies: For final release builds of games or applications, there would be no need to distribute or load slangc.net and its native libraries, significantly reducing runtime footprint and startup overhead.
3. Optimized Workflow: This naturally supports the "offline compilation" best practice. Developers could use Zenith.NET.Shader in their tooling layer (e.g., editor or build server) to pre-compile .slang or .hlsl source files into final bytecode or DXIL/SPIR-V. The game runtime would only need to load these pre-compiled artifacts, without carrying the compiler SDK, improving runtime stability and security.
4. Build Flexibility: It would allow users of the core library to choose their preferred shader compilation toolchain, rather than being limited to the Slang compiler.

I hope you'll consider this suggestion. If needed, I'm also willing to assist with the initial refactoring work and submit a pull request (PR). Thank you for creating such an excellent library!

Use Case

Zenith.NET --> Zenith.NET(RHI)+Zenith.NET.Shader
Engine ->Zenith.NET(RHI)
Editor->Zenith.NET.Shader(tool)

Additional context

No response

[qian-o]

Thanks for the thoughtful proposal and for offering to help.

In earlier versions of Zenith.NET, the Slang compiler was indeed provided as an optional extension. At that time, the runtime imposed very few assumptions on the shader language or compilation toolchain, and it still used a traditional slot-based resource-binding model.

The architecture has since changed intentionally. Zenith.NET's bindless resource model relies on Slang's DescriptorHandle<T>, so its shader resource layout and ABI are deliberately aligned with Slang. Making the core shader contract compiler-agnostic, or treating shader toolchains as freely interchangeable, is therefore not a current design goal unless another toolchain can reproduce the same contract exactly.

This integration is deliberate. One of Zenith.NET's goals is to provide a consistent shader-authoring model across DirectX 12, Vulkan, and Metal. Users, especially newcomers, should not need to maintain separate HLSL, GLSL/SPIR-V, and Metal shader implementations or learn each backend's binding conventions before they can render something.

That said, I agree with an important part of your proposal: the shader/ABI contract and compiler packaging are separate concerns. Using Slang as the canonical shader language and ABI does not necessarily mean that final applications must ship the Slang compiler and its native libraries. Build-time or offline compilation, together with loading precompiled shader artifacts at runtime, is worth exploring.

A separate tooling or build package could be one possible solution, but I would like to evaluate the package and API boundaries before committing to a Zenith.NET.Shader split. The integrated Slang workflow should remain the default development experience, while release applications that only consume precompiled shaders could potentially avoid the compiler dependency.

I will keep this issue open as an enhancement while we investigate that direction. Before starting a refactoring PR, I think we should first define the expected precompiled-shader workflow and the boundary between build-time tooling and runtime loading.

Thanks again for raising this.