make material draw functions instance independent

[ecoskey]

Objective

#19667 introduced a type-erased material system that effectively puts all material instances through a single cache: during asset preparation (ErasedRenderAssetPlugin), materials are processed into a set of MaterialProperties that contains all the data needed to render them, and these are all cached and deduplicated as needed.

This allows for maximal flexibility (every single material instance could have a different ""type"") but complicates the logic and makes cache keys really big. So, one goal for the material revamp I have (and I think @tychedelia is on board) is to cache materials at two levels: material "types" and material "instances", where material types roughly map to the rust types that currently implement Material. Without getting into implementation details, storing mostly static data separate from instance data would let us simplify a lot of the logic, while only requiring a little more work for fully-dynamic use cases.

This PR is a first step in that direction, which stores all the available draw functions in MaterialProperties, and pushes the decision for "what draw function should I use for this material?" to queue time, where before it was split between there and asset preparation. This makes the list of available draw functions instance-independent, and will later allow us to store it with other "static" material data.

Solution

• Make draw function labels 1:1 with render phases, and include all of them in the list in MaterialProperties

Testing

• Ran 3d_scene
• Ran manual_material

[alice-i-cecile]

Also needs a migration guide :)

[alice-i-cecile]

I don't see any obvious problems, but this is beyond my current rendering expertise so I can't leave a full approval.

addressed

[alice-i-cecile]

@ecoskey can you edit the PR description to make the motivation more clear? I'm mostly content to merge this (especially with IceSentry's approval), but "why are we doing this" isn't immediately apparent to me (skill issue, I know :p), and I think that future readers will benefit from a more detailed log.

[superdump]

I don't suppose this has any impact on benchmarks?

[ecoskey]

I don't suppose this has any impact on benchmarks?

I doubt it, since the code paths (in queue_ etc) are nearly identical. I can still check though if you'd like to be sure?

[tychedelia]

I'm fine with making things more flexible, especially because this will make it easier to add custom queue logic / phase items in the future, but am not totally sure how this relates to the stated goal of making draw functions instance independent?

Also note that the claim in the PR that material properties inflates the cache key size isn't correct. This is what the material_key field on material properties is for.

I'm still not totally convinced that denormalization is actually a problem, but this is totally a good incremental change regardless.

[ecoskey]

Oops sorry for the misinfo! I think I could have phrased that better as "we have to reconstruct the specializer metadata for each instance"

I'm not sure what you mean by denormalization, but the main idea here is to not narrow down the set of available draw functions at asset-prep time. Then, the list should only depend on info from the type and not instance-specific data, so we can store it independently later.