More fully type erase all pbr types from specialization

[tychedelia]

We remove the M: Material trait bound in #19667, however we still had an implicit dependency on pbr via MeshPipelineKey and the concrete specializer type that prevents other rendering paths (i.e. 2d) from using our specialization infrastructure.

Here we more completely erase pbr specifics in MaterialProperties by the following pattern:

• Make specialize_* a world exclusive system.
• Have an even higher level erased specialization thunk than just the user specializer that accepts &mut World and can look up it's own specializer.

I think there's more opportunity here to make this more ECS-y in the future by using entities to reference the specializer or something similar. But that's an exercise left for later once we work out what additional refactors may be needed to get 2d to work.

Tested a few scenes to confirm things still work.

[atlv24]

This is not sound:

let me_peek_uninit_bytes = format!(
    "{:?}",
    ErasedMeshPipelineKey::new(MaybeUninit::<u64>::uninit())
);

miri says:

error: Undefined Behavior: calling a function with calling convention "Rust" using calling convention "C"
  |
  = note: Undefined Behavior occurred here
  = note: (no span available)
  = help: this indicates a bug in the program: it performed an invalid operation, and caused Undefined Behavior
  = help: see https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html for further information
  = note: BACKTRACE:

We either need more bounds on T, or make this type not pub, or to have useless Debug and no Hash/PartialEq impls. (PartialEq and Hash are also unsound by this same principle)

As far as i know, theres no trait that enforces T to actually be all init: MaybeUninit::uninit() is an init value, because MaybeUninit doesnt have to have init bytes to be init. Theres also padding issues to account for.

This is also UB:

ErasedMeshPipelineKey::new(0u64).downcast::<&u64>();

(I dont know why, but miri doesnt hit the type_id assert, it just hits UB)

Here's a fix to make it safe and sound: tychedelia#5

[tychedelia]

Okay yeah, thanks for checking this. The From impl makes more sense anyway. Tbh this probably could be dyn Any just for maximal flexibility as we only hit it on the slow path. We'd just have to do the same vtable shenanigans that we do for the user key.

[github-actions]

Your PR caused a change in the graphical output of an example or rendering test. This might be intentional, but it could also mean that something broke!
You can review it at https://pixel-eagle.com/project/B04F67C0-C054-4A6F-92EC-F599FEC2FD1D?filter=PR-22408

If it's expected, please add the M-Deliberate-Rendering-Change label.

If this change seems unrelated to your PR, you can consider updating your PR to target the latest main branch, either by rebasing or merging main into it.

[atlv24]

Fixes CI and pixel eagle: tychedelia#6

[atlv24]

this is exactly what i wanted but couldnt figure out how to make the implementation work yay

[atlv24]

this is so much nicer extracted into a sys param

[atlv24]

perfect

[atlv24]

Lets try to keep this Default, can we make base_specialize: Option<BaseSpecializeFn>?

[Zeophlite]

My PR against this is a nit, approved with or without it

[atlv24]

Benchmarked against main with cargo run --example many_cubes --release -- --animate-materials --vary-material-data-per-instance --material-texture-count 500 --mesh-count 500 and performance is unaffected

[mockersf]

#22537 is likely caused by this PR