# \`varying\` cause shader error when shadow is enabled in WebGPU

**URL:** <https://forum.babylonjs.com/t/varying-cause-shader-error-when-shadow-is-enabled-in-webgpu/46396>\
**Category:** Questions\
**Tags:** webgpu, shadowgenerator, pbrcustommaterial\
**Created:** [December 13, 2023, 3:55pm UTC](https://forum.babylonjs.com/t/varying-cause-shader-error-when-shadow-is-enabled-in-webgpu/46396 "2023-12-13T15:55:10Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![slin](https://sea2.discourse-cdn.com/flex024/user_avatar/forum.babylonjs.com/slin/32/36084_2.png) [@slin](https://forum.babylonjs.com/u/slin)\
**Post date:** [December 13, 2023, 3:55pm UTC](https://forum.babylonjs.com/t/varying-cause-shader-error-when-shadow-is-enabled-in-webgpu/46396/1 "2023-12-13T15:55:10Z")

</div>

Dear BJS team,

I wish you a happy holiday. 🥰

I am able to reproduce my issue in a PG. It looks like a bug in BJS code. First this PG works fine with WebGL engine: [https://playground.babylonjs.com/#KY0N7T#29](https://playground.babylonjs.com/#KY0N7T#29)

But failed in WebGPU engine: [https://playground.babylonjs.com?webgpu#KY0N7T#29](https://playground.babylonjs.com?webgpu#KY0N7T#29)

If you remove lines 70-75, the PG should work again. The problem is these internally computed values that pass from vertex shader to fragment shader are tagged with `location (<#>)` with a number \> 15.

It would also work if you comment out addShadowCaster at line 46 and 50. It seems enabling shadow triggers `location` tag added to the varying. And then the location number is increased in a way that exceeds the underlying system limit.

**Update:** lines 70-75 need to be deleted to make it work again. If you comment out them, the error still occurs.

---

<div class="post-metadata">

**Author:** ![sebavan](https://sea2.discourse-cdn.com/flex024/user_avatar/forum.babylonjs.com/sebavan/32/57_2.png) [@sebavan](https://forum.babylonjs.com/u/sebavan)\
**Post date:** [December 13, 2023, 6:06pm UTC](https://forum.babylonjs.com/t/varying-cause-shader-error-when-shadow-is-enabled-in-webgpu/46396/2 "2023-12-13T18:06:22Z")

</div>

probably exceeding limits cc @Evgeni_Popov

---

<div class="post-metadata">

**Author:** ![Evgeni\_Popov](https://sea2.discourse-cdn.com/flex024/user_avatar/forum.babylonjs.com/evgeni_popov/32/4432_2.png) [@Evgeni\_Popov](https://forum.babylonjs.com/u/Evgeni_Popov)\
**Post date:** [December 13, 2023, 6:12pm UTC](https://forum.babylonjs.com/t/varying-cause-shader-error-when-shadow-is-enabled-in-webgpu/46396/3 "2023-12-13T18:12:41Z")

</div>

Yes, the number of varying is not very high in WebGPU at the time. It has been raised in Chrome Canary (122.0.6182.0), so the PG works in Canary (I don’t know when this will be available in Chrome retail, though).

---

<div class="post-metadata">

**Author:** ![slin](https://sea2.discourse-cdn.com/flex024/user_avatar/forum.babylonjs.com/slin/32/36084_2.png) [@slin](https://forum.babylonjs.com/u/slin)\
**Post date:** [December 13, 2023, 7:22pm UTC](https://forum.babylonjs.com/t/varying-cause-shader-error-when-shadow-is-enabled-in-webgpu/46396/4 "2023-12-13T19:22:58Z")

</div>

Thanks @Evgeni_Popov ,

The initial PG works in canary. But my project still fails for the same error. Also, if I increase the number of varying declaration in the PG to 17, it will still fail in canary.

Does it work if I combine multiple float type varying to a vec4 varying?

---

<div class="post-metadata">

**Author:** ![Evgeni\_Popov](https://sea2.discourse-cdn.com/flex024/user_avatar/forum.babylonjs.com/evgeni_popov/32/4432_2.png) [@Evgeni\_Popov](https://forum.babylonjs.com/u/Evgeni_Popov)\
**Post date:** [December 13, 2023, 7:56pm UTC](https://forum.babylonjs.com/t/varying-cause-shader-error-when-shadow-is-enabled-in-webgpu/46396/5 "2023-12-13T19:56:04Z")

</div>

It should help packing 4 varyings into a single one, yes.

There are two limits, one for the number of varying, and one for the total number of components (floats) you can pass through varyings, but I think you hit the first limit right now.

On my computer, in Chrome:  
 ![image](https://us1.discourse-cdn.com/flex024/uploads/babylonjs/original/3X/d/f/df97fb069de128b60776fcc7a7e668cc96d80a71.png)

In Canary:  
 ![image](https://us1.discourse-cdn.com/flex024/uploads/babylonjs/original/3X/b/d/bddfd1d2c228db423cfc0a2e87b5b7fee2973fd0.png)

---

<div class="post-metadata">

**Author:** ![slin](https://sea2.discourse-cdn.com/flex024/user_avatar/forum.babylonjs.com/slin/32/36084_2.png) [@slin](https://forum.babylonjs.com/u/slin)\
**Post date:** [December 14, 2023, 4:59am UTC](https://forum.babylonjs.com/t/varying-cause-shader-error-when-shadow-is-enabled-in-webgpu/46396/6 "2023-12-14T04:59:38Z")

</div>

Thanks @Evgeni_Popov

The problem is solved after combining 4 float varyings to a single vec4. It even worked in regular chrome. So I didn’t further optimize. I actually did the same before. It didn’t work because I left the 4 float varyings as comments. I guess BJS preprocess still picked the commented varyings?

What is this limitation you mentioned? `one for the total number of components (floats)`, is it the same as varyings but flatten to total number of floats?

---

<div class="post-metadata">

**Author:** ![Evgeni\_Popov](https://sea2.discourse-cdn.com/flex024/user_avatar/forum.babylonjs.com/evgeni_popov/32/4432_2.png) [@Evgeni\_Popov](https://forum.babylonjs.com/u/Evgeni_Popov)\
**Post date:** [December 14, 2023, 10:04am UTC](https://forum.babylonjs.com/t/varying-cause-shader-error-when-shadow-is-enabled-in-webgpu/46396/7 "2023-12-14T10:04:30Z")

</div>

> [@slin](#):
>
> I guess BJS preprocess still picked the commented varyings?

Yes, we have a simple parser, so we don’t account for comments (maybe `//` would work - not sure, but I’m sure `/* ... */` would not).

> [@slin](#):
>
> What is this limitation you mentioned? `one for the total number of components (floats)`, is it the same as varyings but flatten to total number of floats?

Yes, it is the total number of components (float, bool, int) you can pass through varyings. A `vec4` count for 4, for eg (as well as `ivec4`).
