Iris Shaders

What happened?

When i look at anyone's/my own player shadow it drops my FPS more than half, but whenever i stop looking at my player shadow FPS goes back to normal (It happens on every single shaderpack i try).

Screenshots

Log output

No response

Minecraft Version

1.19

Iris Version

iris-mc1.19.1-1.2.6.jar

Operating System

Windows 10

What is your GPU?

Nvidia GTX 1650 Super

Additional context

No response

The performance difference is actually just caused by looking away from the sun. Iris's Advanced Shadow Frustum Culling is most effective when you're looking towards the sun, but it can only cull very little when you are looking in the exact opposite direction of the sun (ie, your own shadow) due to how it works. There's not really a bug here, just a limitation of the current shadow culling methods.

In the future there might be ways to overcome this, however.

Technical information on how the algorithm works can be found here:

Iris/src/main/java/net/coderbot/iris/shadows/frustum/advanced/AdvancedShadowCullingFrustum.java

Lines 11 to 30 in 1a5e5e6

    
           /** 
        
            * A Frustum implementation that derives a tightly-fitted shadow pass frustum based on the player's camera frustum and 
        
            * an assumption that the shadow map will only be sampled for the purposes of direct shadow casting, volumetric lighting, 
        
            * and similar effects, but notably not sun-bounce GI or similar effects. 
        
            * 
        
            * <p>The key idea of this algorithm is that if you are looking at the sun, something behind you cannot directly cast 
        
            * a shadow on things visible to you. It's clear why this wouldn't work for sun-bounce GI, since with sun-bounce GI an 
        
            * object behind you could cause light to bounce on to things visible to you.</p> 
        
            * 
        
            * <p>Derived from L. Spiro's clever algorithm & helpful diagrams described in a two-part blog tutorial:</p> 
        
            * 
        
            * <ul> 
        
            * <li><a href="http://lspiroengine.com/?p=153">Tutorial: Tightly Culling Shadow Casters for Directional Lights (Part 1)</a></li> 
        
            * <li><a href="http://lspiroengine.com/?p=187">Tutorial: Tightly Culling Shadow Casters for Directional Lights (Part 2)</a></li> 
        
            * </ul> 
        
            * 
        
            * <p>Notable changes include switching out some of the sub-algorithms for computing the "extruded" edge planes to ones that 
        
            * are not sensitive to the specific internal ordering of planes and corners, in order to avoid potential bugs at the 
        
            * cost of slightly more computations.</p> 
        
            */

The key idea of this algorithm is that if you are looking at the sun, something behind you cannot directly cast a shadow on things visible to you.

	/**
	* A Frustum implementation that derives a tightly-fitted shadow pass frustum based on the player's camera frustum and
	* an assumption that the shadow map will only be sampled for the purposes of direct shadow casting, volumetric lighting,
	* and similar effects, but notably not sun-bounce GI or similar effects.
	*
	* <p>The key idea of this algorithm is that if you are looking at the sun, something behind you cannot directly cast
	* a shadow on things visible to you. It's clear why this wouldn't work for sun-bounce GI, since with sun-bounce GI an
	* object behind you could cause light to bounce on to things visible to you.</p>
	*
	* <p>Derived from L. Spiro's clever algorithm & helpful diagrams described in a two-part blog tutorial:</p>
	*
	* <ul>
	* <li><a href="http://lspiroengine.com/?p=153">Tutorial: Tightly Culling Shadow Casters for Directional Lights (Part 1)</a></li>
	* <li><a href="http://lspiroengine.com/?p=187">Tutorial: Tightly Culling Shadow Casters for Directional Lights (Part 2)</a></li>
	* </ul>
	*
	* <p>Notable changes include switching out some of the sub-algorithms for computing the "extruded" edge planes to ones that
	* are not sensitive to the specific internal ordering of planes and corners, in order to avoid potential bugs at the
	* cost of slightly more computations.</p>
	*/

Share to