If an active shader entrypoint is removed during runtime, PipelineCache attempts to use out-of-date shader information and panics.
This doesn't occur if the affected shader asset is removed before the render phase, as PipelineCache responds to asset removal events before trying to build.
Now material reloading has been refactored to use an incrementing pipeline key, it may be viable to temporarily remove shaders on change, then re-add them once the material has respecialized around the default setup.
The main issue is that the removal code would be triggered by a shader create / modify event, which would later be emitted by the re-adding code, thus causing a loop. Need to think on this and see if there's a robust way to selectively ignore events.
If an active shader entrypoint is removed during runtime, PipelineCache attempts to use out-of-date shader information and panics.
This doesn't occur if the affected shader asset is removed before the render phase, as PipelineCache responds to asset removal events before trying to build.
Now material reloading has been refactored to use an incrementing pipeline key, it may be viable to temporarily remove shaders on change, then re-add them once the material has respecialized around the default setup.
The main issue is that the removal code would be triggered by a shader create / modify event, which would later be emitted by the re-adding code, thus causing a loop. Need to think on this and see if there's a robust way to selectively ignore events.