Additional light shadowmap

2025-09-02 16:17 UTC gpt-5-thinking Open in ChatGPT ↗

how can i choose arbitrary ligths’s shadowmap instead of the main light?

void MainLight_float(float3 WorldPos, out float3 Direction, out float3 Color, out float DistanceAtten, out float ShadowAtten) { #if SHADERGRAPH_PREVIEW Direction = float3(0.5, 0.5, 0); Color = 1; DistanceAtten = 1; ShadowAtten = 1; #else #if SHADOWS_SCREEN float4 clipPos = TransformWorldToHClip(WorldPos); float4 shadowCoord = ComputeScreenPos(clipPos); #else float4 shadowCoord = TransformWorldToShadowCoord(WorldPos); #endif Light mainLight = GetMainLight(shadowCoord); Direction = mainLight.direction; Color = mainLight.color; DistanceAtten = mainLight.distanceAttenuation; ShadowSamplingData shadowSamplingData = GetMainLightShadowSamplingData(); float shadowStrength = GetMainLightShadowStrength(); ShadowAtten = SampleShadowmap(shadowCoord, TEXTURE2D_ARGS(_MainLightShadowmapTexture, sampler_MainLightShadowmapTexture), shadowSamplingData, shadowStrength, false); #endif }

Short answer: don’t try to sample _MainLightShadowmapTexture for non-main lights. In URP, additional lights have their own shadow atlas and helper functions. Use GetAdditionalLight(...) for the light data and AdditionalLightRealtimeShadow(...) for its shadow term.

Here’s a drop-in Custom Function you can use from Shader Graph (URP). It lets you pick an additional light by index and returns its direction/color/attenuations + shadow:

// Works with URP (ShaderLibrary/Lighting.hlsl)

#include "Packages/com.unity.render-pipelines.universal/ShaderLibrary/Lighting.hlsl"

void AdditionalLight_float(
    float3 WorldPos,
    int LightIndex,                     // 0..GetAdditionalLightsCount()-1
    out float3 Direction,
    out float3 Color,
    out float  DistanceAtten,
    out float  ShadowAtten)
{
#if defined(SHADERGRAPH_PREVIEW)
    Direction     = normalize(float3(0.5, 0.5, 0.0));
    Color         = 1.0.xxx;
    DistanceAtten = 1.0;
    ShadowAtten   = 1.0;
#else
    // Default fallbacks
    Direction     = 0;
    Color         = 0;
    DistanceAtten = 0;
    ShadowAtten   = 1.0;

    // Clamp the index to the valid additional-lights range.
    // (The main light is NOT included here.)
    uint addCount = GetAdditionalLightsCount();
    if (addCount == 0) return;

    uint i = (uint)clamp(LightIndex, 0, (int)addCount - 1);

    // Fetch the light (direction, color, distance attenuation, etc.)
    Light L = GetAdditionalLight(i, WorldPos);
    Direction     = L.direction;
    Color         = L.color;
    DistanceAtten = L.distanceAttenuation;

    // Per-light shadow term (atlas-sampled). This already accounts for
    // caster/receiver settings, bias, softness, etc.
#if defined(_ADDITIONAL_LIGHT_SHADOWS)
    ShadowAtten = AdditionalLightRealtimeShadow(i, WorldPos);
#else
    ShadowAtten = 1.0;
#endif
#endif
}

How to use it (Shader Graph)

Add a Custom Function node.
Point it to AdditionalLight.hlsl, function name AdditionalLight_float.
Inputs: WorldPos (connect Position (World) from a Position node), LightIndex (make a property or constant).
Outputs: Direction / Color / DistanceAtten / ShadowAtten. Multiply your lighting by ShadowAtten.

Notes & gotchas

Main vs additional lights: SHADOWS_SCREEN (screen-space shadows) only applies to the main light. Additional lights always use the shadow atlas. So don’t try TransformWorldToShadowCoord + _MainLightShadowmapTexture for additional lights; use AdditionalLightRealtimeShadow(...).
Which light is “index 0”? It’s the first additional light URP picked for the object this frame (after the main light). The set/order can change per object and frame based on URP’s “Per-Object Limit” and sorting. If you need a specific scene light, pass its current additional light index from C# (see below).
Make sure shadows are enabled: In your URP Asset and on the Light: “Additional Lights” → Per Pixel and Cast Shadows must be on, and “Additional Lights Shadow Resolution” high enough.
Performance: Sampling additional-light shadows is more expensive; keep the per-object additional light count modest.

(Optional) getting a specific light’s index from C#

If you need to target a named Light (e.g., “KeyLight”) reliably, determine its additional light index that URP assigned for the current renderer, then push that to the material:

// Example idea (URP):
// During rendering or before drawing your object, find the index of your Light
// in UniversalRenderPipeline.lightData (or via a ScriptableRenderPass)
// and set a material int property _TargetAdditionalLightIndex.

material.SetInt("_TargetAdditionalLightIndex", index);

Then feed that property into LightIndex in Shader Graph.

This approach is the supported way in URP—don’t manually sample _AdditionalLightsShadowmapTexture; the built-ins (GetAdditionalLight, AdditionalLightRealtimeShadow) handle all the matrix/indexing/bias details correctly.

Short answer: yes, but not the same way as URP.
HDRP doesn’t expose a “Custom Lighting” master in Shader Graph. If you want your own BRDF or light evaluation you have to do it with HLSL + HDRP includes, or via Custom Passes. That’s why you won’t find a URP-style tutorial—HDRP’s path is different.

Your options (what’s actually supported)

Write a real HDRP material shader (HLSL)

This is how you add a custom lighting model that participates in HDRP’s forward/deferred lighting, shadows, decals, light layers, etc.
You structure your shader like HDRP’s built-in Lit family (GBuffer/Forward/DepthOnly/ShadowCaster/MotionVectors/Meta passes) and use the HDRP include files (SurfaceData/BSDFData/BuiltinData) to plug into the pipeline’s light loop. It’s “heavyweight,” but it’s the correct way to get full integration. Unity’s docs/forums are up-front that this is complex, but it’s the supported route. citeturn2search6turn2search8

Use an HDRP Custom Pass (Full Screen or Renderers)

Great for stylized/NPR or experimental lighting that you’re OK doing in screen space or on a separate draw. You can inject your HLSL at defined points, read depth/normals/color buffers, and compute your own lighting/post-lighting effects.
Start here: Custom Pass docs and the “Create → Shader → HDRP → Custom FullScreen Pass / Custom Renderers Pass” workflow. Also see the official note about building surface/builtin data from a Custom Renderers Pass shader. For practical samples, check the HDRP Custom Passes repo. citeturn0search9turn2search0turn0search25

Shader Graph “Unlit” + your own math (forward only)

You can fake lighting inside an Unlit graph with Custom Function nodes, but you won’t get HDRP’s proper light loop, GI, or deferred path. This is fine for simple toon/MatCap looks, but it’s not “true” HDRP lighting. Unity’s own guidance and community threads call out that HDRP SG does not expose custom lighting models. citeturn1search2turn2search16

When to choose which

Need full engine features (deferred, shadows, probes, decals, light layers): write an HDRP HLSL material (#1).
Need a stylized pass, outline, rim, or experimental light treatment: do a Custom Pass (#2).
Quick stylized look and you don’t need GI or multi-light correctness: an Unlit Graph with custom math (#3).

Handy links (good starting points)

Custom Pass docs: creation flow, injection points, buffer access. citeturn0search9turn0search1
Forward vs Deferred in HDRP: understand what you’re opting into. citeturn0search12
Examples: HDRP Custom Passes (by an HDRP dev) with many working samples. citeturn0search25
Community reality-check: custom lighting in HDRP is possible, but complex—expect to write HLSL and follow HDRP’s shader structure. citeturn2search2

If you tell me which effect you’re after (toon, wrap, stylized specular, SDF rim, etc.), I can sketch the concrete path (Custom Pass vs full material) and give you a minimal shader skeleton to start from.

Yep—use screen-space derivatives.

The “fwidth” equivalent in Shader Graph

Shader Graph doesn’t (always) ship a dedicated FWidth node, but you can build it exactly with:

fwidth(x) = abs(DDX(x)) + abs(DDY(x))

So: add DDX and DDY nodes, Abs both, then Add them. (Those derivative nodes are fragment-only, just like fwidth.) citeturn0search3

Drop-in anti-alias step (“aastep”) for crisp edges/lines

Make a tiny Sub Graph:

Inputs: Edge (float), X (float)
Nodes:

w = abs(DDX(X)) + abs(DDY(X))
Output AA = smoothstep(Edge - w, Edge + w, X)

This reproduces the classic aastep. Use it anywhere you’d normally do a hard step. (Same trick as the well-known AA alpha test / A2C approach.) citeturn0search26

Anti-aliased line mask (usable for grids/stripes)

If you have a distance d from the line center and want half-thickness t:

w     = abs(DDX(d)) + abs(DDY(d))
alpha = 1 - smoothstep(t - w, t + w, d)

For a vertical UV line at u = u0:

d = abs(UV.x - u0)
then compute w from d as above and feed into smoothstep.

This is the standard way people fix aliasing on grid shaders / hard borders. citeturn0search6turn0search2

When thickness must be in screen pixels

If you want the line to stay ~N pixels wide regardless of scale, work in screen space:

Use Screen Position (or multiply normalized UV by screen width/height) to get pixel units,
Build d in pixel space, then the same aastep logic applies. (DDX/DDY already give you screen-space gradients, which is why this works from any mapping.) citeturn0search23

Alternative helpers

Custom Function node: you can paste a tiny HLSL helper if you prefer:
```
inline float AAStep(float edge, float x)
{
    float w = fwidth(x);
    return smoothstep(edge - w, edge + w, x);
}
```
Then call it from a Custom Function node. citeturn1search9
Alpha-to-Coverage (MSAA): for cutout lines, enabling A2C + the fwidth remap can further smooth edges on MSAA targets. citeturn0search26
Sample subgraphs: Unity ships sample Shader Graph subgraphs for anti-aliased SDF edges—handy reference for how they do the derivative falloff. citeturn0search16

TL;DR: build fwidth with DDX+DDY, and replace hard steps with a smoothstep widened by that fwidth. That’s the go-to workaround for aliasing on lines in Shader Graph.