Move the construction of LightingInput in apply_pbr_lighting into its own function.

[13ros27]

Objective

Reduce duplication in the bevy_pbr shaders by using a function to create LightingInput from PbrInput which can then be shared between apply_pbr_lighting and ssr::fragment.

Solution

I created a function pbr_input_to_lighting_input in pbr_lighting to do this (lighting seemed the most logical place for it as that is where LightingInput lives and in a higher level language this would be a constructor). This also required moving calculate_F0 and calculate_diffuse_color into pbr_lighting to prevent a circular dependency (infinite load during shader compilation), this makes sense for calculate_F0 as this is now the only thing that uses it but calculate_diffuse_color does still have another user file.

Questions for reviewers

• Should pbr_input_to_lighting_input instead accept a ptr to PbrInput, I don't feel like I have a sufficient grasp of shader optimisers to know whether this is better (or if we can trust this should always be inlined)?
• Should it instead live in pbr_functions which has the advantage of making this a non-breaking change (because no functions would have to move) but separates a constructor from its struct definition?

Testing

I ran ssr and anisotropy and checked them for visual issues/crashes and ran as much CI as I could before running out of disk space. I tried to test clearcoat but that example is broken for me (#18104)

Migration Guide

Shader function changes:

• calculate_diffuse_color and calculate_F0 have been moved from bevy_pbr::pbr_functions to bevy_pbr::lighting.

[IceSentry]

I'm generally in favor of this change, but have you ran it through a gpu profiler? Using more functions can increase register pressure and lead to bad performance.

[JMS55]

(Modern drivers tend to use LLVM and will inline functions, but not always, and this is very perf-sensitive code)